From: Hans de Goede <hdegoede@redhat.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: "russianneuromancer @ ya . ru" <russianneuromancer@ya.ru>,
linux-input@vger.kernel.org, Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH 2/2] Input: soc_button_array: Add support for ACPI 6.0 Generic Button Device
Date: Fri, 17 Mar 2017 14:57:40 +0100 [thread overview]
Message-ID: <c3d81e1b-7f9c-a8ba-c8c9-b927f38ebbc0@redhat.com> (raw)
In-Reply-To: <20170316205157.GB2935@dtor-ws>
Hi,
On 16-03-17 21:51, Dmitry Torokhov wrote:
> Hi Hans,
>
> On Tue, Feb 14, 2017 at 03:10:06PM +0100, Hans de Goede wrote:
>> Windows 10 tablets with gpio buttons will typically use the ACPI 6.0
>> Generic Button Device with a HID of ACPI0011 for these buttons.
>>
>> The ACPI description for these in the ACPI0011 devices _DSD object uses
>> something resembling HID descriptors, except that instead of indicating
>> a bit index into a HID input report, the index indicates the _CRS index
>> for the GPIO.
>>
>> The use of 1 interrupt per button, some of which need to be wakeup
>> sources, instead of using input reports makes it impossible to use the
>> HID subsystem for this.
>>
>> This really is just another gpio-keys input device with the platform
>> data described in ACPI, so this commit adds parsing for this new way
>> to describe gpio-keys to the soc_button_array driver.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/input/misc/soc_button_array.c | 158 +++++++++++++++++++++++++++++++++-
>> 1 file changed, 157 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
>> index eb1ba4e..a52eb12 100644
>> --- a/drivers/input/misc/soc_button_array.c
>> +++ b/drivers/input/misc/soc_button_array.c
>> @@ -138,6 +138,152 @@ soc_button_device_create(struct platform_device *pdev,
>> return ERR_PTR(error);
>> }
>>
>> +static int soc_button_get_acpi_object_int(const union acpi_object *obj)
>> +{
>> + if (obj->type != ACPI_TYPE_INTEGER)
>> + return -1;
>> +
>> + return obj->integer.value;
>> +}
>> +
>> +/* Parse a single ACPI0011 _DSD button descriptor */
>> +static int soc_button_parse_btn_desc(struct device *dev,
>> + const union acpi_object *desc,
>> + int collection_uid,
>> + struct soc_button_info *info)
>> +{
>> + int upage, usage;
>> +
>> + if (desc->type != ACPI_TYPE_PACKAGE ||
>> + desc->package.count != 5 ||
>> + /* First byte should be 1 (control) */
>> + soc_button_get_acpi_object_int(&desc->package.elements[0]) != 1 ||
>> + /* Third byte should be collection uid */
>> + soc_button_get_acpi_object_int(&desc->package.elements[2]) !=
>> + collection_uid) {
>> + dev_err(dev, "Invalid ACPI Button Descriptor\n");
>> + return -ENODEV;
>> + }
>> +
>> + info->event_type = EV_KEY;
>> + info->acpi_index =
>> + soc_button_get_acpi_object_int(&desc->package.elements[1]);
>> + upage = soc_button_get_acpi_object_int(&desc->package.elements[3]);
>> + usage = soc_button_get_acpi_object_int(&desc->package.elements[4]);
>> +
>> + /*
>> + * The UUID: fa6bd625-9ce8-470d-a2c7-b3ca36c4282e descriptors use HID
>> + * usage page and usage codes, but otherwise the device is not HID
>> + * compliant: it uses one irq per button instead of generating HID
>> + * input reports and some buttons should generate wakeups where as
>> + * others should not, so we cannot use the HID subsystem.
>> + *
>> + * Luckily all devices only use a few usage page + usage combinations,
>> + * so we can simply check for the known combinations here.
>> + */
>> + if (upage == 0x01 && usage == 0x81) {
>> + info->name = "power";
>> + info->event_code = KEY_POWER;
>> + info->wakeup = true;
>> + } else if (upage == 0x07 && usage == 0xe3) {
>> + info->name = "home";
>> + info->event_code = KEY_HOMEPAGE;
>> + info->wakeup = true;
>> + } else if (upage == 0x0c && usage == 0xe9) {
>> + info->name = "volume_up";
>> + info->event_code = KEY_VOLUMEUP;
>> + info->autorepeat = true;
>> + } else if (upage == 0x0c && usage == 0xea) {
>> + info->name = "volume_down";
>> + info->event_code = KEY_VOLUMEDOWN;
>> + info->autorepeat = true;
>> + } else {
>> + dev_warn(dev, "Unknown button index %d upage %02x usage %02x, ignoring\n",
>> + info->acpi_index, upage, usage);
>> + info->name = "unkown";
>> + info->event_code = KEY_RESERVED;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/* ACPI0011 _DSD btns descriptors UUID: fa6bd625-9ce8-470d-a2c7-b3ca36c4282e */
>> +static const u8 btns_desc_uuid[16] = {
>> + 0x25, 0xd6, 0x6b, 0xfa, 0xe8, 0x9c, 0x0d, 0x47,
>> + 0xa2, 0xc7, 0xb3, 0xca, 0x36, 0xc4, 0x28, 0x2e
>> +};
>> +
>> +/* Parse ACPI0011 _DSD button descriptors */
>> +static struct soc_button_info *soc_button_get_button_info(struct device *dev)
>> +{
>> + struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
>> + const union acpi_object *desc, *uuid, *btns_desc = NULL;
>> + struct soc_button_info *button_info;
>> + acpi_status status;
>> + int i, btn, collection_uid = -1;
>> +
>> + status = acpi_evaluate_object_typed(ACPI_HANDLE(dev), "_DSD", NULL,
>> + &buf, ACPI_TYPE_PACKAGE);
>> + if (ACPI_FAILURE(status)) {
>> + dev_err(dev, "ACPI _DSD object not found\n");
>> + return NULL;
>> + }
>> +
>> + /* Look for the Button Descriptors UUID */
>> + desc = buf.pointer;
>> + for (i = 0; (i + 1) < desc->package.count; i += 2) {
>> + uuid = &desc->package.elements[i];
>> +
>> + if (uuid->type != ACPI_TYPE_BUFFER || uuid->buffer.length != 16
>> + || desc->package.elements[i + 1].type != ACPI_TYPE_PACKAGE)
>> + break;;
>
> Are you sure you want to break and not continue?
Yes, the whole _DSD should be an array with UUID, package, UUID, package, ...
elements. So if the element we are checking does not match a UUID (note
we do i += 2), then something is wrong and we should bail.
Also see acpi_extract_properties() in drivers/acpi/property.c from
which this code is more or less borrowed (that code parses generic
properties, not driver specific ones like we've here).
The double ;; otoh is a typo, will fix for v2.
> Maybe the whole thing
> should be:
>
> const union acpi_object *uuid = &desc->package.elements[i];
> const union acpi_object *bdsc = &desc->package.elements[i + 1];
>
>
> if (uuid->type == ACPI_TYPE_BUFFER &&
> uuid->buffer.length == 16 &&
> memcmp(uuid->buffer.pointer, btns_desc_uuid, 16) == 0 &&
> bdsc->type == ACPI_TYPE_PACKAGE) {
> btns_desc = bdsc;
> break;
> }
>
>> +
>> + if (memcmp(uuid->buffer.pointer, btns_desc_uuid, 16) == 0) {
>> + btns_desc = &desc->package.elements[i + 1];
>> + break;
>> + }
>> + }
>> +
>> + if (!btns_desc) {
>> + dev_err(dev, "ACPI Button Descriptors not found\n");
>> + return NULL;
>> + }
>> +
>> + /* There are package.count - 1 buttons + 1 terminating empty entry */
>> + button_info = devm_kcalloc(dev, btns_desc->package.count,
>> + sizeof(*button_info), GFP_KERNEL);
>> + if (!button_info)
>> + return NULL;
>> +
>> + /* The first package describes the collection */
>> + if (btns_desc->package.elements[0].type == ACPI_TYPE_PACKAGE &&
>> + btns_desc->package.elements[0].package.count == 5 &&
>> + /* First byte should be 0 (collection) */
>> + soc_button_get_acpi_object_int(
>> + &btns_desc->package.elements[0].package.elements[0]) == 0 &&
>> + /* Third byte should be 0 (top level collection) */
>> + soc_button_get_acpi_object_int(
>> + &btns_desc->package.elements[0].package.elements[2]) == 0) {
>> + collection_uid = soc_button_get_acpi_object_int(
>> + &btns_desc->package.elements[0].package.elements[1]);
>> + }
>> + if (collection_uid == -1) {
>> + dev_err(dev, "Invalid Button Collection Descriptor\n");
>> + return NULL;
>> + }
>
> Should we do it before trying to allocate memory? Also maybe have a
> temporary, like el0 for btns_desc->package.elements[0]?
Both good idea, both fixed for v2.
>
>> +
>> + /* Parse the button descriptors */
>> + for (i = 1, btn = 0; i < btns_desc->package.count; i++, btn++) {
>> + if (soc_button_parse_btn_desc(dev,
>> + &btns_desc->package.elements[i],
>> + collection_uid,
>> + &button_info[btn]))
>> + return NULL;
>> + }
>> +
>> + return button_info;
>> +}
>> +
>> static int soc_button_remove(struct platform_device *pdev)
>> {
>> struct soc_button_data *priv = platform_get_drvdata(pdev);
>> @@ -165,7 +311,13 @@ static int soc_button_probe(struct platform_device *pdev)
>> if (!id)
>> return -ENODEV;
>>
>> - button_info = (struct soc_button_info *)id->driver_data;
>> + if (!id->driver_data) {
>> + button_info = soc_button_get_button_info(dev);
>> + if (!button_info)
>> + return -ENODEV;
>
> Better have soc_button_get_button_info() return ERR_PTR-encoded errors
> and propagate them to the callers.
Fixed for v2.
>
>> + } else {
>> + button_info = (struct soc_button_info *)id->driver_data;
>> + }
>>
>> if (gpiod_count(dev, KBUILD_MODNAME) <= 0) {
>> dev_dbg(dev, "no GPIO attached, ignoring...\n");
>> @@ -195,6 +347,9 @@ static int soc_button_probe(struct platform_device *pdev)
>> if (!priv->children[0] && !priv->children[1])
>> return -ENODEV;
>>
>> + if (!id->driver_data)
>> + devm_kfree(dev, button_info);
>> +
>> return 0;
>> }
>>
>> @@ -214,6 +369,7 @@ static struct soc_button_info soc_button_PNP0C40[] = {
>>
>> static const struct acpi_device_id soc_button_acpi_match[] = {
>> { "PNP0C40", (unsigned long)soc_button_PNP0C40 },
>> + { "ACPI0011", 0 },
>> { }
>> };
>>
>> --
>> 2.9.3
>>
>
> Thanks.
Thank you for the review. I'll prepare, test and then submit a v2.
Regards,
Hans
prev parent reply other threads:[~2017-03-17 13:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-14 14:10 [PATCH 1/2] Input: soc_button_array: Get rid of MAX_NBUTTONS Hans de Goede
2017-02-14 14:10 ` [PATCH 2/2] Input: soc_button_array: Add support for ACPI 6.0 Generic Button Device Hans de Goede
2017-03-16 20:51 ` Dmitry Torokhov
2017-03-17 13:57 ` Hans de Goede [this message]
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=c3d81e1b-7f9c-a8ba-c8c9-b927f38ebbc0@redhat.com \
--to=hdegoede@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=russianneuromancer@ya.ru \
--cc=tiwai@suse.de \
/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).