On Mon, Mar 19, 2018 at 09:20:23AM -0500, Bin Liu wrote: > On Sun, Mar 18, 2018 at 02:16:25PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Mar 16, 2018 at 02:09:51PM -0500, Bin Liu wrote: > > > Hi, > > > > > > The kernel usb stack and musb drivers have gone through some changes in > > > the past several kernel versions, such as adding otg fsm, musb runtime > > > PM, and musb otg state moving from musb to musb->xceiv... I am wondering > > > if the otg protocol (hnp, srp) functions are already broken in the musb > > > drivers, but I don't have a platform to confirm it. > > > > > > Do we know by any chance there is still someone using the musb otg > > > functions in any relatively newer kernel and we still need to support > > > otg in musb? If not, I am thinking to clean up the otg functions in > > > musb drivers to make the code easy to read and maintain. > > > > By "clean up" do you mean "delete it"? :) > > Yes, delete it to make the driver state machine simpler and use less > flags for recording states. > > > > > I don't know of any real OTG hardware that ever shipped, does anyone > > else? > > > > > If we can make the conclusion to remove it, I propose the patch below > > > to disable musb otg first, then clean up the driver later if nobody > > > complains about the otg function removal. > > > > It will take years for people who make these types of devices to notice > > that OTG is removed, so be careful about this. Refactor away, but > > I personally think we can safely say there wasn't any true OTG products > where were under development in the last several years, but I am more > concerned if there was any such product released in the past, for > example omap24xx/34xx based, but was still actively maintained to the > latest kernel? Then deleting OTG protocol from musb drivers would break > them. Wasn't the BeagleBone devices using that chipset? If not, then you are probably fine. thanks, greg k-h -- 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
