Re: [PATCH] usb: phy: rename all phy drivers to phy-$name.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, Mar 11, 2013 at 01:54:54PM -0600, Stephen Warren wrote:
> > On Mon, Mar 11, 2013 at 11:02:43AM -0600, 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.
> > 
> > alright, so what's the problem of adding new binding without
> > removing old one for v3.10 and remove old on v3.11 ? It gives a 3
> > month grace period for all boards to be converted, at least.
> 
> By binding, I assume you mean the driver code that implements the
> binding, so you want the driver to support both the old and new
> bindings at once? I don't think that's practical in this case.
> 
> Currently the EHCI driver parses a single EHCI DT node, and passes
> some information down to the PHY driver. The PHY driver is in fact
> just a set of functions and not actually any kind of driver.

that's quite wrong :-)

> The patches will split the single EHCI DT node into a separate EHCI
> and PHY DT nodes, convert the PHY driver to an actual (platform)
> driver, move the parsing of the PHY DT node into the new PHY DT
> driver, and remove the parsing of the PHY-related properties from the
> EHCI driver. Supporting both sets of DT content across that transition
> would be rather difficult I think.

ok, now I get the full picture.

> The patches will convert all in-tree boards, and I'm pretty confident
> that there aren't actually any out-of-tree boards for Tegra (that use
> a mainline kernel; there are plenty that don't use DT and are based on
> much older kernels). Hence, I don't see any need for a grace period
> here. Even if there are out-of-tree boards, the conversion of the DT
> content would take about 30 seconds. I'll volunteer to even do it
> (without testing!) for any out-of-tree boards if there are any.

I guess we can't delete this from archives anymore :-p

> One reason that I really care about moving this forward quickly, is
> that you had indicated the driver cleanup was a pre-requisite to
> continuing to extend the code. Right now, the Tegra USB drivers only
> support Tegra20. We'd really like to get Tegra30 and now Tegra114 USB
> support into mainline ASAP.

Alright, now that I have the full picture it makes it a lot easier to
ack patches, thanks. Sorry for somewhat wasting time, please carry on.

-- 
balbi

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux