diff mbox

[01/11] i2c: add helpers for locking the I2C segment

Message ID 20180615101506.8012-2-peda@axentia.se (mailing list archive)
State Not Applicable
Headers show

Commit Message

Peter Rosin June 15, 2018, 10:14 a.m. UTC
This is what almost all drivers want to do. By only advertising
i2c_lock_adapter, they are tricked into locking the root adapter
which is too big of a hammer in most cases.

While at it, convert all open-coded locking of the I2C segment.

Signed-off-by: Peter Rosin <peda@axentia.se>
---
 drivers/i2c/i2c-core-base.c  |  6 +++---
 drivers/i2c/i2c-core-smbus.c |  4 ++--
 include/linux/i2c.h          | 18 ++++++++++++++++++
 3 files changed, 23 insertions(+), 5 deletions(-)

Comments

Wolfram Sang June 18, 2018, 11:05 a.m. UTC | #1
> +static inline void
> +i2c_lock_segment(struct i2c_adapter *adapter)
> +{
> +	i2c_lock_bus(adapter, I2C_LOCK_SEGMENT);
> +}
> +
> +static inline int
> +i2c_trylock_segment(struct i2c_adapter *adapter)
> +{
> +	return i2c_trylock_bus(adapter, I2C_LOCK_SEGMENT);
> +}
> +
> +static inline void
> +i2c_unlock_segment(struct i2c_adapter *adapter)
> +{
> +	i2c_unlock_bus(adapter, I2C_LOCK_SEGMENT);
> +}

I wonder if i2c_lock_segment() and i2c_lock_root_adapter() are really
more readable and convenient than i2c_lock_bus() with the flag. I think
the flags have speaking names, too.

Is that an idea to remove these functions altogether and start using
i2c_lock_bus()?
Peter Rosin June 18, 2018, 11:32 a.m. UTC | #2
On 2018-06-18 13:05, Wolfram Sang wrote:
> 
>> +static inline void
>> +i2c_lock_segment(struct i2c_adapter *adapter)
>> +{
>> +	i2c_lock_bus(adapter, I2C_LOCK_SEGMENT);
>> +}
>> +
>> +static inline int
>> +i2c_trylock_segment(struct i2c_adapter *adapter)
>> +{
>> +	return i2c_trylock_bus(adapter, I2C_LOCK_SEGMENT);
>> +}
>> +
>> +static inline void
>> +i2c_unlock_segment(struct i2c_adapter *adapter)
>> +{
>> +	i2c_unlock_bus(adapter, I2C_LOCK_SEGMENT);
>> +}
> 
> I wonder if i2c_lock_segment() and i2c_lock_root_adapter() are really
> more readable and convenient than i2c_lock_bus() with the flag. I think
> the flags have speaking names, too.
> 
> Is that an idea to remove these functions altogether and start using
> i2c_lock_bus()?

That would be fine with me. I don't have a strong opinion and agree that
both are readable enough...

It would make for a reduction of the number of lines so that's nice, but
the macro in drivers/i2c/busses/i2c-gpio.c (patch 11) would not fit in
the current \-width (or whatever you'd call that line of backslashes to
the right in a multi-line macro).

Does anyone have a strong opinion?

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wolfram Sang June 18, 2018, 11:54 a.m. UTC | #3
> > I wonder if i2c_lock_segment() and i2c_lock_root_adapter() are really
> > more readable and convenient than i2c_lock_bus() with the flag. I think
> > the flags have speaking names, too.
> > 
> > Is that an idea to remove these functions altogether and start using
> > i2c_lock_bus()?
> 
> That would be fine with me. I don't have a strong opinion and agree that
> both are readable enough...
> 
> It would make for a reduction of the number of lines so that's nice, but
> the macro in drivers/i2c/busses/i2c-gpio.c (patch 11) would not fit in
> the current \-width (or whatever you'd call that line of backslashes to
> the right in a multi-line macro).
> 
> Does anyone have a strong opinion?

I have a strong opinion on making i2c.h less bloated. And yes, less
number of lines is nice, too. I think that surely pays off the
whitespace exception.

