[linux-yocto][linux-yocto v6.1/standard/nxp-sdk-6.1/nxp-soc & v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc][PATCH 2/2] serial: imx: work-around for hardware RX flood

2023-11-28 Thread Xiaolei Wang via lists.yoctoproject.org
From: Sergey Organov 

commit 496a4471b7c3ae5c0be1a3fccd69e7debc127e08 from upstream.

Check if hardware Rx flood is in progress, and issue soft reset to UART to
stop the flood.

A way to reproduce the flood (checked on iMX6SX) is: open iMX UART at 9600
8N1, and from external source send 0xf0 char at 115200 8N1. In about 90% of
cases this starts a flood of "receiving" of 0xff characters by the iMX UART
that is terminated by any activity on RxD line, or could be stopped by
issuing soft reset to the UART (just stop/start of RX does not help). Note
that in essence what we did here is sending isolated start bit about 2.4
times shorter than it is to be if issued on the UART configured baud rate.

There was earlier attempt to fix similar issue in: 'commit
b38cb7d25711 ("serial: imx: Disable new features of autobaud detection")',
but apparently it only gets harder to reproduce the issue after that
commit.

Signed-off-by: Sergey Organov 
Link: https://lore.kernel.org/r/20230201142700.4346-3-sorga...@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Xiaolei Wang 
---
 drivers/tty/serial/imx.c | 123 ++-
 1 file changed, 95 insertions(+), 28 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 3d909dbc7e3e..d58724e71983 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -213,6 +213,9 @@ struct imx_port {
 
struct mctrl_gpios *gpios;
 
+   /* counter to stop 0xff flood */
+   int idle_counter;
+
/* shadow registers */
unsigned int ucr1;
unsigned int ucr2;
@@ -443,6 +446,8 @@ static void imx_uart_soft_reset(struct imx_port *sport)
imx_uart_writel(sport, ubir, UBIR);
imx_uart_writel(sport, ubmr, UBMR);
imx_uart_writel(sport, uts, IMX21_UTS);
+
+   sport->idle_counter = 0;
 }
 
 /* called with port.lock taken and irqs off */
