linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Seth Forshee <seth.forshee@canonical.com>,
	Len Brown <lenb@kernel.org>,
	Azael Avalos <coproscefalo@gmail.com>,
	platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Subject: Re: [PATCH 1/4] ACPI: EC: Add ec_get_handle()
Date: Fri, 16 Dec 2011 02:52:25 +0100	[thread overview]
Message-ID: <201112160252.26681.trenn@suse.de> (raw)
In-Reply-To: <20111216003333.GA18489@srcf.ucam.org>

On Friday 16 December 2011 01:33:33 Matthew Garrett wrote:
> On Fri, Dec 16, 2011 at 01:22:35AM +0100, Thomas Renninger wrote:
> 
> > I think best is to move the thinkpad implementation of getting
> > ACPI handles based on HIDs to osl.c and make it global.
> > I'll send patches.
> > Please review them carefully, they are only compile tested.
> 
> The ec driver is already finding the hardware on the basis of the HID - 
> is there any reason to do this twice rather than just exporting the 
> information the ec driver already has?
Exporting the EC handle is static, you do not want to export all
kind of ACPI devices as soon as other drivers need them.

The question is how long it takes to do:
acpi_ns_walk_namespace(ACPI_TYPE_DEVICE, ...
in worst case (not found).

Ok, the EC may be somewhat special because it's the most likely
candidate to get shared (or say needed by other drivers)
and its driver has to be compiled in.
.
thinkpad_acpi should at least also make use of Seth's approach and get the
ec_handle quickly/directly.

And my patches should still be added, because others could use
them as well. Beside thinkpad_acpi grabbing the video handle, there
is another re-implementation of my acpi_handle_locate (eeepc_wmi.c):
static acpi_status eeepc_wmi_parse_device(acpi_handle handle, u32 level,
                                                 void *context, void **retval)
{
        pr_warn("Found legacy ATKD device (%s)\n", EEEPC_ACPI_HID);
        *(bool *)context = true;
        return AE_CTRL_TERMINATE;
}

static int eeepc_wmi_check_atkd(void)
{
        acpi_status status;
        bool found = false;

        status = acpi_get_devices(EEEPC_ACPI_HID, eeepc_wmi_parse_device,
                                  &found, NULL);

        if (ACPI_FAILURE(status) || !found)
                return 0;
        return -1;                                                                                                                                                    
}


If you agree I can send something tomorrow.


    Thomas

  reply	other threads:[~2011-12-16  1:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-15 18:06 [PATCH 0/4] toshiba_acpi: Expanded hotkey support Seth Forshee
2011-12-15 18:06 ` [PATCH 1/4] ACPI: EC: Add ec_get_handle() Seth Forshee
2011-12-16  0:22   ` Thomas Renninger
2011-12-16  0:33     ` Matthew Garrett
2011-12-16  1:52       ` Thomas Renninger [this message]
2011-12-16 13:19       ` Thomas Renninger
2011-12-16 13:44         ` Corentin Chary
2011-12-16 14:18         ` Seth Forshee
2011-12-15 18:06 ` [PATCH 2/4] toshiba_acpi: Support alternate hotkey interfaces Seth Forshee
2011-12-17  8:31   ` Thomas Renninger
2011-12-17 11:32     ` Azael Avalos
2011-12-17 15:07       ` Seth Forshee
2011-12-18 14:01         ` Thomas Renninger
2011-12-19 18:24           ` Seth Forshee
2011-12-15 18:06 ` [PATCH 3/4] toshiba_acpi: Support additional hotkey scancodes Seth Forshee
2011-12-15 18:06 ` [PATCH 4/4] toshiba_acpi: Add blacklist for devices with hotkey problems Seth Forshee

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=201112160252.26681.trenn@suse.de \
    --to=trenn@suse.de \
    --cc=coproscefalo@gmail.com \
    --cc=hmh@hmh.eng.br \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=seth.forshee@canonical.com \
    /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;
as well as URLs for NNTP newsgroup(s).