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]
Date:	Fri, 1 Jul 2011 18:09:03 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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>, 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, 1 Jul 2011 15:41:50 +0100, Alan Cox wrote:
> > Just to field this quickly, since I've been playing with the hardware
> 
> (Ditto)
> 
> > 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. 
> 
> 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.

I didn't look in the code in details, but I see no reason to destroy
buses. This is a standard multi-master case, where a given I2C bus
segment can be driven by two masters. If both the host I2C controller
and the MPU3050 master are fully I2C compliant, it should be no problem
to let both coexist. If you really need to handle mutual exclusion
(e.g. the MPU3050 implementation forces you to do so), you can leverage
the i2c multiplexing support for this, which is available since kernel
2.6.36. See drivers/i2c/muxes/pca9541.c for an example implementation.

-- 
Jean Delvare
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