Re: [RFC PATH 0/3] USB PHYs and PCI

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

 



Hi,

On Mon, Dec 02, 2013 at 04:33:26PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Thursday 28 November 2013 09:29 PM, Heikki Krogerus wrote:
> > Hi guys,
> > 
> > PCI does not give any information about the PHY but we still need to
> > be able to take advantage of any possible vendor specific features,
> > such as custom PM operations, charger detection, ADP probing and
> > sensing, etc. the PHY provides. Since ULPI provides a way to do
> > runtime detection, I'm introducing this layer on top of Kishon's
> > generic phy framework. It gives us means to detect the ULPI product
> > and bind it to a driver without need for nasty platform/device
> > specific quirks in case of ULPI PHYs.
> 
> nice :-) Clearly there's a shortcoming in the current PHY framework to discover
> PHY's behind a pci. Thanks for attempting to solve it.
> 
> But I think it needs a few modification like the ULPI device should be created
> by the glue (dwc3-pci?) and phy create should be done in phy driver. We should
> think of a better way for the controller to find the PHY (lets try and not use
> PHY CONSUMER or device name).

Man I don't see any way to avoid the device name matching. We should
drop the init_data thing so the phy drivers don't need to know about
their users even when using platform data. You should have separate
phy_lookup_add() function for that which, the platform code can call.

I would also add support for matching based on index on top of the
port name. I think it's fare to assume index 0 is always usb2 type. We
could then have phy_get_index() and wrapper like gpiod_get() (phy_get)
that tries to get the phy with index 0, that the usb2 controllers can
use.

Those two changes would make it look exactly like clk framework and
gpiolib are now. The small benefit with those changes is that the phy
drivers and the users, both don't need to know about each other in any
case (DT, platform).

So the device name matching would still be there. Though I'm not sure
if it's such a huge problem to have it. At least the drivers don't
need to care about it.

If you like this idea, I can prepare the patches.

Br,

-- 
heikki
--
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




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

  Powered by Linux