linux-kernel - Re: [PATCH 3/3] usb: phy-generic: Add ULPI VBUS support

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: <529ED6C5.3000608@gtsys.com.hk>
Date:	Wed, 04 Dec 2013 15:16:21 +0800
From:	Chris Ruehl <chris.ruehl@...ys.com.hk>
To:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
CC:	balbi@...com, gregkh@...uxfoundation.org,
	linux-usb@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] usb: phy-generic: Add ULPI VBUS support

On Tuesday, December 03, 2013 04:15 PM, Heikki Krogerus wrote:
> On Mon, Dec 02, 2013 at 03:05:19PM +0800, Chris Ruehl wrote:
>> @@ -154,6 +164,27 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_gen_xceiv *nop,
>>   {
>>   	int err;
>>
>> +	if (nop->ulpi_vbus>  0) {
>> +		unsigned int flags = 0;
>> +
>> +		if (nop->ulpi_vbus&  0x1)
>> +			flags |= ULPI_OTG_DRVVBUS;
>> +		if (nop->ulpi_vbus&  0x2)
>> +			flags |= ULPI_OTG_DRVVBUS_EXT;
>> +		if (nop->ulpi_vbus&  0x4)
>> +			flags |= ULPI_OTG_EXTVBUSIND;
>> +		if (nop->ulpi_vbus&  0x8)
>> +			flags |= ULPI_OTG_CHRGVBUS;
>> +
>> +		nop->ulpi = otg_ulpi_create(&ulpi_viewport_access_ops, flags);
>> +		if (!nop->ulpi) {
>> +			dev_err(dev, "Failed create ULPI Phy\n");
>> +			return -ENOMEM;
>> +		}
>> +		dev_dbg(dev, "Create ULPI Phy\n");
>> +		nop->ulpi->io_priv =  nop->viewport;
>> +	}
>
> This is so wrong. You are registering one kind of usb phy driver from
> an other. Change drivers/usb/phy/ulpi.c to be a platform device. The
> whole flag system in it is pretty horrid. While you are at it, change
> that so it sets the values based on boolean flags from OF properties
> or platform data.
>
> NAK for the whole set.
>
>

Heikki,

Thanks for your comments, even not much positive to me.. any how.
My intention on the "horrid" path was to reduce kernel code where
one of_read32 vs. four of_boolean. And mentioned logic is simple. But that's 
history.

On my way to find a solution for my board I'd look around and found using of
phy-ulpi.c functions in phy-tegra-usb.c and don't mind to use them too.

I accept your NAK and will work on a patch to make phy-ulpi.c working as 
platform device.

Last question to you. What you don't like on the patch to support chip-select 
gpio of my patch-set.. I ask because you NAK the whole set.
I really need the ChipSelect function to make my hardware work!

Chris

-- 
GTSYS Limited RFID Technology
A01 24/F Gold King Industrial Bld
35-41 Tai Lin Pai Road, Kwai Chung, Hong Kong
Fax (852) 8167 4060 - Tel (852) 3598 9488

Disclaimer: http://www.gtsys.com.hk/email/classified.html
--
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/