From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Subject: Re: [PATCH v2 2/2] serial: sc16is7xx: Add bindings documentation for the SC16IS7XX UARTs Date: Wed, 26 Mar 2014 13:35:18 +0000 Message-ID: <20140326133518.GA6209@e106331-lin.cambridge.arm.com> References: <1395771564-30534-1-git-send-email-jon@ringle.org> <1395771564-30534-2-git-send-email-jon@ringle.org> <20140326090855.GP10341@e106331-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-serial-owner@vger.kernel.org To: Jon Ringle Cc: "linux-serial@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "devicetree@vger.kernel.org" , Jon Ringle List-Id: devicetree@vger.kernel.org On Wed, Mar 26, 2014 at 12:49:59PM +0000, Jon Ringle wrote: > On Wed, Mar 26, 2014 at 5:08 AM, Mark Rutland wrote: > > On Tue, Mar 25, 2014 at 06:19:24PM +0000, jon@ringle.org wrote: > >> +- interrupt-parent: The phandle for the interrupt controller that > >> + services interrupts for this IC. > >> +- interrupts: Specifies the interrupt source of the parent interrupt > >> + controller. The format of the interrupt specifier depends on the > >> + parent interrupt controller. > > > > Just describe what the device-specific interrupt logically is, not what > > the interrupts property means in general. > > > > Something like this ok?: > > -interrupts: Should contain the UART interrupt Sure. > > >> +- clocks: phandle to the IC source clock. > > > > Nit: clocks aren't just referred to with phandles; there's a clock > > specifier too. > > > > Either correct the type here or don't mention the type at all, given > > this is a common property. > > > > I'm not sure what to do here. Many of the other > devicetree/bindings/serial/*.txt use phandle verbage and also the > devicetree/bindings/clock-bindings.txt documentation for clocks refers > the type as phandle too: > > ==Clock consumers== > > Required properties: > clocks: List of phandle and clock specifier pairs, one pair > for each clock input to the device. Note: if the > clock provider specifies '0' for #clock-cells, then > only the phandle portion of the pair will appear. > Those bindings which refer to clocks as just being phandles are simply wrong. While clocks _may_ be simply phandles, that isn't the general case (and when this is the case they can be thought of as having a zero cell clock-specifier). The quoted portion of the core clock bindings describes clocks as consisting of "phandle and and clock specifier pairs", not just phandles. > Is something like this ok?: > > clocks: reference to the source clock Sure. That'll be fine. Thanks, Mark.