On Wed, Mar 26, 2014 at 12:49:59PM +0000, Jon Ringle wrote: > On Wed, Mar 26, 2014 at 5:08 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Tue, Mar 25, 2014 at 06:19:24PM +0000, jon@xxxxxxxxxx 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
