summaryrefslogtreecommitdiffstats
path: root/security
diff options
context:
space:
mode:
authorAlan Jenkins <alan-jenkins@tuffmail.co.uk>2009-12-03 07:45:09 +0000
committerLen Brown <len.brown@intel.com>2009-12-09 15:54:32 -0500
commit854c78363f37f03e30e2856ef17d7eefc62e0d06 (patch)
tree897125099c071c0afa2b7cfb799790c0a8a8bbd8 /security
parenta7624b63fdf50d7f460170891a49397280f08758 (diff)
downloadop-kernel-dev-854c78363f37f03e30e2856ef17d7eefc62e0d06.zip
op-kernel-dev-854c78363f37f03e30e2856ef17d7eefc62e0d06.tar.gz
eeepc-laptop: callbacks should use "driver data" parameter or field
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>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud