All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: linux@arm.linux.org.uk, tony@atomide.com,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, balbi@ti.com, eballetbo@gmail.com,
	javier@dowhile0.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Date: Tue, 30 Jul 2013 11:15:20 +0300	[thread overview]
Message-ID: <20130730081520.GH16441@radagast> (raw)
In-Reply-To: <51F7752B.8050804@ti.com>


[-- Attachment #1.1: Type: text/plain, Size: 2287 bytes --]

On Tue, Jul 30, 2013 at 01:41:23PM +0530, Kishon Vijay Abraham I wrote:
> On Tuesday 30 July 2013 12:46 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
> >>>>>> the list of controller device (names) it can support (PHY framework does not
> >>>>>> maintain a separate list for binding like how we had in USB PHY library). e.g.
> >>>>>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92817.html. In such
> >>>>>
> >>>>> this has nothing to do with $subject though. We talk about generic PHY
> >>>>> framework once all these PHY drivers are moved there :-)
> >>>>>
> >>>>>> cases how do we pass the device names. Also will the MUSB core device be
> >>>>>> created before twl4030-usb PHY device?
> >>>>>
> >>>>> and why would that be a problem ? We're telling the framework that the
> >>>>> musb device will use a phy with a name of 'twl4030'. If musb calls
> >>>>> usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
> >>>>> try again later.
> >>>>
> >>>> I think we are talking about different problems here ;-) I'm trying to tell
> >>>> using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
> >>>> Generic PHY Framework series depends on this patch series or else MUSB in OMAP3
> >>>> platforms wont work after Generic PHY framework gets merged.
> >>>
> >>> then you just found a limitation in your framework, right ? :-) I mean,
> >>> imagine if now we have to add an IDR to every single user of your
> >>> framework because they could end up in systems with multiple instances
> >>> of the same IP ?
> >>
> >> I raised a similar concern in the PHY framework discussion [1] :-) And since
> >> it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in
> >> PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should
> >> fail IMO.
> >>
> >> [1] -> http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html
> > 
> > look at Greg's and my reply to that email.
> 
> but finally Greg agreed to what Tomasz proposed no?

that's not what I see in the thread. I see Greg agreed to regulator's
own IDs being sequentially created, but he mentions device names can
change.

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: balbi@ti.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Date: Tue, 30 Jul 2013 11:15:20 +0300	[thread overview]
Message-ID: <20130730081520.GH16441@radagast> (raw)
In-Reply-To: <51F7752B.8050804@ti.com>

On Tue, Jul 30, 2013 at 01:41:23PM +0530, Kishon Vijay Abraham I wrote:
> On Tuesday 30 July 2013 12:46 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
> >>>>>> the list of controller device (names) it can support (PHY framework does not
> >>>>>> maintain a separate list for binding like how we had in USB PHY library). e.g.
> >>>>>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg92817.html. In such
> >>>>>
> >>>>> this has nothing to do with $subject though. We talk about generic PHY
> >>>>> framework once all these PHY drivers are moved there :-)
> >>>>>
> >>>>>> cases how do we pass the device names. Also will the MUSB core device be
> >>>>>> created before twl4030-usb PHY device?
> >>>>>
> >>>>> and why would that be a problem ? We're telling the framework that the
> >>>>> musb device will use a phy with a name of 'twl4030'. If musb calls
> >>>>> usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
> >>>>> try again later.
> >>>>
> >>>> I think we are talking about different problems here ;-) I'm trying to tell
> >>>> using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
> >>>> Generic PHY Framework series depends on this patch series or else MUSB in OMAP3
> >>>> platforms wont work after Generic PHY framework gets merged.
> >>>
> >>> then you just found a limitation in your framework, right ? :-) I mean,
> >>> imagine if now we have to add an IDR to every single user of your
> >>> framework because they could end up in systems with multiple instances
> >>> of the same IP ?
> >>
> >> I raised a similar concern in the PHY framework discussion [1] :-) And since
> >> it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in
> >> PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should
> >> fail IMO.
> >>
> >> [1] -> http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html
> > 
> > look at Greg's and my reply to that email.
> 
> but finally Greg agreed to what Tomasz proposed no?

that's not what I see in the thread. I see Greg agreed to regulator's
own IDs being sequentially created, but he mentions device names can
change.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/12cfc057/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: <balbi@ti.com>, <tony@atomide.com>, <linux@arm.linux.org.uk>,
	<eballetbo@gmail.com>, <javier@dowhile0.org>,
	<gregkh@linuxfoundation.org>, <linux-omap@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-usb@vger.kernel.org>
Subject: Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Date: Tue, 30 Jul 2013 11:15:20 +0300	[thread overview]
Message-ID: <20130730081520.GH16441@radagast> (raw)
In-Reply-To: <51F7752B.8050804@ti.com>

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

