Hi Kishon,

On Tue, Mar 31, 2015 at 09:16:40PM +0530, Kishon Vijay Abraham I wrote:

On Tuesday 31 March 2015 09:11 PM, Baruch Siach wrote:

quoted

On Tue, Mar 31, 2015 at 08:56:54PM +0530, Kishon Vijay Abraham I wrote:

quoted

On Tuesday 31 March 2015 05:04 PM, Baruch Siach wrote:

quoted

On Sat, Mar 28, 2015 at 04:33:02PM +0100, Marek Vasut wrote:

quoted

On Friday, March 27, 2015 at 05:36:29 AM, Baruch Siach wrote:

quoted

Add a driver for the USB PHY on the Conexant CX92755 SoC, from the
Digicolor series of SoCs. The PHY is connected to the on-chip chipidea
usb2 host.

The hardware is somewhat similar to the phy-mxs-usb.c usb_phy, but it is
different enough to merit its own driver. Also, this driver uses the
generic phy infrastructure.

the register set looks very similar to MXS one indeed. How is it different
please ?

Almost of the bits that are defined in the MXS USBPHY_CTRL register are not
defined in the Digicolor one. Some have different meaning, and some are
reserved. OTOH, the Digicolor USBPHY_CTRL register uses all bits in the 1-13
range. Also, the Digicolor phy does not have anatop registers.

I think we should try adding support for this in the same driver.

The only code that can actually be shared between the driver is the two lines
usb_phy .on_connect callback routine. The init sequence that takes most of the
digicolor driver is totally different. Using a single driver for both PHYs
does not make much sense, IMHO.

Besides, phy-mxs-usb.c uses the deprecated usb_phy framework. So we first need
to port this driver to the generic phy framework.

Doesn't your driver also use the usb_phy framework?

My driver uses usb_phy only for the .notify_connect/.notify_disconnect 
callbacks, since there is no comparable functionality in the generic phy 
framework. But it doesn't make this driver any more similar to phy-mxs-usb.

My point is that merging the drives would require migrating phy-mxs-usb to 
generic phy. But this is just an added complication. The main reason I think 
the drivers should be separate is because they have very little in common, 
regardless of the framework they are using.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -