All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Oleksandr Andrushchenko <andr2000@gmail.com>
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 <oleksandr_andrushchenko@epam.com>
Subject: Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration
Date: Wed, 16 May 2018 14:08:17 -0700	[thread overview]
Message-ID: <20180516210817.GF21971@dtor-ws> (raw)
In-Reply-To: <e9882c52-3641-7c32-1f64-dd9c4f35de5f@gmail.com>

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;
> 
> <read with_mtouch, with_kbd, with_ptr here>
> 
> 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

  reply	other threads:[~2018-05-16 21:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-14 14:40 [PATCH v3 1/2] xen/kbdif: Sync up with the canonical definition in Xen Oleksandr Andrushchenko
2018-05-14 14:40 ` [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration Oleksandr Andrushchenko
2018-05-14 14:40 ` Oleksandr Andrushchenko
2018-05-16 17:15   ` Dmitry Torokhov
2018-05-16 17:47     ` Oleksandr Andrushchenko
2018-05-16 17:47     ` Oleksandr Andrushchenko
2018-05-16 21:08       ` Dmitry Torokhov [this message]
2018-05-17  5:31         ` Oleksandr Andrushchenko
2018-05-17  5:31         ` Oleksandr Andrushchenko
2018-05-17 13:08           ` Boris Ostrovsky
2018-05-17 13:08           ` Boris Ostrovsky
2018-05-17 13:09             ` Oleksandr Andrushchenko
2018-05-17 13:09             ` Oleksandr Andrushchenko
2018-05-17 14:29               ` Konrad Rzeszutek Wilk
2018-05-17 14:29               ` Konrad Rzeszutek Wilk
2018-05-16 21:08       ` Dmitry Torokhov
2018-05-16 17:15   ` Dmitry Torokhov

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=20180516210817.GF21971@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=andr2000@gmail.com \
    --cc=andrii_chepurnyi@epam.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyan@suse.com \
    --cc=oleksandr_andrushchenko@epam.com \
    --cc=xen-devel@lists.xenproject.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.