From: Tom Rini Date: Fri, 1 May 2015 09:38:43 -0400 Subject: [U-Boot] [PATCH] dm: core: Fix regression caused by c1d6f91 In-Reply-To: References: <1430280873-20561-1-git-send-email-joe.hershberger@ni.com> Message-ID: <20150501133843.GI16702@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Apr 30, 2015 at 07:54:21PM -0600, Simon Glass wrote: > Hi Joe, > > On 29 April 2015 at 10:17, Joe Hershberger wrote: > > Hi Simon, > > > > On Wed, Apr 29, 2015 at 8:30 AM, Simon Glass wrote: > >> Hi Joe, > >> > >> On 28 April 2015 at 22:14, Joe Hershberger wrote: > >>> The change to refactor these functions created a regression. > >>> > >>> commit c1d6f91952d0761f61b0f0f96e4c7aa32eee2788 > >>> Author: Przemyslaw Marczak > >>> Date: Wed Apr 15 13:07:17 2015 +0200 > >>> dm: core: add internal functions for getting the device without probe > >>> > >>> With this change, the dm unit tests started failing with a probe error > >>> -22 in the dm_test_children test. > >>> > >>> Test: dm_test_children > >>> test/dm/core.c:544, dm_test_children(): 0 == ret: Expected 0, got -22 > >>> > >>> This restores the original behavior which would avoid a probe on invalid > >>> device pointers. > >>> > >>> Signed-off-by: Joe Hershberger > >>> --- > >>> > >>> drivers/core/uclass.c | 8 ++++++-- > >>> 1 file changed, 6 insertions(+), 2 deletions(-) > >> > >> Can you please check this - it is very similar to yours: > >> > >> http://patchwork.ozlabs.org/patch/464459/ > > > > Yes, it looks like it solves the same problem. I don't care which way > > it gets solved. Looks like yours is already on the way in. Hopefully > > sooner than later. > > > > At what point will we make the tests be a gating factor for pulling > > patches, kinda like checkpatch.pl? > > Not sure, we don't even check that things build at present.... That's not quite true. For every PR I do: ./tools/buildman/buildman -b master --force-build --step 0 -dvel 'blackfin|microblaze|m68k|nds32|x86|aarch64|sandbox|mips|avr32|arm|powerpc|sh4' And check that things haven't changed or at least not changed in a breaking way. > Now that the tests are running again, I'll resume checking driver > model things before pulling things in. > > But we could use a way to run all tests, and some unification of them > (e.g. all run with the same U-Boot build). Yes, if it was easy to kick off most of the tests (ie anything we can do with sandbox) I'd integrate that into my process. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: