[RFC] musb: removing otg protocol support

[Bin Liu <b-liu@ti.com>]

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.

> watch out you don't break someone's stuff and get told about it in 2
> years :(

My plan is to take two steps if we decided we can delete it.

First use the patch I copied in my first email to disable OTG protocols
support and wait for 2~3 quarters, we can simply revert it back if we
got yelled for any breakage ;)

Then *gradually* cleaning out any HNP/SRP related code through several
kernel versions (I don't think I have that much time to clean up all OTG
code within one kernel version anyway.)

If we break anyone in the second step, we can handle it as for any
typical regression, shouldn't be an issue.

Regards,
-Bin.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html