[PATCH v2 1/2] i3c: master: svc: fix IBIWON not set if IBI follow a hot join

[PATCH v2 1/2] i3c: master: svc: fix IBIWON not set if IBI follow a hot join

[Frank Li]

When an In-Band Interrupt(IBI) occurs after svc_i3c_master_do_daa_locked(),
typically triggered during a Hot Join (HJ) event, the IBIWON flag fails to
be set when issuing an auto IBI command.

The issue stems from the omission of emitting STOP upon successful
execution of svc_i3c_master_do_daa_locked(). Consequently, the controller
interprets it as a repeat start when emitting the auto IBI command. Per the
I3C specification, an IBI should never occur during a repeat start, thus
preventing the IBIWON flag from being set.

Emit STOP regardless of the success or failure of
svc_i3c_master_do_daa_locked() to match I3C spec requirement.

Cc: <stable@vger.kernel.org>
Fixes: 05b26c31a485 ("i3c: master: svc: add hot join support")
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---

Notes:
    Change from v1 to v2
    - update fixes tag

 drivers/i3c/master/svc-i3c-master.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/i3c/master/svc-i3c-master.c b/drivers/i3c/master/svc-i3c-master.c
index bb299ce02cccb..032fe032ec433 100644
--- a/drivers/i3c/master/svc-i3c-master.c
+++ b/drivers/i3c/master/svc-i3c-master.c
@@ -961,11 +961,11 @@ static int svc_i3c_master_do_daa(struct i3c_master_controller *m)
 	spin_lock_irqsave(&master->xferqueue.lock, flags);
 	ret = svc_i3c_master_do_daa_locked(master, addrs, &dev_nb);
 	spin_unlock_irqrestore(&master->xferqueue.lock, flags);
