Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2510067imm; Wed, 16 May 2018 14:10:25 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrrlgKcmYQAPG909hA3AMDx3ZfdFWIcDE/q2HRxBmSmshcxIzGjXLEPf/Pcm5laou9FzMH7 X-Received: by 2002:a17:902:ab83:: with SMTP id f3-v6mr2476447plr.344.1526505025662; Wed, 16 May 2018 14:10:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526505025; cv=none; d=google.com; s=arc-20160816; b=myOXIGeNhD9E6QYYs+SXcYrDRk/xEjrdH5jsoV3i5+Ir/tjqrmIIe4vS7c0lD4X6kX tFh+mJY3ZbIyiw60BpZczo52ikLZETeDTZ0t9sIA1b5bK12l6AVD9RplczOVlZeRFXY3 uBfaNMQSC6VU+oRGmsR3QXcUuPrS78Dfn+OS7ZhnzaNO2L35f9Z3AAZtKk7YsZBGYHUg rM/ocSpKQlW1KmaggLAeFP/PUvHY7QXd+fmJoD8tYDxczgubBOx0COJbNMM0Oq6GiYdx 6zDaJb/RAROXJNb8BG3znUoVN1l0QnNsPF0rXJXQc/zvBe4Lpm5ZBeOqazCXcOKy2vkv 4z8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=gjRulsXdUN/sEGMcPCqAlzJtnEFNljzyRr+BHQYX3lE=; b=ZaDepJGTznD/E2pSpE4VMVEuYveu8TFxxWXco9PYZsOgKODhcn3Tr2iBQfDCzgweLO kl1n/08koEKtM0X+XMP3iA4EcuJkAnKz2OcQGppxuK3qdVcwa02O+eXN2NDyArPubQXN NFRqngokMemBX+6U3Is/7IfAbf73oWjMjos1osOF8SGVCV6/LAGElRf30pkWuWytsQN3 C6cxOd/J9Xfef1bFsJ+Ujv5r94qWfZRFBGfOXVE7oTP+o8smesK7W9zqTuKr3kpW/TFg ChPI6uxoJQZO9f+KKO23Vd+G+TnPPQWCRAuIh7QxV1mAXbxw+7iWhQHxzuPAHyUV1FuF tZkA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=GTpJVxk8; 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 73-v6si3589110pld.217.2018.05.16.14.10.11; Wed, 16 May 2018 14:10:25 -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=GTpJVxk8; 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 S1752165AbeEPVIX (ORCPT + 99 others); Wed, 16 May 2018 17:08:23 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:44823 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751198AbeEPVIV (ORCPT ); Wed, 16 May 2018 17:08:21 -0400 Received: by mail-pl0-f68.google.com with SMTP id e6-v6so1128816plt.11; Wed, 16 May 2018 14:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=gjRulsXdUN/sEGMcPCqAlzJtnEFNljzyRr+BHQYX3lE=; b=GTpJVxk8HmdpgJ3rxBCF2dBaPev6G5FQzyr2Nujogb7FNgGo24fuWnr7gYZZqIBrHm sMQRyTsH8574LIur+KXHt1lEhg3A6FvqbCxx4xNsVadbdQslM3WhiOfTh9PWlEN5jRQx bZTjf2CgWJjKp9UncHQZgtNGHbzYJDnulA0TCHXllC66y4E3CR6e0o5FJS8fj5wX7ACe 507YC92K7kQBMELK5sglm2gejoUxpnEDg6prT4yNqQtb5BTdodtFzl76nmFYr3O1UwGe 4r0gNkNbG3Df849g1jGqjoRRRuVqPPkisWQ+4R5WeQli370mQECsr/CQuAkRItVhFps4 EPcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=gjRulsXdUN/sEGMcPCqAlzJtnEFNljzyRr+BHQYX3lE=; b=Bpk8CckT7o0bD6Euvq189vlByY3FqhgrgnPB2VdWKCOCmNLW1a8mKnWOU6m1s2CRv9 wublFwa8x6Ix4uvDUyoMk/w1EaaBg/04Yyyv+YAF1xRGN6v9ZuZjQQxhGLi9smpa7+7b 740mznWeT+0naLrf6eYfJa/4T/jg148Szd/Tp7npwUYc8jcPRI4/z+9euF2BtucMCckE j775krgm2HWBWqCSCrvzQ5Bm2FXnQIndGw74jahcXKo8W4IW+XF1qWgxCotOKrIHUNEf UQcRN5m5HrXMhSYv5q8PtDRMPiMfWs4GgkvYQ5dPRT12RrGx2S0B1y8CKAY1iPcXQgmX B+Dg== X-Gm-Message-State: ALKqPwd+YIPuHsl51FDaS6YKpGeC3IPVkiTrFcXSQcWFmnQgRuDVNUp8 KMmBO6GwBA9Ut6uWglnm8/Y= X-Received: by 2002:a17:902:1029:: with SMTP id b38-v6mr2467288pla.277.1526504900658; Wed, 16 May 2018 14:08:20 -0700 (PDT) Received: from dtor-ws ([2620:0:1000:1511:8de6:27a8:ed13:2ef5]) by smtp.gmail.com with ESMTPSA id q207-v6sm5009784pgq.9.2018.05.16.14.08.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 May 2018 14:08:19 -0700 (PDT) Date: Wed, 16 May 2018 14:08:17 -0700 From: Dmitry Torokhov To: Oleksandr Andrushchenko 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 Subject: Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration Message-ID: <20180516210817.GF21971@dtor-ws> References: <20180514144029.16019-1-andr2000@gmail.com> <20180514144029.16019-2-andr2000@gmail.com> <20180516171528.GD21971@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks. -- Dmitry