On Wed, Aug 07, 2013 at 11:08:45AM +0200, Sascha Hauer wrote: > > > > > > - Convert imx-usb-misc from a driver into something which is called > > > directly > > > - add aliases > > > - change devicetree bindings (which causes pain and it's not explained why > > > this is necessary at all) > > > > Yes, I need to split doc from implementation. > > No, you don't. You just have to explain *why* the bindings need to be > chaged. > OK, I will > > > > > - converts the misc stuff to regmap > > > > > > Please split this up so that it can be reviewed. > > > > The changes are all related to convert usbmisc_imx from a driver to something > > which can be called directly. > > > > - usbmisc has #index-cells to indicate controller number, now, it is not > > a driver, we use aliases at controller driver to instead of it. > > Why? > We need to know controller number, like pdev->id in the past. The registers at non core register is messy, the specific bit is for specific controller. > > - When usbmisc_imx is a device, the register maps only one time. > > But ci_hdrc_imx will be several devices, the non-core register > > will be mapped several times, we have to use syscon to visit one register > > region among several devices. > > Converting the imx-usb misc driver to regmap is fine, but I see no > reason to not make this a separate patch. This would make this much > easier to read. You mean delete "reg" entry at usbmisc dts, and using noncore phandle at usbmisc_imx.c as the first patch, then, convert driver as separate file. > > > > Yes, it is not a good practice, but I want to keep ci_hdrc_imx.c > > as clean as possible. The SoC related implementation will be more > > and more in the future after we add more USB functions. > > Just because you want to have the binary code in a single module doesn't > mean the source code has to be in a single C file. > OK, I will do. -- Best Regards, Peter Chen -- 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