drivers/i2c/i2c-core-base.c | 12 ++++++------ drivers/i2c/i2c-core-smbus.c | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-)
Brauch reported an OOPS when using the designware controller as target
only. Target-only modes break the assumption of one transfer function
always being available. Fix this by always checking the pointer in
__i2c_transfer.
Reported-by: Baruch Siach <baruch@tkos.co.il>
Closes: https://lore.kernel.org/r/4269631780e5ba789cf1ae391eec1b959def7d99.1712761976.git.baruch@tkos.co.il
Fixes: 4b1acc43331d ("i2c: core changes for slave support")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/i2c/i2c-core-base.c | 12 ++++++------
drivers/i2c/i2c-core-smbus.c | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index ff5c486a1dbb..db0d1ac82910 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -2200,13 +2200,18 @@ static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg *msgs,
* Returns negative errno, else the number of messages executed.
*
* Adapter lock must be held when calling this function. No debug logging
- * takes place. adap->algo->master_xfer existence isn't checked.
+ * takes place.
*/
int __i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
{
unsigned long orig_jiffies;
int ret, try;
+ if (!adap->algo->master_xfer) {
+ dev_dbg(&adap->dev, "I2C level transfers not supported\n");
+ return -EOPNOTSUPP;
+ }
+
if (WARN_ON(!msgs || num < 1))
return -EINVAL;
@@ -2273,11 +2278,6 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
{
int ret;
- if (!adap->algo->master_xfer) {
- dev_dbg(&adap->dev, "I2C level transfers not supported\n");
- return -EOPNOTSUPP;
- }
-
/* REVISIT the fault reporting model here is weak:
*
* - When we get an error after receiving N bytes from a slave,
diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
index e3b96fc53b5c..a942c5306a4e 100644
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -596,7 +596,7 @@ s32 __i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
break;
}
- if (res != -EOPNOTSUPP || !adapter->algo->master_xfer)
+ if (res != -EOPNOTSUPP)
goto trace;
/*
* Fall back to i2c_smbus_xfer_emulated if the adapter doesn't
--
2.39.2
On Fri, Apr 26, 2024 at 08:44:08AM +0200, Wolfram Sang wrote: > Brauch reported an OOPS when using the designware controller as target > only. Target-only modes break the assumption of one transfer function > always being available. Fix this by always checking the pointer in > __i2c_transfer. > > Reported-by: Baruch Siach <baruch@tkos.co.il> > Closes: https://lore.kernel.org/r/4269631780e5ba789cf1ae391eec1b959def7d99.1712761976.git.baruch@tkos.co.il > Fixes: 4b1acc43331d ("i2c: core changes for slave support") > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Fixed the name typo and applied to for-current, thanks!
Hi Wolfram, On Fri, Apr 26 2024, Wolfram Sang wrote: > Brauch reported an OOPS when using the designware controller as target > only. Target-only modes break the assumption of one transfer function > always being available. Fix this by always checking the pointer in > __i2c_transfer. > > Reported-by: Baruch Siach <baruch@tkos.co.il> > Closes: https://lore.kernel.org/r/4269631780e5ba789cf1ae391eec1b959def7d99.1712761976.git.baruch@tkos.co.il > Fixes: 4b1acc43331d ("i2c: core changes for slave support") > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Baruch Siach <baruch@tkos.co.il> Thanks, baruch > --- > drivers/i2c/i2c-core-base.c | 12 ++++++------ > drivers/i2c/i2c-core-smbus.c | 2 +- > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c > index ff5c486a1dbb..db0d1ac82910 100644 > --- a/drivers/i2c/i2c-core-base.c > +++ b/drivers/i2c/i2c-core-base.c > @@ -2200,13 +2200,18 @@ static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg *msgs, > * Returns negative errno, else the number of messages executed. > * > * Adapter lock must be held when calling this function. No debug logging > - * takes place. adap->algo->master_xfer existence isn't checked. > + * takes place. > */ > int __i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) > { > unsigned long orig_jiffies; > int ret, try; > > + if (!adap->algo->master_xfer) { > + dev_dbg(&adap->dev, "I2C level transfers not supported\n"); > + return -EOPNOTSUPP; > + } > + > if (WARN_ON(!msgs || num < 1)) > return -EINVAL; > > @@ -2273,11 +2278,6 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) > { > int ret; > > - if (!adap->algo->master_xfer) { > - dev_dbg(&adap->dev, "I2C level transfers not supported\n"); > - return -EOPNOTSUPP; > - } > - > /* REVISIT the fault reporting model here is weak: > * > * - When we get an error after receiving N bytes from a slave, > diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c > index e3b96fc53b5c..a942c5306a4e 100644 > --- a/drivers/i2c/i2c-core-smbus.c > +++ b/drivers/i2c/i2c-core-smbus.c > @@ -596,7 +596,7 @@ s32 __i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, > break; > } > > - if (res != -EOPNOTSUPP || !adapter->algo->master_xfer) > + if (res != -EOPNOTSUPP) > goto trace; > /* > * Fall back to i2c_smbus_xfer_emulated if the adapter doesn't -- ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
On 4/26/24 9:44 AM, Wolfram Sang wrote: > Brauch reported an OOPS when using the designware controller as target He's Baruch... :-) > only. Target-only modes break the assumption of one transfer function > always being available. Fix this by always checking the pointer in > __i2c_transfer. > > Reported-by: Baruch Siach <baruch@tkos.co.il> > Closes: https://lore.kernel.org/r/4269631780e5ba789cf1ae391eec1b959def7d99.1712761976.git.baruch@tkos.co.il > Fixes: 4b1acc43331d ("i2c: core changes for slave support") > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> [...] MBR, Sergey
On Fri, Apr 26, 2024 at 10:28:40AM +0300, Sergei Shtylyov wrote: > On 4/26/24 9:44 AM, Wolfram Sang wrote: > > > Brauch reported an OOPS when using the designware controller as target > > He's Baruch... :-) Oh, I am very sorry Baruch!
© 2016 - 2024 Red Hat, Inc.