linux-kernel - Re: [PATCH 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

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:	Thu, 2 Jun 2016 10:53:02 +0800
From:	Frank Wang <frank.wang@...k-chips.com>
To:	Heiko Stübner <heiko@...ech.de>
Cc:	dianders@...omium.org, kishon@...com, robh+dt@...nel.org,
	pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
	linux-usb@...r.kernel.org, kever.yang@...k-chips.com,
	huangtao@...k-chips.com, william.wu@...k-chips.com,
	frank.wang@...k-chips.com
Subject: Re: [PATCH 1/2] Documentation: bindings: add DT documentation for
 Rockchip USB2PHY

Hi Heiko,

On 06/02/2016 06:17 AM, Heiko Stübner wrote:
> Hi Frank,
>
> Am Mittwoch, 1. Juni 2016, 16:09:41 schrieb Frank Wang:
>>> You might want to add the bvalid and id interrupts for the otg phys as
>>> well
>>> already - would make handling legacy devicetree files easier. [= if they
>>> get specified later, the driver would always need to also handle
>>> devicetrees where they aren't specified].
>>
>> Hmmm! you mean that I can specify these properties into documentation,
>> even if the driver have not handled (implemented) them in current?
>
> The devicetree bindings are supposed to be a generic hardware-description.
> And a driver then simply implements that binding. So if the interrupt is part
> of the hardware it can be part of the binding, independent of the driver.
>
> I guess it really comes down to, will you need those interrupts later in the
> driver, then they should definitly be specified now, as later on you cannot
> require them anymore and always need to also support devicetrees not having
> them.
>

Got it, I have already added them in the new patches which I will hand 
out later.

BR.
Frank