@@ -853,15 +858,66 @@ static irqreturn_t imx_uart_txint(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+/* Check if hardware Rx flood is in progress, and issue soft reset to stop it.
+ * This is to be called from Rx ISRs only when some bytes were actually
+ * received.
+ *
+ * A way to reproduce the flood (checked on iMX6SX) is: open iMX UART at 9600
+ * 8N1, and from external source send 0xf0 char at 115200 8N1. In about 90% of
+ * cases this starts a flood of "receiving" of 0xff characters by the iMX6 UART
+ * that is terminated by any activity on RxD line, or could be stopped by
+ * issuing soft reset to the UART (just stop/start of RX does not help). Note
+ * that what we do here is sending isolated start bit about 2.4 times shorter
+ * than it is to be on UART configured baud rate.
+ */
+static void imx_uart_check_flood(struct imx_port *sport, u32 usr2)
+{
+   /* To detect hardware 0xff flood we monitor RxD line between RX
+* interrupts to isolate "receiving" of char(s) with no activity
+* on RxD line, that'd never happen on actual data transfers.
+*
+* We use USR2_WAKE bit to check for activity on RxD line, but we have a
+* race here if we clear USR2_WAKE when receiving of a char is in
+* progress, so we might get RX interrupt later with USR2_WAKE bit
+* cleared. Note though that as we don't try to clear USR2_WAKE when we
+* detected no activity, this race may hide actual activity only once.
+*
+* Yet another case where receive interrupt may occur without RxD
+* activity is expiration of aging timer, so we consider this as well.
+*
+* We use 'idle_counter' to ensure that we got at least so many RX
+* interrupts without any detected activity on RxD line. 2 cases
+* described plus 1 to be on the safe side gives us a margin of 3,
+* below. In practice I was not able to produce a false positive to
+* induce soft reset at regular data transfers even using 1 as the
+* margin, so 3 is actually very strong.
+*
+* We count interrupts, not chars in 'idle-counter' for simplicity.
+*/
+
+   if (usr2 & USR2_WAKE) {
+   imx_uart_writel(sport, USR2_WAKE, USR2);
+   sport->idle_counter = 0;
+   } else if (++sport->idle_counter > 3) {
+   dev_warn(sport->port.dev, "RX flood detected: soft reset.");
+   imx_uart_soft_reset(sport); /* also clears 
'sport->idle_counter' */
+   }
+}
+
 static irqreturn_t __imx_uart_rxint(int irq, void *dev_id)
 {
struct imx_port *sport = dev_id;
unsigned int rx, flg, ignored = 0;
struct tty_port *port = >port.state->port;
+   u32 usr2;
+
+   usr2 = imx_uart_readl(sport, USR2);
 
-   while (imx_uart_readl(sport, USR2) & USR2_RDR) {
-   u32 usr2;
+   /* If we received something, check for 0xff flood */
+   if (usr2 & USR2_RDR)
+   imx_uart_check_flood(sport, usr2);
 
+   for ( ; usr2 & USR2_RDR; usr2 = 

[linux-yocto][linux-yocto v6.1/standard/nxp-sdk-6.1/nxp-soc & v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc][PATCH 1/2] serial: imx: factor-out common code to imx_uart_soft_reset()

2023-11-28 Thread Xiaolei Wang via lists.yoctoproject.org
From: Sergey Organov 

commit d45fb2e430e54fac6af3cabb39c36171c4bf3f52 from upstream.

We perform soft reset in 2 places, slightly differently for no sufficient
reasons, so move more generic variant to a function, and re-use the code.

Out of 2 repeat counters, 10 and 100, select 10, as the code works at
interrupts disabled, and in practice the reset happens immediately.

Signed-off-by: Sergey Organov 
Link: https://lore.kernel.org/r/20230201142700.4346-2-sorga...@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Xiaolei Wang 
---
 drivers/tty/serial/imx.c | 73 
 1 file changed, 37 insertions(+), 36 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 3054be617266..3d909dbc7e3e 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -412,6 +412,39 @@ static void imx_uart_disable_loopback_rs485(struct 
imx_port *sport)
imx_uart_writel(sport, uts, imx_uart_uts_reg(sport));
 }
 
+/* called with port.lock taken and irqs off */
+static void imx_uart_soft_reset(struct imx_port *sport)
+{
+   int i = 10;
+   u32 ucr2, ubir, ubmr, uts;
+
+   /*
+* According to the Reference Manual description of the UART SRST bit:
+*
+* "Reset the transmit and receive state machines,
+* all FIFOs and register USR1, USR2, UBIR, UBMR, UBRC, URXD, UTXD
+* and UTS[6-3]".
+*
+* We don't need to restore the old values from USR1, USR2, URXD and
+* UTXD. UBRC is read only, so only save/restore the other three
+* registers.
+*/
+   ubir = imx_uart_readl(sport, UBIR);
+   ubmr = imx_uart_readl(sport, UBMR);
+   uts = imx_uart_readl(sport, IMX21_UTS);
+
+   ucr2 = imx_uart_readl(sport, UCR2);
+   imx_uart_writel(sport, ucr2 & ~UCR2_SRST, UCR2);
+
+   while (!(imx_uart_readl(sport, UCR2) & UCR2_SRST) && (--i > 0))
+   udelay(1);
+
+   /* Restore the registers */
+   imx_uart_writel(sport, ubir, UBIR);
+   imx_uart_writel(sport, ubmr, UBMR);
+   imx_uart_writel(sport, uts, IMX21_UTS);
+}
+
 /* called with port.lock taken and irqs off */
 static void imx_uart_start_rx(struct uart_port *port)
 {
@@ -1425,7 +1458,7 @@ static int imx_uart_startup(struct uart_port *port)
 {
struct imx_port *sport = (struct imx_port *)port;
struct tty_port *tty_port = >port.state->port;
-   int retval, i;
+   int retval;
unsigned long flags;
int dma_is_inited = 0;
u32 ucr1, ucr2, ucr3, ucr4;
@@ -1464,15 +1497,9 @@ static int imx_uart_startup(struct uart_port *port)
dma_is_inited = 1;
 
spin_lock_irqsave(>port.lock, flags);
-   /* Reset fifo's and state machines */
-   i = 100;
 
-   ucr2 = imx_uart_readl(sport, UCR2);
-   ucr2 &= ~UCR2_SRST;
-   imx_uart_writel(sport, ucr2, UCR2);
-
-   while (!(imx_uart_readl(sport, UCR2) & UCR2_SRST) && (--i > 0))
-   udelay(1);
+   /* Reset fifo's and state machines */
+   imx_uart_soft_reset(sport);
 
/*
 * Finally, clear and enable interrupts
@@ -1626,8 +1653,6 @@ static void imx_uart_flush_buffer(struct uart_port *port)
 {
struct imx_port *sport = (struct imx_port *)port;
struct scatterlist *sgl = >tx_sgl[0];
-   u32 ucr2;
-   int i = 100, ubir, ubmr, uts;
 
if (!sport->dma_chan_tx)
return;
@@ -1645,32 +1670,8 @@ static void imx_uart_flush_buffer(struct uart_port *port)
sport->dma_is_txing = 0;
}
 
-   /*
-* According to the Reference Manual description of the UART SRST bit:
-*
-* "Reset the transmit and receive state machines,
-* all FIFOs and register USR1, USR2, UBIR, UBMR, UBRC, URXD, UTXD
-* and UTS[6-3]".
-*
-* We don't need to restore the old values from USR1, USR2, URXD and
-* UTXD. UBRC is read only, so only save/restore the other three
-* registers.
-*/
-   ubir = imx_uart_readl(sport, UBIR);
-   ubmr = imx_uart_readl(sport, UBMR);
-   uts = imx_uart_readl(sport, IMX21_UTS);
-
-   ucr2 = imx_uart_readl(sport, UCR2);
-   ucr2 &= ~UCR2_SRST;
-   imx_uart_writel(sport, ucr2, UCR2);
+   imx_uart_soft_reset(sport);
 
-   while (!(imx_uart_readl(sport, UCR2) & UCR2_SRST) && (--i > 0))
-   udelay(1);
-
-   /* Restore the registers */
-   imx_uart_writel(sport, ubir, UBIR);
-   imx_uart_writel(sport, ubmr, UBMR);
-   imx_uart_writel(sport, uts, IMX21_UTS);
 }
 
 static void
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13322): 
https://lists.yoctoproject.org/g/linux-yocto/message/13322
Mute This Topic: https://lists.yoctoproject.org/mt/102866842/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 

[linux-yocto][linux-yocto v5.15/standard/nxp-sdk-5.15/nxp-soc & v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc][PATCH 2/2] serial: imx: work-around for hardware RX flood

2023-11-28 Thread Xiaolei Wang via lists.yoctoproject.org
From: Sergey Organov 

commit 496a4471b7c3ae5c0be1a3fccd69e7debc127e08 from upstream.

Check if hardware Rx flood is in progress, and issue soft reset to UART to
stop the flood.

A way to reproduce the flood (checked on iMX6SX) is: open iMX UART at 9600
8N1, and from external source send 0xf0 char at 115200 8N1. In about 90% of
cases this starts a flood of "receiving" of 0xff characters by the iMX UART
that is terminated by any activity on RxD line, or could be stopped by
issuing soft reset to the UART (just stop/start of RX does not help). Note
that in essence what we did here is sending isolated start bit about 2.4
times shorter than it is to be if issued on the UART configured baud rate.

There was earlier attempt to fix similar issue in: 'commit
b38cb7d25711 ("serial: imx: Disable new features of autobaud detection")',
but apparently it only gets harder to reproduce the issue after that
commit.

Signed-off-by: Sergey Organov 
Link: https://lore.kernel.org/r/20230201142700.4346-3-sorga...@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Xiaolei Wang 
---
 drivers/tty/serial/imx.c | 123 ++-
 1 file changed, 95 insertions(+), 28 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 8b32d8e549dc..001f88b15752 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -214,6 +214,9 @@ struct imx_port {
 
struct mctrl_gpios *gpios;
 
+   /* counter to stop 0xff flood */
+   int idle_counter;
+
/* shadow registers */
unsigned int ucr1;
unsigned int ucr2;
@@ -444,6 +447,8 @@ static void imx_uart_soft_reset(struct imx_port *sport)
imx_uart_writel(sport, ubir, UBIR);
imx_uart_writel(sport, ubmr, UBMR);
imx_uart_writel(sport, uts, IMX21_UTS);
+
+   sport->idle_counter = 0;
 }
 
 /* called with port.lock taken and irqs off */
@@ -844,15 +849,66 @@ static irqreturn_t imx_uart_txint(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+/* Check if hardware Rx flood is in progress, and issue soft reset to stop it.
+ * This is to be called from Rx ISRs only when some bytes were actually
+ * received.
+ *
+ * A way to reproduce the flood (checked on iMX6SX) is: open iMX UART at 9600
+ * 8N1, and from external source send 0xf0 char at 115200 8N1. In about 90% of
+ * cases this starts a flood of "receiving" of 0xff characters by the iMX6 UART
+ * that is terminated by any activity on RxD line, or could be stopped by
+ * issuing soft reset to the UART (just stop/start of RX does not help). Note
+ * that what we do here is sending isolated start bit about 2.4 times shorter
+ * than it is to be on UART configured baud rate.
+ */
+static void imx_uart_check_flood(struct imx_port *sport, u32 usr2)
+{
+   /* To detect hardware 0xff flood we monitor RxD line between RX
+* interrupts to isolate "receiving" of char(s) with no activity
+* on RxD line, that'd never happen on actual data transfers.
+*
+* We use USR2_WAKE bit to check for activity on RxD line, but we have a
+* race here if we clear USR2_WAKE when receiving of a char is in
+* progress, so we might get RX interrupt later with USR2_WAKE bit
+* cleared. Note though that as we don't try to clear USR2_WAKE when we
+* detected no activity, this race may hide actual activity only once.
+*
+* Yet another case where receive interrupt may occur without RxD
+* activity is expiration of aging timer, so we consider this as well.
+*
+* We use 'idle_counter' to ensure that we got at least so many RX
+* interrupts without any detected activity on RxD line. 2 cases
+* described plus 1 to be on the safe side gives us a margin of 3,
+* below. In practice I was not able to produce a false positive to
+* induce soft reset at regular data transfers even using 1 as the
+* margin, so 3 is actually very strong.
+*
+* We count interrupts, not chars in 'idle-counter' for simplicity.
+*/
+
+   if (usr2 & USR2_WAKE) {
+   imx_uart_writel(sport, USR2_WAKE, USR2);
+   sport->idle_counter = 0;
+   } else if (++sport->idle_counter > 3) {
+   dev_warn(sport->port.dev, "RX flood detected: soft reset.");
+   imx_uart_soft_reset(sport); /* also clears 
'sport->idle_counter' */
+   }
+}
+
 static irqreturn_t __imx_uart_rxint(int irq, void *dev_id)
 {
struct imx_port *sport = dev_id;
unsigned int rx, flg, ignored = 0;
struct tty_port *port = >port.state->port;
+   u32 usr2;
+
+   usr2 = imx_uart_readl(sport, USR2);
 
-   while (imx_uart_readl(sport, USR2) & USR2_RDR) {
-   u32 usr2;
+   /* If we received something, check for 0xff flood */
+   if (usr2 & USR2_RDR)
+   imx_uart_check_flood(sport, usr2);
 
+   for ( ; usr2 & USR2_RDR; usr2 = 

[linux-yocto][linux-yocto v5.15/standard/nxp-sdk-5.15/nxp-soc & v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc][PATCH 1/2] serial: imx: factor-out common code to imx_uart_soft_reset()

2023-11-28 Thread Xiaolei Wang via lists.yoctoproject.org
From: Sergey Organov 

commit d45fb2e430e54fac6af3cabb39c36171c4bf3f52 from upstream.

We perform soft reset in 2 places, slightly differently for no sufficient
reasons, so move more generic variant to a function, and re-use the code.

Out of 2 repeat counters, 10 and 100, select 10, as the code works at
interrupts disabled, and in practice the reset happens immediately.

Signed-off-by: Sergey Organov 
Link: https://lore.kernel.org/r/20230201142700.4346-2-sorga...@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Xiaolei Wang 
---
 drivers/tty/serial/imx.c | 73 
 1 file changed, 37 insertions(+), 36 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 77a3649f80ba..8b32d8e549dc 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -413,6 +413,39 @@ static void imx_uart_disable_loopback_rs485(struct 
imx_port *sport)
imx_uart_writel(sport, uts, imx_uart_uts_reg(sport));
 }
 
+/* called with port.lock taken and irqs off */
+static void imx_uart_soft_reset(struct imx_port *sport)
+{
+   int i = 10;
+   u32 ucr2, ubir, ubmr, uts;
+
+   /*
+* According to the Reference Manual description of the UART SRST bit:
+*
+* "Reset the transmit and receive state machines,
+* all FIFOs and register USR1, USR2, UBIR, UBMR, UBRC, URXD, UTXD
+* and UTS[6-3]".
+*
+* We don't need to restore the old values from USR1, USR2, URXD and
+* UTXD. UBRC is read only, so only save/restore the other three
+* registers.
+*/
+   ubir = imx_uart_readl(sport, UBIR);
+   ubmr = imx_uart_readl(sport, UBMR);
+   uts = imx_uart_readl(sport, IMX21_UTS);
+
+   ucr2 = imx_uart_readl(sport, UCR2);
+   imx_uart_writel(sport, ucr2 & ~UCR2_SRST, UCR2);
+
+   while (!(imx_uart_readl(sport, UCR2) & UCR2_SRST) && (--i > 0))
+   udelay(1);
+
+   /* Restore the registers */
+   imx_uart_writel(sport, ubir, UBIR);
+   imx_uart_writel(sport, ubmr, UBMR);
+   imx_uart_writel(sport, uts, IMX21_UTS);
+}
+
 /* called with port.lock taken and irqs off */
 static void imx_uart_start_rx(struct uart_port *port)
 {
@@ -1420,7 +1453,7 @@ static int imx_uart_startup(struct uart_port *port)
 {
struct imx_port *sport = (struct imx_port *)port;
struct tty_port *tty_port = >port.state->port;
-   int retval, i;
+   int retval;
unsigned long flags;
int dma_is_inited = 0;
u32 ucr1, ucr2, ucr3, ucr4;
@@ -1459,15 +1492,9 @@ static int imx_uart_startup(struct uart_port *port)
dma_is_inited = 1;
 
spin_lock_irqsave(>port.lock, flags);
-   /* Reset fifo's and state machines */
-   i = 100;
 
-   ucr2 = imx_uart_readl(sport, UCR2);
-   ucr2 &= ~UCR2_SRST;
-   imx_uart_writel(sport, ucr2, UCR2);
-
-   while (!(imx_uart_readl(sport, UCR2) & UCR2_SRST) && (--i > 0))
-   udelay(1);
+   /* Reset fifo's and state machines */
+   imx_uart_soft_reset(sport);
 
/*
 * Finally, clear and enable interrupts
@@ -1620,8 +1647,6 @@ static void imx_uart_flush_buffer(struct uart_port *port)
 {
struct imx_port *sport = (struct imx_port *)port;
struct scatterlist *sgl = >tx_sgl[0];
-   u32 ucr2;
-   int i = 100, ubir, ubmr, uts;
 
if (!sport->dma_chan_tx)
return;
@@ -1639,32 +1664,8 @@ static void imx_uart_flush_buffer(struct uart_port *port)
sport->dma_is_txing = 0;
}
 
-   /*
-* According to the Reference Manual description of the UART SRST bit:
-*
-* "Reset the transmit and receive state machines,
-* all FIFOs and register USR1, USR2, UBIR, UBMR, UBRC, URXD, UTXD
-* and UTS[6-3]".
-*
-* We don't need to restore the old values from USR1, USR2, URXD and
-* UTXD. UBRC is read only, so only save/restore the other three
-* registers.
-*/
-   ubir = imx_uart_readl(sport, UBIR);
-   ubmr = imx_uart_readl(sport, UBMR);
-   uts = imx_uart_readl(sport, IMX21_UTS);
-
-   ucr2 = imx_uart_readl(sport, UCR2);
-   ucr2 &= ~UCR2_SRST;
-   imx_uart_writel(sport, ucr2, UCR2);
+   imx_uart_soft_reset(sport);
 
-   while (!(imx_uart_readl(sport, UCR2) & UCR2_SRST) && (--i > 0))
-   udelay(1);
-
-   /* Restore the registers */
-   imx_uart_writel(sport, ubir, UBIR);
-   imx_uart_writel(sport, ubmr, UBMR);
-   imx_uart_writel(sport, uts, IMX21_UTS);
 }
 
 static void
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13320): 
https://lists.yoctoproject.org/g/linux-yocto/message/13320
Mute This Topic: https://lists.yoctoproject.org/mt/102866412/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 

[yocto] Canceled: OpenEmbedded Happy Hour November 29

2023-11-28 Thread Denys Dmytriyenko
There will be no OE Happy Hour on November 29 due to the ongoing Yocto Project 
Summit[1] this week and the OpenEmbedded Developers Meeting[2] on Friday.

[1] https://summit.yoctoproject.org/yocto-project-summit-2023-11/
[2] https://www.openembedded.org/wiki/OEDvM_2023.12

Best regards,
Denys Dmytriyenko
OpenEmbedded Board of Directors

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61770): https://lists.yoctoproject.org/g/yocto/message/61770
Mute This Topic: https://lists.yoctoproject.org/mt/102861584/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto][v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g][PATCH] gpio: s32: make irq_chip immutable

2023-11-28 Thread Bruce Ashfield
FYI. I'll be a bit slow in merging these changes, I'm experiencing a
disk failure on my build machine, and I need to get it
fixed/replaced/another machine.

Bruce

On Tue, Nov 28, 2023 at 4:16 AM  wrote:
>
> From: Quanyang Wang 
>
> The kernel requires that the flag IRQCHIP_IMMUTABLE is set for irqchip
> structure in gpio driver, or else it complains with:
>
> gpio gpiochip0: (4009d700.siul2-gpio): not an immutable chip, please consider 
> fixing it!
>
> Signed-off-by: Quanyang Wang 
> ---
> Hi Bruce,
> Would you please help merge this patch to the branches:
> v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g
> v6.1/standard/nxp-sdk-5.15/nxp-s32g
> Thanks,
> Quanyang
> ---
>  drivers/gpio/gpio-siul2-s32cc.c | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpio/gpio-siul2-s32cc.c b/drivers/gpio/gpio-siul2-s32cc.c
> index 668eab91859f2..5db92ad73772d 100644
> --- a/drivers/gpio/gpio-siul2-s32cc.c
> +++ b/drivers/gpio/gpio-siul2-s32cc.c
> @@ -153,7 +153,6 @@ struct siul2_gpio_dev {
> struct regmap *irqmap;
> struct regmap *eirqimcrsmap;
> struct gpio_chip gc;
> -   struct irq_chip irq;
>
> /* Mutual access to SIUL2 registers. */
> raw_spinlock_t lock;
> @@ -473,6 +472,8 @@ static void siul2_gpio_irq_unmask(struct irq_data *data)
> return;
> }
>
> +   gpiochip_enable_irq(gc, gpio);
> +
> /* Disable interrupt */
> regmap_update_bits(gpio_dev->irqmap, SIUL2_DIRER0, mask, 0);
>
> @@ -526,6 +527,8 @@ static void siul2_gpio_irq_mask(struct irq_data *data)
> regmap_write(gpio_dev->eirqimcrsmap,
>  SIUL2_EIRQ_REG(platdata->irqs[index].eirq),
>  0);
> +
> +   gpiochip_disable_irq(gc, gpio);
>  }
>
>  static const struct regmap_config siul2_regmap_conf = {
> @@ -1101,6 +1104,16 @@ static int siul2_gpio_populate_names(struct device 
> *dev,
> return 0;
>  }
>
> +static const struct irq_chip siul2_irqchip = {
> +   .name   = "gpio-siul2",
> +   .irq_ack= siul2_gpio_irq_mask,
> +   .irq_mask   = siul2_gpio_irq_mask,
> +   .irq_unmask = siul2_gpio_irq_unmask,
> +   .irq_set_type   = siul2_gpio_irq_set_type,
> +   .flags = IRQCHIP_IMMUTABLE,
> +   GPIOCHIP_IRQ_RESOURCE_HELPERS,
> +};
> +
>  static int siul2_gpio_probe(struct platform_device *pdev)
>  {
> int err = 0;
> @@ -1173,14 +1186,6 @@ static int siul2_gpio_probe(struct platform_device 
> *pdev)
> sizeof(*gpio_dev->pin_dir_bitmap);
> gpio_dev->pin_dir_bitmap = devm_kzalloc(dev, bitmap_size,
> GFP_KERNEL);
> -   gpio_dev->irq = (struct irq_chip) {
> -   .name   = dev_name(dev),
> -   .irq_ack= siul2_gpio_irq_mask,
> -   .irq_mask   = siul2_gpio_irq_mask,
> -   .irq_unmask = siul2_gpio_irq_unmask,
> -   .irq_set_type   = siul2_gpio_irq_set_type,
> -   };
> -
> gc->parent = dev;
> gc->label = dev_name(dev);
>
> @@ -1195,7 +1200,7 @@ static int siul2_gpio_probe(struct platform_device 
> *pdev)
> gc->owner = THIS_MODULE;
>
> girq = >irq;
> -   girq->chip = _dev->irq;
> +   gpio_irq_chip_set_chip(girq, _irqchip);
> girq->parent_handler = NULL;
> girq->num_parents = 0;
> girq->parents = NULL;
> --
> 2.36.1
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13319): 
https://lists.yoctoproject.org/g/linux-yocto/message/13319
Mute This Topic: https://lists.yoctoproject.org/mt/102847614/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy
 [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [PATCH yocto-autobuilder-helper] config.json: Match the machine spec to task for rv32 qemu jobs

2023-11-28 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 config.json | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index e95a292..c4b31e3 100644
--- a/config.json
+++ b/config.json
@@ -589,7 +589,7 @@
 "TEMPLATE" : "ltp-qemu"
 },
 "qemuriscv32" : {
-"MACHINE" : "qemuriscv64",
+"MACHINE" : "qemuriscv32",
 "TEMPLATE" : "arch-qemu"
 },
 "qemuriscv64" : {
@@ -597,7 +597,7 @@
 "TEMPLATE" : "arch-qemu"
 },
 "qemuriscv32-tc" : {
-"MACHINE" : "qemuriscv64",
+"MACHINE" : "qemuriscv32",
 "TEMPLATE" : "toolchain-qemu"
 },
 "qemuriscv64-tc" : {
-- 
2.43.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61769): https://lists.yoctoproject.org/g/yocto/message/61769
Mute This Topic: https://lists.yoctoproject.org/mt/102856570/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Yocto Project Status 28 November 2023 (WW48)

2023-11-28 Thread Neal Caidin
Current Dev Position: YP 5.0 M1

Next Deadline: 4th December 2023 YP 5.0 M1 build

Next Team Meetings:

   -

   Meetings canceled this week for YP Summit.


Key Status/Updates:

   -

   YP 4.2.4  has passed QA and under discussion pending release
   -

   YP 4.3.1 is in QA
   -

   The BB_DEFAULT_EVENTLOG setting has exposed a bug where the bitbake
   server could hang due to thread deadlocking. A fix has been merged for it
   yesterday.
   -

   The length of builds (world and oe-selftest) continues to be a concern.
   -

   The intermittent issues on the autobuilder are causing problems for
   master branch development and stable releases and this is slowing down
   patch testing and merging. We simply don't have enough people to fix the
   issues quickly enough and the people we do have are struggling.
   -

   There are some worrying issues around trying to fix the useradd bugs,
   particularly around inter-sstate task dependencies. There is a discussion
   about this on the openembedded-architecture list for those interested.
   -

   The Yocto Project Summit is this week so the regular meetings are
   canceled so people can attend the summit:
   https://summit.yoctoproject.org/yocto-project-summit-2023-11/ .


Ways to contribute:

   -

   As people are likely aware, the project has a number of components which
   are either unmaintained, or have people with little to no time trying to
   keep them alive. These components include: devtool, toaster, wic, oeqa,
   autobuilder, CROPs containers, pseudo and more. Many have open bugs. Help
   is welcome in trying to better look after these components!
   -

   There are bugs identified as possible for newcomers to the project:
   https://wiki.yoctoproject.org/wiki/Newcomers
   -

   There are bugs that are currently unassigned for YP 4.3. See:
   
https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.3_Unassigned_Enhancements.2FBugs
   -

   We’d welcome new maintainers for recipes in OE-Core. Please see the list
   at:
   
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc
   and discuss with the existing maintainer, or ask on the OE-Core mailing
   list. We will likely move a chunk of these to “Unassigned” soon to help
   facilitate this.
   -

   Help is very much welcome in trying to resolve our autobuilder
   intermittent issues. You can see the list of failures we’re continuing to
   see by searching for the “AB-INT” tag in bugzilla:
   https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
   -

   Help us resolve CVE issues: CVE metrics
   
   -

   We have a growing number of bugs in bugzilla, any help with them is
   appreciated.


YP 5.0 Milestone Dates:

   -

   YP 5.0 M1 build date 2023/12/04
   -

   YP 5.0 M1 Release date 2023/12/15
   -

   YP 5.0 M2 build date  2024/01/15
   -

   YP 5.0 M2 Release date 2024/01/24
   -

   YP 5.0 M3 build date  2024/02/19
   -

   YP 5.0 M3 Release date 2024/03/01
   -

   YP 5.0 M4 build date  2024/04/01
   -

   YP 5.0 M4 Release date 2024/04/30


Upcoming dot releases:

   -

   YP 3.1.29 build date 2023/10/30
   -

   YP 3.1.29 Release date 2023/11/10
   -

   YP 4.0.14 build date 2023/11/06
   -

   YP 4.0.14 Release date 2023/11/17
   -

   YP 4.2.4 build date 2023/11/13
   -

   YP 4.2.4 Release date 2023/11/24
   -

   YP 4.3.1 build date 2023/11/27
   -

   YP 4.3.1 Release date 2023/12/08
   -

   YP 3.1.30 build date 2023/12/11
   -

   YP 3.1.30 Release date 2023/12/22
   -

   YP 4.0.15 build date 2023/12/18
   -

   YP 4.0.15 Release date 2023/12/29
   -

   YP 4.3.2 build date 2024/01/08
   -

   YP 4.3.2 Release date 2024/01/19
   -

   YP 3.1.31 build date 2024/01/22
   -

   YP 3.1.31 Release date 2024/02/02
   -

   YP 4.0.16 build date 2024/01/29
   -

   YP 4.0.16 Release date 2024/02/09
   -

   YP 4.3.3 build date 2024/02/12
   -

   YP 4.3.3 Release date 2024/02/23
   -

   YP 3.1.32 build date 2024/03/04
   -

   YP 3.1.32 Release date 2024/03/15
   -

   YP 4.0.17 build date 2024/03/11
   -

   YP 4.0.17 Release date 2024/03/22
   -

   YP 4.3.4 build date 2024/03/25
   -

   YP 4.3.4 Release date 2024/04/05
   -

   YP 3.1.33 build date 2024/04/15
   -

   YP 3.1.33 Release date 2024/04/26
   -

   YP 4.0.18 build date 2024/04/22
   -

   YP 4.0.18 Release date 2024/05/03
   -

   YP 4.0.19 build date 2024/06/03
   -

   YP 4.0.19 Release date 2024/06/14


Tracking Metrics:

   -

   WDD 2547 (last week 2517) (
   https://wiki.yoctoproject.org/charts/combo.html)
   -

   OE-Core/Poky Patch Metrics
   -

  Total patches found: 1178 (last week 1177)
  -

  Patches in the Pending State: 253 (21%) [last week 253 (21%)]
  -

   https://autobuilder.yocto.io/pub/non-release/patchmetrics/


The Yocto Project’s technical governance is through its Technical Steering
Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

The 

Re: [yocto] TI AM62x based EV charger platform with Pionix UI s/w Image build problem. #apt #bitbake #distro #poky

2023-11-28 Thread Zoran
Hello Sairaj,

You should do df command and explore how much of your /home or /
partitions (have no idea how the system was installed) is left.

Maybe you have a problem with the limited free space on your SSD/HDD?

You should have at least 60GB or even more disk space available to do
one successful YOCTO build.

Two cent worth answer,
Zee
___


On Tue, Nov 28, 2023 at 7:00 AM  wrote:
>
> Hi team,
>
>
>
> we are trying to build TI AM62x EVSE SDK referring to 
> https://github.com/PionixPublic/ti-am62x-evse-sdk  we have tried building in 
> virtual machine and now we are trying to build in Linux  host pc with 500gb 
> of storage and 16gb ram but still bitbake runs till 99 percentage   and last 
> module Nodejs takes forever to run system experiences a freeze. Tried 
> multiple times running the bitbake but still problem remains same .
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61767): https://lists.yoctoproject.org/g/yocto/message/61767
Mute This Topic: https://lists.yoctoproject.org/mt/102846254/21656
Mute #distro:https://lists.yoctoproject.org/g/yocto/mutehashtag/distro
Mute #poky:https://lists.yoctoproject.org/g/yocto/mutehashtag/poky
Mute #apt:https://lists.yoctoproject.org/g/yocto/mutehashtag/apt
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto][v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g][PATCH] gpio: s32: make irq_chip immutable

2023-11-28 Thread quanyang.wang via lists.yoctoproject.org
From: Quanyang Wang 

The kernel requires that the flag IRQCHIP_IMMUTABLE is set for irqchip
structure in gpio driver, or else it complains with:

gpio gpiochip0: (4009d700.siul2-gpio): not an immutable chip, please consider 
fixing it!

Signed-off-by: Quanyang Wang 
---
Hi Bruce,
Would you please help merge this patch to the branches:
v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g
v6.1/standard/nxp-sdk-5.15/nxp-s32g
Thanks,
Quanyang
---
 drivers/gpio/gpio-siul2-s32cc.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-siul2-s32cc.c b/drivers/gpio/gpio-siul2-s32cc.c
index 668eab91859f2..5db92ad73772d 100644
--- a/drivers/gpio/gpio-siul2-s32cc.c
+++ b/drivers/gpio/gpio-siul2-s32cc.c
@@ -153,7 +153,6 @@ struct siul2_gpio_dev {
struct regmap *irqmap;
struct regmap *eirqimcrsmap;
struct gpio_chip gc;
-   struct irq_chip irq;
 
/* Mutual access to SIUL2 registers. */
raw_spinlock_t lock;
@@ -473,6 +472,8 @@ static void siul2_gpio_irq_unmask(struct irq_data *data)
return;
}
 
+   gpiochip_enable_irq(gc, gpio);
+
/* Disable interrupt */
regmap_update_bits(gpio_dev->irqmap, SIUL2_DIRER0, mask, 0);
 
@@ -526,6 +527,8 @@ static void siul2_gpio_irq_mask(struct irq_data *data)
regmap_write(gpio_dev->eirqimcrsmap,
 SIUL2_EIRQ_REG(platdata->irqs[index].eirq),
 0);
+
+   gpiochip_disable_irq(gc, gpio);
 }
 
 static const struct regmap_config siul2_regmap_conf = {
@@ -1101,6 +1104,16 @@ static int siul2_gpio_populate_names(struct device *dev,
return 0;
 }
 
+static const struct irq_chip siul2_irqchip = {
+   .name   = "gpio-siul2",
+   .irq_ack= siul2_gpio_irq_mask,
+   .irq_mask   = siul2_gpio_irq_mask,
+   .irq_unmask = siul2_gpio_irq_unmask,
+   .irq_set_type   = siul2_gpio_irq_set_type,
+   .flags = IRQCHIP_IMMUTABLE,
+   GPIOCHIP_IRQ_RESOURCE_HELPERS,
+};
+
 static int siul2_gpio_probe(struct platform_device *pdev)
 {
int err = 0;
@@ -1173,14 +1186,6 @@ static int siul2_gpio_probe(struct platform_device *pdev)
sizeof(*gpio_dev->pin_dir_bitmap);
gpio_dev->pin_dir_bitmap = devm_kzalloc(dev, bitmap_size,
GFP_KERNEL);
-   gpio_dev->irq = (struct irq_chip) {
-   .name   = dev_name(dev),
-   .irq_ack= siul2_gpio_irq_mask,
-   .irq_mask   = siul2_gpio_irq_mask,
-   .irq_unmask = siul2_gpio_irq_unmask,
-   .irq_set_type   = siul2_gpio_irq_set_type,
-   };
-
gc->parent = dev;
gc->label = dev_name(dev);
 
@@ -1195,7 +1200,7 @@ static int siul2_gpio_probe(struct platform_device *pdev)
gc->owner = THIS_MODULE;
 
girq = >irq;
-   girq->chip = _dev->irq;
+   gpio_irq_chip_set_chip(girq, _irqchip);
girq->parent_handler = NULL;
girq->num_parents = 0;
girq->parents = NULL;
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13318): 
https://lists.yoctoproject.org/g/linux-yocto/message/13318
Mute This Topic: https://lists.yoctoproject.org/mt/102847614/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] [yocto-kernel-cache][yocto-6.1][PATCH] aptiv-s32g: add aptiv-cvc-131 machine support

2023-11-28 Thread quanyang.wang via lists.yoctoproject.org
From: Quanyang Wang 

Add the new machine aptiv-cvc-131 support.

Signed-off-by: Quanyang Wang 
---
Hi Bruce,
Would you please help merge this patch to the branch:
yocto-6.1
Thanks,
Quanyang
---
 bsp/aptiv-s32g/aptiv-cvc-fl-preempt-rt.scc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsp/aptiv-s32g/aptiv-cvc-fl-preempt-rt.scc 
b/bsp/aptiv-s32g/aptiv-cvc-fl-preempt-rt.scc
index d8a0c51af0..9dfbe1a498 100644
--- a/bsp/aptiv-s32g/aptiv-cvc-fl-preempt-rt.scc
+++ b/bsp/aptiv-s32g/aptiv-cvc-fl-preempt-rt.scc
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: MIT
 define KMACHINE aptiv-cvc-fl
+define KMACHINE aptiv-cvc-131
 define KTYPE preempt-rt
 define KARCH arm64
 
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13317): 
https://lists.yoctoproject.org/g/linux-yocto/message/13317
Mute This Topic: https://lists.yoctoproject.org/mt/102847516/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-