All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: <linux-omap@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-samsung-soc@vger.kernel.org>,
	Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
Date: Tue, 7 Jan 2014 18:31:52 +0530	[thread overview]
Message-ID: <52CBFAC0.9040103@ti.com> (raw)
In-Reply-To: <20131216144314.GB22944@xps8300>

Hi,

On Monday 16 December 2013 08:13 PM, Heikki Krogerus wrote:
> Hi,
> 
> On Mon, Dec 16, 2013 at 04:34:35PM +0530, Kishon Vijay Abraham I wrote:
>> On Monday 09 December 2013 08:38 PM, Heikki Krogerus wrote:
>>> Provide a complete association for the phy and it's user
>>> (musb) with the new phy_lookup_table.
>>>
>>> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>>> ---
>>>  arch/arm/mach-omap2/twl-common.c | 15 ++++++---------
>>>  1 file changed, 6 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
>>> index b0d54da..972430b 100644
>>> --- a/arch/arm/mach-omap2/twl-common.c
>>> +++ b/arch/arm/mach-omap2/twl-common.c
>>> @@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void)
>>>  }
>>>  
>>>  #if defined(CONFIG_ARCH_OMAP3)
>>> -struct phy_consumer consumers[] = {
>>> -	PHY_CONSUMER("musb-hdrc.0", "usb"),
>>> -};
>>> -
>>> -struct phy_init_data init_data = {
>>> -	.consumers = consumers,
>>> -	.num_consumers = ARRAY_SIZE(consumers),
>>> +static struct phy_lookup_table twl4030_usb_lookup = {
>>> +	.dev_id = "musb-hdrc.0",
>>> +	.table = PHY_LOOKUP("phy-twl4030_usb.0", NULL),
>>>  };
>>
>> had a similar approach during the initial version of phy framework [1] (see
>> phy_bind) but changed it later [2] . Here you should know the device names of
>> two devices and even if one of them started using DEVID_AUTO, it'll start
>> breaking. Such an approach needs to reviewed carefully.
> 
> If somebody creates a regression by changing something like the
> platform device id without checking all the users, he deserves to get
> into big trouble. I don't see why an individual framework should
> provide protection against such cases.
> 
> In any case, having two device names to deal with does not add any
> more risk. These associations should always be made in the place where
> the phy device is created so you will always know it's device name.

huh.. we should also know the 'controller' device name while defining these
associations and in some cases the controller device and phy device are created
in entirely different places.
> Normally the platform code creates these associations in the same
> place it creates the platform devices, so you definitely know what the
> device names will be.
> 
> In this case it's actually created in drivers/mfd/twl-core.c, so I do
> need to update this and move the lookup table there. We can still
> deliver the user name as platform data, though I believe it's always
> "musb". Maybe we could actually skip that and just hard code the name?

I would rather leave the way it is modelled now.

Thanks
Kishon

WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
Date: Tue, 7 Jan 2014 18:31:52 +0530	[thread overview]
Message-ID: <52CBFAC0.9040103@ti.com> (raw)
In-Reply-To: <20131216144314.GB22944@xps8300>

Hi,

On Monday 16 December 2013 08:13 PM, Heikki Krogerus wrote:
> Hi,
> 
> On Mon, Dec 16, 2013 at 04:34:35PM +0530, Kishon Vijay Abraham I wrote:
>> On Monday 09 December 2013 08:38 PM, Heikki Krogerus wrote:
>>> Provide a complete association for the phy and it's user
>>> (musb) with the new phy_lookup_table.
>>>
>>> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>>> ---
>>>  arch/arm/mach-omap2/twl-common.c | 15 ++++++---------
>>>  1 file changed, 6 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
>>> index b0d54da..972430b 100644
>>> --- a/arch/arm/mach-omap2/twl-common.c
>>> +++ b/arch/arm/mach-omap2/twl-common.c
>>> @@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void)
>>>  }
>>>  
>>>  #if defined(CONFIG_ARCH_OMAP3)
>>> -struct phy_consumer consumers[] = {
>>> -	PHY_CONSUMER("musb-hdrc.0", "usb"),
>>> -};
>>> -
>>> -struct phy_init_data init_data = {
>>> -	.consumers = consumers,
>>> -	.num_consumers = ARRAY_SIZE(consumers),
>>> +static struct phy_lookup_table twl4030_usb_lookup = {
>>> +	.dev_id = "musb-hdrc.0",
>>> +	.table = PHY_LOOKUP("phy-twl4030_usb.0", NULL),
>>>  };
>>
>> had a similar approach during the initial version of phy framework [1] (see
>> phy_bind) but changed it later [2] . Here you should know the device names of
>> two devices and even if one of them started using DEVID_AUTO, it'll start
>> breaking. Such an approach needs to reviewed carefully.
> 
> If somebody creates a regression by changing something like the
> platform device id without checking all the users, he deserves to get
> into big trouble. I don't see why an individual framework should
> provide protection against such cases.
> 
> In any case, having two device names to deal with does not add any
> more risk. These associations should always be made in the place where
> the phy device is created so you will always know it's device name.

huh.. we should also know the 'controller' device name while defining these
associations and in some cases the controller device and phy device are created
in entirely different places.
> Normally the platform code creates these associations in the same
> place it creates the platform devices, so you definitely know what the
> device names will be.
> 
> In this case it's actually created in drivers/mfd/twl-core.c, so I do
> need to update this and move the lookup table there. We can still
> deliver the user name as platform data, though I believe it's always
> "musb". Maybe we could actually skip that and just hard code the name?

I would rather leave the way it is modelled now.

Thanks
Kishon

WARNING: multiple messages have this Message-ID (diff)
From: kishon@ti.com (Kishon Vijay Abraham I)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
Date: Tue, 7 Jan 2014 18:31:52 +0530	[thread overview]
Message-ID: <52CBFAC0.9040103@ti.com> (raw)
In-Reply-To: <20131216144314.GB22944@xps8300>

Hi,

On Monday 16 December 2013 08:13 PM, Heikki Krogerus wrote:
> Hi,
> 
> On Mon, Dec 16, 2013 at 04:34:35PM +0530, Kishon Vijay Abraham I wrote:
>> On Monday 09 December 2013 08:38 PM, Heikki Krogerus wrote:
>>> Provide a complete association for the phy and it's user
>>> (musb) with the new phy_lookup_table.
>>>
>>> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>>> ---
>>>  arch/arm/mach-omap2/twl-common.c | 15 ++++++---------
>>>  1 file changed, 6 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
>>> index b0d54da..972430b 100644
>>> --- a/arch/arm/mach-omap2/twl-common.c
>>> +++ b/arch/arm/mach-omap2/twl-common.c
>>> @@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void)
>>>  }
>>>  
>>>  #if defined(CONFIG_ARCH_OMAP3)
>>> -struct phy_consumer consumers[] = {
>>> -	PHY_CONSUMER("musb-hdrc.0", "usb"),
>>> -};
>>> -
>>> -struct phy_init_data init_data = {
>>> -	.consumers = consumers,
>>> -	.num_consumers = ARRAY_SIZE(consumers),
>>> +static struct phy_lookup_table twl4030_usb_lookup = {
>>> +	.dev_id = "musb-hdrc.0",
>>> +	.table = PHY_LOOKUP("phy-twl4030_usb.0", NULL),
>>>  };
>>
>> had a similar approach during the initial version of phy framework [1] (see
>> phy_bind) but changed it later [2] . Here you should know the device names of
>> two devices and even if one of them started using DEVID_AUTO, it'll start
>> breaking. Such an approach needs to reviewed carefully.
> 
> If somebody creates a regression by changing something like the
> platform device id without checking all the users, he deserves to get
> into big trouble. I don't see why an individual framework should
> provide protection against such cases.
> 
> In any case, having two device names to deal with does not add any
> more risk. These associations should always be made in the place where
> the phy device is created so you will always know it's device name.

huh.. we should also know the 'controller' device name while defining these
associations and in some cases the controller device and phy device are created
in entirely different places.
> Normally the platform code creates these associations in the same
> place it creates the platform devices, so you definitely know what the
> device names will be.
> 
> In this case it's actually created in drivers/mfd/twl-core.c, so I do
> need to update this and move the lookup table there. We can still
> deliver the user name as platform data, though I believe it's always
> "musb". Maybe we could actually skip that and just hard code the name?

I would rather leave the way it is modelled now.

Thanks
Kishon

  reply	other threads:[~2014-01-07 13:02 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-09 15:08 [PATCH 0/5] phy: remove the need for the phys to know about their users Heikki Krogerus
2013-12-09 15:08 ` Heikki Krogerus
2013-12-09 15:08 ` [PATCH 1/5] phy: unify the phy name parameters Heikki Krogerus
2013-12-09 15:08   ` Heikki Krogerus
2013-12-09 15:08   ` Heikki Krogerus
2013-12-09 15:08 ` [PATCH 2/5] phy: add support for indexed lookup Heikki Krogerus
2013-12-09 15:08   ` Heikki Krogerus
2013-12-16 11:02   ` Kishon Vijay Abraham I
2013-12-16 11:02     ` Kishon Vijay Abraham I
2013-12-16 11:02     ` Kishon Vijay Abraham I
2013-12-16 14:32     ` Heikki Krogerus
2013-12-16 14:32       ` Heikki Krogerus
2014-01-07 13:40       ` Kishon Vijay Abraham I
2014-01-07 13:40         ` Kishon Vijay Abraham I
2014-01-07 13:40         ` Kishon Vijay Abraham I
2014-01-14 14:23         ` Heikki Krogerus
2014-01-14 14:23           ` Heikki Krogerus
2014-01-15 14:11           ` Kishon Vijay Abraham I
2014-01-15 14:11             ` Kishon Vijay Abraham I
2014-01-15 14:11             ` Kishon Vijay Abraham I
2013-12-09 15:08 ` [PATCH 3/5] phy: improved lookup method Heikki Krogerus
2013-12-09 15:08   ` Heikki Krogerus
2013-12-09 15:08 ` [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy Heikki Krogerus
2013-12-09 15:08   ` Heikki Krogerus
2013-12-16 11:04   ` Kishon Vijay Abraham I
2013-12-16 11:04     ` Kishon Vijay Abraham I
2013-12-16 11:04     ` Kishon Vijay Abraham I
2013-12-16 14:43     ` Heikki Krogerus
2013-12-16 14:43       ` Heikki Krogerus
2014-01-07 13:01       ` Kishon Vijay Abraham I [this message]
2014-01-07 13:01         ` Kishon Vijay Abraham I
2014-01-07 13:01         ` Kishon Vijay Abraham I
2014-01-14 14:38         ` Heikki Krogerus
2014-01-14 14:38           ` Heikki Krogerus
2014-01-15 14:11           ` Kishon Vijay Abraham I
2014-01-15 14:11             ` Kishon Vijay Abraham I
2014-01-15 14:11             ` Kishon Vijay Abraham I
2014-01-16 11:58             ` Heikki Krogerus
2014-01-16 11:58               ` Heikki Krogerus
2014-01-08 17:53   ` Tony Lindgren
2014-01-08 17:53     ` Tony Lindgren
2013-12-09 15:08 ` [PATCH] phy: remove the old lookup method Heikki Krogerus
2013-12-09 15:08   ` Heikki Krogerus

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=52CBFAC0.9040103@ti.com \
    --to=kishon@ti.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --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.