All of lore.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: 38+ 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-13  5:27     ` 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 22:42 ` 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-14 23:17 ` Brown, Len
2006-04-19 17:14 Moore, Robert
2006-04-19 17:14 ` Moore, Robert
2006-04-19 17:36 ` Patrick Mochel
2006-04-19 17:51 Moore, Robert
2006-04-19 17:51 ` Moore, Robert
2006-04-19 18:06 ` Patrick Mochel
2006-04-19 19:17 Moore, Robert
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.