Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752654AbdFSU14 (ORCPT ); Mon, 19 Jun 2017 16:27:56 -0400 Received: from ale.deltatee.com ([207.54.116.67]:43517 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752112AbdFSU1x (ORCPT ); Mon, 19 Jun 2017 16:27:53 -0400 To: Jon Mason References: <20170615203729.9009-1-logang@deltatee.com> <20170619200659.GA20437@kudzu.us> Cc: linux-ntb@googlegroups.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Dave Jiang , Allen Hubbe , Bjorn Helgaas , Greg Kroah-Hartman , Kurt Schwemmer , Stephen Bates From: Logan Gunthorpe Message-ID: Date: Mon, 19 Jun 2017 14:27:41 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170619200659.GA20437@kudzu.us> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.111 X-SA-Exim-Rcpt-To: sbates@raithlin.com, kurt.schwemmer@microsemi.com, gregkh@linuxfoundation.org, bhelgaas@google.com, Allen.Hubbe@emc.com, dave.jiang@intel.com, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-ntb@googlegroups.com, jdmason@kudzu.us X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [RFC PATCH 00/13] Switchtec NTB Support X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1442 Lines: 34 On 19/06/17 02:07 PM, Jon Mason wrote: > I think this code is of quality enough to go from an RFC to a standard > patch, and we can nit pick it to death there ;-) Thanks! > Please rebase on ntb-next (which I believe you are already doing), and > resbutmit. I'll try to get the rebase done and all the feedback so far applied by the end of the week and resend a v1. > I'm thinking that we'll want to keep this series all in one place. > So, #2 sounds like the best option. But, I need Bjorns $0.02 on this. I was thinking #2 was the best choice as well but really it's for you maintainers to decide. And, yes, we'd want to get Bjorn's ack. > FYI, I ran smatch on the patches and got this. Please correct them in > v2 (or v1 of the non-RFC...however you want to think of it). > drivers/pci/switch/switchtec.c:484 switchtec_dev_read() error: double unlock 'mutex:&stdev->mrpc_mutex' > drivers/pci/switch/switchtec.c:506 switchtec_dev_read() error: double unlock 'mutex:&stdev->mrpc_mutex' > drivers/pci/switch/switchtec.c:513 switchtec_dev_read() warn: inconsistent returns 'mutex:&stdev->mrpc_mutex'. This looks like a false positive to me. The code looks correct. smatch may have been confused by the fact that the lock is taken by two calls to the static function 'lock_mutex_and_test_alive'. This is also part of the switchtec management driver that's already in the kernel and not part of the NTB related patches I sent. Logan