On Tuesday 15 December 2015 16:44:41 Kishon Vijay Abraham I wrote: > Hi Arnd, > > On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote: > > On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote: > >> This series is basically to deprecate using phy-omap-control and use > >> syscon APIs to program the control module registers. > >> > >> Changes from v2: > >> No changes. > >> > >> Changes from v1: > >> *) cleanup ti_pipe3_probe in multiple steps > >> *) other minor cleanups > >> > >> Changes from [1] in PHY patches include > >> *) cleanup ti_pipe3_probe > >> *) have mask, power_on and power_off values in usb_phy_data for > >> omap-usb2 phy > >> > >> The patches have been pushed to > >> git://git.ti.com/linux-phy/linux-phy.git syscon > >> > >> [1] -> https://lkml.org/lkml/2015/6/23/189 > >> > >> All the testing was done both before applying the dt patches and after > >> applying the dt patches (dt patches will be posted shortly). > >> > > > > Can you explain here what the conversion is good for? Why do you > > prefer the syscon mapping over a high-level driver in this case? > > phy-omap-control driver was added when there was no proper > infrastructure for doing control module initializations. The > phy-omap-control driver is not an 'actual' PHY driver and it > was just a hack to do PHY related control module initializations. > phy-omap-control is also getting unmanageable with the number of > platforms each having number of modules (like USB, SATA, PCIe), > using the same driver for control module initializations. > > Now with SYSCON framework being added to the kernel, phy-omap-control > shouldn't be needed and it also provides a uniform API across all the > modules to program the control module. Ok, so the "phy-control" devices were really just a few registers of a system controller device that does a lot of other things as well, right? Can you put your description above into the cover-letter for the series, and the merge commit? Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
