[PATCH v2 02/10] test: pinmux: Add test for pin muxing

[Sean Anderson]

On 6/24/20 9:45 AM, Simon Glass wrote:
> Hi Sean,
> 
> On Wed, 24 Jun 2020 at 02:01, Sean Anderson <seanga2 at gmail.com> wrote:
>>
>> On 6/17/20 10:07 AM, Simon Glass wrote:
>>> Hi Sean,
>>>
>>> On Tue, 16 Jun 2020 at 21:18, Sean Anderson <seanga2 at gmail.com> wrote:
>>>>
>>>> On 6/16/20 11:11 PM, Simon Glass wrote:
>>>>> Hi Sean,
>>>>>
>>>>> On Sun, 7 Jun 2020 at 19:27, Sean Anderson <seanga2 at gmail.com> wrote:
>>>>>>
>>>>>> This extends the pinctrl-sandbox driver to support pin muxing, and adds a
>>>>>> test for that behaviour. The test is done in C and not python (like the
>>>>>> existing tests for the pinctrl uclass) because it needs to call
>>>>>> pinctrl_select_state.  Another option could be to add a command that
>>>>>> invokes pinctrl_select_state and then test everything in
>>>>>> test/py/tests/test_pinmux.py.
>>>>>>
>>>>>> The pinctrl-sandbox driver now mimics the way that many pinmux devices
>>>>>> work.  There are two groups of pins which are muxed together, as well as
>>>>>> four pins which are muxed individually. I have tried to test all normal
>>>>>> paths. However, very few error cases are explicitly checked for.
>>>>>>
>>>>>> Signed-off-by: Sean Anderson <seanga2 at gmail.com>
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - New
>>>>>>
>>>>>>  arch/sandbox/dts/test.dts         |  45 +++++++--
>>>>>>  drivers/pinctrl/pinctrl-sandbox.c | 155 +++++++++++++++++++++++-------
>>>>>>  test/dm/Makefile                  |   3 +
>>>>>>  test/py/tests/test_pinmux.py      |  36 +++----
>>>>>>  4 files changed, 178 insertions(+), 61 deletions(-)
>>>>>>
>>>>>
>>>>> [..]
>>>>>
>>>>>
>>>>>> diff --git a/test/dm/Makefile b/test/dm/Makefile
>>>>>> index 0d1c66fa1e..9e273ee02d 100644
>>>>>> --- a/test/dm/Makefile
>>>>>> +++ b/test/dm/Makefile
>>>>>> @@ -76,4 +76,7 @@ obj-$(CONFIG_DM_RNG) += rng.o
>>>>>>  obj-$(CONFIG_CLK_K210_SET_RATE) += k210_pll.o
>>>>>>  obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o
>>>>>>  obj-$(CONFIG_RESET_SYSCON) += syscon-reset.o
>>>>>> +ifneq ($(CONFIG_PINMUX),)
>>>>>> +obj-$(CONFIG_PINCONF) += pinmux.o
>>>>>
>>>>> I don't see this file in your patch.
>>>>
>>>> Whoops, will add it next revision.
>>>>
>>>>>
>>>>>> +endif
>>>>>>  endif
>>>>>> diff --git a/test/py/tests/test_pinmux.py b/test/py/tests/test_pinmux.py
>>>>>> index 4e6df992a4..0cbbae000c 100644
>>>>>> --- a/test/py/tests/test_pinmux.py
>>>>>> +++ b/test/py/tests/test_pinmux.py
>>>>>> @@ -28,15 +28,15 @@ def test_pinmux_status_all(u_boot_console):
>>>>>
>>>>> Feel free to convert this to C also if you like. It is faster,
>>>>> although perhaps not much faster since it only runs a few commands?
>>>>
>>>> Ok, I can have a look.
>>>>
>>>> Should C be preferred for new tests?
>>>
>>> +Stephen Warren
>>>
>>> For sandbox tests, yes. If there is a lot of interaction, Python is
>>> extremely slow.
>>>
>>> But with Python we can run a test on real hardware without compiling
>>> the test into U-Boot. So there are benefits on both sides.
>>
>> Ok, I looked into it, and the python test uses the
>>     assert 'somestring' in output
>> idiom a lot. From what I can tell, there's not an easy way to replicate
>> this behavior on the C side of things. Adding a function to do this
>> would probably call for its own patch. I could also use the existing
>> functionality to test for lines, but I think that would be much more
>> brittle when compared to the python version.
> 
> Well you could add assert_nextline_contains() for example?

Yes, but I would also have to skip a specific number of lines, e.g.

console_record_reset();
run_command("pinmux", 0);
ut_assert_nextline_contains("");
ut_assert_nextline_contains("");
ut_assert_nextline_contains("Usage:");

console_record_reset();
/* ... */

That's ok, but still fairly brittle in how it tests the output.

Oh well, perhaps I'll add something like that next revision...

--Sean