| Message ID | 1498095926-51264-1-git-send-email-matthew.weber@rockwellcollins.com |
|---|---|
| State | Superseded |
| Headers | show |
On Wed, Jun 21, 2017 at 08:45:26PM -0500, Matt Weber wrote: > The driver was clearing the hold bit in the control register before > writing to the address register which resulted in a stop condition > being generated rather than a repeated start. > > This issue was only observed when a system was running much > slower than a normal processor would execute. The IP data sheet > mentions a ordering of writing to the address register before > clearing the hold. > > Signed-off-by: John Linn <john.linn@xilinx.com> > Signed-off-by: Paresh Chaudhary <paresh.chaudhary@rockwellcollins.com> > Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> Looks good. It seems not urgent to me, though. Are you fine with me scheduling it for 4.13 yet with a stable tag attached? Or do you consider it 4.12 material? And if you could provide a Fixes: tag that would be helpful. Thanks for the patch!
Wolfram, On Thu, Jun 22, 2017 at 3:35 AM, Wolfram Sang <wsa@the-dreams.de> wrote: > On Wed, Jun 21, 2017 at 08:45:26PM -0500, Matt Weber wrote: >> The driver was clearing the hold bit in the control register before >> writing to the address register which resulted in a stop condition >> being generated rather than a repeated start. >> >> This issue was only observed when a system was running much >> slower than a normal processor would execute. The IP data sheet >> mentions a ordering of writing to the address register before >> clearing the hold. >> >> Signed-off-by: John Linn <john.linn@xilinx.com> >> Signed-off-by: Paresh Chaudhary <paresh.chaudhary@rockwellcollins.com> >> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> > > Looks good. It seems not urgent to me, though. Are you fine with me > scheduling it for 4.13 yet with a stable tag attached? Or do you > consider it 4.12 material? And if you could provide a Fixes: tag that > would be helpful. > Not urgent, fell free to work it in where it makes sense. We're on a older LTS at this point and will carry the patch. For the Fixes: tag in this case, should I just prefix my last statement about the issue as there isn't a public bug report or specific commit I can note? I could add cadence ref manual section and a link to a public download of the doc. Matt
> Not urgent, fell free to work it in where it makes sense. We're on a > older LTS at this point and will carry the patch. Okay then. I'll add it to 4.13. > For the Fixes: tag in this case, should I just prefix my last > statement about the issue as there isn't a public bug report or > specific commit I can note? I could add cadence ref manual section > and a link to a public download of the doc. The Fixes: tag is for specifying the commit ID which introduced the bug. So, all stable kernel versions having that commit ID know they want the patch carrying the Fixes: tag. I can look it up as well, but it makes my life easier if I get it provided. No worries!
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c index 45d6771..75d8016 100644 --- a/drivers/i2c/busses/i2c-cadence.c +++ b/drivers/i2c/busses/i2c-cadence.c @@ -405,14 +405,14 @@ static void cdns_i2c_mrecv(struct cdns_i2c *id) cdns_i2c_writereg(id->recv_count, CDNS_I2C_XFER_SIZE_OFFSET); } + /* Set the slave address in address register - triggers operation */ + cdns_i2c_writereg(id->p_msg->addr & CDNS_I2C_ADDR_MASK, + CDNS_I2C_ADDR_OFFSET); /* Clear the bus hold flag if bytes to receive is less than FIFO size */ if (!id->bus_hold_flag && ((id->p_msg->flags & I2C_M_RECV_LEN) != I2C_M_RECV_LEN) && (id->recv_count <= CDNS_I2C_FIFO_DEPTH)) cdns_i2c_clear_bus_hold(id); - /* Set the slave address in address register - triggers operation */ - cdns_i2c_writereg(id->p_msg->addr & CDNS_I2C_ADDR_MASK, - CDNS_I2C_ADDR_OFFSET); cdns_i2c_writereg(CDNS_I2C_ENABLED_INTR_MASK, CDNS_I2C_IER_OFFSET); }