[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OF9A2BDEDE.DC0DE0D4-ONC1257608.004A7A59-C1257608.004AF3BF@transmode.se>
Date: Tue, 4 Aug 2009 15:38:40 +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: Re: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
Anton Vorontsov <avorontsov@...mvista.com> wrote on 15/07/2009 00:09:31:
>
> On Tue, Jul 14, 2009 at 11:20:13PM +0200, Joakim Tjernlund wrote:
> [...]
> > >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.
>
> It's legacy because there are no in-tree users anymore. Nowadays
> we're trying to pass all needed information via OF, and we're
> trying to avoid ugly platform-dependant hacks. Your SPI scheme
> can be easily described via OF, but sure, it's hard to implement
> it with the current SPI/OF subsystem.
Sorry for the long delay, I have been on vaction and been busy with other stuff.
Tell me, how does this new OF SPI device scheme work out if you want
to use the bitbanged SPI driver?
>
> [...]
> > >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?
>
> I'm not the right person to ask. I can only express my opinions.
> The maintainer make final decision.
>
> But if you ask for my opinion, I don't think that they should stay
> unless we'll see a user in the mainline.
>
> > As is now, SPI has regressed w.r.t earlier releases.
>
> Yes and no. Yes, it has "regressed" for out-of-tree code, and no,
> I don't feel sorry about that. :-)
That is a Yes and some bla bla so the answer is yes.
Jocke
--
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