linux-kernel - Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51F7590B.4020705@ti.com>
Date:	Tue, 30 Jul 2013 11:41:23 +0530
From:	Kishon Vijay Abraham I <kishon@...com>
To:	<balbi@...com>
CC:	<tony@...mide.com>, <linux@....linux.org.uk>,
	<eballetbo@...il.com>, <javier@...hile0.org>,
	<gregkh@...uxfoundation.org>, <linux-omap@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given
 in usb_bind_phy

Hi,

On Tuesday 30 July 2013 11:31 AM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 30, 2013 at 10:44:48AM +0530, Kishon Vijay Abraham I wrote:
>>> On Mon, Jul 29, 2013 at 08:59:26PM +0530, Kishon Vijay Abraham I wrote:
>>>>>> Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating
>>>>>> MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the
>>>>>> device name of the controller had *.auto* in it. Since with using
>>>>>> PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance,
>>>>>> the data given in usb_bind_phy became obsolete and usb_get_phy was failing.
>>>>>> So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding
>>>>>> change is done in board file here.
>>>>>>
>>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@...com>
>>>>>> ---
>>>>>>  arch/arm/mach-omap2/board-2430sdp.c          |    2 +-
>>>>>>  arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
>>>>>>  arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
>>>>>>  arch/arm/mach-omap2/board-devkit8000.c       |    2 +-
>>>>>>  arch/arm/mach-omap2/board-igep0020.c         |    2 +-
>>>>>>  arch/arm/mach-omap2/board-ldp.c              |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3beagle.c      |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3evm.c         |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3logic.c       |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3pandora.c     |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3touchbook.c   |    2 +-
>>>>>>  arch/arm/mach-omap2/board-overo.c            |    2 +-
>>>>>>  arch/arm/mach-omap2/board-rm680.c            |    2 +-
>>>>>>  arch/arm/mach-omap2/board-rx51.c             |    2 +-
>>>>>>  arch/arm/mach-omap2/board-zoom-peripherals.c |    2 +-
>>>>>>  16 files changed, 16 insertions(+), 16 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
>>>>>> index 244d8a5..17bb076 100644
>>>>>> --- a/arch/arm/mach-omap2/board-2430sdp.c
>>>>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
>>>>>> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
>>>>>>  	omap_hsmmc_init(mmc);
>>>>>>  
>>>>>>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
>>>>>> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>>>>>> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
>>>>>
>>>>> how about moving usb_bind_phy() calls to omap2430.c ?
>>>>>
>>>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>>>> index f44e8b5..b6abc1a 100644
>>>>> --- a/drivers/usb/musb/omap2430.c
>>>>> +++ b/drivers/usb/musb/omap2430.c
>>>>> @@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
>>>>>  
>>>>>  		pdata->board_data	= data;
>>>>>  		pdata->config		= config;
>>>>> +	} else {
>>>>> +		/* bind the PHY */
>>>>> +		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");
>>>>
>>>> This looks like a hack IMHO to workaround the usb phy library. otherwise it is
>>>> similar to get_phy_by_name.
>>>
>>> actually, this is a workaround to the fact that we're not creating all
>>> platform_devices in arch/arm/mach-omap2/ :-)
>>>
>>> If we had the musb allocation there, we could easily handle
>>> usb_bind_phy()
>>>
>>>>> so that's temporary. It might be better than to reintroduce the IDR in
>>>>> musb_core.c.
>>>>
>>>> that’s needed for generic phy framework anyway :-s
>>>
>>> right, but generic phy framework can handle everything just fine, the
>>> only problem is that names are changing.
>>
>> right. But if the names change, PHY framework wouldn't be able to return the
>> reference to the PHY.
> 
> with my suggestion they can change whenever they want since we're using
> dev_name() of the just-created musb platform_device. Right ?

right. But the PHY device can be created in a different place from where the
musb devices are created. And in the PHY framework, the PHY device should have
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
cases how do we pass the device names. Also will the MUSB core device be
created before twl4030-usb PHY device?

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/