linux-kernel - Re: [PATCH v3] gpio: mcp23s08: convert driver to DT

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] [day] [month] [year] [list]

Message-ID: <CACRpkdZue4QjQ+SS_go8i_LJZm7RJPFQr6sDcNaCp3FhkUrseQ@mail.gmail.com>
Date:	Wed, 27 Mar 2013 16:23:25 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Lars Poeschel <poeschel@...onage.de>
Cc:	Lars Poeschel <larsi@....tu-dresden.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	grant.likely@...retlab.ca, rob.herring@...xeda.com,
	rob@...dley.net, devicetree-discuss@...ts.ozlabs.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	spi-devel-general@...ts.sourceforge.net,
	Peter Korsgaard <jacmet@...site.dk>
Subject: Re: [PATCH v3] gpio: mcp23s08: convert driver to DT

On Wed, Mar 27, 2013 at 12:35 PM, Lars Poeschel <poeschel@...onage.de> wrote:
> On Friday 22 March 2013 at 09:33:10, Linus Walleij wrote:

>> I would currently feel a lot better if you did not include this
>> flag. How would you control this the day drivers need to
>> enable/disable pull-up at runtime?
>
> For me it would also be easier to remove the flag (for DT boot case). I don't
> need the pullups. I did only include it, because this is how the driver is
> designed to work and what it did already. What I wanted was to make a good
> transfer from what the features of the driver are and how it works to be able
> to use it with device tree. If it now turns out that's bad for some reason, I
> have no problem to remove this from the patch completely.
> You're right: Runtime config is not possible this way.
> What should I do now ? Remove it ?

Remove. The less complicated binding, the better.

>> > +- gpio-controller : Marks the device node as a GPIO controller.
>> > +- reg : For an address on its bus
>>
>> On the I2C/SPI bus?
>
> Yes, both. For I2C it's the I2C address, for SPI it's the chip select to use
> for this chip.

OK please write these specifics in the binding doc.

>> Please state here what kind of buses it can be. Explain if multiple
>> buses are supported.
>
> Ok, I will add a line about it.

Thx.

>> > +Required device specific properties (only for SPI chips):
>> > +- mcp,spi-present-mask : This is a present flag, that makes only sense
>> > for SPI +        chips - as the name suggests.
>>
>> AFAIK this is not how we disable/enable devices in the device tree.
>>
>> Istead we include a property on the node called "status" and set it
>> to "disabled" if the device is not there.
>
> This would require multiple instances with the same reg property as up to 8
> chips can live on the same chip select. I wonder if this is possible ?

If there is not one instance/device node per chip things are
very wrong anyway. Maybe I don't understand fully... each
device on the system should have a node, you can't have a node
spanning several devices unless it's a bus node.

> Grant had the idea with the bitfield. You have the reg property specifying
> the chip select line. This bitfield is then used to indicate which of the 8
> possible chips on this same chip select line is really present. Not beeing
> able to support more than 8 devices is not problem, because it is a hardware
> limitation, that not more than 8 devices can share the same SPI chip select.
> This is again how the driver worked so far.
>
>> What about just using a number?
>
> This would again require multiple instances with the same reg property for
> SPI. Is this really possible ?

If Grant is OK with this then so am I, he surely know this better
than me. But you nee to trick him to come out and review it.

Yours,
Linus Walleij
--
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/