linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
	Manoj Chourasia <mchourasia@nvidia.com>,
	"open list:HID CORE LAYER" <linux-input@vger.kernel.org>
Subject: Re: Q: weird hidraw behaviour
Date: Thu, 10 Oct 2013 12:39:39 +0300	[thread overview]
Message-ID: <20131010093939.GH3521@intel.com> (raw)
In-Reply-To: <CANq1E4TxGS4NSc3BOon2+zVwkvY2LQTmQowHxOJnypf860+-jw@mail.gmail.com>

On Thu, Oct 10, 2013 at 11:26:45AM +0200, David Herrmann wrote:
> Hi
> 
> On Tue, Sep 24, 2013 at 10:56 AM, Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> > Hi,
> >
> > I noticed that after commit 212a871a393 (HID: hidraw: correctly deallocate
> > memory on device disconnect) hidraw doesn't close the underlying hid device
> > when the device node is closed last time.
> >
> > For example I have a touch panel (HID over I2C) device with added debug
> > prints in i2c_hid_open()/i2c_hid_close():
> >
> >         # od -x /dev/hidraw0
> >         [   41.363813] i2c_hid 1-004c: i2c_hid_power lvl:32
> >         [   41.368464] i2c_hid 1-004c: i2c_hid_set_power
> >         [   41.372831] i2c_hid 1-004c: __i2c_hid_command: cmd=54 01 00 08
> >         [   41.451455] i2c_hid 1-004c: i2c_hid_open
> >         ^C
> >
> >         # od -x /dev/hidraw0
> >         [   58.420928] i2c_hid 1-004c: i2c_hid_power lvl:32
> >         [   58.425577] i2c_hid 1-004c: i2c_hid_set_power
> >         [   58.429945] i2c_hid 1-004c: __i2c_hid_command: cmd=54 01 00 08
> >         [   58.525276] i2c_hid 1-004c: i2c_hid_open
> >         ^C
> >
> > i2c_hid_close() is never called. Is this intended or am I missing
> > something?
> 
> I don't know whether it's intentional, but it is hardcoded this way
> now. Logic is, ->close() is called on hidraw_disconnect() that is,
> when hidraw is unloaded on a device. It no longer depends on
> user-space processes.
> 
> Any reason to change it back? It's no bug, so if no-one cares I'd
> leave it as it is now. Otherwise, we can try to change it again.

Well, if you open the device and close it from userspace, the device stays
opened forever. I'm not sure if that's the intention.

I think that fix for this was already merged.

  reply	other threads:[~2013-10-10  9:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-24  8:56 Q: weird hidraw behaviour Mika Westerberg
2013-10-01 11:43 ` Manoj Chourasia
2013-10-01 12:43   ` Mika Westerberg
2013-10-01 13:18     ` Manoj Chourasia
2013-10-01 13:37     ` Manoj Chourasia
2013-10-01 13:56       ` Mika Westerberg
2013-10-10  9:26 ` Q: " David Herrmann
2013-10-10  9:39   ` Mika Westerberg [this message]
2013-10-10  9:41     ` David Herrmann

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=20131010093939.GH3521@intel.com \
    --to=mika.westerberg@linux.intel.com \
    --cc=dh.herrmann@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    --cc=mchourasia@nvidia.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).