lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170313110159.GG4378@mail.corp.redhat.com>
Date:   Mon, 13 Mar 2017 12:01:59 +0100
From:   Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Andrew Duggan <aduggan@...aptics.com>,
        linux-kernel@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: [PATCH v2 6/9] Input: psmouse - add support for SMBus companions

On Mar 10 2017 or thereabouts, Dmitry Torokhov wrote:
> From: Benjamin Tissoires <benjamin.tissoires@...hat.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@...hat.com>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