[PATCH 4/7] at91: remove non used at91_spi.h

Jean-Christophe PLAGNIOL-VILLARD plagnioj at jcrosoft.com
Sat Jul 16 22:33:26 EDT 2011


On 16:00 Sat 16 Jul     , Detlef Vollmann wrote:
> On 07/16/11 13:56, Wolfram Sang wrote:
> >
> >>>About the SPI driver:
> >>> From Documentation/spi/spi-summary:
> >>>"At this writing, Linux has no slave side programming interface."
> >>>So there's no SPI framwork that covers the slave side.
> >>This what I mean use the SPI framework and add the SPI Slave support there
> >
> >[CCing spi-devel]
> >
> >If you talk about SPI slaves, be sure to have read Grant's comments in
> >
> >http://thread.gmane.org/gmane.linux.kernel.spi.devel/7401
> >
> >to see what would be needed for slave support.
> I completely agree with Gran't comments here.
> 
> >Short note: Would be
> >seperate subsystem, master subsystem is of limited use. I think a few
> >slave-drivers would be nice to evaluate, so one can get a feeling if a
> >subsystem makes sense and if so, how it could look like.
> >
> >Detlef, have you posted your slave driver so far?
> No, and I didn't plan to do so.
> Not because I don't want to publish it, if you want to look at it,
> I'm happy to send the driver.
> But I don't think it makes much sense to put my driver into mainline
> Linux.
> The reason for this is very simple: the protocol is specific for this
> hardware, and the driver needs this specific protocol.
> The Atmel hardware is not able to maintain information about frame
> ends when running in DMA mode, so we need to put the length of the
> frame to the beginning of the frame, and also need to put in some
> extra information to be able to re-sync in case of transmission errors.
> 
> So this driver is very specific for this hardware, and I wrote SPI
> slave drivers in the past for other hardware that were also very
> specific.  I really doubt that an SPI slave framework really makes
> sense.
> 
> And that's the reason why I'm keen that the hardware description
> headers are available to out-of-tree drivers.
So I'm sorry but this is clear I'm not going to keep the header
out-of-tree drivers are not an enough reason to keep it

Best Regards,
J.



More information about the linux-arm-kernel mailing list