From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751229AbdFCTey (ORCPT ); Sat, 3 Jun 2017 15:34:54 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:37888 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750991AbdFCTew (ORCPT ); Sat, 3 Jun 2017 15:34:52 -0400 Date: Sat, 3 Jun 2017 21:34:45 +0200 From: Greg Kroah-Hartman To: Luc Van Oostenryck Cc: Peter Rosin , open list , Peter Rosin , Wolfram Sang , Rob Herring , Mark Rutland , Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Jonathan Corbet , linux-i2c@vger.kernel.org, devicetree@vger.kernel.org, linux-iio@vger.kernel.org, linux-doc@vger.kernel.org, Andrew Morton , Colin Ian King , Paul Gortmaker , Philipp Zabel , kernel@pengutronix.de Subject: Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes Message-ID: <20170603193445.GA18851@kroah.com> References: <1494791476-14599-1-git-send-email-peda@lysator.liu.se> <20170603102627.GA24274@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 03, 2017 at 08:37:21PM +0200, Luc Van Oostenryck wrote: > On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman > wrote: > > On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote: > >> From: Peter Rosin > >> > >> Hi Greg, > >> > >> Philipp found problems in v14 with using a mutex for locking that was > >> the outcome of the review for v13, so I'm now using a semaphore instead > >> of the rwsem that was in v13. That at least got rid of the scary call > >> to downgrade_write. However, I'm still unsure about what you actually > >> meant with your comment about lack of sparse markings [1]. I did add > >> __must_check to the funcs that selects the mux, but I've got this > >> feeling that this is not what you meant? > > > > I thought there was a way to mark a function as requiring a lock be held > > when it is being called. Does sparse not support that anymore? > > sparse still support these annotations, of course. > In this case, I suppose you're talking about '__must_hold()' which > *must* be used instead of a pair of '__releases()' + '__acquires()' > when the lock is help on function entry and exit. Ah, yes, that's what I was thinking of. I don't know if sparse can track things like this across an exported symbol, so I doubt it really will help here. Sorry for the noise. thanks, greg k-h