Add removal schedule of register_serial/unregister_serial to appropriate file
Subsystems (4)
PATCH 1/1 Add removal schedule of register_serial/unregister_serial to appropriate file
I hope there's no need to explain this in the email; if there is, the entry isn't good enough. 8)
However, wouldn't it be a good idea if this file was ordered by "when" ? A quick scan of the file reveals a couple of overdue/forgotten items (maybe they happened but the entry in the file got missed?):
What: ACPI S4bios support When: May 2005
What: register_ioctl32_conversion() / unregister_ioctl32_conversion() When: April 2005
Documentation/feature-removal-schedule.txt +10 -0
@@ -83,3 +83,13 @@ Why: Deprecated in favour of the new ioc more efficient. You should really be using libraw1394 for raw1394 access anyway. Who: Jody McIntyre <[email protected]> + +--------------------------- + +What: register_serial/unregister_serial +When: December 2005 +Why: This interface does not allow serial ports to be registered against + a struct device, and as such does not allow correct power management + of such ports. 8250-based ports should use serial8250_register_port + and serial8250_unregister_port instead. +Who: Russell King <[email protected]>
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 2 lines
What: register_ioctl32_conversion() / unregister_ioctl32_conversion() When: April 2005
I already have a patch queued for that, will send soon.
-Andi
Quoted 8 lines · Russell King
...
However, wouldn't it be a good idea if this file was ordered by "when" ? A quick scan of the file reveals a couple of overdue/forgotten items (maybe they happened but the entry in the file got missed?):
...What: register_ioctl32_conversion() / unregister_ioctl32_conversion() When: April 2005...
The removal (including the removal of the feature-removal-schedule.txt entry) is already in -mm.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 10 lines · Adrian Bunk
Quoted 8 lines · Russell King
...
However, wouldn't it be a good idea if this file was ordered by "when" ? A quick scan of the file reveals a couple of overdue/forgotten items (maybe they happened but the entry in the file got missed?):
...What: register_ioctl32_conversion() / unregister_ioctl32_conversion() When: April 2005...
Quoted 2 lines
The removal (including the removal of the feature-removal-schedule.txt entry) is already in -mm.
Ok, but I hope whoever did that fixed the locking in the compat path too. e.g. the BKL is not needed anymore.
-Andi
Quoted 11 lines · Adrian Bunk
Quoted 8 lines · Russell King
...
However, wouldn't it be a good idea if this file was ordered by "when" ? A quick scan of the file reveals a couple of overdue/forgotten items (maybe they happened but the entry in the file got missed?):
...What: register_ioctl32_conversion() / unregister_ioctl32_conversion() When: April 2005...
Quoted 2 lines
The removal (including the removal of the feature-removal-schedule.txt entry) is already in -mm.
Actually it has been temporarily removed because it has a dependency on update-drm-ioctl-compatibility-to-new-world-order.patch which has a dependency on David's DRM tree and I don't know how to get David's DRM tree any more. Hint.
Quoted 5 lines
Actually it has been temporarily removed because it has a dependency on update-drm-ioctl-compatibility-to-new-world-order.patch which has a dependency on David's DRM tree and I don't know how to get David's DRM tree any more. Hint.
I'll have a new DRM tree up in the next day or two, with it you can drop that patch as I've folded it into my tree...
I'm still trying to get my head around the best workflow for git and me...
Dave.
Signature · 3 lines
David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG
Quoted 10 lines · Adrian Bunk
Quoted 8 lines · Russell King
...
However, wouldn't it be a good idea if this file was ordered by "when" ? A quick scan of the file reveals a couple of overdue/forgotten items (maybe they happened but the entry in the file got missed?):
...What: register_ioctl32_conversion() / unregister_ioctl32_conversion() When: April 2005...
Quoted 2 lines
The removal (including the removal of the feature-removal-schedule.txt entry) is already in -mm.
Perhaps they should be moved to a REMOVED file, with the date (and version) the patch went in? For future generations who wonder when something was axed...
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Hi!
Quoted 9 lines
I hope there's no need to explain this in the email; if there is, the entry isn't good enough. 8)
However, wouldn't it be a good idea if this file was ordered by "when" ? A quick scan of the file reveals a couple of overdue/forgotten items (maybe they happened but the entry in the file got missed?):
What: ACPI S4bios support When: May 2005
ACPI S4bios will be killed "when convient" -- probably when we touch /sys/power/* interface for another reason.
If there's pressure I can probably produce patch faster; I did not forget, just S4bios did not get in my way *yet*.
Pavel
Signature · 1 line
Boycott Kodak -- for their patent abuse against Java.
Documentation/feature-removal-schedule.txt Why: Deprecated in favour of the new ioc · line 95
Quoted 7 lines · Russell King
Documentation/feature-removal-schedule.txt +7
-0+What: register_serial/unregister_serial +When: December 2005 +Why: This interface does not allow serial ports to be registered against + a struct device, and as such does not allow correct power management + of such ports. 8250-based ports should use serial8250_register_port + and serial8250_unregister_port instead. +Who: Russell King <[email protected]>
Ok, now that this is in, I guess I should arrange for register_serial & co to throw a compiler warning. However, this is non-trivial because several other drivers declare this function:
drivers/macintosh/macserial.c:int register_serial(struct serial_struct *req) drivers/macintosh/macserial.c:void unregister_serial(int line) drivers/serial/68328serial.c:int register_serial(struct serial_struct *req) drivers/serial/68328serial.c:void unregister_serial(int line) drivers/serial/crisv10.c:register_serial(struct serial_struct *req) drivers/serial/crisv10.c:void unregister_serial(int line)
Can folk who look after these drivers please comment on why these functions are there.
Other places appear to have a prototype for these functions but do not use them:
arch/xtensa/platform-iss/console.c:int register_serial(struct serial_struct*); arch/xtensa/platform-iss/console.c:void unregister_serial(int); drivers/char/amiserial.c:int register_serial(struct serial_struct *req); drivers/char/amiserial.c:void unregister_serial(int line);
The patch which follows this message will remove these.
In terms of the use of these functions, this is the state of play as of yesterday:
arch/frv/kernel/setup.c:// register_serial(&__frv_uart0); arch/frv/kernel/setup.c:// register_serial(&__frv_uart1); drivers/char/mwave/mwavedd.c: return register_serial(&serial); drivers/char/mwave/mwavedd.c: unregister_serial(pDrvData->sLine); drivers/misc/ibmasm/uart.c: sp->serial_line = register_serial(&serial); drivers/misc/ibmasm/uart.c: unregister_serial(sp->serial_line); drivers/net/ioc3-eth.c: register_serial(&req); drivers/net/ioc3-eth.c: register_serial(&req); drivers/parport/parport_serial.c: line = register_serial (&serial_req); drivers/parport/parport_serial.c: unregister_serial (priv->line[i]); drivers/serial/bast_sio.c: return register_serial(&serial_req); drivers/serial/bast_sio.c: unregister_serial(port[0]); drivers/serial/bast_sio.c: unregister_serial(port[1]);
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 17 lines · Russell King
Review
Quoted 7 lines · Russell King
(quoted diff) +7
-0+What: register_serial/unregister_serial +When: December 2005 +Why: This interface does not allow serial ports to be registered against + a struct device, and as such does not allow correct power management + of such ports. 8250-based ports should use serial8250_register_port + and serial8250_unregister_port instead. +Who: Russell King <[email protected]>Other places appear to have a prototype for these functions but do not use them:
arch/xtensa/platform-iss/console.c:int
register_serial(struct serial_struct*); arch/xtensa/platform-iss/console.c:voidunregister_serial(int); drivers/char/amiserial.c:intregister_serial(struct serial_struct *req); drivers/char/amiserial.c:voidunregister_serial(int line);
Quoted 8 lines
The patch which follows this message will remove these.
In terms of the use of these functions, this is the state of play as of yesterday:
arch/frv/kernel/setup.c://
register_serial(&__frv_uart0);
arch/frv/kernel/setup.c://register_serial(&__frv_uart1);
I've also removed this. The following is mostly for comment only. I'm intending to commit this change by Monday at the latest.
[PATCH] Serial: remove unnecessary register_serial/unregister_serial
A couple of drivers declare register_serial/unregister_serial prototypes but don't use them. FRV contains a commented out call to register_serial. Since these are deprecated, remove these unnecessary references.
arch/frv/kernel/setup.c (mode:100644) +0 -2
@@ -790,12 +790,10 @@ #ifndef CONFIG_GDBSTUB_UART0 __reg(UART0_BASE + UART_IER * 8) = 0; early_serial_setup(&__frv_uart0); -// register_serial(&__frv_uart0); #endif #ifndef CONFIG_GDBSTUB_UART1 __reg(UART1_BASE + UART_IER * 8) = 0; early_serial_setup(&__frv_uart1); -// register_serial(&__frv_uart1); #endif #if defined(CONFIG_CHR_DEV_FLASH) || defined(CONFIG_BLK_DEV_FLASH)
arch/xtensa/platform-iss/console.c (mode:100644) +0 -3
@@ -198,9 +198,6 @@ } -int register_serial(struct serial_struct*); -void unregister_serial(int); - static struct tty_operations serial_ops = { .open = rs_open, .close = rs_close,
drivers/char/amiserial.c (mode:100644) +0 -4
@@ -1973,10 +1973,6 @@ } -int register_serial(struct serial_struct *req); -void unregister_serial(int line); - - static struct tty_operations serial_ops = { .open = rs_open, .close = rs_close,
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Jivin Russell King lays it down ...
Quoted 12 lines · Russell King
Documentation/feature-removal-schedule.txt Why: Deprecated in favour of the new ioc · line 95
Quoted 7 lines
Documentation/feature-removal-schedule.txt +7
-0+What: register_serial/unregister_serial +When: December 2005 +Why: This interface does not allow serial ports to be registered against + a struct device, and as such does not allow correct power management + of such ports. 8250-based ports should use serial8250_register_port + and serial8250_unregister_port instead. +Who: Russell King <[email protected]>Ok, now that this is in, I guess I should arrange for
register_serial& co to throw a compiler warning. However, this is non-trivial because several other drivers declare this function:
...
Quoted 2 lines
drivers/serial/68328serial.c:int
register_serial(struct serial_struct *req)drivers/serial/68328serial.c:voidunregister_serial(int line)
These can go. AFAICT they were never used and I have no idea why they are there.
Cheers,
Davidm
Signature · 2 lines
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
Quoted 6 lines · David McCullough
Jivin Russell King lays it down ...
Quoted 2 lines
drivers/serial/68328serial.c:int
register_serial(struct serial_struct *req)drivers/serial/68328serial.c:voidunregister_serial(int line)These can go. AFAICT they were never used and I have no idea why they are there.
Thanks David. I've just committed a patch to remove these.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Review
Quoted 10 lines · Russell King
(quoted diff) +10
-0+ +--------------------------- + +What: register_serial/unregister_serial +When: December 2005 +Why: This interface does not allow serial ports to be registered against + a struct device, and as such does not allow correct power management + of such ports. 8250-based ports should use serial8250_register_port + and serial8250_unregister_port instead. +Who: Russell King <[email protected]>
I think it's about time to make the build a little more vocal about the expiry of these functions. Due to recent discussions with problems in the console initialisation vs power manglement, I'd like to move the date forward to September.
include/linux/serial_core.h +3 -2
@@ -122,6 +122,7 @@#ifdef __KERNEL__#include <linux/config.h> +#include <linux/compiler.h> #include <linux/interrupt.h> #include <linux/circ_buf.h> #include <linux/spinlock.h>
@@ -359,8 +360,8 @@ struct tty_driver *uart_console_device(s*/ int uart_register_driver (struct uart_driver *uart);void uart_unregister_driver (struct uart_driver *uart); -void uart_unregister_port (struct uart_driver *reg,int line); -int uart_register_port (struct uart_driver *reg,struct uart_port *port); +void __deprecated uart_unregister_port (struct uart_driver *reg,int line); +int __deprecated uart_register_port (struct uart_driver *reg,struct uart_port *port);int uart_add_one_port (struct uart_driver *reg,struct uart_port *port);int uart_remove_one_port (struct uart_driver *reg,struct uart_port *port);int uart_match_port (struct uart_port *port1,struct uart_port *port2);
include/linux/serial.h +4 -2
@@ -174,9 +174,11 @@ struct serial_icounter_struct {#ifdef __KERNEL__ +#include <linux/compiler.h> +/* Export to allow PCMCIA to use this - Dave Hinds */ -extern int register_serial (struct serial_struct *req); -extern void unregister_serial (int line); +extern int __deprecated register_serial (struct serial_struct *req); +extern void __deprecated unregister_serial (int line);/* Allow architectures to override entries in serial8250_ports[] at run time: */ struct uart_port ;/* forward declaration */
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 17 lines · Russell King
Review
Quoted 10 lines · Russell King
(quoted diff) +10
-0+ +--------------------------- + +What: register_serial/unregister_serial +When: December 2005 +Why: This interface does not allow serial ports to be registered against + a struct device, and as such does not allow correct power management + of such ports. 8250-based ports should use serial8250_register_port + and serial8250_unregister_port instead. +Who: Russell King <[email protected]>I think it's about time to make the build a little more vocal about the expiry of these functions. Due to recent discussions with problems in the console initialisation vs power manglement, I'd like to move the date forward to September.
I am converting the ibmasm driver that uses (un)register_serial to use serial_8250_(un)register_port. However I find function prototypes for the new interfaces only in linux/drivers/char/8250.h. Is there a reason there aren't any extern declarations for these functions in linux/include/serial.h or linux/include/serial_8250.h?
thanks,
max
Quoted 5 lines · Max Asbock
I am converting the ibmasm driver that uses (un)register_serial to use serial_8250_(un)register_port. However I find function prototypes for the new interfaces only in linux/drivers/char/8250.h. Is there a reason there aren't any extern declarations for these functions in
linux/include/serial.horlinux/include/serial_8250.h?
Probably because nothing outside drivers/serial uses these functions at the moment.
They could be moved to include/linux/serial_8250.h though. Patch welcome.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core