]> git.openfabrics.org - ~shefty/rdma-dev.git/commit
eeepc-laptop: callbacks should use "driver data" parameter or field
authorAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Thu, 3 Dec 2009 07:45:09 +0000 (07:45 +0000)
committerLen Brown <len.brown@intel.com>
Wed, 9 Dec 2009 20:54:32 +0000 (15:54 -0500)
commit854c78363f37f03e30e2856ef17d7eefc62e0d06
tree897125099c071c0afa2b7cfb799790c0a8a8bbd8
parenta7624b63fdf50d7f460170891a49397280f08758
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>
drivers/platform/x86/eeepc-laptop.c