From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Skeggs Subject: Re: drm/nouveau/pwr: initial implementation Date: Tue, 12 Nov 2013 16:47:38 -0500 (EST) Message-ID: <1128502611.21441586.1384292858165.JavaMail.root@redhat.com> References: <20131112095433.GA8844@elgon.mountain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 1E8BEFAEB3 for ; Tue, 12 Nov 2013 13:47:39 -0800 (PST) In-Reply-To: <20131112095433.GA8844@elgon.mountain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Dan Carpenter Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org ----- Original Message ----- > From: "Dan Carpenter" > To: bskeggs@redhat.com > Cc: dri-devel@lists.freedesktop.org > Sent: Tuesday, 12 November, 2013 7:54:33 PM > Subject: re: drm/nouveau/pwr: initial implementation > > Hello Ben Skeggs, Hey, > > The patch ff4b42c7532e: "drm/nouveau/pwr: initial implementation" > from Oct 15, 2013, leads to the following Smatch warning: > "drivers/gpu/drm/nouveau/core/subdev/pwr/base.c:48 nouveau_pwr_send() > warn: 'mutex:&subdev->mutex' is sometimes locked here and sometimes > unlocked." > > drivers/gpu/drm/nouveau/core/subdev/pwr/base.c > 35 /* we currently only support a single process at a time > waiting > 36 * on a synchronous reply, take the PPWR mutex and tell the > 37 * receive handler what we're waiting for > 38 */ > 39 if (reply) { > 40 mutex_lock(&subdev->mutex); > 41 ppwr->recv.message = message; > 42 ppwr->recv.process = process; > 43 } > 44 > 45 /* wait for a free slot in the fifo */ > 46 addr = nv_rd32(ppwr, 0x10a4a0); > 47 if (!nv_wait_ne(ppwr, 0x10a4b0, 0xffffffff, addr ^ 8)) > 48 return -EBUSY; > > Should we have an if (reply) mutex_unlock(&subdev->mutex) before the > return? Yes, we should. It's been reported, no fix pushed to Linus' tree yet as the path that can hit it has been hardcoded as disabled for this release. Thanks, Ben. > > 49 > > regards, > dan carpenter > >