linux-kernel - Re: [PATCH V3 3/6] slimbus: Add messaging APIs to slimbus framework

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: <20150814183353.GA30451@sirena.org.uk>
Date:	Fri, 14 Aug 2015 19:33:53 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Sagar Dharia <sdharia@...eaurora.org>
Cc:	gregkh@...uxfoundation.org, bp@...e.de, poeschel@...onage.de,
	treding@...dia.com, gong.chen@...ux.intel.com,
	andreas.noever@...il.com, alan@...ux.intel.com,
	mathieu.poirier@...aro.org, daniel@...ll.ch, oded.gabbay@....com,
	jkosina@...e.cz, sharon.dvir1@...l.huji.ac.il, joe@...ches.com,
	davem@...emloft.net, james.hogan@...tec.com,
	michael.opdenacker@...e-electrons.com, daniel.thompson@...aro.org,
	robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	kheitke@...ience.com, mlocke@...eaurora.org, agross@...eaurora.org,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH V3 3/6] slimbus: Add messaging APIs to slimbus framework

On Fri, Aug 14, 2015 at 07:25:25PM +0100, Mark Brown wrote:
> On Mon, Aug 03, 2015 at 12:59:47AM -0600, Sagar Dharia wrote:

> > +	sema_init(&ctrl->tx_sem, (ctrl->tx.n - 1));

> This sempahore counts the number of free slots in the statically
> allocated list of transfers we have allocated.  It would be good to see
> some discussion in the changelog as to why we've got this statically
> allocated pool rather than just dynamically allocating them as needed -
> I can see a performance argument there but it'd be good to have the
> thinking documented.

One other related thing here: we're keeping the buffers permanently
coherently mapped rather than only mapping them to the device as needed.
Is this the best approach?  On the one hand it increases the cost to the
CPU when setting things up and reading data back, on the other hand it
avoids mapping operations.

Since it's becoming part of the driver API with this it bears some
thought, it will be a little annoying (and fiddly) to change later.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)