From: Patrick Mochel <mochel@linux.intel.com>
To: Kristen Accardi <kristen.c.accardi@intel.com>
Cc: Prarit Bhargava <prarit@sgi.com>, Andrew Morton <akpm@osdl.org>,
len.brown@intel.com, greg@kroah.com, linux-acpi@vger.kernel.org,
pcihpd-discuss@lists.sourceforge.net,
linux-kernel@vger.kernel.org, arjan@linux.intel.com,
muneda.takahiro@jp.fujitsu.com, pavel@ucw.cz, temnota@kmv.ru
Subject: Re: [patch 1/3] acpi: dock driver
Date: Tue, 18 Apr 2006 15:54:27 -0700 [thread overview]
Message-ID: <20060418225427.GE4556@linux.intel.com> (raw)
In-Reply-To: <1145383396.10783.32.camel@whizzy>
On Tue, Apr 18, 2006 at 11:03:16AM -0700, Kristen Accardi wrote:
> Create a driver which lives in the acpi subsystem to handle dock events. This
> driver is not an acpi driver, because acpi drivers require that the object
> be present when the driver is loaded.
A few comments..
> --- /dev/null
> +++ 2.6-git-kca2/drivers/acpi/dock.c
> @@ -0,0 +1,652 @@
> +#define ACPI_DOCK_COMPONENT 0x10000000
> +#define ACPI_DOCK_DRIVER_NAME "ACPI Dock Station Driver"
> +#define _COMPONENT ACPI_DOCK_COMPONENT
These aren't necessary for code that is outside of the ACPI-CA.
> +struct dock_station {
> + acpi_handle handle;
> + unsigned long last_dock_time;
> + u32 flags;
> + spinlock_t dd_lock;
> + spinlock_t hp_lock;
> + struct list_head dependent_devices;
> + struct list_head hotplug_devices;
> +};
> +
> +struct dock_dependent_device {
> + struct list_head list;
> + struct list_head hotplug_list;
> + acpi_handle handle;
> + acpi_notify_handler handler;
> + void *context;
> +};
> +
> +#define DOCK_DOCKING 0x00000001
> +
> +static struct dock_station *dock_station;
Does this need to be dynamically allocated? Static initialization
would be a bit cleaner and obviate the need for the NULL checks in
several of the functions below.
> +/**
> + * eject_dock - respond to a dock eject request
> + * @ds: the dock station
> + *
> + * This is called after _DCK is called, to execute the dock station's
> + * _EJ0 method.
> + */
> +static void eject_dock(struct dock_station *ds)
> +{
> + struct acpi_object_list arg_list;
> + union acpi_object arg;
> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> + union acpi_object *obj;
> +
> + acpi_get_name(ds->handle, ACPI_FULL_PATHNAME, &buffer);
> + obj = buffer.pointer;
> +
> + arg_list.count = 1;
> + arg_list.pointer = &arg;
> + arg.type = ACPI_TYPE_INTEGER;
> + arg.integer.value = 1;
Minor nit (that is replicated in many of the ACPI drivers). This can be
done by just describing the data better:
struct acpi_object arg = {
.type = ACPI_TYPE_INTEGER,
.integer = {
.value = 1,
},
};
struct acpi_object_list arg_list = {
.count = 1,
.pointer = &arg,
};
...
In the long run, since the same exact code exists in dozens of places
in the ACPI drivers, there should just be a helper for it. E.g.:
int ret;
unsigned long value;
ret = acpi_get_int(ds->handle, "_EJO", &value);
if (!ret)
/* Use Value */
else
/* Error */
...and get rid of the awkward object/object list handling.
> +static inline void begin_dock(struct dock_station *ds)
> +{
> + ds->flags |= DOCK_DOCKING;
> +}
> +
> +static inline void complete_dock(struct dock_station *ds)
> +{
> + ds->flags &= ~(DOCK_DOCKING);
> + ds->last_dock_time = jiffies;
> +}
> +
> +/**
> + * dock_in_progress - see if we are in the middle of handling a dock event
> + * @ds: the dock station
> + *
> + * Sometimes while docking, false dock events can be sent to the driver
> + * because good connections aren't made or some other reason. Ignore these
> + * if we are in the middle of doing something.
> + */
> +static int dock_in_progress(struct dock_station *ds)
> +{
> + if ((ds->flags & DOCK_DOCKING) ||
> + time_before(jiffies, (ds->last_dock_time + HZ)))
> + return 1;
> + return 0;
> +}
These seem racy. It seems the flag should should at least be an atomic_t. But,
if it's that, then it might as well be a mutex, eh? And, if it's a mutex, then
do we need the other spinlocks?
> +acpi_status
> +register_hotplug_dock_device(acpi_handle handle, acpi_notify_handler handler,
> + void *context)
If this is called from outside drivers/acpi/, you should return an int with a
real errno value. The AE_* values shouldn't be used outside of the ACPI CA.
> +acpi_status unregister_hotplug_dock_device(acpi_handle handle)
Does unregister need to return an error?
Thanks,
Pat
next prev parent reply other threads:[~2006-04-18 22:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060412221027.472109000@intel.com>
2006-04-12 22:18 ` [patch 1/3] acpi: dock driver Kristen Accardi
2006-04-12 22:35 ` [patch 1/3] acpi: dock driver (refreshed) Kristen Accardi
2006-04-13 5:27 ` [patch 1/3] acpi: dock driver Andrew Morton
2006-04-14 22:02 ` Kristen Accardi
2006-04-14 22:49 ` Kristen Accardi
2006-04-15 14:29 ` Prarit Bhargava
2006-04-18 18:03 ` Kristen Accardi
2006-04-18 22:54 ` Patrick Mochel [this message]
2006-04-19 17:08 ` Kristen Accardi
2006-04-19 17:28 ` Patrick Mochel
2006-04-19 18:28 ` Kristen Accardi
2006-04-19 18:20 ` Patrick Mochel
2006-04-28 23:51 ` [patch 1/3] acpi: dock driver v3 Kristen Accardi
2006-05-11 18:45 ` [patch 1/3] acpi: dock driver v4 Kristen Accardi
2006-06-01 23:05 ` [patch 1/3] acpi: dock driver v6 Kristen Accardi
2006-06-01 23:20 ` Andrew Morton
2006-06-02 0:53 ` Kristen Accardi
2006-04-16 13:28 ` [patch 1/3] acpi: dock driver Prarit Bhargava
2006-04-12 22:18 ` [patch 2/3] acpiphp: use new " Kristen Accardi
2006-04-12 23:16 ` Christian Trefzer
2006-04-28 23:55 ` [patch 2/3] acpiphp: use new dock driver v2 Kristen Accardi
2006-04-12 22:18 ` [patch 3/3] acpiphp: prevent duplicate slot numbers when no _SUN Kristen Accardi
2006-04-13 12:36 ` MUNEDA Takahiro
2006-04-14 21:39 ` Kristen Accardi
2006-04-14 22:42 [patch 1/3] acpi: dock driver Brown, Len
2006-04-14 23:11 ` Kristen Accardi
-- strict thread matches above, loose matches on Subject: below --
2006-04-14 23:17 Brown, Len
2006-04-19 17:14 Moore, Robert
2006-04-19 17:36 ` Patrick Mochel
2006-04-19 17:51 Moore, Robert
2006-04-19 18:06 ` Patrick Mochel
2006-04-19 19:17 Moore, Robert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060418225427.GE4556@linux.intel.com \
--to=mochel@linux.intel.com \
--cc=akpm@osdl.org \
--cc=arjan@linux.intel.com \
--cc=greg@kroah.com \
--cc=kristen.c.accardi@intel.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=muneda.takahiro@jp.fujitsu.com \
--cc=pavel@ucw.cz \
--cc=pcihpd-discuss@lists.sourceforge.net \
--cc=prarit@sgi.com \
--cc=temnota@kmv.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox