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

Simon Glass sjg at chromium.org
Fri May 1 16:23:39 CEST 2015


Hi Tom,

On 1 May 2015 at 07:38, Tom Rini <trini at konsulko.com> wrote:
>
> 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.

Oops I completely got the wrong end of the stick there. I was thinking
of a something like checkpatch that checks the build and tests before
people send patches. It's an idea that has come up before but I'm
don't think anyone has a good idea on how to do it.

Of course PRs are built! I do the same before sending them, although I
actually don't --force-build which might leave me open to problems.
Sorry Tom.

>
> > 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.

Me too. Something I vaguely think about tidying up one day.

Regards,
Simon


More information about the U-Boot mailing list