| Message ID | 1528918579-27602-1-git-send-email-eajames@linux.vnet.ibm.com |
|---|---|
| Headers | show |
| Series | i2c: Add FSI-attached I2C master algorithm | expand |
On Wed, Jun 13, 2018 at 10:36 PM, Eddie James <eajames@linux.vnet.ibm.com> wrote: > This series adds an algorithm for an I2C master physically located on an FSI > slave device. The I2C master has multiple ports, each of which may be connected > to an I2C slave. Access to the I2C master registers is achieved over FSI bus. > > Due to the multi-port nature of the I2C master, the driver instantiates a new > I2C adapter for each port connected to a slave. The connected ports should be > defined in the device tree under the I2C master device. > You missed to include tag I gave Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> be careful next time. > Changes since v9 > - Switch the status masks to use a combination of bits rather than directly > coding the value > - Remove the interrupt mask definition as it was unused > - Fixed return value of master_xfer function (return number of xfrs, not 0) > > Changes since v8 > - Drop unecessary else statements > - Use i++ instead of ++i > - Use kzalloc/kfree instead of devm_kzalloc/devm_kfree for port structure > - Drop the list_empty check in remove > > Changes since v7 > - Fix grammer in Kconfig (a -> an) > - Change I2C registers to use BIT and GENMASK > - Remove custom macros and use FIELD_PREP and FIELD_GET > - Fix a few unecessary initializations and "return rc" that are always zero > - Clean up the read/write fifo functions a bit > - Few other clean-up items > > Changes since v6 > - Remove spinlock for reset functionality; it's unecessary and doesn't work > with the latest FSI core. > - Use a mutex instead of a semaphore, and don't wait for timeout to get the > lock. > - Use usleeps instead of schedule_timeout; it's not worth the overhead when > the wait should be very short in between sending the command and receiving > the response. > > Changes since v5 > - Fix reset functionality and do a reset after every transfer failure > > Eddie James (7): > dt-bindings: i2c: Add FSI-attached I2C master dt binding documentation > i2c: Add FSI-attached I2C master algorithm > i2c: fsi: Add port structures > i2c: fsi: Add abort and hardware reset procedures > i2c: fsi: Add transfer implementation > i2c: fsi: Add I2C master locking > i2c: fsi: Add bus recovery > > Documentation/devicetree/bindings/i2c/i2c-fsi.txt | 40 ++ > drivers/i2c/busses/Kconfig | 11 + > drivers/i2c/busses/Makefile | 1 + > drivers/i2c/busses/i2c-fsi.c | 727 ++++++++++++++++++++++ > 4 files changed, 779 insertions(+) > create mode 100644 Documentation/devicetree/bindings/i2c/i2c-fsi.txt > create mode 100644 drivers/i2c/busses/i2c-fsi.c > > -- > 1.8.3.1 >
On 14 June 2018 at 05:06, Eddie James <eajames@linux.vnet.ibm.com> wrote: > This series adds an algorithm for an I2C master physically located on an FSI > slave device. The I2C master has multiple ports, each of which may be connected > to an I2C slave. Access to the I2C master registers is achieved over FSI bus. > > Due to the multi-port nature of the I2C master, the driver instantiates a new > I2C adapter for each port connected to a slave. The connected ports should be > defined in the device tree under the I2C master device. Looks good Eddie. I had a read over what you have, and I would be happy to see this merged in 4.19. Reviewed-By: Joel Stanley <joel@jms.id.au> Also, I have merged this into the 4.17 based openbmc tree for testing while we wait for it to be merged upstream. Cheers, Joel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 20 June 2018 at 13:04, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > On Wed, 2018-06-13 at 14:36 -0500, Eddie James wrote: >> } >> >> +static int fsi_i2c_remove(struct device *dev) >> +{ >> + struct fsi_i2c_master *i2c = dev_get_drvdata(dev); >> + struct fsi_i2c_port *port; >> + >> + list_for_each_entry(port, &i2c->ports, list) { >> + i2c_del_adapter(&port->adapter); >> + kfree(port); >> + } >> + >> + return 0; >> +} >> + > > This is a use-after-free, the list linkage of the freed port is used to > get to the next one. With memory poisoning, kbooom ! > > You can fold that in: > > From f9d9092160897e7308f6990067a03e937339537f Mon Sep 17 00:00:00 2001 > From: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Date: Wed, 20 Jun 2018 13:27:32 +1000 > Subject: [PATCH] i2c: fsi: Fix use after free This fixes the issue I was seeing. For the series: Tested-by: Joel Stanley <joel@jms.id.au> Thanks, Joel > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > --- > drivers/i2c/busses/i2c-fsi.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-fsi.c b/drivers/i2c/busses/i2c-fsi.c > index 713959b44403..ff69ab6aa79a 100644 > --- a/drivers/i2c/busses/i2c-fsi.c > +++ b/drivers/i2c/busses/i2c-fsi.c > @@ -696,9 +696,10 @@ static int fsi_i2c_probe(struct device *dev) > static int fsi_i2c_remove(struct device *dev) > { > struct fsi_i2c_master *i2c = dev_get_drvdata(dev); > - struct fsi_i2c_port *port; > + struct fsi_i2c_port *port, *tmp; > > - list_for_each_entry(port, &i2c->ports, list) { > + list_for_each_entry_safe(port,tmp, &i2c->ports, list) { > + list_del(&port->list); > i2c_del_adapter(&port->adapter); > kfree(port); > } > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 13, 2018 at 02:36:17PM -0500, Eddie James wrote: > Execute I2C transfers from the FSI-attached I2C master. Use polling > instead of interrupts as we have no hardware IRQ over FSI. > > Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com> > --- > drivers/i2c/busses/i2c-fsi.c | 195 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 193 insertions(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-fsi.c b/drivers/i2c/busses/i2c-fsi.c > index 4611a0b..8c0a6cb 100644 > --- a/drivers/i2c/busses/i2c-fsi.c > +++ b/drivers/i2c/busses/i2c-fsi.c > @@ -155,6 +155,7 @@ struct fsi_i2c_port { > struct i2c_adapter adapter; > struct fsi_i2c_master *master; > u16 port; > + u16 xfrd; > }; > > static int fsi_i2c_read_reg(struct fsi_device *fsi, unsigned int reg, > @@ -230,6 +231,99 @@ static int fsi_i2c_set_port(struct fsi_i2c_port *port) > return fsi_i2c_write_reg(fsi, I2C_FSI_RESET_ERR, &dummy); > } > > +static int fsi_i2c_start(struct fsi_i2c_port *port, struct i2c_msg *msg, > + bool stop) > +{ > + struct fsi_i2c_master *i2c = port->master; > + u32 cmd = I2C_CMD_WITH_START | I2C_CMD_WITH_ADDR; > + > + port->xfrd = 0; > + > + if (msg->flags & I2C_M_RD) > + cmd |= I2C_CMD_READ; Since you support MANGLING, I'd think you can easily support I2C_M_REV_DIR_ADDR here, too? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 13, 2018 at 02:36:19PM -0500, Eddie James wrote: > Bus recovery should reset the engine and force clock the bus 9 times > to recover most situations. > > Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com> > --- > drivers/i2c/busses/i2c-fsi.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/drivers/i2c/busses/i2c-fsi.c b/drivers/i2c/busses/i2c-fsi.c > index d6cab4b..940b198 100644 > --- a/drivers/i2c/busses/i2c-fsi.c > +++ b/drivers/i2c/busses/i2c-fsi.c > @@ -611,6 +611,24 @@ static u32 fsi_i2c_functionality(struct i2c_adapter *adap) > I2C_FUNC_SMBUS_BLOCK_DATA; > } > > +static int fsi_i2c_recover_bus(struct i2c_adapter *adap) > +{ > + int rc; > + struct fsi_i2c_port *port = adap->algo_data; > + struct fsi_i2c_master *master = port->master; > + > + mutex_lock(&master->lock); > + > + rc = fsi_i2c_reset(master, port->port); > + > + mutex_unlock(&master->lock); > + return rc; > +} > + > +static struct i2c_bus_recovery_info fsi_i2c_bus_recovery_info = { > + .recover_bus = fsi_i2c_recover_bus, > +}; > + This all won't have any effect since you never call i2c_recover_bus which calls back into i2c_bus_recovery_info callbacks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 13, 2018 at 02:36:16PM -0500, Eddie James wrote: > Add abort procedure for failed transfers. Add engine and bus reset > procedures to recover from as many faults as possible. I think this is a way too aggressive recovery. Your are doing the 9 pulse toggles basically on any error while this is only when the device keeps SDA low and you want to recover from that. If SDA is not stuck low, sending a STOP should do. Or do you have a known case where this is not going to work? Also, you implement the pulse toggling manually. Can't you just populate {get|set}_{scl|sda} and use the generic routine we have in the core? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 13, 2018 at 02:36:12PM -0500, Eddie James wrote: > This series adds an algorithm for an I2C master physically located on an FSI > slave device. The I2C master has multiple ports, each of which may be connected > to an I2C slave. Access to the I2C master registers is achieved over FSI bus. > > Due to the multi-port nature of the I2C master, the driver instantiates a new > I2C adapter for each port connected to a slave. The connected ports should be > defined in the device tree under the I2C master device. Thanks for this series and your patience. While I can see why it also helps reviewing to send it as a series of multiple patches, I consider applying the driver itself as just one hunk. I am not decided on this yet. I have a few comments, especially about recovery. I replied to the relevant patches with more detail. Also, are you (or someone from your company) willing to maintain the driver? Then, an addition to MAINTAINERS would be much appreciated. Thanks, Wolfram -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/25/2018 09:38 PM, Wolfram Sang wrote: > On Wed, Jun 13, 2018 at 02:36:17PM -0500, Eddie James wrote: >> Execute I2C transfers from the FSI-attached I2C master. Use polling >> instead of interrupts as we have no hardware IRQ over FSI. >> >> Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com> >> --- >> drivers/i2c/busses/i2c-fsi.c | 195 ++++++++++++++++++++++++++++++++++++++++++- >> 1 file changed, 193 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-fsi.c b/drivers/i2c/busses/i2c-fsi.c >> index 4611a0b..8c0a6cb 100644 >> --- a/drivers/i2c/busses/i2c-fsi.c >> +++ b/drivers/i2c/busses/i2c-fsi.c >> @@ -155,6 +155,7 @@ struct fsi_i2c_port { >> struct i2c_adapter adapter; >> struct fsi_i2c_master *master; >> u16 port; >> + u16 xfrd; >> }; >> >> static int fsi_i2c_read_reg(struct fsi_device *fsi, unsigned int reg, >> @@ -230,6 +231,99 @@ static int fsi_i2c_set_port(struct fsi_i2c_port *port) >> return fsi_i2c_write_reg(fsi, I2C_FSI_RESET_ERR, &dummy); >> } >> >> +static int fsi_i2c_start(struct fsi_i2c_port *port, struct i2c_msg *msg, >> + bool stop) >> +{ >> + struct fsi_i2c_master *i2c = port->master; >> + u32 cmd = I2C_CMD_WITH_START | I2C_CMD_WITH_ADDR; >> + >> + port->xfrd = 0; >> + >> + if (msg->flags & I2C_M_RD) >> + cmd |= I2C_CMD_READ; > Since you support MANGLING, I'd think you can easily support > I2C_M_REV_DIR_ADDR here, too? Hm, I don't really understand the purpose of that flag. From the docs: This toggles the Rd/Wr flag. That is, if you want to do a write, but need to emit an Rd instead of a Wr, or vice versa, you set this flag. For example: S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P I don't think our hardware supports this type of operation. Thanks, Eddie > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/25/2018 09:38 PM, Wolfram Sang wrote: > On Wed, Jun 13, 2018 at 02:36:19PM -0500, Eddie James wrote: >> Bus recovery should reset the engine and force clock the bus 9 times >> to recover most situations. >> >> Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com> >> --- >> drivers/i2c/busses/i2c-fsi.c | 19 +++++++++++++++++++ >> 1 file changed, 19 insertions(+) >> >> diff --git a/drivers/i2c/busses/i2c-fsi.c b/drivers/i2c/busses/i2c-fsi.c >> index d6cab4b..940b198 100644 >> --- a/drivers/i2c/busses/i2c-fsi.c >> +++ b/drivers/i2c/busses/i2c-fsi.c >> @@ -611,6 +611,24 @@ static u32 fsi_i2c_functionality(struct i2c_adapter *adap) >> I2C_FUNC_SMBUS_BLOCK_DATA; >> } >> >> +static int fsi_i2c_recover_bus(struct i2c_adapter *adap) >> +{ >> + int rc; >> + struct fsi_i2c_port *port = adap->algo_data; >> + struct fsi_i2c_master *master = port->master; >> + >> + mutex_lock(&master->lock); >> + >> + rc = fsi_i2c_reset(master, port->port); >> + >> + mutex_unlock(&master->lock); >> + return rc; >> +} >> + >> +static struct i2c_bus_recovery_info fsi_i2c_bus_recovery_info = { >> + .recover_bus = fsi_i2c_recover_bus, >> +}; >> + > This all won't have any effect since you never call i2c_recover_bus > which calls back into i2c_bus_recovery_info callbacks. Ah, I thought there would be some use of this in the core or in client drivers, or some ioctl interface. Would there be any outside users of these callbacks in the future? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/25/2018 09:38 PM, Wolfram Sang wrote: > On Wed, Jun 13, 2018 at 02:36:16PM -0500, Eddie James wrote: >> Add abort procedure for failed transfers. Add engine and bus reset >> procedures to recover from as many faults as possible. > I think this is a way too aggressive recovery. Your are doing the 9 > pulse toggles basically on any error while this is only when the device > keeps SDA low and you want to recover from that. If SDA is not stuck > low, sending a STOP should do. Or do you have a known case where this is > not going to work? It is aggressive, but I don't see the harm in doing this on every error. There are some other error conditions with this hardware which may require the clock toggling, such as "bus arbitration lost." I think this is the safest option for this hardware, and this routine has been tested for many years. > > Also, you implement the pulse toggling manually. Can't you just populate > {get|set}_{scl|sda} and use the generic routine we have in the core? I see that the generic implementation breaks the loop if it sees the clock isn't high after setting it, or if SDA goes high. I think it's safer to finish the reset for our hardware. Plus, we actually have different registers for setting 0 or 1 to the clock/data, so we save some cpu cycles by doing it directly instead of implementing set_scl/sda and having to check val every time :) If you feel very strongly that this recovery procedure needs to be reduced, then I will work on that and have to do some extensive testing. Thanks! Eddie > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/25/2018 09:39 PM, Wolfram Sang wrote: > On Wed, Jun 13, 2018 at 02:36:12PM -0500, Eddie James wrote: >> This series adds an algorithm for an I2C master physically located on an FSI >> slave device. The I2C master has multiple ports, each of which may be connected >> to an I2C slave. Access to the I2C master registers is achieved over FSI bus. >> >> Due to the multi-port nature of the I2C master, the driver instantiates a new >> I2C adapter for each port connected to a slave. The connected ports should be >> defined in the device tree under the I2C master device. > Thanks for this series and your patience. > > While I can see why it also helps reviewing to send it as a series of > multiple patches, I consider applying the driver itself as just one > hunk. I am not decided on this yet. > > I have a few comments, especially about recovery. I replied to the > relevant patches with more detail. > > Also, are you (or someone from your company) willing to maintain the > driver? Then, an addition to MAINTAINERS would be much appreciated. Thanks for the review Wolfram! I addressed your comments about recovery, please let me know what you think. I will fix the email for the dt patch and make an addition to MAINTAINERS for the next version. Thanks, Eddie > > Thanks, > > Wolfram > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Eddie, > > I think this is a way too aggressive recovery. Your are doing the 9 > > pulse toggles basically on any error while this is only when the device > > keeps SDA low and you want to recover from that. If SDA is not stuck > > low, sending a STOP should do. Or do you have a known case where this is > > not going to work? > > It is aggressive, but I don't see the harm in doing this on every error. Well, as it happens, I just fixed such a case. Please check these patch series and elinux wiki pages: === (new fault injector) [PATCH v2 0/2] i2c: gpio: fault-injector: add new injector (actual recovery fix) [PATCH 0/2] i2c: recovery: make sure pulses are not misinterpreted === And here is the new elinux wiki page to describe my findings: https://elinux.org/Tests:I2C-bus-recovery-write-byte-fix Also, the previous pages have been updated to reflect the latest status: https://elinux.org/Tests:I2C-fault-injection https://elinux.org/Tests:I2C-bus-recovery To sum it up: This is a proven case where uncontrolled bus recovery can result into a bogus write! > There are some other error conditions with this hardware which may require > the clock toggling, such as "bus arbitration lost." I think this is the Why is that? In my understanding, recovery is *only* needed when SDA is stuck low. If SDA is high, sending STOP should do. If not, it needs to be researched why. > safest option for this hardware, and this routine has been tested for many > years. I remember having a similar argument with Joakim Tjernlund a while ago. I recently re-read our argument, yet I still keep my position: I don't want to do $random things to recover, just a tested and well understood procedure. And in that thread, I was never given a test case. > > > > Also, you implement the pulse toggling manually. Can't you just populate > > {get|set}_{scl|sda} and use the generic routine we have in the core? > > I see that the generic implementation breaks the loop if it sees the clock > isn't high after setting it, or if SDA goes high. I think it's safer to > finish the reset for our hardware. Plus, we actually have different Why do you think it is safer? What is the test case for that? I think one really should do check SDA! See above, you might trigger a write otherwise. If this breaks something for you, I am looking forward to discuss it. > registers for setting 0 or 1 to the clock/data, so we save some cpu cycles > by doing it directly instead of implementing set_scl/sda and having to check > val every time :) Correctness comes above all here. And I am afraid your implementation is not correct. > If you feel very strongly that this recovery procedure needs to be reduced, > then I will work on that and have to do some extensive testing. I am open for discussion, yet I also feel strong about it. The reason why the recovery procedure is moved into the core is to have one working and understood bit-banging algorithm which all drivers can rely on. If all drivers implement their custom version, they might miss gory details like the above write_byte fix. I do understand this might cause testing effort for you, I am sorry for the delay it causes. However, my goal as a maintainer is to have a reliable recovery mechanism, for your driver as well as for all drivers. I hope this is understandable. BTW if you want this driver upstream soon, then it may be an idea to resend it without any bus recovery and then we can work on it incrementally. Kind regards and thanks, Wolfram
> > This all won't have any effect since you never call i2c_recover_bus > > which calls back into i2c_bus_recovery_info callbacks. > > Ah, I thought there would be some use of this in the core or in client > drivers, or some ioctl interface. Would there be any outside users of these > callbacks in the future? No. i2c_recover_bus() is only to recover from stalled SDA and the only place where this can be detected is inside the I2C master driver. It is not an event which can be controlled by a user.
> > > + if (msg->flags & I2C_M_RD) > > > + cmd |= I2C_CMD_READ; > > Since you support MANGLING, I'd think you can easily support > > I2C_M_REV_DIR_ADDR here, too? > > Hm, I don't really understand the purpose of that flag. From the docs: > > This toggles the Rd/Wr flag. That is, if you want to do a write, but > need to emit an Rd instead of a Wr, or vice versa, you set this > flag. For example: > S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P > > I don't think our hardware supports this type of operation. I'd think something like this should do: if (msg->flags & I2C_M_REV_DIR_ADDR) cmd ^= I2C_CMD_READ;
On 07/02/2018 01:15 PM, Wolfram Sang wrote: > Hi Eddie, > >>> I think this is a way too aggressive recovery. Your are doing the 9 >>> pulse toggles basically on any error while this is only when the device >>> keeps SDA low and you want to recover from that. If SDA is not stuck >>> low, sending a STOP should do. Or do you have a known case where this is >>> not going to work? >> It is aggressive, but I don't see the harm in doing this on every error. > Well, as it happens, I just fixed such a case. Please check these patch > series and elinux wiki pages: > > === > > (new fault injector) > [PATCH v2 0/2] i2c: gpio: fault-injector: add new injector > > (actual recovery fix) > [PATCH 0/2] i2c: recovery: make sure pulses are not misinterpreted > > === > > And here is the new elinux wiki page to describe my findings: > > https://elinux.org/Tests:I2C-bus-recovery-write-byte-fix > > Also, the previous pages have been updated to reflect the latest status: > > https://elinux.org/Tests:I2C-fault-injection > https://elinux.org/Tests:I2C-bus-recovery > > To sum it up: This is a proven case where uncontrolled bus recovery can > result into a bogus write! > >> There are some other error conditions with this hardware which may require >> the clock toggling, such as "bus arbitration lost." I think this is the > Why is that? In my understanding, recovery is *only* needed when SDA is > stuck low. If SDA is high, sending STOP should do. If not, it needs to > be researched why. > >> safest option for this hardware, and this routine has been tested for many >> years. > I remember having a similar argument with Joakim Tjernlund a while ago. > I recently re-read our argument, yet I still keep my position: I don't > want to do $random things to recover, just a tested and well understood > procedure. And in that thread, I was never given a test case. > >>> Also, you implement the pulse toggling manually. Can't you just populate >>> {get|set}_{scl|sda} and use the generic routine we have in the core? >> I see that the generic implementation breaks the loop if it sees the clock >> isn't high after setting it, or if SDA goes high. I think it's safer to >> finish the reset for our hardware. Plus, we actually have different > Why do you think it is safer? What is the test case for that? I think > one really should do check SDA! See above, you might trigger a write > otherwise. If this breaks something for you, I am looking forward to > discuss it. > >> registers for setting 0 or 1 to the clock/data, so we save some cpu cycles >> by doing it directly instead of implementing set_scl/sda and having to check >> val every time :) > Correctness comes above all here. And I am afraid your implementation is > not correct. > >> If you feel very strongly that this recovery procedure needs to be reduced, >> then I will work on that and have to do some extensive testing. > I am open for discussion, yet I also feel strong about it. The reason > why the recovery procedure is moved into the core is to have one working > and understood bit-banging algorithm which all drivers can rely on. If > all drivers implement their custom version, they might miss gory details > like the above write_byte fix. > > I do understand this might cause testing effort for you, I am sorry for > the delay it causes. However, my goal as a maintainer is to have a > reliable recovery mechanism, for your driver as well as for all drivers. > > I hope this is understandable. BTW if you want this driver upstream > soon, then it may be an idea to resend it without any bus recovery and > then we can work on it incrementally. Thanks for the details. I have sent up a new series which will only do the bus reset if SDA is low. With our current hardware configuration, this *should* be sufficient to recover all the possible errors. However, there are configurations where it will not be enough, in which case getting the data line stuck high or clock line stuck either high or low can occur, necessitating the full reset. But since I can't demonstrate those at the moment, I can't argue to include that now :) Thanks again, Eddie > > Kind regards and thanks, > > Wolfram -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/02/2018 01:24 PM, Wolfram Sang wrote: >>>> + if (msg->flags & I2C_M_RD) >>>> + cmd |= I2C_CMD_READ; >>> Since you support MANGLING, I'd think you can easily support >>> I2C_M_REV_DIR_ADDR here, too? >> Hm, I don't really understand the purpose of that flag. From the docs: >> >> This toggles the Rd/Wr flag. That is, if you want to do a write, but >> need to emit an Rd instead of a Wr, or vice versa, you set this >> flag. For example: >> S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P >> >> I don't think our hardware supports this type of operation. > I'd think something like this should do: > > if (msg->flags & I2C_M_REV_DIR_ADDR) > cmd ^= I2C_CMD_READ; I meant that the hardware cannot interpret this, it would be a meaningless command unfortunately. > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> I meant that the hardware cannot interpret this, it would be a meaningless > command unfortunately. I see. Thanks for double-checking.
Eddie, > Thanks for the details. I have sent up a new series which will only do the > bus reset if SDA is low. With our current hardware configuration, this Thanks. > *should* be sufficient to recover all the possible errors. However, there > are configurations where it will not be enough, in which case getting the > data line stuck high or clock line stuck either high or low can occur, > necessitating the full reset. But since I can't demonstrate those at the > moment, I can't argue to include that now :) For the record, I am *really* interested in these cases. Just from reading the above I wonder how SDA can stuck high when being open drain, and how you will create 9 SCL pulses if SCL is stuck low. But if we have a test case, we will figure out something together. Thanks, Wolfram