All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Liu <b-liu@ti.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, Felipe Balbi <balbi@kernel.org>,
	Apelete Seketeli <apelete@seketeli.net>,
	Hans de Goede <hdegoede@redhat.com>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: [RFC] musb: removing otg protocol support
Date: Mon, 19 Mar 2018 09:59:23 -0500	[thread overview]
Message-ID: <20180319145923.GR14921@uda0271908> (raw)

On Mon, Mar 19, 2018 at 03:40:48PM +0100, Greg Kroah-Hartman wrote:
> 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

No, BeagleBone uses TI AM335x devices which have two MUSB controllers,
and released in around 2012. And I don't think anyone uses the true OTG
on AM335x, but omap24xx/34xx devices are much older which I don't know
the history...

> probably fine.

Sounds good. I will send a patch in a few weeks to disable OTG in musb
for v3.18-rc1, too late for v4.17 now I think...

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

             reply	other threads:[~2018-03-19 14:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19 14:59 Bin Liu [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-03-19 14:40 [RFC] musb: removing otg protocol support Greg Kroah-Hartman
2018-03-19 14:24 Bin Liu
2018-03-19 14:20 Bin Liu
2018-03-18 16:36 Hans de Goede
2018-03-18 13:16 Greg Kroah-Hartman
2018-03-16 19:09 Bin Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180319145923.GR14921@uda0271908 \
    --to=b-liu@ti.com \
    --cc=apelete@seketeli.net \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.