linux-kernel - Re: [PATCH v6 3/5] test: add new driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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
>