netdev - Re: [PATCH net-next 1/8] Documentation/bindings: net: ocelot: document the PTP bank

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: <20190705144517.GD4428@lunn.ch>
Date:   Fri, 5 Jul 2019 16:45:17 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Antoine Tenart <antoine.tenart@...tlin.com>
Cc:     davem@...emloft.net, richardcochran@...il.com,
        alexandre.belloni@...tlin.com, UNGLinuxDriver@...rochip.com,
        ralf@...ux-mips.org, paul.burton@...s.com, jhogan@...nel.org,
        netdev@...r.kernel.org, linux-mips@...r.kernel.org,
        thomas.petazzoni@...tlin.com, allan.nielsen@...rochip.com
Subject: Re: [PATCH net-next 1/8] Documentation/bindings: net: ocelot:
 document the PTP bank

On Fri, Jul 05, 2019 at 03:30:16PM +0200, Antoine Tenart wrote:
> Hi Andrew,
> 
> On Mon, Jul 01, 2019 at 03:52:14PM +0200, Andrew Lunn wrote:
> > On Mon, Jul 01, 2019 at 12:03:20PM +0200, Antoine Tenart wrote:
> > > One additional register range needs to be described within the Ocelot
> > > device tree node: the PTP. This patch documents the binding needed to do
> > > so.
> > 
> > Are there any more register banks? Maybe just add them all?
> 
> I checked and there are (just a few) more. I also saw your other comment
> about interrupts, and it's also true there.
> 
> Those definitions aren't related to the PHC so I'll prepare a patch for
> a following series to add all the missing parts.

Thanks.
 
> > Also, you should probably add a comment that despite it being in the
> > Required part of the binding, it is actually optional.
> 
> I'm not sure about this: optional properties means some parts of the h/w
> can be missing or not wired. It's not the case here, it's "optional" in
> the driver only for dt compatibility (so that an older dt blob can work
> with a newer kernel image), but it's now mandatory in the binding.

Hi Antoine

If the driver can work without it, it is clearly optional. You just
get reduced functionality. That is the thing with DT. You can never
add more required properties after the first commit without breaking
backwards compatibility. To make the documentation fit the driver,
somewhere you need to state they are optional. Either by placing the
new properties in the optional section of the binding, or add a
comment.

	Andrew