Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932121AbbGTR0g (ORCPT ); Mon, 20 Jul 2015 13:26:36 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:60266 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752134AbbGTR0f (ORCPT ); Mon, 20 Jul 2015 13:26:35 -0400 Date: Mon, 20 Jul 2015 18:26:27 +0100 From: Mark Brown To: Alexander Stein Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org Message-ID: <20150720172627.GF11162@sirena.org.uk> References: <1437061732-21018-1-git-send-email-alexander.stein@systec-electronic.com> <20150716190657.GA11162@sirena.org.uk> <3879923.hy2mOjvtRz@ws-stein> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ufKotkMdkVlnDasC" Content-Disposition: inline In-Reply-To: <3879923.hy2mOjvtRz@ws-stein> X-Cookie: Stay together, drag each other down. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 1/1] regmap: regcache-rbtree: Use GFP_ATOMIC when using spinlocks X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2624 Lines: 63 --ufKotkMdkVlnDasC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 20, 2015 at 09:04:05AM +0200, Alexander Stein wrote: > On Thursday 16 July 2015 20:06:57, Mark Brown wrote: Please fix your mailer to word wrap within paragraphs for legibility. > > The expectation here is that we should either be using no or a flat > > cache here or (if we're using rbtree) providing register defaults to > > ensure that we never do allocations in the spinlock. The rbtree code is > > written on the assumption that we only have to be faster than reading > > from a serial bus so I'd be worried about it not behaving at all nicely > > in a spinlock even ignoring this issue. > AFAICS even a flat cache seems also only be usefull when providing > defaults, no? (Or having volatile registers). Well, it's *better* to provide defaults since otherwise everything defaults to 0 but it does avoid the whole allocation during fast path issue since it allocates the cache on init and perhaps that's OK. > So how to handle this properly? Bail out, if fast_io is available and > cache_type != (REGCACHE_NONE || REGCACHE_FLAT)? Or perhaps just if we have to do an allocation? I can see that someone might want to use an rbtree and would be careful enough to do the init, though I *am* a bit dubious about it. > > Why are you using a dynamically allocated rbtree for a device like this? > On my way home, I came to the same question. In fact this is not a > driver written by myself, but from here > http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/tree/drivers/video/fsl-dcu-fb.c#n1024. > I guess as this is a mmio device and things like regcache_cache_only() > are used, REGCACHE_FLAT seems appropriate. Ah, out of tree BSP code... --ufKotkMdkVlnDasC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVrS9CAAoJECTWi3JdVIfQ38oH/R4P0Kx9hoVP2DbA4X7VH1sT HV205BUFTYgcx5iZixci+Sxyur0dAE+FzVyZBRn6kmJQ5hEeQrHh+o6HrNcDjc9m WLY8G45dXYdmtC3mFexVRcHeU5HWzLgVmNeGdV55pAYlfv+eWHzSgtTEU9i/fjgP ys0ZSHZBD+PQzKhgekKJov/zP5mV0Bg08VrqJx8ohdjIi+ecJiZkWu1KvAkW3TRf 4qbiDokm8mzAUu/3h/dSm0jZZzZeYmCdaXh8MTYU/SFEfsT18NsyolJ/jy+ccGaT FIkrddxrGXVxx39q9wWxJ32FvThwPiovwWhVrHJ47yqfhilL+XdK1211x/EHBm0= =fBYn -----END PGP SIGNATURE----- --ufKotkMdkVlnDasC-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/