linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: [patch 1/3] acpi: dock driver
@ 2006-04-14 22:42 Brown, Len
  2006-04-14 23:11 ` Kristen Accardi
  0 siblings, 1 reply; 32+ messages in thread
From: Brown, Len @ 2006-04-14 22:42 UTC (permalink / raw)
  To: Accardi, Kristen C, Andrew Morton
  Cc: greg, linux-acpi, pcihpd-discuss, linux-kernel, mochel, arjan,
	muneda.takahiro, pavel, temnota

 
Re: indenting & white-space

Please run the whole thing through the latest Lindent.
It will delete the white space.
It will do a couple of stupid things with indenting --
such as with MODULE_AUTHOR --
feel free to hand tweak those by hand.

Re: acpi_os_free()
Please call kfree() instead, that wrapper is intended
just for the ACPICA core and although it appears symmetric,
it really shouldn't be used outside drivers/acpi/*/*.c

Re: ACPI_FUNCTION_TRACE()/return_VALUE()
Don't feel compelled to include these idioms unless
you think they will really be useful.

Re: ACPI_FAILURE()
just use printk(KERN_whatever_level_you_like "...") here.

Re: ACPI_DEBUG_PRINT()
note that these appear only with CONFIG_ACPI_DEBUG
(along with tracing).  So if you want it to go away
in the production kernel, this is okay.  but if you want
it to ship in the production kernel, use printk().


> > +config ACPI_DOCK
> > +	tristate "Dock"
> > +	default y
> > +	help
> > +	  This driver adds support for ACPI controlled docking stations
> 
> It doesn't depend upon anything else?

What happens if the acpi_ibm driver's docking support is enabled at the
same time.
Perhaps that should depend on not this?

-Len

^ permalink raw reply	[flat|nested] 32+ messages in thread
* RE: [patch 1/3] acpi: dock driver
@ 2006-04-14 23:17 Brown, Len
  0 siblings, 0 replies; 32+ messages in thread
From: Brown, Len @ 2006-04-14 23:17 UTC (permalink / raw)
  To: Accardi, Kristen C
  Cc: Andrew Morton, greg, linux-acpi, pcihpd-discuss, linux-kernel,
	mochel, arjan, muneda.takahiro, pavel, temnota

 
On Fri, 2006-04-14 at 15:42 -0700, Brown, Len wrote:

>> Re: acpi_os_free()
>> Please call kfree() instead, that wrapper is intended
>> just for the ACPICA core and although it appears symmetric,
>> it really shouldn't be used outside drivers/acpi/*/*.c

> Really?  why is it exported then?  We use this in drivers/pci/hotplug
as
> well, and it is all over the place in drivers/acpi.  Should I be
> modifying the hotplug drivers to not use this call?

yes.

re: why it is exported?
this is just the tip of the ice-berg of things that are exported and
should not be.

thanks,
-Len

^ permalink raw reply	[flat|nested] 32+ messages in thread
* RE: [patch 1/3] acpi: dock driver
@ 2006-04-19 17:14 Moore, Robert
  2006-04-19 17:36 ` Patrick Mochel
  0 siblings, 1 reply; 32+ messages in thread
From: Moore, Robert @ 2006-04-19 17:14 UTC (permalink / raw)
  To: Accardi, Kristen C, Patrick Mochel
  Cc: Prarit Bhargava, Andrew Morton, Brown, Len, greg, linux-acpi,
	pcihpd-discuss, linux-kernel, arjan, muneda.takahiro, pavel,
	temnota

