From mboxrd@z Thu Jan 1 00:00:00 1970 From: Baruch Siach Subject: Re: [PATCH RFC 4/4] spi: dw: migrate to generic queue infrastructure Date: Fri, 24 Jan 2014 08:36:11 +0200 Message-ID: <20140124063611.GL12751@tarshish> References: <20140123195148.GL11727@sirena.org.uk> <20140123200710.GK12751@tarshish> <20140123201306.GP11727@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Feng Tang To: Mark Brown Return-path: Content-Disposition: inline In-Reply-To: <20140123201306.GP11727-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Hi Mark, On Thu, Jan 23, 2014 at 08:13:06PM +0000, Mark Brown wrote: > On Thu, Jan 23, 2014 at 10:07:10PM +0200, Baruch Siach wrote: > > I'll look into it. I had to dig in include/linux/spi/spi.h, 'git blame' > > and commit b158935f70b9c to see how it all works together. The > > Documentation/spi/spi-summary doesn't mention the transfer_one callback. > > The kerneldoc in spi.h should make it clear that transfer_one and > > transfer_one_message are mutually exclusive. > > Feel free to submit documentation patches... Done. > I'd have thought that transfer_one_message() and transfer_one() being > exclusive was fairly obvious given that the former takes an entire message. IMO, adding this small clarification would better serve newcomers. I think there is also a need for some additional explanation on the difference between these two callback, and why a driver should implement one over the other. I hope to look into it when I have more experience with the new API. baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.2.679.5364, http://www.tkos.co.il - -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html