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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5266F06C.2080701@gmail.com>
Date:	Tue, 22 Oct 2013 16:38:52 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Matt Porter <matt.porter@...aro.org>,
	Matthijs Kooijman <matthijs@...in.nl>,
	Kishon Vijay Abraham I <kishon@...com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dia.com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Paul Zimmerman <paulz@...opsys.com>,
	Devicetree List <devicetree@...r.kernel.org>,
	Linux USB List <linux-usb@...r.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Does PHY UTMI data width belong to DWC2 or PHY binding?

On 10/22/2013 06:25 AM, Matt Porter wrote:
> On Tue, Oct 22, 2013 at 12:48:29PM +0200, Matthijs Kooijman wrote:
>> Hi Kishon,
>>
>> On Mon, Oct 21, 2013 at 02:57:26PM +0530, Kishon Vijay Abraham I wrote:
>>> I think it makes sense to keep the data width property in the dwc2 node itself.
>>> I mean it describes how the dwc2 IP is configured in that particular SoC (given
>>> that it can be either <8> or <16>).
>> If I'm reading the RT3052 datasheet correctly (GHWCFG4 register), the IP
>> can be configured for 8, 16 or 8 _and_ 16. In the latter case, the "8
>> and 16 supported" would make sense as a property of dwc2 (though this
>> value should be autodetectable through GHWCFG4), while the actual 8 or
>> 16 supported by the PHY would make sense as property of a phy.
> 
> There would be no value in adding a property for an already detectable
> value to dwc2's binding. To be honest, it's pretty much useless
> information due to the existence of the "8 and 16" option.
> 
>> Note sure if this is really useful in practice as well, or if just
>> setting the actual width to use on dwc2 makes more sense...
> 
> The GHWCFG4 information itself is not useful in practice, as described
> in the original thread: https://lkml.org/lkml/2013/10/10/477
> 
> It's certainly useful in practice to have this width property in either
> the dwc2 or the phy binding. One can make a case for either. As I
> mentioned in the original post, if we put it in the phy binding we'll be
> updating the generic phy binding. We'll then need an api added into the
> generic phy framework to fetch the width of a phy.
> 
> Both cases are doable and trivial, we just need the canonical decision
> from a DT maintainer as to where the property belongs. Given that they
> are in ARM ksummit, I'm not expecting to hear anything right this
> moment. :)

The host can support both, so it is not a property of the host and is a
property of the phy. It is no different than what mode a SPI slave
requires or whether an i2c slave supports 8 or 10-bit addressing. Those
examples are all 1 to many rather than 1 to 1 where it doesn't really
matter, but the same logic applies.

Rob


--
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