Thanks!
Peter Rosin June 19, 2018, 9:29 p.m. UTC | #4
On 2018-06-18 13:54, Wolfram Sang wrote:
> 
>>> I wonder if i2c_lock_segment() and i2c_lock_root_adapter() are really
>>> more readable and convenient than i2c_lock_bus() with the flag. I think
>>> the flags have speaking names, too.
>>>
>>> Is that an idea to remove these functions altogether and start using
>>> i2c_lock_bus()?
>>
>> That would be fine with me. I don't have a strong opinion and agree that
>> both are readable enough...
>>
>> It would make for a reduction of the number of lines so that's nice, but
>> the macro in drivers/i2c/busses/i2c-gpio.c (patch 11) would not fit in
>> the current \-width (or whatever you'd call that line of backslashes to
>> the right in a multi-line macro).
>>
>> Does anyone have a strong opinion?
> 
> I have a strong opinion on making i2c.h less bloated. And yes, less
> number of lines is nice, too. I think that surely pays off the
> whitespace exception.

Ok, I have rebased onto v4.18-rc1, killed the i2c-tegra hunk and converted
i2c_lock_root(foo) over to i2c_lock_bus(foo, I2C_LOCK_ROOT_ADAPTER) and
i2c_lock_segment(foo) over to i2c_lock_bus(foo, I2C_LOCK_SEGMENT). And I
of course killed a bunch of locking helpers in i2c.h.

I doing build tests now, will post a v2 in the morning.

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 1ba40bb2b966..3eb09dc20573 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1932,16 +1932,16 @@  int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
 #endif
 
 		if (in_atomic() || irqs_disabled()) {
-			ret = i2c_trylock_bus(adap, I2C_LOCK_SEGMENT);
+			ret = i2c_trylock_segment(adap);
 			if (!ret)
 				/* I2C activity is ongoing. */
 				return -EAGAIN;
 		} else {
-			i2c_lock_bus(adap, I2C_LOCK_SEGMENT);
+			i2c_lock_segment(adap);
 		}
 
 		ret = __i2c_transfer(adap, msgs, num);
-		i2c_unlock_bus(adap, I2C_LOCK_SEGMENT);
+		i2c_unlock_segment(adap);
 
 		return ret;
 	} else {
diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
index b5aec33002c3..8a820fdef3e0 100644
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -537,7 +537,7 @@  s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, unsigned short flags,
 	flags &= I2C_M_TEN | I2C_CLIENT_PEC | I2C_CLIENT_SCCB;
 
 	if (adapter->algo->smbus_xfer) {
-		i2c_lock_bus(adapter, I2C_LOCK_SEGMENT);
+		i2c_lock_segment(adapter);
 
 		/* Retry automatically on arbitration loss */
 		orig_jiffies = jiffies;
@@ -551,7 +551,7 @@  s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, unsigned short flags,
 				       orig_jiffies + adapter->timeout))
 				break;
 		}
-		i2c_unlock_bus(adapter, I2C_LOCK_SEGMENT);
+		i2c_unlock_segment(adapter);
 
 		if (res != -EOPNOTSUPP || !adapter->algo->master_xfer)
 			goto trace;
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 44ad14e016b5..c9080d49e988 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -768,6 +768,24 @@  i2c_unlock_adapter(struct i2c_adapter *adapter)
 	i2c_unlock_bus(adapter, I2C_LOCK_ROOT_ADAPTER);
 }
 
+static inline void
+i2c_lock_segment(struct i2c_adapter *adapter)
+{
+	i2c_lock_bus(adapter, I2C_LOCK_SEGMENT);
+}
+
+static inline int
+i2c_trylock_segment(struct i2c_adapter *adapter)
+{
+	return i2c_trylock_bus(adapter, I2C_LOCK_SEGMENT);
+}
+
+static inline void
+i2c_unlock_segment(struct i2c_adapter *adapter)
+{
+	i2c_unlock_bus(adapter, I2C_LOCK_SEGMENT);
+}
+
 /*flags for the client struct: */
 #define I2C_CLIENT_PEC		0x04	/* Use Packet Error Checking */
 #define I2C_CLIENT_TEN		0x10	/* we have a ten bit chip address */