Skip to contentSkip to conversation

serial: omap: fix compile breakage

PATCH Superseded Felipe Balbi 3 participants 8 messages Sep 7, 2012

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 serial: omap: fix compile breakage

when rebasing patches on top of Greg's tty-next, it looks like automerge broke a few things which I didn't catch (for whatever reason I didn't have OMAP Serial enabled on .config) so I ended up breaking the build on Greg's tty-next branch.

Fix the breakage by re-adding the three missing members on struct uart_omap_port.

---
 drivers/tty/serial/omap-serial.c | 4 ++++
 1 file changed, 4 insertions(+)
drivers/tty/serial/omap-serial.c +4 -0
index e31d291..8e4a7aa 100644
@@ -123,6 +123,10 @@ struct uart_omap_port {
 	u8			wakeups_enabled;
 	unsigned int		irq_pending:1;
 
+	int			DTR_gpio;
+	int			DTR_inverted;
+	int			DTR_active;
+
 	struct pm_qos_request	pm_qos_request;
 	u32			latency;
 	u32			calc_latency;
Signature · 1 line
1.7.12.rc3
#1 lore raw

PATCH v2 1/1 serial: omap: fix compile breakage

when rebasing patches on top of Greg's tty-next, it looks like automerge broke a few things which I didn't catch (for whatever reason I didn't have OMAP Serial enabled on .config) so I ended up breaking the build on Greg's tty-next branch.

Fix the breakage by re-adding the three missing members on struct uart_omap_port.

---

Changes since v1:
. remove the fields from <plat/omap-serial.h>

 arch/arm/plat-omap/include/plat/omap-serial.h | 4 ----
 drivers/tty/serial/omap-serial.c              | 4 ++++
 2 files changed, 4 insertions(+), 4 deletions(-)
arch/arm/plat-omap/include/plat/omap-serial.h +0 -4
index 57ff78c..74caddc 100644
@@ -79,8 +79,4 @@ struct omap_uart_port_info {
 	void (*enable_wakeup)(struct device *, bool);
 };
 
-
-	int			DTR_gpio;
-	int			DTR_inverted;
-	int			DTR_active;
 #endif /* __OMAP_SERIAL_H__ */
drivers/tty/serial/omap-serial.c +4 -0
index e31d291..8e4a7aa 100644
@@ -123,6 +123,10 @@ struct uart_omap_port {
 	u8			wakeups_enabled;
 	unsigned int		irq_pending:1;
 
+	int			DTR_gpio;
+	int			DTR_inverted;
+	int			DTR_active;
+
 	struct pm_qos_request	pm_qos_request;
 	u32			latency;
 	u32			calc_latency;
Signature · 1 line
1.7.12.rc3
maintainer
#2 lore raw

PATCH v2 1/1 serial: omap: fix compile breakage

Quoted 11 lines · Felipe Balbi

when rebasing patches on top of Greg's tty-next, it looks like automerge broke a few things which I didn't catch (for whatever reason I didn't have OMAP Serial enabled on .config) so I ended up breaking the build on Greg's tty-next branch.

Fix the breakage by re-adding the three missing members on struct uart_omap_port.

Quoted 8 lines

---

Changes since v1:
. remove the fields from <plat/omap-serial.h>

 arch/arm/plat-omap/include/plat/omap-serial.h | 4 ----
 drivers/tty/serial/omap-serial.c              | 4 ++++
 2 files changed, 4 insertions(+), 4 deletions(-)

This applies with fuzz, what tree did you make it against?

patching file arch/arm/plat-omap/include/plat/omap-serial.h Hunk #1 succeeded at 105 with fuzz 1 (offset 26 lines). patching file drivers/tty/serial/omap-serial.c Hunk #1 succeeded at 100 (offset -23 lines).

Should I still apply it?

greg k-h

#3 lore raw

PATCH 1/1 serial: omap: fix compile breakage

when rebasing patches on top of Greg's tty-next, it looks like automerge broke a few things which I didn't catch (for whatever reason I didn't have OMAP Serial enabled on .config) so I ended up breaking the build on Greg's tty-next branch.

Fix the breakage by re-adding the three missing members on struct uart_omap_port.

---

Hi Greg,

I just fetched your tree again and rebased again just to make sure. Everything is fine here, let me know if it still applies with fuzz.

cheers

 arch/arm/plat-omap/include/plat/omap-serial.h | 4 ----
 drivers/tty/serial/omap-serial.c              | 4 ++++
 2 files changed, 4 insertions(+), 4 deletions(-)
arch/arm/plat-omap/include/plat/omap-serial.h +0 -4
index 3c9fd3e..a531149 100644
@@ -105,8 +105,4 @@ struct uart_omap_dma {
 	unsigned int		rx_timeout;
 };
 
-
-	int			DTR_gpio;
-	int			DTR_inverted;
-	int			DTR_active;
 #endif /* __OMAP_SERIAL_H__ */
drivers/tty/serial/omap-serial.c +4 -0
index cfd2094..0a6e78e 100644
@@ -100,6 +100,10 @@ struct uart_omap_port {
 	u8			wakeups_enabled;
 	unsigned int		irq_pending:1;
 
+	int			DTR_gpio;
+	int			DTR_inverted;
+	int			DTR_active;
+
 	struct pm_qos_request	pm_qos_request;
 	u32			latency;
 	u32			calc_latency;
Signature · 1 line
1.7.12.rc3
maintainer
#4 lore raw
Quoted 11 lines · Felipe Balbi

when rebasing patches on top of Greg's tty-next, it looks like automerge broke a few things which I didn't catch (for whatever reason I didn't have OMAP Serial enabled on .config) so I ended up breaking the build on Greg's tty-next branch.

Fix the breakage by re-adding the three missing members on struct uart_omap_port.

Quoted 7 lines

---

Hi Greg,

I just fetched your tree again and rebased again just to make sure. Everything is fine here, let me know if it still applies with fuzz.

That worked, thanks.

greg k-h

#5 lore raw
Quoted 14 lines · Greg KH
Quoted 13 lines · Felipe Balbi

when rebasing patches on top of Greg's tty-next, it looks like automerge broke a few things which I didn't catch (for whatever reason I didn't have OMAP Serial enabled on .config) so I ended up breaking the build on Greg's tty-next branch.

Fix the breakage by re-adding the three missing members on struct uart_omap_port.

---

Quoted 7 lines
Quoted 5 lines

Hi Greg,

I just fetched your tree again and rebased again just to make sure. Everything is fine here, let me know if it still applies with fuzz.

That worked, thanks.

Something is still wrong with omap-serial in tty-next. It now compiles and works for the legacy non-devicetree case, but with device tree booting there's now regression during boot:

[    5.200836] Freeing init memory: 332K
[    6.881744] Unable to handle kernel NULL pointer dereference at virtual address 00000030
[    6.890258] pgd = ee664000
[    6.893096] [00000030] *pgd=ae64f831, *pte=00000000, *ppte=00000000
[    6.899688] Internal error: Oops: 17 [#1] SMP ARM
[    6.904632] Modules linked in:
[    6.907836] CPU: 1    Not tainted  (3.6.0-rc4-00207-gc893c8c-dirty #485)
[    6.914916] PC is at serial_omap_start_tx+0x60/0x98
[    6.920043] LR is at serial_omap_start_tx+0x44/0x98
[    6.925140] pc : [<c0316978>]    lr : [<c031695c>]    psr: 60000193
[    6.925140] sp : ee661e80  ip : 00000060  fp : a0000113
[    6.937194] r10: ef3c0010  r9 : ee798800  r8 : 00000072
[    6.942687] r7 : ef3d7472  r6 : 00000002  r5 : 00000007  r4 : ef3c0010
[    6.949523] r3 : 00000000  r2 : 00000004  r1 : 00000007  r0 : ef0da008
[    6.956390] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
[    6.963958] Control: 10c53c7d  Table: ae66404a  DAC: 00000015
[    6.970001] Process modprobe (pid: 715, stack limit = 0xee6602f8)
[    6.976379] Stack: (0xee661e80 to 0xee662000)
[    6.980957] 1e80: ee798800 ef3c0010 20000113 c030fcb4 00000000 ef3eead0 00000000 c0310544
[    6.989562] 1ea0: ef3eead0 ee798800 00000fff 00000073 ee798d94 ef3d7400 ee660000 ee7989b8
[    6.998138] 1ec0: ef3d7400 c02fa090 00000073 ef3d7400 ee798800 ee798800 ef0ccdc0 c02fb8e4
[    7.006713] 1ee0: beaa07bc ee798a2c beaa07bc 00000000 ef38aa00 c00778a0 ee798a4c ee798a4c
[    7.015319] 1f00: ee798d4c ef0ccdc0 00000073 00000073 ee798800 b6f19000 ee660000 00000400
[    7.023895] 1f20: 00000000 c02f775c c02fb7a8 ef1f6840 ee661f80 ef0ccdc0 00000000 ef0ccdc0
[    7.032470] 1f40: 00000073 b6f19000 ee661f80 00000073 ee660000 00000000 beaa07bc c010b580
[    7.041046] 1f60: ef38aa00 00000001 00000000 00000000 ef0ccdc0 b6f19000 00000073 c010b6e4
[    7.049652] 1f80: 00000000 00000000 beaa0888 00000000 00000073 beaa0888 00000073 00000004
[    7.058227] 1fa0: c0014308 c0014160 00000073 beaa0888 00000000 b6f19000 00000073 00000000
[    7.066802] 1fc0: 00000073 beaa0888 00000073 00000004 b6f19000 00000000 b6ee271d beaa07bc
[    7.075408] 1fe0: 00000000 beaa01c0 b6e2c874 b6e8015c 60000110 00000000 aaaaaaaa aaeaaaaa
[    7.083984] [<c0316978>] (serial_omap_start_tx+0x60/0x98) from [<c030fcb4>] (uart_start+0x68/0x6c)
[    7.093414] [<c030fcb4>] (uart_start+0x68/0x6c) from [<c0310544>] (uart_write+0xcc/0xf4)
[    7.101928] [<c0310544>] (uart_write+0xcc/0xf4) from [<c02fa090>] (process_output_block+0xc0/0x17c)
[    7.111419] [<c02fa090>] (process_output_block+0xc0/0x17c) from [<c02fb8e4>] (n_tty_write+0x13c/0x2ac)
[    7.121215] [<c02fb8e4>] (n_tty_write+0x13c/0x2ac) from [<c02f775c>] (tty_write+0x13c/0x228)
[    7.130065] [<c02f775c>] (tty_write+0x13c/0x228) from [<c010b580>] (vfs_write+0xb0/0x144)
[    7.138671] [<c010b580>] (vfs_write+0xb0/0x144) from [<c010b6e4>] (sys_write+0x40/0x70)
[    7.147094] [<c010b6e4>] (sys_write+0x40/0x70) from [<c0014160>] (ret_fast_syscall+0x0/0x3c)
[    7.155944] Code: e6ff1075 e18310b2 e5940180 e5903084 (e5933030) 
[    7.162353] ---[ end trace 8cfe94e3de797bda ]---
#6 lore raw

PATCH 1/1 serial: omap: fix DeviceTree boot

OMAP Architecture code, passes a few function pointers for UART driver to use in order to properly implement Power Management and Wakeup capabilities.

The problem is that those function pointers, which are passed (ab)using platform_data on non-DT kernels, can't be passed down to drivers through DT.

commit e5b57c0 (serial: omap: define helpers for pdata function pointers) failed to take DT kernels into consideration and caused a regression to DT kernel boot.

Fix that by (re-)adding a check for valid pdata pointer together with valid pdata->$FUNCTION pointer.

---

Tony, does this solve the issue ?

 drivers/tty/serial/omap-serial.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)
drivers/tty/serial/omap-serial.c +13 -7
index 0a6e78e..743e8e1 100644
@@ -143,7 +143,7 @@ static int serial_omap_get_context_loss_count(struct uart_omap_port *up)
 {
 	struct omap_uart_port_info *pdata = up->dev->platform_data;
 
-	if (!pdata->get_context_loss_count)
+	if (!pdata || !pdata->get_context_loss_count)
 		return 0;
 
 	return pdata->get_context_loss_count(up->dev);
@@ -153,24 +153,30 @@ static void serial_omap_set_forceidle(struct uart_omap_port *up)
 {
 	struct omap_uart_port_info *pdata = up->dev->platform_data;
 
-	if (pdata->set_forceidle)
-		pdata->set_forceidle(up->dev);
+	if (!pdata || !pdata->set_forceidle)
+		return;
+
+	pdata->set_forceidle(up->dev);
 }
 
 static void serial_omap_set_noidle(struct uart_omap_port *up)
 {
 	struct omap_uart_port_info *pdata = up->dev->platform_data;
 
-	if (pdata->set_noidle)
-		pdata->set_noidle(up->dev);
+	if (!pdata || !pdata->set_noidle)
+		return;
+
+	pdata->set_noidle(up->dev);
 }
 
 static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
 {
 	struct omap_uart_port_info *pdata = up->dev->platform_data;
 
-	if (pdata->enable_wakeup)
-		pdata->enable_wakeup(up->dev, enable);
+	if (!pdata || !pdata->enable_wakeup)
+		return;
+
+	pdata->enable_wakeup(up->dev, enable);
 }
 
 /*
Signature · 1 line
1.7.12.rc3
#7 lore raw

PATCH 1/1 serial: omap: fix DeviceTree boot

Quoted 19 lines · Felipe Balbi

OMAP Architecture code, passes a few function pointers for UART driver to use in order to properly implement Power Management and Wakeup capabilities.

The problem is that those function pointers, which are passed (ab)using platform_data on non-DT kernels, can't be passed down to drivers through DT.

commit e5b57c0 (serial: omap: define helpers for pdata function pointers) failed to take DT kernels into consideration and caused a regression to DT kernel boot.

Fix that by (re-)adding a check for valid pdata pointer together with valid pdata->$FUNCTION pointer.

Quoted 5 lines

---

Tony, does this solve the issue ?

Yes thanks console works again now: