[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4545ecbd-b030-a2c0-66f2-faf4116b04b6@linux.intel.com>
Date: Wed, 17 May 2017 17:45:22 -0500
From: "Li, Yi" <yi1.li@...ux.intel.com>
To: "Luis R. Rodriguez" <mcgrof@...e.com>,
AKASHI Takahiro <takahiro.akashi@...aro.org>,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
gregkh@...uxfoundation.org, wagi@...om.org, dwmw2@...radead.org,
rafal@...ecki.pl, arend.vanspriel@...adcom.com, rjw@...ysocki.net,
atull@...nsource.altera.com, moritz.fischer@...us.com,
pmladek@...e.com, johannes.berg@...el.com,
emmanuel.grumbach@...el.com, luciano.coelho@...el.com,
kvalo@...eaurora.org, luto@...nel.org, dhowells@...hat.com,
pjones@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 3/5] test: add new driver_data load tester
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". :-)
What's the proper way to test a real image in the driver_data.sh script,
change config_set_name?
Yi
>
> Luis
>
Powered by blists - more mailing lists