linux-kernel - Re: [PATCH] DMAEngine: Define generic transfer request api

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]

Message-ID: <1313774883.18591.11.camel@vkoul-udesk3>
Date:	Fri, 19 Aug 2011 22:58:03 +0530
From:	"Koul, Vinod" <vinod.koul@...el.com>
To:	Jassi Brar <jaswinder.singh@...aro.org>
Cc:	Linus Walleij <linus.ml.walleij@...il.com>,
	"sundaram@...com" <sundaram@...com>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"rmk+kernel@....linux.org.uk" <rmk+kernel@....linux.org.uk>,
	"nsekhar@...com" <nsekhar@...com>
Subject: Re: [PATCH] DMAEngine: Define generic transfer request api

On Fri, 2011-08-19 at 21:16 +0530, Jassi Brar wrote:
> On 19 August 2011 19:49, Linus Walleij <linus.ml.walleij@...il.com> wrote:
> > 2011/8/19 Koul, Vinod <vinod.koul@...el.com>:
> >> On Tue, 2011-08-16 at 15:06 +0200, Linus Walleij wrote:
> >>> On Tue, Aug 16, 2011 at 2:56 PM, Koul, Vinod <vinod.koul@...el.com> wrote:
> >
> >>> I think Sundaram is in the position of doing some heavy work on
> >>> using one or the other of the API:s, and I think he is better
> >>> suited than anyone else of us to select what scheme to use,
> >>> in the end he's going to write the first code using the API.
> >
> >> And Unfortunately TI folks don't seem to care about this discussion :(
> >> Haven't seen anything on this from them, or on previous RFC by Jassi
> >
> > Well if there is no code usig the API then there is no rush
> > in merging it either I guess. Whenever someone (TI or
> > Samsung) cook some driver patches they can choose their
> > approach.
> >
> No, it's not a matter of "choice".
> If that were the case, Sundaram already proposed a TI specific
> flag. Why wait for him to tell his choice again?
> 
> You might, but I can't molest my sensibility to believe that a Vendor
> specific flag could be better than a generic solution.
> Not here at least, where the overhead due to generality is not much.
> (though I can trim some 'futuristic' members from the 'struct xfer_template')
Who said anything about adding a vendor flag solution, since TI are
potential users of the API it would good to know i this fits there needs
are not. If they don't care, we can't help it...

> 
> Maintainers might wait as long as they want, but there should never
> be an option to have vendor specific hacks.
to me API looks decent after reading some specs of DMACs which support
this mode. Pls send updated patch along with one driver which uses it.
Should be good to go...


-- 
~Vinod

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