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: <20110701180046.20efb83e@lxorguk.ukuu.org.uk>
Date:	Fri, 1 Jul 2011 18:00:46 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Chris Wolfe <cwolfe@...omium.org>
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

> > 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"?

The hardware or the driver ?

As far as the OS is concerned it would have gone away.

> 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.

Thats a bit messier but we'd still want them to be normal i²c drivers
when on the slave bus and being driven by Linux. Possibly you end up with
a little helper to send i²c commands directly to the bus  in the "smart"
mode.

> 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.

If it's operating as a normal i²c device then it'll behave like any
normal kernel device, and really ought to be using runtime pm anyway.

In "smart" mode its really up to the driver how it does it but two
versions of every device is not a good answer !

> 
> >> 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 :)

Sorry may not have been clear "just those" as in "just those which can be
used without loading firmware and running non-free stuff"

And really until that area is sorted it may be premature to worry about
the rest - if its going to need proprietary bits to use the smart mode,
then the kernel just needs an i2c slave bus implementation, a few drivers
(we have most listed already it seems), and we are done.

Alan
--
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/