public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
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

  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