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]
Date:	Mon, 10 Feb 2014 13:57:37 +0530
From:	Kishon Vijay Abraham I <kishon@...com>
To:	Tomasz Figa <t.figa@...sung.com>,
	Vivek Gautam <gautam.vivek@...sung.com>,
	<linux-usb@...r.kernel.org>, <linux-samsung-soc@...r.kernel.org>
CC:	<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <gregkh@...uxfoundation.org>,
	<kgene.kim@...sung.com>, <balbi@...com>, <k.debski@...sung.com>,
	<s.nawrocki@...sung.com>, <jwerner@...omium.org>,
	<jg1.han@...sung.com>
Subject: Re: [PATCH v3] phy: Add new Exynos5 USB 3.0 PHY driver

Hi,

On Thursday 06 February 2014 07:37 PM, Tomasz Figa wrote:
> Hi Vivek,
> 
> This patch is just adding the PHY driver. I would also like to look at some
> users of it, to see how this works when put together.
> 
> For now, please see my comments inline.
> 
> On 20.01.2014 14:42, Vivek Gautam wrote:
>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> The new driver uses the generic PHY framework and will interact
>> with DWC3 controller present on Exynos5 series of SoCs.
>> Thereby, removing old phy-samsung-usb3 driver and related code
>> used untill now which was based on usb/phy framework.
>>
>> Signed-off-by: Vivek Gautam <gautam.vivek@...sung.com>
>> ---
>>
>> Changes from v2:
>> 1) Added support for multiple PHYs (UTMI+ and PIPE3) and
>>     related changes in the driver structuring.
> 
> I'm a bit skeptical about this separation. Can the PHY operate with just the
> UTMI+ or PIPE3 part enabled alone without the other? Can any PHY consumer
> operate this way?

Theoretically yes. If the USB controller should operate only in high-speed
mode, the PIPE3 part is not required at all. However for super speed mode both
PIPE3 part and UTMI part should be enabled. Maybe it doesn't work that way with
all SoCs because of some HW bug.
> 
> Introducing separation of something that can't exist alone doesn't add any
> value, but instead makes things more difficult to work with. Of course, it's

IMO separating it into different parts adds more clarity to the driver.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