public inbox for linux-input@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Andrew Duggan <aduggan@synaptics.com>,
	linux-kernel@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: [PATCH v2 6/9] Input: psmouse - add support for SMBus companions
Date: Sun, 19 Mar 2017 17:22:04 -0700	[thread overview]
Message-ID: <20170320002204.GB27328@dtor-ws> (raw)
In-Reply-To: <20170313110159.GG4378@mail.corp.redhat.com>

On Mon, Mar 13, 2017 at 12:01:59PM +0100, Benjamin Tissoires wrote:
> On Mar 10 2017 or thereabouts, Dmitry Torokhov wrote:
> > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > 
> > This provides glue between PS/2 devices that enumerate the RMI4 devices
> > and Elan touchpads to the RMI4 (or Elan) SMBus driver.
> > 
> > The SMBus devices keep their PS/2 connection alive. If the initialization
> > process goes too far (psmouse_activate called), the device disconnects
> > from the I2C bus and stays on the PS/2 bus, that is why we explicitly
> > disable PS/2 device reporting (by calling psmouse_deactivate) before
> > trying to register SMBus companion device.
> > 
> > The HID over I2C devices are enumerated through the ACPI DSDT, and
> > their PS/2 device also exports the InterTouch bit in the extended
> > capability 0x0C. However, the firmware keeps its I2C connection open
> > even after going further in the PS/2 initialization. We don't need
> > to take extra precautions with those device, especially because they
> > block their PS/2 communication when HID over I2C is used.
> > 
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
> 
> Actually, one thing I noticed but forgot to say in my previous email:
> 
> If you call rescan from the sysfs, there is a chance the i2c device is
> still there while we are trying to reconnect the device. Which means
> that we fail at creating the i2c device, and then fall back on PS/2.
> 
> It's not a big issue, but still it will show some warning in the dmesg
> while attempting to create some sysfs files that already exist.
> 
> S solution could be to unlock the mutexes and wait for the termination
> of i2c_unregister_device, but I would believe the best approach would be
> to remove the mutexes in serio and psmouse, and directly call
> i2c_unregister_device in .disconnect.

Yeah, I think we'll have to live with rescan from sysfs hiccuping for
now. I want to do a bit of face-lift for serio/psmouse, but it will
take a bit of time.

Thanks.

-- 
Dmitry

  reply	other threads:[~2017-03-20  0:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10 23:01 [PATCH v2 0/9] PS/2 and SMBus companions Dmitry Torokhov
2017-03-10 23:01 ` [PATCH v2 1/9] i2c: export i2c_client_type structure Dmitry Torokhov
2017-03-13 10:23   ` Benjamin Tissoires
2017-03-10 23:01 ` [PATCH v2 2/9] Input: serio - add fast reconnect option Dmitry Torokhov
2017-03-10 23:01 ` [PATCH v2 3/9] Input: psmouse - implement " Dmitry Torokhov
2017-03-10 23:01 ` [PATCH v2 4/9] Input: psmouse - store pointer to current protocol Dmitry Torokhov
2017-03-10 23:01 ` [PATCH v2 5/9] Input: psmouse - introduce notion of SMBus companions Dmitry Torokhov
2017-03-10 23:01 ` [PATCH v2 6/9] Input: psmouse - add support for " Dmitry Torokhov
2017-03-13 10:31   ` Benjamin Tissoires
2017-03-20  0:20     ` Dmitry Torokhov
2017-03-13 11:01   ` Benjamin Tissoires
2017-03-20  0:22     ` Dmitry Torokhov [this message]
2017-03-31  9:37   ` Benjamin Tissoires
2017-04-01 17:22     ` Dmitry Torokhov
2017-04-03 16:04       ` Benjamin Tissoires
2017-03-10 23:01 ` [PATCH v2 7/9] Input: synaptics - split device info into a separate structure Dmitry Torokhov
2017-03-10 23:01 ` [PATCH v2 8/9] Input: synaptics - add support for Intertouch devices Dmitry Torokhov
2017-03-10 23:01 ` [PATCH v2 9/9] [NEEDS F21] Input: synaptics - switch forcepad devices over to SMbus access 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=20170320002204.GB27328@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=aduggan@synaptics.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox