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@gmail.com wrote:
Hi Simon,
On Wed, Apr 29, 2015 at 8:30 AM, Simon Glass sjg@chromium.org wrote:
Hi Joe,
On 28 April 2015 at 22:14, Joe Hershberger joe.hershberger@ni.com wrote:
The change to refactor these functions created a regression.
commit c1d6f91952d0761f61b0f0f96e4c7aa32eee2788 Author: Przemyslaw Marczak p.marczak@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@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:
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.