Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755475AbbLQUf4 (ORCPT ); Thu, 17 Dec 2015 15:35:56 -0500 Received: from mail-yk0-f182.google.com ([209.85.160.182]:34317 "EHLO mail-yk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754824AbbLQUfy (ORCPT ); Thu, 17 Dec 2015 15:35:54 -0500 MIME-Version: 1.0 In-Reply-To: <20151217184641.GI8644@n2100.arm.linux.org.uk> References: <20151217184641.GI8644@n2100.arm.linux.org.uk> Date: Thu, 17 Dec 2015 12:35:54 -0800 Message-ID: Subject: Re: -next regression: "driver cohandle -EPROBE_DEFER from bus_type.match()" From: Dan Williams To: Russell King - ARM Linux Cc: Tomeu Vizoso , Marek Szyprowski , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-nvdimm@lists.01.org" , Stephen Rothwell , dhowells@redhat.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1664 Lines: 40 [Adding Dave Howells who tried to correct this situation earlier this year] On Thu, Dec 17, 2015 at 10:46 AM, Russell King - ARM Linux wrote: > On Thu, Dec 17, 2015 at 07:51:14AM -0800, Dan Williams wrote: >> The commit below causes the libnvdimm sub-system to stop loading. >> This is due to the fact that nvdimm_bus_match() returns the result of >> test_bit() which may be negative. If there are any other bus match >> functions using test_bit they may be similarly impacted. >> >> Can we queue a fixup like the following to libnvdimm, and maybe >> others, ahead of this driver core change? > > This is rather annoying. Have we uncovered a latent bug in other > architectures? Well, looking through the test_bit() implementations, > it looks like it. > > I'll drop the patch set for the time being, we can't go around breaking > stuff like this. ...or make the interpretation from the return value of ->match() be 0, -EPROBE_DEFER, or other non-zero value for success? Although that's fairly subtle. > However, I think the test_bit() result should be > regularised across different architectures - it _looks_ to me like most > implementations return 0/1 values, but there may be some that don't > (maybe the assembly versions?) Correct. Al the constant versions return 0 or 1, but the assembly return 0 or non-zero. Here's a link to Dave's rework. https://lwn.net/Articles/642437/ -- 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/