On 03/11/2013 12:59 AM, Felipe Balbi wrote: > Hi, > > On Fri, Mar 08, 2013 at 10:26:45AM -0700, Stephen Warren wrote: >> 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). >>> >>>> Venu, please comment on what conflicts, if any, this will >>>> cause with the patches you'll be sending to clean up the >>>> Tegra USB/PHY drivers. Thanks. >>> >>> BTW, let's stop with the whole dependency between PHY driver >>> cleanup and arch/arm/mach-tegra/, too many patches have gone >>> upstream bypassing my tree. What we should be doing is figuring >>> out how to remove arch/ dependencies so that patches can go >>> upstream and not cause conflicts. >> >> Unfortunately, there's no way to actually avoid the dependencies >> themselves. The DT bindings and EHCI/PHY controller split are >> wrong, and need work on both the DT and drivers to fix. > > but those changes don't need to come together, right ? I mean, for > the DT part you could add the bindings to driver A without removing > from driver B and span the changes accross 2 merge windows. There is only a single driver. It's being reworked to support the new binding. >> I guess I could apply all the initial DT changes to a topic >> branch in the Tegra tree (item 1 below), and have you merge that >> branch into yours, and then you could take all the USB-related >> patches (item 2 below) through your tree. Would that work >> better? > > I'm not merging, taking everything as patches, sorry. In that case, the Tegra USB driver changes have to go through the Tegra tree this kernel cycle. The only way to avoid this, as you said above, would be to break the patches into n kernel cycles, which will introduce another 2-3 months delay, and I really don't see any point at all in doing that just to avoid a git pull, or taking the patches through the Tegra tree. -- 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
