forked from luck/tmp_suning_uos_patched
854c78363f
Callback methods should not refer to a variable like "eeepc" (formally
"ehotk"). Instead, they should extract the data they need either from
a "driver data" parameter, or the "driver data" field of the object
which they operate on. The "eeepc" variable can then be removed.
In practice, drivers under "drivers/platform" can get away without using
driver data, because it doesn't make sense to have more than one
instance of them. However this makes it harder to review them for
correctness. This is especially true for core ACPI developers who have
not previously been exposed to this anti-pattern :-).
This will serve as an example of best practice for new driver writers
(whether they find it themselves, or have it pointed out during review
:-).
The hwmon sub-device is a special case. It uses ec_{read,write} which
are defined to communicate with the (first) EC, so it does not require
any driver data. It should still only be instantiated in the context of
an ASUS010 device because we don't have a safe way to probe for it.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
CC: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
||
|---|---|---|
| .. | ||
| acer-wmi.c | ||
| acerhdf.c | ||
| asus_acpi.c | ||
| asus-laptop.c | ||
| compal-laptop.c | ||
| dell-laptop.c | ||
| dell-wmi.c | ||
| eeepc-laptop.c | ||
| fujitsu-laptop.c | ||
| hp-wmi.c | ||
| intel_menlow.c | ||
| Kconfig | ||
| Makefile | ||
| msi-laptop.c | ||
| panasonic-laptop.c | ||
| sony-laptop.c | ||
| tc1100-wmi.c | ||
| thinkpad_acpi.c | ||
| topstar-laptop.c | ||
| toshiba_acpi.c | ||
| wmi.c | ||