Re: [PATCH v5 2/2] i2c: New bus driver for the Qualcomm QUP I2C controller

[PATCH v5 0/2] Qualcomm Universal Peripheral (QUP) I2C controller · Bjorn Andersson <hidden> · 2014-03-14
[PATCH v5 1/2] i2c: qup: Add device tree bindings information · Bjorn Andersson <hidden> · 2014-03-14
Re: [PATCH v5 1/2] i2c: qup: Add device tree bindings information · Rob Herring <hidden> · 2014-03-14
Re: [PATCH v5 1/2] i2c: qup: Add device tree bindings information · Wolfram Sang <hidden> · 2014-03-28
[PATCH v5 2/2] i2c: New bus driver for the Qualcomm QUP I2C controller · Bjorn Andersson <hidden> · 2014-03-14
Re: [PATCH v5 2/2] i2c: New bus driver for the Qualcomm QUP I2C controller · Josh Cartwright <hidden> · 2014-03-14
Re: [PATCH v5 2/2] i2c: New bus driver for the Qualcomm QUP I2C controller · Wolfram Sang <hidden> · 2014-03-28
Re: [PATCH v5 2/2] i2c: New bus driver for the Qualcomm QUP I2C controller · Andy Gross <hidden> · 2014-03-20
Re: [PATCH v5 2/2] i2c: New bus driver for the Qualcomm QUP I2C controller · Philip Elcan <hidden> · 2014-03-20
Re: [PATCH v5 2/2] i2c: New bus driver for the Qualcomm QUP I2C controller · Wolfram Sang <hidden> · 2014-03-28

From: Wolfram Sang <hidden>
Date: 2014-03-28 22:51:49
Also in: linux-arm-kernel, linux-arm-msm, linux-i2c, lkml

General i2c question: is there a reason why the core isn't responsible
for ensuring a device is not suspended before invoking ->master_xfer
(and smbus_xfer)?

Can't think of one right now.

Attachments

signature.asc [application/pgp-signature] 836 bytes

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help