[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa686aa40807041642m1ecd1f8fr33382076ca5c11fa@mail.gmail.com>
Date: Fri, 4 Jul 2008 17:42:46 -0600
From: "Grant Likely" <grant.likely@...retlab.ca>
To: "Segher Boessenkool" <segher@...nel.crashing.org>
Cc: linux-kernel@...r.kernel.org,
spi-devel-general@...ts.sourceforge.net, david-b@...bell.net,
linuxppc-dev@...abs.org, fabrizio.garetto@...il.com
Subject: Re: [PATCH v2 3/5] of-bindings: Add binding documentation for SPI busses and devices
On Fri, Jul 4, 2008 at 5:36 PM, Segher Boessenkool
<segher@...nel.crashing.org> wrote:
>> + The SPI master node requires the following properties:
>> + - #address-cells - number of cells required to define a chip select
>> + address on the SPI bus.
>
> Hrm. Should this (and "reg" in the child node) be required for SPI
> masters that have only one chip select?
I suppose it could be skipped, but I'd rather have it there for consistency
>
>> + - max-speed - (required) Maximum SPI clocking speed of device
>> in Hz
>
> The property name should include something "SPI", it's way too generic
> otherwise.
Good point; I'll change this to 'spi-max-speed'
>> + - spi,cpol - (optional) Device requires inverse clock polarity
>> + - spi,cpha - (optional) Device requires shifted clock phase
>
> Don't abbr the property names, there's nothing wrong with longer names.
> The names shouldn't start with "spi," either, "spi" isn't a vendor;
> how about "spi-inverse-clock-polarity" or similar?
Okay, but cpol and cpha are common abbreviations w.r.t. SPI devices.
>> + - linux,modalias - (optional, Linux specific) Force binding of SPI
>> device
>> + to a particular spi_device driver. Useful for
>> changing
>> + driver binding between spidev and a kernel SPI
>> driver.
>
> This is a temporary workaround I hope?
Yeah, I'm kind of ashamed of this one. I'll drop it.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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/
Powered by blists - more mailing lists