Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2869019imm; Wed, 16 May 2018 22:32:50 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpFOVPDfv2e9iZlC1NG/cRTmnLHnjbz1SHDsUPVOiZ9tP5B4lLLYQZuzJkgKo6IqvznmmsT X-Received: by 2002:a17:902:3c5:: with SMTP id d63-v6mr3756364pld.163.1526535170892; Wed, 16 May 2018 22:32:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526535170; cv=none; d=google.com; s=arc-20160816; b=xd4zjuh1DcL4g06lnGOo+wg9iZ0uvzAsHAu2GQ/KIKDyvqyDwco8HjI/v2l16y8Eej 58Jbx9ppvPd5+Q0FXaB1saF7AoKN+53kcw6m7TnVvecBw496hJo7+JJZB1USw+vkNUF7 eXqWM1g9KUNGzPZDr1CeroR+Dzy1n8oYeJsuSkoYDNBrub5E2Fvk5pP9flYFIpjFZqyZ 7iDE0FHoxIirx5MUBPnq6qV1A8zn83j8a4e1Nv2LK5on9IHqSyF7vP9n0ERm9RDZJ00e aJGWgrI+/gg9+dIvpk0cf60kTBJ6Nn4Zcm4Y9Dofo5/iKkbSvPPNnNgo6yGsBxQSpIYl bsXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=b4ZOnwjO7QuFmWQ7VFY66HyYAbToAtHW24Kv8H1n+/8=; b=V9lwNBNRvTBKZtLz8dfnNVmYVL8oSRsRL3GbAlmoVEMMnNidc3XOefYCDQ+9CrB6lQ GDCy8H9Bfv61AWf8pGne3zpIA1hiTZwYTyZeUFhY8U3eMllTravVxTFVTvryk+S+e/0Q negSOREr7vwd2MSjbzb7PCK0HVODzZmRycLAa4HksiO5LBguXwaVK1pIftOjXODlcro3 rlwnfKNjDQROgK4hJIAvvBrxNEWhsICrXOVuERSljCeMB0ZE9a59epY9P069Pvr0Xvq+ Y8Y0xATVzYzqSyrqyekLI1er4Wu4B2Sc5BhOoh1ytli6OIDYgdPrcAAW6AEQsZhs6jpw 7Ykw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lYUfq+9A; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z86-v6si4497349pfa.120.2018.05.16.22.32.36; Wed, 16 May 2018 22:32:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lYUfq+9A; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751438AbeEQFb7 (ORCPT + 99 others); Thu, 17 May 2018 01:31:59 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:35313 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750815AbeEQFb6 (ORCPT ); Thu, 17 May 2018 01:31:58 -0400 Received: by mail-lf0-f67.google.com with SMTP id y72-v6so6850027lfd.2; Wed, 16 May 2018 22:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=b4ZOnwjO7QuFmWQ7VFY66HyYAbToAtHW24Kv8H1n+/8=; b=lYUfq+9A/pAoD3lecOc6tSTZ1VHWntHn6BRZMQVDxazG49omYvri7EOC+vt0udBFGh H+oifzI+5wEygxEdzZP0gW5lBUXWWOf3Uul18Ejptdg/Y+lsl57TE0nX4CG4f9dWa9sz ZXnMkjSOAvs5ceBR203f5p9ASmQU/RST7cCMBVJWQyW2hZOHf9957dp78jRB0PKLnQlj KIP6+KImyYIBfF6y0/Df7fsA0ehn7BZ0pJrC/gvnumJEVKI2waK0roIYSkjPFtBOHf/H F30mkVJca0DSKMNGd0UoAsPRscMQZWjZHGPG4NsnitfHejzE7IO4Sr0uIfDLuyvUyZcu CJqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=b4ZOnwjO7QuFmWQ7VFY66HyYAbToAtHW24Kv8H1n+/8=; b=HF4wGrD+0ugUxHqkvhmE4CJNJGjR1BNa8ztX5JmkqLNxO2xkAQntDtUppihPVhKMHb FdFtI5PPbBadAak1noC/onWY8yfdWfE7Wm/XhpCWShq9eCH8GbL46XFZzZ7oeMUr1zIi FQm3245MJ8H2AtsBqQIceiKg7Bp0TgcyVCVTYslcqLpaQx2/ulS+bxaoaLTAtGQk/UFM PTG8HpzO7zjnYTybSHZ7YrNb9QY34pvmWscfgEh27pmZDuFaJkWuuoeXT+nTe5OLjP0M 1Mfw6vF5XuREqJiSwgFEElxvYLxT8AZyehmdE+tYgKQmeAaDiZXOj6jKepQKTOipGDea zt+w== X-Gm-Message-State: ALKqPwfTG1ISUJQt4Rnz3r6ZZfiJ3JQ6fwahRCNi4DU5YM3lMuwVQjAz XLne5p9w7dq8TvxKgY6eSQs= X-Received: by 2002:a19:1186:: with SMTP id 6-v6mr17428406lfr.134.1526535116436; Wed, 16 May 2018 22:31:56 -0700 (PDT) Received: from [10.17.182.9] (ll-52.209.223.85.sovam.net.ua. [85.223.209.52]) by smtp.gmail.com with ESMTPSA id f10-v6sm1007869lfh.88.2018.05.16.22.31.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 May 2018 22:31:55 -0700 (PDT) Subject: Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration To: Dmitry Torokhov Cc: xen-devel@lists.xenproject.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, jgross@suse.com, lyan@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, andrii_chepurnyi@epam.com, Oleksandr Andrushchenko References: <20180514144029.16019-1-andr2000@gmail.com> <20180514144029.16019-2-andr2000@gmail.com> <20180516171528.GD21971@dtor-ws> <20180516210817.GF21971@dtor-ws> From: Oleksandr Andrushchenko Message-ID: <7cecb5d1-5cd3-b63d-d6eb-d1e2dfba9ca6@gmail.com> Date: Thu, 17 May 2018 08:31:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180516210817.GF21971@dtor-ws> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/17/2018 12:08 AM, Dmitry Torokhov wrote: > On Wed, May 16, 2018 at 08:47:30PM +0300, Oleksandr Andrushchenko wrote: >> On 05/16/2018 08:15 PM, Dmitry Torokhov wrote: >>> Hi Oleksandr, >>> >>> On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote: >>>> @@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *dev, >>>> if (!info->page) >>>> goto error_nomem; >>>> - /* Set input abs params to match backend screen res */ >>>> - abs = xenbus_read_unsigned(dev->otherend, >>>> - XENKBD_FIELD_FEAT_ABS_POINTER, 0); >>>> - ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, >>>> - XENKBD_FIELD_WIDTH, >>>> - ptr_size[KPARAM_X]); >>>> - ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, >>>> - XENKBD_FIELD_HEIGHT, >>>> - ptr_size[KPARAM_Y]); >>>> - if (abs) { >>>> - ret = xenbus_write(XBT_NIL, dev->nodename, >>>> - XENKBD_FIELD_REQ_ABS_POINTER, "1"); >>>> - if (ret) { >>>> - pr_warn("xenkbd: can't request abs-pointer\n"); >>>> - abs = 0; >>>> - } >>>> - } >>>> + /* >>>> + * The below are reverse logic, e.g. if the feature is set, then >>>> + * do not expose the corresponding virtual device. >>>> + */ >>>> + with_kbd = !xenbus_read_unsigned(dev->nodename, >>>> + XENKBD_FIELD_FEAT_DSBL_KEYBRD, 0); >>>> - touch = xenbus_read_unsigned(dev->nodename, >>>> - XENKBD_FIELD_FEAT_MTOUCH, 0); >>>> - if (touch) { >>>> + with_ptr = !xenbus_read_unsigned(dev->nodename, >>>> + XENKBD_FIELD_FEAT_DSBL_POINTER, 0); >>>> + >>>> + /* Direct logic: if set, then create multi-touch device. */ >>>> + with_mtouch = xenbus_read_unsigned(dev->nodename, >>>> + XENKBD_FIELD_FEAT_MTOUCH, 0); >>>> + if (with_mtouch) { >>>> ret = xenbus_write(XBT_NIL, dev->nodename, >>>> XENKBD_FIELD_REQ_MTOUCH, "1"); >>>> if (ret) { >>>> pr_warn("xenkbd: can't request multi-touch"); >>>> - touch = 0; >>>> + with_mtouch = 0; >>>> } >>>> } >>> Does it make sense to still end up calling xenkbd_connect_backend() when >>> all interfaces (keyboard, pointer, and multitouch) are disabled? Should >>> we do: >>> >>> if (!(with_kbd || || with_ptr || with_mtouch)) >>> return -ENXIO; >>> >>> ? >> It does make sense. Then we probably need to move all xenbus_read_unsigned >> calls to the very beginning of the .probe, so no memory allocations are made >> which will be useless if we return -ENXIO, e.g. something like >> >> static int xenkbd_probe(struct xenbus_device *dev, >>                   const struct xenbus_device_id *id) >> { >>     int ret, i; >>     bool with_mtouch, with_kbd, with_ptr; >>     struct xenkbd_info *info; >>     struct input_dev *kbd, *ptr, *mtouch; >> >> >> >> if (!(with_kbd | with_ptr | with_mtouch)) >>         return -ENXIO; >> >> Does the above looks ok? > Yes. Another option is to keep the check where I suggested and do > > if (...) { > ret = -ENXIO; > goto error; > } > > Whichever you prefer is fine with me. I will go with the change you suggested and I'll send v4 tomorrow then. > Thanks. > Thank you, Oleksandr