On Tue, Jul 30, 2013 at 01:41:23PM +0530, Kishon Vijay Abraham I wrote:
> On Tuesday 30 July 2013 12:46 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
> >>>>>> the list of controller device (names) it can support (PHY framework does not
> >>>>>> maintain a separate list for binding like how we had in USB PHY library). e.g.
> >>>>>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92817.html. In such
> >>>>>
> >>>>> this has nothing to do with $subject though. We talk about generic PHY
> >>>>> framework once all these PHY drivers are moved there :-)
> >>>>>
> >>>>>> cases how do we pass the device names. Also will the MUSB core device be
> >>>>>> created before twl4030-usb PHY device?
> >>>>>
> >>>>> and why would that be a problem ? We're telling the framework that the
> >>>>> musb device will use a phy with a name of 'twl4030'. If musb calls
> >>>>> usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
> >>>>> try again later.
> >>>>
> >>>> I think we are talking about different problems here ;-) I'm trying to tell
> >>>> using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
> >>>> Generic PHY Framework series depends on this patch series or else MUSB in OMAP3
> >>>> platforms wont work after Generic PHY framework gets merged.
> >>>
> >>> then you just found a limitation in your framework, right ? :-) I mean,
> >>> imagine if now we have to add an IDR to every single user of your
> >>> framework because they could end up in systems with multiple instances
> >>> of the same IP ?
> >>
> >> I raised a similar concern in the PHY framework discussion [1] :-) And since
> >> it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in
> >> PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should
> >> fail IMO.
> >>
> >> [1] -> http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html
> > 
> > look at Greg's and my reply to that email.
> 
> but finally Greg agreed to what Tomasz proposed no?

that's not what I see in the thread. I see Greg agreed to regulator's
own IDs being sequentially created, but he mentions device names can
change.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-07-30  8:15 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-26  9:03 [PATCH 0/2] usb: fix controller-PHY binding for OMAP3 platform Kishon Vijay Abraham I
2013-07-26  9:03 ` Kishon Vijay Abraham I
2013-07-26  9:03 ` Kishon Vijay Abraham I
2013-07-26  9:03 ` [PATCH 1/2] usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c Kishon Vijay Abraham I
2013-07-26  9:03   ` Kishon Vijay Abraham I
2013-07-26  9:03   ` Kishon Vijay Abraham I
2013-07-26  9:03 ` [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy Kishon Vijay Abraham I
2013-07-26  9:03   ` Kishon Vijay Abraham I
2013-07-26  9:03   ` Kishon Vijay Abraham I
2013-07-29 15:06   ` Felipe Balbi
2013-07-29 15:06     ` Felipe Balbi
2013-07-29 15:06     ` Felipe Balbi
2013-07-29 15:29     ` Kishon Vijay Abraham I
2013-07-29 15:29       ` Kishon Vijay Abraham I
2013-07-29 15:29       ` Kishon Vijay Abraham I
2013-07-29 17:54       ` Felipe Balbi
2013-07-29 17:54         ` Felipe Balbi
2013-07-29 17:54         ` Felipe Balbi
2013-07-30  5:14         ` Kishon Vijay Abraham I
2013-07-30  5:14           ` Kishon Vijay Abraham I
2013-07-30  5:14           ` Kishon Vijay Abraham I
     [not found]           ` <51F74BC8.7020903-l0cyMroinI0@public.gmane.org>
2013-07-30  6:01             ` Felipe Balbi
2013-07-30  6:01               ` Felipe Balbi
2013-07-30  6:01               ` Felipe Balbi
2013-07-30  6:11               ` Kishon Vijay Abraham I
2013-07-30  6:11                 ` Kishon Vijay Abraham I
2013-07-30  6:11                 ` Kishon Vijay Abraham I
2013-07-30  6:18                 ` Felipe Balbi
2013-07-30  6:18                   ` Felipe Balbi
2013-07-30  6:18                   ` Felipe Balbi
2013-07-30  6:25                   ` Kishon Vijay Abraham I
2013-07-30  6:25                     ` Kishon Vijay Abraham I
2013-07-30  6:25                     ` Kishon Vijay Abraham I
2013-07-30  6:28                     ` Felipe Balbi
2013-07-30  6:28                       ` Felipe Balbi
2013-07-30  6:28                       ` Felipe Balbi
2013-07-30  6:46                       ` Kishon Vijay Abraham I
2013-07-30  6:46                         ` Kishon Vijay Abraham I
2013-07-30  6:46                         ` Kishon Vijay Abraham I
2013-07-30  7:16                         ` Felipe Balbi
2013-07-30  7:16                           ` Felipe Balbi
2013-07-30  7:16                           ` Felipe Balbi
2013-07-30  8:11                           ` Kishon Vijay Abraham I
2013-07-30  8:11                             ` Kishon Vijay Abraham I
2013-07-30  8:11                             ` Kishon Vijay Abraham I
2013-07-30  8:15                             ` Felipe Balbi [this message]
2013-07-30  8:15                               ` Felipe Balbi
2013-07-30  8:15                               ` Felipe Balbi
2013-07-30 14:25                               ` Greg KH
2013-07-30 14:25                                 ` Greg KH

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=20130730081520.GH16441@radagast \
    --to=balbi@ti.com \
    --cc=eballetbo@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=javier@dowhile0.org \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=tony@atomide.com \
    /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.