[PATCH 0/2] oem: add oem-specific tests for verifying BIOS interfaces

[Alex Hung]

Hi Kengyu,

It should be mostly get and set since that's how kernel and BIOS interact with each other; however that may be also depend on the OEM BIOS design. For example, triggering a wireless set in hp-wmi generate a WMI event, which I also plan to include a test later.

Cheers, 
Alex Hung






Keng-Yu Lin <kengyu at canonical.com> wrote:

>Hi Alex:
>  The idea of removing the rfkill makes this a bit more convincing.
>
>  Can you give us some idea of what kind of tests you will like to
>implement based on the kernel module? (besides the wireless state
>get() and set()).
>
>  So we can have the overview and better understand the role of this
>kernel module.
>
>  cheers,
>-kengyu
>
>On Tue, Dec 11, 2012 at 1:52 PM, Alex Hung <alex.hung at canonical.com> wrote:
>> Hi,
>>
>> I am trying to avoid the needs to sync up with hp-wmi.c in kernel source.
>> After all, it is the BIOS interfaces that are tested, not the kernel driver
>> - of course in theory we can also come back to check kernel driver if BIOS
>> interfaces are working perfectly according to our tests.
>>
>> That's also why I removed rfkill devices so an userspace application cannot
>> alter the wireless states during the tests.
>>
>> Cheers,
>> Alex Hung
>>
>>
>> On 12/11/2012 01:33 PM, Keng-Yu Lin wrote:
>>>
>>> Is it possible to re-wrap the get_wireless_device() and
>>> set_wireless_device() in the original hp_wmi.c (the one in the kernel)
>>> and export them via the debugfs.
>>>
>>> So we can manipulate them and build the test from the userspace on them.
>>>
>>> If the get and the set are the only two kernel functions needed, this
>>> may be doable.
>>>
>>> Any comment?
>>>
>>> On Mon, Dec 10, 2012 at 10:29 AM, Alex Hung <alex.hung at canonical.com>
>>> wrote:
>>>>
>>>> Each OEM (i.e. hp, dell, acer, asus and so on) has different set of BIOS
>>>> interfaces for implementing OEM features, such as wireless device
>>>> controls and
>>>> special power management, that are not defined in ACPI specification.
>>>>
>>>> It may worth noting that the kernel module is not integrated into fwts,
>>>> i.e. it
>>>> will not be compiled with fwts. The intended behaviors is not to make a
>>>> dkms
>>>> package to replace the origin kernel module, but is to do the following
>>>> (using hp-wmi as an example):
>>>>
>>>> 1. rmmod original hp-wmi.ko
>>>> 2. insmod new hp-wmi.ko
>>>> 3. run the tests
>>>> 4. rmmod new hp-wmi.ko
>>>> 5. insmod original hp-wmi.ko
>>>>
>>>> Does the above make sense? Any comments are appreciated.
>>>>
>>>> Alex Hung (2):
>>>>    oem: wireless: add tests for toggling the states of wireless device,
>>>>         including WIFI, Bluetooth and WWAN (3G), via a kernel interface
>>>>      that     will be created for different OEM systems (i.e. ASUS,
>>>>      Dell, HP, and     so on).
>>>>    oem: the kernel module creates an ioctl sys nodes for testing hp's
>>>>       WMI interface. This interface currently supports WMI command 0x1b,
>>>>          including get and set functions.
>>>>
>>>>   oem/Makefile                |    6 +
>>>>   oem/hp-wmi.c                |  533
>>>> +++++++++++++++++++++++++++++++++++++++++++
>>>>   src/Makefile.am             |    3 +-
>>>>   src/oem/wireless/wireless.c |  189 +++++++++++++++
>>>>   4 files changed, 730 insertions(+), 1 deletion(-)
>>>>   create mode 100644 oem/Makefile
>>>>   create mode 100644 oem/hp-wmi.c
>>>>   create mode 100644 src/oem/wireless/wireless.c
>>>>
>>>> --
>>>> 1.7.10.4
>>>>
>>>>
>>>> --
>>>> fwts-devel mailing list
>>>> fwts-devel at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/fwts-devel
>>>
>>>
>>
>