linux-kernel - Re: [PATCH 11/11] misc: Add slave driver for bma085 pressure sensor

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: <CAN_12A9jvid+7u5mOHbFBqE+Xtb6kbo_endwRk98JLrGK2E2TA@mail.gmail.com>
Date:	Fri, 1 Jul 2011 08:52:28 -0700
From:	Chris Wolfe <cwolfe@...omium.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Alan Cox <alan@...ux.intel.com>,
	Nathan Royer <nroyer@...ensense.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Jonathan Cameron <jic23@....ac.uk>,
	Jiri Kosina <jkosina@...e.cz>,
	Jean Delvare <khali@...ux-fr.org>,
	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: [PATCH 11/11] misc: Add slave driver for bma085 pressure sensor

On Fri, Jul 1, 2011 at 7:41 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> Part of the reason I got started on the KXTF9 driver was to try and
>> understand how a normal kernel driver could cope with the "here and
>> gone again" behavior of being on the MPU's secondary bus.
>
> It's a hot pluggable bus - no different to an i2c bus on a hot pluggable
> device.

Can such a hot pluggable device maintain state while "unplugged"?

e.g. if the system is going to suspend, we need to pause the MPU,
switch it back to pass-through mode, then send commands to suspend the
slave on that bus. I took that to mean we wanted the secondary bus to
have a normal device on it, which is still considered plugged in, but
temporarily inaccessible from the CPU.

> I would guess however that if you knew the device was going to be used for
> the mpu3050 only you'd not add the "slave" devices in your platform data
> in the first place as well so they didn't bounce in and out and you'd
> probably teach the mpu3050 code to not create the bus if it was then
> going to destroy it again a moment later.

Something needs to initialize and configure the slaved devices (and
suspend/resume/shutdown/etc). I'm not sure where this happens if not
A) special-purpose code in the mpu3050 driver for each possible slave;
or B) normal drivers and platform data which cope with B1) the kernel
relaying their data to the MPU and B2) being disconnected from the CPU
while the MPU reads from the device directly.

>> The other note that may not have been made explicit yet is that the
>> 3050 will happily provide unprocessed gyro and slave data without
>> firmware loaded. The firmware sets up some additional processing
>> capabilities of the chip, which are used by InvenSense's user-space
>> products.
>
> Yes - and the current mpu3050 driver provides just these interfaces.

Ah, great. Sorry for missing them. In scanning the ioctls, it looked
like dev-i2c was still a similar level of abstraction :)

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/