From: Bruno Ducrot <ducrot@poupinou.org>
To: Johan Vromans <jvromans@squirrel.nl>
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: RFC [PATCH] acpi: allow SMBus access
Date: Mon, 3 Jul 2006 14:51:56 +0200 [thread overview]
Message-ID: <20060703125156.GD17014@poupinou.org> (raw)
In-Reply-To: <m2mzbrj5yp.fsf@phoenix.squirrel.nl>
On Mon, Jul 03, 2006 at 01:14:22PM +0200, Johan Vromans wrote:
> Bruno Ducrot <ducrot@poupinou.org> writes:
>
> > I don't think this patch is correct, or else I would have already
> > asked this patch being added to mainline.
>
> You've been standing at the origins of where this patch came from. Can
> you provide a better alternative?
>
If you want this patch to be applied, I think you should at least
mark ec_read/ec_write being obsolete and maybe provide a
solution for drivers who use those functions, as for example
sonypi. Having two very same kind of access for the EC is
not good IMHO.
In fact why I didn't submitted this patch myself is because
I wanted to provide a real bus access via the EC driver, including
the interrupt driven ones.
Something like that :
int acpi_ec_register(struct acpi_ec_driver *child);
int acpi_ec_unregister(struct acpi_ec_driver *child);
The struct acpi_ec_driver should be something like that:
struct acpi_ec_driver {
acpi_handle ec_handle;
acpi_handle handle;
unsigned long uid;
unsigned long query;
int (*acpi_ec_query_handler) (???);
...
/* maybe a private space somewhere */
void *private;
}
reading/writing may pass perhaps via an exported acpi_ec_(read|write)()
functions, but the real key would have to be able to register a function
in order to trigger the acpi_ec_query_handler function member when the EC
receive the interrupt for the query number ->query instead of the _Qxx
method provided by the OEM. Please look at ACPI 3.0 specification,
more precisely "5.6.2.2.2 Dispatching to an ACPI-aware Device Driver",
and the whole chapter 12 (ACPI Embedded Controller Interface Specification).
We may have then an access to the ACPI EC HC SMbus with a interrupt
driven driver, which imho is the correct approach: we will be sure
a _Qxx method provided by the bios writer will interferre with our
SMbus driver.
Unfortunately I don't have anymore the time to provide this support
for Linux.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
next prev parent reply other threads:[~2006-07-03 12:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-02 21:12 RFC [PATCH] acpi: allow SMBus access Johan Vromans
2006-07-03 1:51 ` Yu Luming
2006-07-03 8:22 ` Bruno Ducrot
2006-07-03 8:22 ` Bruno Ducrot
2006-07-03 11:14 ` Johan Vromans
2006-07-03 12:51 ` Bruno Ducrot [this message]
2006-07-04 8:09 ` Johan Vromans
2006-07-04 9:35 ` Bruno Ducrot
2006-07-04 11:44 ` Johan Vromans
2006-07-06 13:58 ` Johan Vromans
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=20060703125156.GD17014@poupinou.org \
--to=ducrot@poupinou.org \
--cc=jvromans@squirrel.nl \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.