[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <956998.65651.qm@web180302.mail.gq1.yahoo.com>
Date: Tue, 2 Nov 2010 19:15:16 -0700 (PDT)
From: David Brownell <david-b@...bell.net>
To: davinci-linux-open-source@...ux.davincidsp.com,
spi-devel-general@...ts.sourceforge.net,
broonie@...nsource.wolfsonmicro.com, lrg@...mlogic.co.uk,
grant.likely@...retlab.ca, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, rpurdie@...ys.net,
Cyril Chemparathy <cyril@...com>
Subject: Re: [PATCH v4 08/12] gpio: add ti-ssp gpio driver
--- On Tue, 10/26/10, Cyril Chemparathy <cyril@...com> wrote:
> From: Cyril Chemparathy <cyril@...com>
> Subject: [PATCH v4 08/12] gpio: add ti-ssp gpio driver
On the assumptions you've tested this *AND* will
resubmit with the previously-requested change of
removing all references to non-existent
"virtual"ness in the driver ... I'll likely
add my ack to that resubmitted version
Also, chip2gpio seems an excessively generic name;
maybe chip2_ti_ssp_gpio or somesuch?
I'd still be happier seeing this "stack" packaged
as a hardware library called by various drivers
(like GPIO, SPI, etc) rather than a core driver
that's called by other drivers. That seems like
a better structure for various vendors' "SSP"
hardware (multifunction serial interface logic)
since most function drivers just need to poke
the registers a bit differently, and don't have
much to share with a "core driver" beyond a few
setup routines (if that).
- Dave
--
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