On 03/08/2013 12:08 AM, Felipe Balbi wrote: > On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren wrote: >> On 03/07/2013 08:45 AM, Felipe Balbi wrote: >>> this will make sure that we have sensible names for all phy >>> drivers. Current situation was already quite bad with too >>> generic names being used. >> >> Is phy-$name specific enough? There are other types of PHY such >> as Ethernet, etc. What about phy-usb-$name? > > we will be creating a generic (kernel-wide) phy layer, so I guess > that matters very little. Specially since we don't want to be > differentiating PHYs by their subsystem and rather by the IP name > (which means phy-tegra, phy-samsung, phy-omap, are all 'wrong', but > there were no better names). On other thought here: The Tegra PHY in question here very specifically is a USB PHY. There's no way it could be used as e.g. a SATA PHY, either as a HW block or given the driver code that program is. Is sharing a PHY IP block or driver ever possible for any HW? Hence, I don't think removing "USB" from the filename makes sense, nor even moving it into a generic PHY directory. By the same logic, any code for Tegra30's SATA PHY should also be in phy-tegra.c, but that name would conflict. Naming them phy-tegra-usb.c and phy-tegra-sata.c, or something specific like that, would avoid any issue. And actually, better phy-tegra20-usb.c since Tegra114 has some XHCI support, and I have no idea if the PHY code for that will end up being at all related to the existing Tegra20 code, so we might need a separate phy-tegra114-usb.c down the road. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
