All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.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: Mon, 13 Mar 2017 12:01:59 +0100	[thread overview]
Message-ID: <20170313110159.GG4378@mail.corp.redhat.com> (raw)
In-Reply-To: <20170310230114.788-7-dmitry.torokhov@gmail.com>

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.

Cheers,
Benjamin



  parent reply	other threads:[~2017-03-13 11:02 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 [this message]
2017-03-20  0:22     ` Dmitry Torokhov
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=20170313110159.GG4378@mail.corp.redhat.com \
    --to=benjamin.tissoires@redhat.com \
    --cc=aduggan@synaptics.com \
    --cc=dmitry.torokhov@gmail.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 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.