This is something to think about before we rip out all the ACPI
core-style debug stuff.


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Kristen Accardi
> Sent: Wednesday, April 19, 2006 10:09 AM
> To: Patrick Mochel
> Cc: Prarit Bhargava; Andrew Morton; Brown, Len; 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
> 
> On Tue, 2006-04-18 at 15:54 -0700, Patrick Mochel wrote:
> > 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.
> 
> Originally I did not include these, but it turns out if you wish to
use
> the ACPI_DEBUG macro, you need to have these things defined.  I did go
> ahead and use this macro in a couple places, mainly because I felt
that
> even though this isn't strictly an acpi driver (using the acpi driver
> model), it does live in drivers/acpi and perhaps people might expect
to
> be able to debug it the same way.
> 
> >
> > > +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.
> >
> 
> It could be statically allocated, but I have a preference towards not
> allocating statically in this case.  I will consider the option of
> making it static.
> 
> > > +/**
> > > + * 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?
> >
> 
> yes, the flag might be racy.  we do need the other spinlocks however,
> because they are locking lists within the dock_station struct, but not
> the entire struct (unless I just change to something that locks the
> entire struct).
> 
> > > +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.
> >
> 
> Really?  We use these all over the place in drivers/pci/hotplug.  In
> fact, you kinda have to use them if you are calling certain acpi
> symbols, since they return these types.
> 
> For example, here are some functions will return acpi_status that we
use
> in hotplug land.
> 
> pci_osc_control_set()
> acpi_run_oshp()
> acpi_walk_namespace requires its use.
> 
> I felt that by returning acpi_status I was being consistent with how
> other acpi calls acted.  Is this another example of the iceberg that
Len
> was talking about in a previous email?? (ugh.)
> 
> 
> >
> > > +acpi_status unregister_hotplug_dock_device(acpi_handle handle)
> >
> > Does unregister need to return an error?
> >
> 
> No probably not.
> 
> >
> > Thanks,
> >
> >
> > 	Pat
> 
> thanks for reviewing again :).
> 
> Kristen
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 32+ messages in thread
* RE: [patch 1/3] acpi: dock driver
@ 2006-04-19 17:51 Moore, Robert
  2006-04-19 18:06 ` Patrick Mochel
  0 siblings, 1 reply; 32+ messages in thread
From: Moore, Robert @ 2006-04-19 17:51 UTC (permalink / raw)
  To: Patrick Mochel, Accardi, Kristen C
  Cc: Prarit Bhargava, Andrew Morton, Brown, Len, greg, linux-acpi,
	pcihpd-discuss, linux-kernel, arjan, muneda.takahiro, pavel,
	temnota


Architecturally, this was the design of ACPICA -- that anything
OS-dependent would be written in whatever format/style/exception
model/threading model/blah as the host OS.

We even discussed having an interface layer in order to translate
incoming requests (to ACPICA) from the host drivers to ACPICA requests,
and then translate the output (such as exception codes) back to the host
format, but we ended up deciding that this was overkill. 

I certainly agree that it is not a good idea to mix exception code
spaces.

Bob


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Patrick Mochel
> Sent: Wednesday, April 19, 2006 10:28 AM
> To: Accardi, Kristen C
> Cc: Prarit Bhargava; Andrew Morton; Brown, Len; 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
> 
> On Wed, Apr 19, 2006 at 10:08:57AM -0700, Kristen Accardi wrote:
> > On Tue, 2006-04-18 at 15:54 -0700, Patrick Mochel wrote:
> 
> > > > +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.
> > >
> >
> > Really?  We use these all over the place in drivers/pci/hotplug.  In
> > fact, you kinda have to use them if you are calling certain acpi
> > symbols, since they return these types.
> >
> > For example, here are some functions will return acpi_status that we
use
> > in hotplug land.
> >
> > pci_osc_control_set()
> > acpi_run_oshp()
> > acpi_walk_namespace requires its use.
> 
> Well, it's one thing to use a function that returns a non-standard
error-
> value,
> but it's another to add more functions that do. :-)
> 
> > I felt that by returning acpi_status I was being consistent with how
> > other acpi calls acted.  Is this another example of the iceberg that
Len
> > was talking about in a previous email?? (ugh.)
> 
> I believe so.
> 
> We have a standard, well-defined error namespace that lives in
> include/*/errno.h.
> ACPI defines its own error namespace because it must be portable, and
even
> though
> most OSes will define the standard errno values, some do not, so it
cannot
> assume that it will be there. I'm not sure why the choice was to
redefine
> similar
> error values instead of reusing the errno values, but that's moot at
this
> point..
> 
> The only place where the ACPI error values need to be used is in the
ACPI
> CA. The
> functions exposed to the OS from the CA will return AE_* because the
same
> source
> runs everywhere. However, Linux-specific code doesn't need to do that.
It
> is free
> to use Linux-specific error reporting (except in the OSL layer that
the CA
> uses,
> because it is expecting well-defined return values, as specified in
the CA
> Programmers Reference).
> 
> My standpoint is that Linux-specific code should not be using any ACPI
> CAisms at
> all because since the code is Linux-specific, it doesn't need to be
> portable in
> the same manner that the CA is. This is true for all of
drivers/acpi/*.c,
> with the
> exception of drivers/acpi/osl.c, but even some of that source can be
> cleaned up
> to be more Linux-friendly.
> 
> Further rationale is that there is no way to enforce the CAisms in
Linux-
> specific
> code. You will frequently find mixed return values. Sometimes a
function
> is
> declared as
> 
> 	acpi_status acpi_foo()
> 
> and return -1 and 0. Or vice versa.
> 
> The ACPI drivers were initially written in the same style that the CA
was
> written,
> which makes it confusing when you look at them. But, they don't need
to be
> that
> way. They can look like real Linux drivers and become a lot more
> palatable.
> 
> Eventually, all of the CAisms should be pushed down to the thin layer
that
> sits
> above the interpreter. All exported functions should return ints, and
> those that
> deal directly with the CA interface should simply translate the AE_*
error
> values into an errno return.
> 
> Thanks,
> 
> 
> 	Pat
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 32+ messages in thread
* RE: [patch 1/3] acpi: dock driver
@ 2006-04-19 19:17 Moore, Robert
  0 siblings, 0 replies; 32+ messages in thread
From: Moore, Robert @ 2006-04-19 19:17 UTC (permalink / raw)
  To: Patrick Mochel
  Cc: Accardi, Kristen C, Prarit Bhargava, Andrew Morton, Brown, Len,
	greg, linux-acpi, pcihpd-discuss, linux-kernel, arjan,
	muneda.takahiro, pavel, temnota

Whatever makes the most sense for the host OS.

I think the original linux/acpi drivers were developed and debugged at
the same time we were debugging the ACPICA core code, and it became very
convenient to use the ACPI tracing and debugging mechanism to grab
information about everything that was going on, ACPI-wise. This may or
may not be important today.

Also, there may come a time when we will decide to remove the tracing
mechanism in ACPICA. However, over the years, this mechanism has proven
very useful in finding problems. The execution trace is very helpful
because of the nature of the AML interpretation and internal state
changes.

Bob


> -----Original Message-----
> From: Patrick Mochel [mailto:mochel@linux.intel.com]
> Sent: Wednesday, April 19, 2006 10:37 AM
> To: Moore, Robert
> Cc: Accardi, Kristen C; Prarit Bhargava; Andrew Morton; Brown, Len;
> 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
> 
> On Wed, Apr 19, 2006 at 10:14:46AM -0700, Moore, Robert wrote:
> > This is something to think about before we rip out all the ACPI
> > core-style debug stuff.
> 
> Not sure which part you're referring to, but maybe these:
> 
> > > > > --- /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.
> > >
> > > Originally I did not include these, but it turns out if you wish
to
> > use
> > > the ACPI_DEBUG macro, you need to have these things defined.  I
did go
> > > ahead and use this macro in a couple places, mainly because I felt
> > that
> > > even though this isn't strictly an acpi driver (using the acpi
driver
> > > model), it does live in drivers/acpi and perhaps people might
expect
> > to
> > > be able to debug it the same way.
> 
> 
> Some of us have already thought about it. :-)
> 
> We have standard debugging macros that are used in many driver
subsystems
> defined in include/linux/device.h (dev_printk(), dev_dbg(), dev_err(),
and
> friends). The ACPI drivers are not very different than other Linux
driver
> subsystems (at a very basic level). They are very Linux-specific (not
> portable like the CA), and should be using Linux-specific constructs
as
> much as possible to match the rest of the kernel. This makes it much
> eaiser for people to understand exactly what those drivers are doing..
> 
> 
> 	Pat

^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2006-06-02  0:41 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).