hardware-r-fwts-features: OEM-specific (hotkey) features
Colin Ian King
colin.king at canonical.com
Wed Nov 28 09:20:50 UTC 2012
On 28/11/12 08:20, Alex Hung wrote:
> Hi,
>
> As discussed in UDS-r, I modified drivers/platform/x86/hp-wmi.c to
> demonstrate my ideas of verifying OEM's BIOS interface, and the source
> code is attached. Please note it is still in early stage.
>
> Some highlights of my ideas:
>
> 1. fwts's OEM modules should replace existing ones during the execution,
> i.e. rmmod hp-wmi and insmod fwts's hp-wmi. This is done to focus on
> verify BIOS instead of exiting kernel modules.
A few Questions:
Is it our intention to ensure this modified version is kept in-sync with
the kernel? If so, how much effort is required?
Is the final aim to upstream this code so it is in the kernel?
I attempted to diff this but I am unsure which kernel version you based
it on. Which version?
>
> 2. sysfs nodes are used to trigger tests, and returns pass/fail. I tend
> to make the interface simpler and have kernel modules to perform the
> actual checking.
> For example,
> I. this hp-wmi.c creates
> "/sys/bus/platform/devices/hp-wmi/wireless-state_test.
> II. Reading wireless-state_test returns wireless devices recognized
> by BIOS (this can be used to compare with lspci or/and lsusb for read
> hardware devices) - can be added to fwts
> III. Writing to wireless-state_test triggers soft_block changes for
> supported wireless devices.
>
> 3. fwts can also expect a keycode from the modules, ex. adding the
> keycode in hp_wmi_notify who is expecting receives with hotkey presses
> (note: in 2.III HP BIOS also generates a HPWMI_WIRELESS event).
>
> As each OEM has different interfaces, we will need to create modules for
> thinkpad-acpi, asus-wmi, dell-laptops and so on.
>
> Any comments are most appreciated.
>
> Cheers,
> Alex Hung
>
>
More information about the fwts-devel
mailing list