[U-Boot] [PATCH] dm: core: Fix regression caused by c1d6f91

[Tom Rini]

On Thu, Apr 30, 2015 at 07:54:21PM -0600, Simon Glass wrote:
> Hi Joe,
> 
> On 29 April 2015 at 10:17, Joe Hershberger <joe.hershberger at gmail.com> wrote:
> > Hi Simon,
> >
> > On Wed, Apr 29, 2015 at 8:30 AM, Simon Glass <sjg at chromium.org> wrote:
> >> Hi Joe,
> >>
> >> On 28 April 2015 at 22:14, Joe Hershberger <joe.hershberger at ni.com> wrote:
> >>> The change to refactor these functions created a regression.
> >>>
> >>> commit c1d6f91952d0761f61b0f0f96e4c7aa32eee2788
> >>> Author: Przemyslaw Marczak <p.marczak at samsung.com>
> >>> 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 <joe.hershberger at ni.com>
> >>> ---
> >>>
> >>>  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: <http://lists.denx.de/pipermail/u-boot/attachments/20150501/d8475932/attachment.sig>