linux-kernel - Re: Bug: shared usb dt document is incorrect

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]

Date:	Tue, 28 Jul 2015 22:25:18 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Peter Chen <Peter.Chen@...escale.com>
Cc:	Tim Bird <tim.bird@...ymobile.com>,
	Antoine Ténart <antoine.tenart@...e-electrons.com>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux USB List <linux-usb@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Bjorn Andersson <Bjorn.Andersson@...ymobile.com>
Subject: Re: Bug: shared usb dt document is incorrect

On Tue, Jul 28, 2015 at 10:12 PM, Peter Chen <Peter.Chen@...escale.com> wrote:
>
>> > I was just doing some testing with USB on a Qualcomm SoC.
>> >
>> > I followed the instructions in the binding document:
>> > Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>> >
>> > which has a compatible for "qcom,ci-hdrc", and is, in general, for
>> > chipidea-based USB controllers.
>> >
>> > It says in the document that the property usb-phy is deprecated, and
>> > to use phys and phy-names instead.  However, the Qualcomm driver for
>> > this still uses usb-phy.  That driver is in:
>> > drivers/usb/chipidea/ci_hdrc_msm.c
>>
>> Deprecated means it still exists in the wild and should be maintained, but don't
>> use it for new dts files.
>>
>
> But how the new SoC (for new dts) which still uses current USB PHY driver?

That's fine to use, but I would encourage people not to.

> Maybe we should not add additional description for this property,
> it depends on which PHY driver (Generic PHY vs USB PHY)  this controller
> will use, if it uses a new PHY driver, it must use generic PHY framework,  and will
> use 'phy' and 'phy-names' corresponding.

We're thinking about this the wrong way around. The driver should not
determine the binding used. The binding should be independent of the
driver used.

Either we should make the generic phy subsystem have feature parity
with usb-phy, or make the usb-phy drivers use the same generic phy
binding. Long term, I think we want the former and need a way to
subclass the generic phy. Other phys have similar needs for additional
protocol specific functions (e.g. configure the # of lanes for PCIe).
The generic phy subsystem needs some love in my brief experience with
it. For the latter case, this would make switching which phy driver is
used transparent to DT.

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/