Re: [PATCH v6 3/5] test: add new driver_data load tester

[Luis R. Rodriguez]

On Wed, May 17, 2017 at 05:45:22PM -0500, Li, Yi wrote:
> hi Luis
> 
> 
> On 5/11/2017 12:11 PM, Luis R. Rodriguez wrote:
> > On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote:
> > > Luis,
> > > 
> > > On Fri, Apr 28, 2017 at 03:45:35AM +0200, Luis R. Rodriguez wrote:
> > > > > > +To test an async call one could do::
> > > > > > +
> > > > > > +        echo anything > /lib/firmware/test-driver_data.bin
> > > > > Your current shell script doesn't search for the firmware in
> > > > > /lib/firmware unless you explicitly specify $FWPATH.
> > > > This is true but that is the *test* shell script, and it purposely avoids the
> > > > existing firmware path to avoid overriding dummy test files on the production
> > > > path. So the above still stands as it is not using the test shell script
> > > > driver_data.sh.
> > > > 
> > > > I'll add a note:
> > > > 
> > > > """
> > > > Note that driver_data.sh uses its own temporary custom path for creating and
> > > > looking for driver data files, it does this to not overwrite any production
> > > > files you might have which may share the same names used by the test shell
> > > > script driver_data.sh. If you are not using the driver_data.sh script your
> > > > default path will be used.
> > > > """
> > > That looks fine, but I think we'd better change the line:
> > > 
> > > > > > +        echo anything > /lib/firmware/test-driver_data.bin
> > > since it is just incorrect as far as driver_data.sh goes.
> > But that is accurate, given the default file we search for on test_driver_data.c
> > is test-driver_data.bin. It also does not create a conflict to overwrite a file
> > used on driver_data.sh as driver_data.sh uses a custom path. I think the note
> > above on custom path is sufficient for the developer or user to be aware of
> > the fact the driver_data.sh does it own thing, and that the example is just a
> > manual test case.
> > What do you mean by that its incorrect ?
> 
> I understand it now, but was on the same boat as Akashi. Renamed my 12MB
> test firmware binary to /lib/firmware/test-driver_data.bin, but
> driver_data.sh only read back 9 byes from the tmp "ABCD0123". :-)

Right, driver_data.sh is not to stress test a target file, it *builds*
tests and uses a temporary directory to avoid interfering with your own
files.

> What's the proper way to test a real image in the driver_data.sh script,
> change config_set_name?

Yes! You can review how it configures a test case to get an idea but the
name change is one, since you are doing it manually you would just avoid
resetting the firmware test path.

We could extend the script with an argument to leave the directory intact
and trust your own file given in an argument, but that would be a new test
case.

  Luis