All of lore.kernel.org
 help / color / mirror / Atom feed
From: b-liu@ti.com (Bin Liu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block
Date: Fri, 3 Jun 2016 08:04:54 -0500	[thread overview]
Message-ID: <20160603130454.GA3778@uda0271908> (raw)
In-Reply-To: <88cada17-af4c-9548-e734-351b6695e30f@redhat.com>

Hi,

On Fri, Jun 03, 2016 at 12:34:35PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 02-06-16 20:16, Bin Liu wrote:
> >Hi,
> >
> >On Thu, Jun 02, 2016 at 07:31:03PM +0200, Hans de Goede wrote:
> >>Some SoCs have a single phy-hw-block with multiple phys, this is
> >>modelled by a single phy dts node, so we end up with multiple
> >>controller nodes with a phys property pointing to the phy-node
> >>of the otg-phy.
> >>
> >>Only one of these controllers typically is an otg controller, yet we
> >
> >Is it guaranteed that only one of them will be otg?
> 
> I guess not, but if there are 2 then with my patch we are of no worse
> then today, we will then pick the first otg controller. Whereas

What if the first otg controller is not what we want? this patch does
not solve the problem. I would think Kishon's suggestion in another
email - seperate dt phy nodes - is a better option.

> of_usb_get_dr_mode_by_phy currently is broken even on setups with
> a shared phy dt-node and only 1 otg controller, which are quite
> common.

If that is the case, the model has to be changed. Otherwise, a single
phy driver is unable to handle different operations from multiple
controllers.

Regards,
-Bin.

WARNING: multiple messages have this Message-ID (diff)
From: Bin Liu <b-liu-l0cyMroinI0@public.gmane.org>
To: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>,
	Maxime Ripard
	<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/4] USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block
Date: Fri, 3 Jun 2016 08:04:54 -0500	[thread overview]
Message-ID: <20160603130454.GA3778@uda0271908> (raw)
In-Reply-To: <88cada17-af4c-9548-e734-351b6695e30f-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Hi,

On Fri, Jun 03, 2016 at 12:34:35PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 02-06-16 20:16, Bin Liu wrote:
> >Hi,
> >
> >On Thu, Jun 02, 2016 at 07:31:03PM +0200, Hans de Goede wrote:
> >>Some SoCs have a single phy-hw-block with multiple phys, this is
> >>modelled by a single phy dts node, so we end up with multiple
> >>controller nodes with a phys property pointing to the phy-node
> >>of the otg-phy.
> >>
> >>Only one of these controllers typically is an otg controller, yet we
> >
> >Is it guaranteed that only one of them will be otg?
> 
> I guess not, but if there are 2 then with my patch we are of no worse
> then today, we will then pick the first otg controller. Whereas

What if the first otg controller is not what we want? this patch does
not solve the problem. I would think Kishon's suggestion in another
email - seperate dt phy nodes - is a better option.

> of_usb_get_dr_mode_by_phy currently is broken even on setups with
> a shared phy dt-node and only 1 otg controller, which are quite
> common.

If that is the case, the model has to be changed. Otherwise, a single
phy driver is unable to handle different operations from multiple
controllers.

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

  reply	other threads:[~2016-06-03 13:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-02 17:31 [PATCH 1/4] USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block Hans de Goede
2016-06-02 17:31 ` Hans de Goede
2016-06-02 17:31 ` [PATCH 2/4] phy-sun4i-usb: Add support for peripheral-only mode Hans de Goede
2016-06-02 17:31   ` Hans de Goede
2016-06-02 17:31 ` [PATCH 3/4] phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31 Hans de Goede
2016-06-02 17:31   ` Hans de Goede
2016-06-02 17:31 ` [PATCH 4/4] musb: sunxi: Simplify dr_mode handling Hans de Goede
2016-06-02 17:31   ` Hans de Goede
2016-06-02 18:16 ` [PATCH 1/4] USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block Bin Liu
2016-06-02 18:16   ` Bin Liu
2016-06-03 10:34   ` Hans de Goede
2016-06-03 10:34     ` Hans de Goede
2016-06-03 13:04     ` Bin Liu [this message]
2016-06-03 13:04       ` Bin Liu
2016-06-03 13:09       ` Hans de Goede
2016-06-03 13:09         ` Hans de Goede
2016-06-03 11:20 ` Kishon Vijay Abraham I
2016-06-03 11:20   ` Kishon Vijay Abraham I
2016-06-03 11:39   ` Hans de Goede
2016-06-03 11:39     ` Hans de Goede
2016-06-03 13:12     ` Bin Liu
2016-06-03 13:12       ` Bin Liu
2016-06-03 13:15       ` Hans de Goede
2016-06-03 13:15         ` Hans de Goede

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=20160603130454.GA3778@uda0271908 \
    --to=b-liu@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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.