linux-kernel - Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously

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]

Date:	Tue, 14 Jul 2009 23:20:13 +0200
From:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
To:	avorontsov@...mvista.com
Cc:	dbrownell@...rs.sourceforge.net, linux-kernel@...r.kernel.org,
	linuxppc-dev@...abs.org
Subject: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously


-----Anton Vorontsov <avorontsov@...mvista.com> skrev: -----
>Till: Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
>Från: Anton Vorontsov <avorontsov@...mvista.com>
>Datum: 07/14/2009 00:20
>Kopia: David Brownell <dbrownell@...rs.sourceforge.net>,
>linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org
>Ärende: Re: [PATCH 0/2] Setting GPIOs simultaneously
>
>
>On Mon, Jul 13, 2009 at 09:59:54PM +0200, Joakim Tjernlund wrote:
>[...]
>> > > While being at it, the reason for me needing this is that the spi_mpc83xx
>driver
>> > > was recently converted to a OF only driver so I have no way of defining
>my own
>> > > CS function anymore. While OF is good I don't feel that OF drivers
>should
>> > block the native
>> > > method, OF should be a layer on top of the native methods.
>> >
>> > Um, I don't get it. You have a mux, which is a sort of GPIO controller.
>> > All you need to do is to write "of-gpio-mux" driver, that will get all
>> > the needed gpios from the underlaying GPIO controller.
>>
>> Well, I already have a mux controller that is using the native spi methods.
>I
>> don't want to write a new one, far more complicated than what I got now.
>> While the OF system is very powerful and flexible I still think that
>> one should be able to use native SPI methods too. Why can they not
>> co-exist?
>
>I strongly believe that they can. You just need to post patches
>so that we could see them, and maybe discuss how to do things
>more generic. But if making things generic will be too hard (see
>below), I don't think anybody will object applying a non-generic
>solution (even permitting "legacy" bindings in the spi_8xxx driver).
>
>But any users of the legacy bindings should be in-tree.

ehh, it was working until you made it OF only. Why do call the native
way legacy?  It is the method all non OF arch uses.

>
>> > In the device tree it'll look like this:
>>
>> I must admit that I just started to look at the GPIO subsystem, but
>> I do wonder if mpc83xx_spi_cs_control() can do this muxing
>> without any change.
>>
>> Very good example BTW.
>
>Well, there is one caveat: the "GPIOs" aren't independent,
>so thinking about it more, I believe we should now discuss
>"chip-select framework", not gpio controllers (it could be
>that using gpio controllers for this purpose wasn't that
>good idea).
>
>http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg34738.html
>^^^ I'm dreaming about this framework. I.e. true addressing
>    for chip-selects. :-)

This is probably needed to support most SPI users out there, but until
such framework is in place I think the native methods need to stay, right?
As is now, SPI has regressed w.r.t earlier releases.

 Jocke
BTW, I will be offline for a few days as of now.

>
>--
>Anton Vorontsov
>email: cbouatmailru@...il.com
>irc://irc.freenode.net/bd2

--
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/