-	if (ret) {
-		svc_i3c_master_emit_stop(master);
-		svc_i3c_master_clear_merrwarn(master);
+
+	svc_i3c_master_emit_stop(master);
+	svc_i3c_master_clear_merrwarn(master);
+	if (ret)
 		goto rpm_out;
-	}
 
 	/* Register all devices who participated to the core */
 	for (i = 0; i < dev_nb; i++) {
-- 
2.34.1

[PATCH v2 1/2] i3c: master: svc: fix IBIWON not set if IBI follow a hot join

[Frank Li]

When an In-Band Interrupt(IBI) occurs after svc_i3c_master_do_daa_locked(),
typically triggered during a Hot Join (HJ) event, the IBIWON flag fails to
be set when issuing an auto IBI command.

The issue stems from the omission of emitting STOP upon successful
execution of svc_i3c_master_do_daa_locked(). Consequently, the controller
interprets it as a repeat start when emitting the auto IBI command. Per the
I3C specification, an IBI should never occur during a repeat start, thus
preventing the IBIWON flag from being set.

Emit STOP regardless of the success or failure of
svc_i3c_master_do_daa_locked() to match I3C spec requirement.

Cc: <stable@vger.kernel.org>
Fixes: 05b26c31a485 ("i3c: master: svc: add hot join support")
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---

Notes:
    Change from v1 to v2
    - update fixes tag

 drivers/i3c/master/svc-i3c-master.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/i3c/master/svc-i3c-master.c b/drivers/i3c/master/svc-i3c-master.c
index bb299ce02cccb..032fe032ec433 100644
--- a/drivers/i3c/master/svc-i3c-master.c
+++ b/drivers/i3c/master/svc-i3c-master.c
@@ -961,11 +961,11 @@ static int svc_i3c_master_do_daa(struct i3c_master_controller *m)
 	spin_lock_irqsave(&master->xferqueue.lock, flags);
 	ret = svc_i3c_master_do_daa_locked(master, addrs, &dev_nb);
 	spin_unlock_irqrestore(&master->xferqueue.lock, flags);
-	if (ret) {
-		svc_i3c_master_emit_stop(master);
-		svc_i3c_master_clear_merrwarn(master);
+
+	svc_i3c_master_emit_stop(master);
+	svc_i3c_master_clear_merrwarn(master);
+	if (ret)
 		goto rpm_out;
-	}
 
 	/* Register all devices who participated to the core */
 	for (i = 0; i < dev_nb; i++) {
-- 
2.34.1


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

[PATCH v2 2/2] i3c: master: svc: resend target address when get NACK

[Frank Li]

According to I3C Spec 1.1.1, 11-Jun-2021, section: 5.1.2.2.3:

If the Controller chooses to start an I3C Message with an I3C Dynamic
Address, then special provisions shall be made because that same I3C Target
may be initiating an IBI or a Controller Role Request. So, one of three
things may happen: (skip 1, 2)

3. The Addresses match and the RnW bits also match, and so neither
Controller nor Target will ACK since both are expecting the other side to
provide ACK. As a result, each side might think it had "won" arbitration,
but neither side would continue, as each would subsequently see that the
other did not provide ACK.
...
For either value of RnW: Due to the NACK, the Controller shall defer the
Private Write or Private Read, and should typically transmit the Target
						    ^^^^^^^^^^^^^^^^^^^
Address again after a Repeated START (i.e., the next one or any one prior
^^^^^^^^^^^^^
to a STOP in the Frame). Since the Address Header following a Repeated
START is not arbitrated, the Controller will always win (see Section
5.1.2.2.4).

Resend target address again if address is not 7E and controller get NACK.

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---

Notes:
    Change from v1 to v2
    Add Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

 drivers/i3c/master/svc-i3c-master.c | 58 ++++++++++++++++++++++-------
 1 file changed, 44 insertions(+), 14 deletions(-)

diff --git a/drivers/i3c/master/svc-i3c-master.c b/drivers/i3c/master/svc-i3c-master.c
index 032fe032ec433..0b588ed5894ea 100644
--- a/drivers/i3c/master/svc-i3c-master.c
+++ b/drivers/i3c/master/svc-i3c-master.c
@@ -1052,29 +1052,59 @@ static int svc_i3c_master_xfer(struct svc_i3c_master *master,
 			       u8 *in, const u8 *out, unsigned int xfer_len,
 			       unsigned int *actual_len, bool continued)
 {
+	int retry = 2;
 	u32 reg;
 	int ret;
 
 	/* clean SVC_I3C_MINT_IBIWON w1c bits */
 	writel(SVC_I3C_MINT_IBIWON, master->regs + SVC_I3C_MSTATUS);
 
-	writel(SVC_I3C_MCTRL_REQUEST_START_ADDR |
-	       xfer_type |
-	       SVC_I3C_MCTRL_IBIRESP_NACK |
-	       SVC_I3C_MCTRL_DIR(rnw) |
-	       SVC_I3C_MCTRL_ADDR(addr) |
-	       SVC_I3C_MCTRL_RDTERM(*actual_len),
-	       master->regs + SVC_I3C_MCTRL);
 
-	ret = readl_poll_timeout(master->regs + SVC_I3C_MSTATUS, reg,
+	while (retry--) {
+		writel(SVC_I3C_MCTRL_REQUEST_START_ADDR |
+		       xfer_type |
+		       SVC_I3C_MCTRL_IBIRESP_NACK |
+		       SVC_I3C_MCTRL_DIR(rnw) |
+		       SVC_I3C_MCTRL_ADDR(addr) |
+		       SVC_I3C_MCTRL_RDTERM(*actual_len),
+		       master->regs + SVC_I3C_MCTRL);
+
+		ret = readl_poll_timeout(master->regs + SVC_I3C_MSTATUS, reg,
 				 SVC_I3C_MSTATUS_MCTRLDONE(reg), 0, 1000);
-	if (ret)
-		goto emit_stop;
+		if (ret)
+			goto emit_stop;
 
-	if (readl(master->regs + SVC_I3C_MERRWARN) & SVC_I3C_MERRWARN_NACK) {
-		ret = -ENXIO;
-		*actual_len = 0;
-		goto emit_stop;
+		if (readl(master->regs + SVC_I3C_MERRWARN) & SVC_I3C_MERRWARN_NACK) {
+			/*
+			 * According to I3C Spec 1.1.1, 11-Jun-2021, section: 5.1.2.2.3.
+			 * If the Controller chooses to start an I3C Message with an I3C Dynamic
+			 * Address, then special provisions shall be made because that same I3C
+			 * Target may be initiating an IBI or a Controller Role Request. So, one of
+			 * three things may happen: (skip 1, 2)
+			 *
+			 * 3. The Addresses match and the RnW bits also match, and so neither
+			 * Controller nor Target will ACK since both are expecting the other side to
+			 * provide ACK. As a result, each side might think it had "won" arbitration,
+			 * but neither side would continue, as each would subsequently see that the
+			 * other did not provide ACK.
+			 * ...
+			 * For either value of RnW: Due to the NACK, the Controller shall defer the
+			 * Private Write or Private Read, and should typically transmit the Target
+			 * Address again after a Repeated START (i.e., the next one or any one prior
+			 * to a STOP in the Frame). Since the Address Header following a Repeated
+			 * START is not arbitrated, the Controller will always win (see Section
+			 * 5.1.2.2.4).
+			 */
+			if (retry && addr != 0x7e) {
+				writel(SVC_I3C_MERRWARN_NACK, master->regs + SVC_I3C_MERRWARN);
+			} else {
+				ret = -ENXIO;
+				*actual_len = 0;
+				goto emit_stop;
+			}
+		} else {
+			break;
+		}
 	}
 
 	/*
-- 
2.34.1

[PATCH v2 2/2] i3c: master: svc: resend target address when get NACK

[Frank Li]

According to I3C Spec 1.1.1, 11-Jun-2021, section: 5.1.2.2.3:

If the Controller chooses to start an I3C Message with an I3C Dynamic
Address, then special provisions shall be made because that same I3C Target
may be initiating an IBI or a Controller Role Request. So, one of three
things may happen: (skip 1, 2)

3. The Addresses match and the RnW bits also match, and so neither
Controller nor Target will ACK since both are expecting the other side to
provide ACK. As a result, each side might think it had "won" arbitration,
but neither side would continue, as each would subsequently see that the
other did not provide ACK.
...
For either value of RnW: Due to the NACK, the Controller shall defer the
Private Write or Private Read, and should typically transmit the Target
						    ^^^^^^^^^^^^^^^^^^^
Address again after a Repeated START (i.e., the next one or any one prior
^^^^^^^^^^^^^
to a STOP in the Frame). Since the Address Header following a Repeated
START is not arbitrated, the Controller will always win (see Section
5.1.2.2.4).

Resend target address again if address is not 7E and controller get NACK.

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---

Notes:
    Change from v1 to v2
    Add Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

 drivers/i3c/master/svc-i3c-master.c | 58 ++++++++++++++++++++++-------
 1 file changed, 44 insertions(+), 14 deletions(-)

diff --git a/drivers/i3c/master/svc-i3c-master.c b/drivers/i3c/master/svc-i3c-master.c
index 032fe032ec433..0b588ed5894ea 100644
--- a/drivers/i3c/master/svc-i3c-master.c
+++ b/drivers/i3c/master/svc-i3c-master.c
@@ -1052,29 +1052,59 @@ static int svc_i3c_master_xfer(struct svc_i3c_master *master,
 			       u8 *in, const u8 *out, unsigned int xfer_len,
 			       unsigned int *actual_len, bool continued)
 {
+	int retry = 2;
 	u32 reg;
 	int ret;
 
 	/* clean SVC_I3C_MINT_IBIWON w1c bits */
 	writel(SVC_I3C_MINT_IBIWON, master->regs + SVC_I3C_MSTATUS);
 
-	writel(SVC_I3C_MCTRL_REQUEST_START_ADDR |
-	       xfer_type |
-	       SVC_I3C_MCTRL_IBIRESP_NACK |
-	       SVC_I3C_MCTRL_DIR(rnw) |
-	       SVC_I3C_MCTRL_ADDR(addr) |
-	       SVC_I3C_MCTRL_RDTERM(*actual_len),
-	       master->regs + SVC_I3C_MCTRL);
 
-	ret = readl_poll_timeout(master->regs + SVC_I3C_MSTATUS, reg,
+	while (retry--) {
+		writel(SVC_I3C_MCTRL_REQUEST_START_ADDR |
+		       xfer_type |
+		       SVC_I3C_MCTRL_IBIRESP_NACK |
+		       SVC_I3C_MCTRL_DIR(rnw) |
+		       SVC_I3C_MCTRL_ADDR(addr) |
+		       SVC_I3C_MCTRL_RDTERM(*actual_len),
+		       master->regs + SVC_I3C_MCTRL);
+
+		ret = readl_poll_timeout(master->regs + SVC_I3C_MSTATUS, reg,
 				 SVC_I3C_MSTATUS_MCTRLDONE(reg), 0, 1000);
-	if (ret)
-		goto emit_stop;
+		if (ret)
+			goto emit_stop;
 
-	if (readl(master->regs + SVC_I3C_MERRWARN) & SVC_I3C_MERRWARN_NACK) {
-		ret = -ENXIO;
-		*actual_len = 0;
-		goto emit_stop;
+		if (readl(master->regs + SVC_I3C_MERRWARN) & SVC_I3C_MERRWARN_NACK) {
+			/*
+			 * According to I3C Spec 1.1.1, 11-Jun-2021, section: 5.1.2.2.3.
+			 * If the Controller chooses to start an I3C Message with an I3C Dynamic
+			 * Address, then special provisions shall be made because that same I3C
+			 * Target may be initiating an IBI or a Controller Role Request. So, one of
+			 * three things may happen: (skip 1, 2)
+			 *
+			 * 3. The Addresses match and the RnW bits also match, and so neither
+			 * Controller nor Target will ACK since both are expecting the other side to
+			 * provide ACK. As a result, each side might think it had "won" arbitration,
+			 * but neither side would continue, as each would subsequently see that the
+			 * other did not provide ACK.
+			 * ...
+			 * For either value of RnW: Due to the NACK, the Controller shall defer the
+			 * Private Write or Private Read, and should typically transmit the Target
+			 * Address again after a Repeated START (i.e., the next one or any one prior
+			 * to a STOP in the Frame). Since the Address Header following a Repeated
+			 * START is not arbitrated, the Controller will always win (see Section
+			 * 5.1.2.2.4).
+			 */
+			if (retry && addr != 0x7e) {
+				writel(SVC_I3C_MERRWARN_NACK, master->regs + SVC_I3C_MERRWARN);
+			} else {
+				ret = -ENXIO;
+				*actual_len = 0;
+				goto emit_stop;
+			}
+		} else {
+			break;
+		}
 	}
 
 	/*
-- 
2.34.1


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

Re: (subset) [PATCH v2 2/2] i3c: master: svc: resend target address when get NACK

[Alexandre Belloni]

On Mon, 03 Jun 2024 11:15:27 -0400, Frank Li wrote:
> According to I3C Spec 1.1.1, 11-Jun-2021, section: 5.1.2.2.3:
> 
> If the Controller chooses to start an I3C Message with an I3C Dynamic
> Address, then special provisions shall be made because that same I3C Target
> may be initiating an IBI or a Controller Role Request. So, one of three
> things may happen: (skip 1, 2)
> 
> [...]

Applied, thanks!

[2/2] i3c: master: svc: resend target address when get NACK
      https://git.kernel.org/abelloni/c/2d15862dfba6

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: (subset) [PATCH v2 2/2] i3c: master: svc: resend target address when get NACK

[Alexandre Belloni]

On Mon, 03 Jun 2024 11:15:27 -0400, Frank Li wrote:
> According to I3C Spec 1.1.1, 11-Jun-2021, section: 5.1.2.2.3:
> 
> If the Controller chooses to start an I3C Message with an I3C Dynamic
> Address, then special provisions shall be made because that same I3C Target
> may be initiating an IBI or a Controller Role Request. So, one of three
> things may happen: (skip 1, 2)
> 
> [...]

Applied, thanks!

[2/2] i3c: master: svc: resend target address when get NACK
      https://git.kernel.org/abelloni/c/2d15862dfba6

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

Re: [PATCH v2 1/2] i3c: master: svc: fix IBIWON not set if IBI follow a hot join

[Miquel Raynal]

Hi Frank,

Frank.Li@nxp.com wrote on Mon,  3 Jun 2024 11:15:26 -0400:

> When an In-Band Interrupt(IBI) occurs after svc_i3c_master_do_daa_locked(),
> typically triggered during a Hot Join (HJ) event, the IBIWON flag fails to
> be set when issuing an auto IBI command.
> 
> The issue stems from the omission of emitting STOP upon successful
> execution of svc_i3c_master_do_daa_locked(). Consequently, the controller
> interprets it as a repeat start when emitting the auto IBI command. Per the
> I3C specification, an IBI should never occur during a repeat start, thus
> preventing the IBIWON flag from being set.
> 
> Emit STOP regardless of the success or failure of
> svc_i3c_master_do_daa_locked() to match I3C spec requirement.
> 
> Cc: <stable@vger.kernel.org>
> Fixes: 05b26c31a485 ("i3c: master: svc: add hot join support")
> Signed-off-by: Frank Li <Frank.Li@nxp.com>

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thanks,
Miquèl

Re: [PATCH v2 1/2] i3c: master: svc: fix IBIWON not set if IBI follow a hot join

[Miquel Raynal]

Hi Frank,

Frank.Li@nxp.com wrote on Mon,  3 Jun 2024 11:15:26 -0400:

> When an In-Band Interrupt(IBI) occurs after svc_i3c_master_do_daa_locked(),
> typically triggered during a Hot Join (HJ) event, the IBIWON flag fails to
> be set when issuing an auto IBI command.
> 
> The issue stems from the omission of emitting STOP upon successful
> execution of svc_i3c_master_do_daa_locked(). Consequently, the controller
> interprets it as a repeat start when emitting the auto IBI command. Per the
> I3C specification, an IBI should never occur during a repeat start, thus
> preventing the IBIWON flag from being set.
> 
> Emit STOP regardless of the success or failure of
> svc_i3c_master_do_daa_locked() to match I3C spec requirement.
> 
> Cc: <stable@vger.kernel.org>
> Fixes: 05b26c31a485 ("i3c: master: svc: add hot join support")
> Signed-off-by: Frank Li <Frank.Li@nxp.com>

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thanks,
Miquèl

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

Re: [PATCH v2 1/2] i3c: master: svc: fix IBIWON not set if IBI follow a hot join

[Frank Li]

On Mon, Jun 03, 2024 at 05:19:19PM +0200, Miquel Raynal wrote:
> Hi Frank,
> 
> Frank.Li@nxp.com wrote on Mon,  3 Jun 2024 11:15:26 -0400:
> 
> > When an In-Band Interrupt(IBI) occurs after svc_i3c_master_do_daa_locked(),
> > typically triggered during a Hot Join (HJ) event, the IBIWON flag fails to
> > be set when issuing an auto IBI command.
> > 
> > The issue stems from the omission of emitting STOP upon successful
> > execution of svc_i3c_master_do_daa_locked(). Consequently, the controller
> > interprets it as a repeat start when emitting the auto IBI command. Per the
> > I3C specification, an IBI should never occur during a repeat start, thus
> > preventing the IBIWON flag from being set.
> > 
> > Emit STOP regardless of the success or failure of
> > svc_i3c_master_do_daa_locked() to match I3C spec requirement.
> > 
> > Cc: <stable@vger.kernel.org>
> > Fixes: 05b26c31a485 ("i3c: master: svc: add hot join support")
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> 
> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

Please hold on this patch. Hardware can emit stop automatically. It need
better fix.  Let me work on new version for this one.

> 
> Thanks,
> Miquèl

Re: [PATCH v2 1/2] i3c: master: svc: fix IBIWON not set if IBI follow a hot join

[Frank Li]

On Mon, Jun 03, 2024 at 05:19:19PM +0200, Miquel Raynal wrote:
> Hi Frank,
> 
> Frank.Li@nxp.com wrote on Mon,  3 Jun 2024 11:15:26 -0400:
> 
> > When an In-Band Interrupt(IBI) occurs after svc_i3c_master_do_daa_locked(),
> > typically triggered during a Hot Join (HJ) event, the IBIWON flag fails to
> > be set when issuing an auto IBI command.
> > 
> > The issue stems from the omission of emitting STOP upon successful
> > execution of svc_i3c_master_do_daa_locked(). Consequently, the controller
> > interprets it as a repeat start when emitting the auto IBI command. Per the
> > I3C specification, an IBI should never occur during a repeat start, thus
> > preventing the IBIWON flag from being set.
> > 
> > Emit STOP regardless of the success or failure of
> > svc_i3c_master_do_daa_locked() to match I3C spec requirement.
> > 
> > Cc: <stable@vger.kernel.org>
> > Fixes: 05b26c31a485 ("i3c: master: svc: add hot join support")
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> 
> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

Please hold on this patch. Hardware can emit stop automatically. It need
better fix.  Let me work on new version for this one.

> 
> Thanks,
> Miquèl

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c