* serial8250_init and platform_device @ 2005-01-20 7:14 Kumar Gala 2005-01-20 11:43 ` Russell King 0 siblings, 1 reply; 11+ messages in thread From: Kumar Gala @ 2005-01-20 7:14 UTC (permalink / raw) To: Linux Kernel list I dont get how it is you dont have more platform_devices register than you should based on how serial8250_init works if you have additional code registering a serial8250 device. For example, arch/arm/mach-s3c2410/mach-vr1000.c will register one serial8250 device, and it appears to me that serial8250_init will register a 2nd. Is this the expected behavior or am I missing something? - kumar ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: serial8250_init and platform_device 2005-01-20 7:14 serial8250_init and platform_device Kumar Gala @ 2005-01-20 11:43 ` Russell King 2005-01-20 15:23 ` Kumar Gala 0 siblings, 1 reply; 11+ messages in thread From: Russell King @ 2005-01-20 11:43 UTC (permalink / raw) To: Kumar Gala; +Cc: Linux Kernel list On Thu, Jan 20, 2005 at 01:14:49AM -0600, Kumar Gala wrote: > I dont get how it is you dont have more platform_devices register than > you should based on how serial8250_init works if you have additional > code registering a serial8250 device. For example, > arch/arm/mach-s3c2410/mach-vr1000.c will register one serial8250 > device, and it appears to me that serial8250_init will register a 2nd. > Is this the expected behavior or am I missing something? I don't understand what you're saying, sorry. serial8250_init() registers an "ISA compatibility" 8250 device for those architectures which haven't converted themselves to the new scheme. It then creates all the 8250 ports from 0..UART_NR. In the case of an architecture which doesn't have any SERIAL_PORT_DFNS defined (eg, ARM) these are just dummy placeholder registrations. We then register the device driver, which allows us to pick up on the platform devices. This causes the placeholder registrations to be reassigned to the platform devices on a first come first served basis via the standard registration call serial8250_register_port(). While you can have both the "ISA compatibility" scheme and the "platform device" scheme contain the same port description, you'll only end up with just the one port registered in the end. That just happens to be correct and desired behaviour. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: serial8250_init and platform_device 2005-01-20 11:43 ` Russell King @ 2005-01-20 15:23 ` Kumar Gala 2005-01-20 15:44 ` Russell King 0 siblings, 1 reply; 11+ messages in thread From: Kumar Gala @ 2005-01-20 15:23 UTC (permalink / raw) To: Russell King; +Cc: Linux Kernel list I'm trying to convert some PPC embedded code from using the old "ISA compat" style with SERIAL_PORT_DFNS to using platform_device. > On Thu, Jan 20, 2005 at 01:14:49AM -0600, Kumar Gala wrote: > > I dont get how it is you dont have more platform_devices register > than > > you should based on how serial8250_init works if you have additional > > code registering a serial8250 device. For example, > > arch/arm/mach-s3c2410/mach-vr1000.c will register one serial8250 > > device, and it appears to me that serial8250_init will register a > 2nd. > > Is this the expected behavior or am I missing something? > > I don't understand what you're saying, sorry. No problem, let me try to clarify. I'm trying to figure out in the ARM case if there are 2 platform_devices that are registered and if this is the desired behavior (and if so why?). > serial8250_init() registers an "ISA compatibility" 8250 device for > those > architectures which haven't converted themselves to the new scheme. > > It then creates all the 8250 ports from 0..UART_NR. In the case of an > architecture which doesn't have any SERIAL_PORT_DFNS defined (eg, ARM) > these are just dummy placeholder registrations. In serial8250_init() we call platform_device_register_simple(), this will be one registration of a serial8250 device. In my example of vr1000, arch/arm/mach-s3c2410/cpu.c:s3c_arch_init() calls platform_device_register, the 2nd time a serial8250 device is registered. > We then register the device driver, which allows us to pick up on the > platform devices. This causes the placeholder registrations to be > reassigned to the platform devices on a first come first served basis > via the standard registration call serial8250_register_port(). I'm not following you here, its not clear if you mean we have 2 platform devices registered in the system, but only one actually has serial ports that are registered. If you are using SERIAL_PORT_DFNS, it will be the platform_device created in serial8250_init(), if you are not it will be the platform_device created elsewhere? > While you can have both the "ISA compatibility" scheme and the > "platform device" scheme contain the same port description, you'll > only end up with just the one port registered in the end. That just > happens to be correct and desired behaviour. - kumar ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: serial8250_init and platform_device 2005-01-20 15:23 ` Kumar Gala @ 2005-01-20 15:44 ` Russell King 2005-01-20 19:06 ` Kumar Gala 0 siblings, 1 reply; 11+ messages in thread From: Russell King @ 2005-01-20 15:44 UTC (permalink / raw) To: Kumar Gala; +Cc: Linux Kernel list On Thu, Jan 20, 2005 at 09:23:56AM -0600, Kumar Gala wrote: > No problem, let me try to clarify. I'm trying to figure out in the ARM > case if there are 2 platform_devices that are registered and if this is > the desired behavior (and if so why?). Yes. The first (by serial8250_init) is the ISA compatibility platform device, which registers the "old" static list of serial devices found in include/asm-*/serial.h. The second registers a platform device which contains the 8250 serial devices for the particular platform. > In serial8250_init() we call platform_device_register_simple(), this > will be one registration of a serial8250 device. In my example of > vr1000, arch/arm/mach-s3c2410/cpu.c:s3c_arch_init() calls > platform_device_register, the 2nd time a serial8250 device is > registered. Correct. > > We then register the device driver, which allows us to pick up on the > > platform devices. This causes the placeholder registrations to be > > reassigned to the platform devices on a first come first served basis > > via the standard registration call serial8250_register_port(). > > I'm not following you here, its not clear if you mean we have 2 > platform devices registered in the system, but only one actually has > serial ports that are registered. We have two platform devices registered - one representing the compatibility devices, and one (or more) representing the platform's own devices. To illustrate this, let's assume your architecture always has ports at a fixed set of addresses, and then has a set of platform specific ports. You may wish to have one platform device for the platform common serial devices which always gets registered. Your platform specific initialisation code could then register another platform device which contains details of the platform specific serial devices. > If you are using SERIAL_PORT_DFNS, > it will be the platform_device created in serial8250_init(), if you are > not it will be the platform_device created elsewhere? Initially, all serial devices are attached to the platform device created in serial8250_init(), whether or not they are listed in SERIAL_PORT_DFNS or not. Serial devices not listed in SERIAL_PORT_DFNS remain in an unconfigured state. When the 8250 platform device driver is registered, serial devices are "stolen" from this "private" platform device, and are owned by the platform device which registered them. Lets take some examples: 1. SERIAL_PORT_DFNS contains port at 0x3f8, irq4, and we have space for 4 serial ports. No other platform devices are registered. # cat /proc/tty/driver/serial serinfo:1.0 driver revision: 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 1: uart:unknown port:00000000 irq:0 2: uart:unknown port:00000000 irq:0 3: uart:unknown port:00000000 irq:0 # tree /sys/class/tty/ttyS* /sys/class/tty/ttyS0 |-- dev `-- device -> ../../../devices/platform/serial8250 /sys/class/tty/ttyS1 |-- dev `-- device -> ../../../devices/platform/serial8250 /sys/class/tty/ttyS2 |-- dev `-- device -> ../../../devices/platform/serial8250 /sys/class/tty/ttyS3 |-- dev `-- device -> ../../../devices/platform/serial8250 2. SERIAL_PORT_DFNS contains port at 0x3f8, irq4, and we have space for 4 serial ports. A platform device also describing 0x3f8, irq 4 is registered. # cat /proc/tty/driver/serial serinfo:1.0 driver revision: 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 1: uart:unknown port:00000000 irq:0 2: uart:unknown port:00000000 irq:0 3: uart:unknown port:00000000 irq:0 # tree /sys/class/tty/ttyS* /sys/class/tty/ttyS0 |-- dev |-- device -> ../../../devices/platform/serial82500 `-- driver -> ../../../bus/platform/drivers/serial8250 /sys/class/tty/ttyS1 |-- dev `-- device -> ../../../devices/platform/serial8250 /sys/class/tty/ttyS2 |-- dev `-- device -> ../../../devices/platform/serial8250 /sys/class/tty/ttyS3 |-- dev `-- device -> ../../../devices/platform/serial8250 3. SERIAL_PORT_DFNS is empty, otherwise the same as case (2). Results are identical to case (2). HTH. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: serial8250_init and platform_device 2005-01-20 15:44 ` Russell King @ 2005-01-20 19:06 ` Kumar Gala 2005-01-20 19:38 ` Russell King 0 siblings, 1 reply; 11+ messages in thread From: Kumar Gala @ 2005-01-20 19:06 UTC (permalink / raw) To: Russell King; +Cc: Linux Kernel list Russell, I think this all makes sense to me. I'm just wondering why we would have a platform device register in a system for 'legacy ISA' when we know the system doesnt have any ports that will fit the category. As you show in example #2 you have .../devices/platform/serial82500 .../devices/platform/serial8250 why have the 'serial8250' if you know your system doesnt have any ports that will exist there? - kumar On Jan 20, 2005, at 9:44 AM, Russell King wrote: > On Thu, Jan 20, 2005 at 09:23:56AM -0600, Kumar Gala wrote: > > No problem, let me try to clarify. I'm trying to figure out in the > ARM > > case if there are 2 platform_devices that are registered and if > this is > > the desired behavior (and if so why?). > > Yes. The first (by serial8250_init) is the ISA compatibility platform > device, which registers the "old" static list of serial devices found > in include/asm-*/serial.h. > > The second registers a platform device which contains the 8250 serial > devices for the particular platform. > > > In serial8250_init() we call platform_device_register_simple(), this > > will be one registration of a serial8250 device. In my example of > > vr1000, arch/arm/mach-s3c2410/cpu.c:s3c_arch_init() calls > > platform_device_register, the 2nd time a serial8250 device is > > registered. > > Correct. > > > > We then register the device driver, which allows us to pick up on > the > > > platform devices. This causes the placeholder registrations to > be > > > reassigned to the platform devices on a first come first served > basis > > > via the standard registration call serial8250_register_port(). > > > > I'm not following you here, its not clear if you mean we have 2 > > platform devices registered in the system, but only one actually has > > serial ports that are registered. > > We have two platform devices registered - one representing the > compatibility devices, and one (or more) representing the platform's > own devices. > > To illustrate this, let's assume your architecture always has ports at > a fixed set of addresses, and then has a set of platform specific > ports. > You may wish to have one platform device for the platform common > serial > devices which always gets registered. Your platform specific > initialisation code could then register another platform device which > contains details of the platform specific serial devices. > > > If you are using SERIAL_PORT_DFNS, > > it will be the platform_device created in serial8250_init(), if you > are > > not it will be the platform_device created elsewhere? > > Initially, all serial devices are attached to the platform device > created in serial8250_init(), whether or not they are listed in > SERIAL_PORT_DFNS or not. Serial devices not listed in > SERIAL_PORT_DFNS > remain in an unconfigured state. > > When the 8250 platform device driver is registered, serial devices > are "stolen" from this "private" platform device, and are owned by > the platform device which registered them. > > Lets take some examples: > > 1. SERIAL_PORT_DFNS contains port at 0x3f8, irq4, and we have space for > 4 serial ports. No other platform devices are registered. > > # cat /proc/tty/driver/serial > serinfo:1.0 driver revision: > 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 > 1: uart:unknown port:00000000 irq:0 > 2: uart:unknown port:00000000 irq:0 > 3: uart:unknown port:00000000 irq:0 > # tree /sys/class/tty/ttyS* > /sys/class/tty/ttyS0 > |-- dev > `-- device -> ../../../devices/platform/serial8250 > /sys/class/tty/ttyS1 > |-- dev > `-- device -> ../../../devices/platform/serial8250 > /sys/class/tty/ttyS2 > |-- dev > `-- device -> ../../../devices/platform/serial8250 > /sys/class/tty/ttyS3 > |-- dev > `-- device -> ../../../devices/platform/serial8250 > > 2. SERIAL_PORT_DFNS contains port at 0x3f8, irq4, and we have space for > 4 serial ports. A platform device also describing 0x3f8, irq 4 is > registered. > > # cat /proc/tty/driver/serial > serinfo:1.0 driver revision: > 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 > 1: uart:unknown port:00000000 irq:0 > 2: uart:unknown port:00000000 irq:0 > 3: uart:unknown port:00000000 irq:0 > # tree /sys/class/tty/ttyS* > /sys/class/tty/ttyS0 > |-- dev > |-- device -> ../../../devices/platform/serial82500 > `-- driver -> ../../../bus/platform/drivers/serial8250 > /sys/class/tty/ttyS1 > |-- dev > `-- device -> ../../../devices/platform/serial8250 > /sys/class/tty/ttyS2 > |-- dev > `-- device -> ../../../devices/platform/serial8250 > /sys/class/tty/ttyS3 > |-- dev > `-- device -> ../../../devices/platform/serial8250 > > 3. SERIAL_PORT_DFNS is empty, otherwise the same as case (2). Results > are identical to case (2). > > HTH. > > -- > Russell King > Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ > maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ > 2.6 Serial core ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: serial8250_init and platform_device 2005-01-20 19:06 ` Kumar Gala @ 2005-01-20 19:38 ` Russell King 2005-01-20 19:50 ` Greg KH 2005-01-20 20:26 ` Kumar Gala 0 siblings, 2 replies; 11+ messages in thread From: Russell King @ 2005-01-20 19:38 UTC (permalink / raw) To: Kumar Gala, Greg KH; +Cc: Linux Kernel list On Thu, Jan 20, 2005 at 01:06:55PM -0600, Kumar Gala wrote: > Russell, > > I think this all makes sense to me. I'm just wondering why we would > have a platform device register in a system for 'legacy ISA' when we > know the system doesnt have any ports that will fit the category. > > As you show in example #2 you have > > .../devices/platform/serial82500 > .../devices/platform/serial8250 > > why have the 'serial8250' if you know your system doesnt have any ports > that will exist there? In this case, it is a placeholder, and needs to be there if you're using power management. For instance, you may use setserial on /dev/ttyS2 to reconfigure it to an address where you know a serial port is. Without the "serial8250" device, it isn't linked into the device model, and therefore doesn't receive any power management notifications. Once the SERIAL_PORT_DFNS are gone, and we have a more modern interface than setserial for setting up random ports, this "serial8250" device will vanish. While we're here, you've reminded me about an annoying point about platform device naming... Greg - the name is constructed from "name" + "id num" thusly: serial8250 serial82500 serial82501 serial82502 When "name" ends in a number, it gets rather confusing. Can we have an optional delimiter in there when we append the ID number, maybe something like a '.' or ':' ? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: serial8250_init and platform_device 2005-01-20 19:38 ` Russell King @ 2005-01-20 19:50 ` Greg KH 2005-01-20 20:10 ` Russell King 2005-01-20 20:26 ` Kumar Gala 1 sibling, 1 reply; 11+ messages in thread From: Greg KH @ 2005-01-20 19:50 UTC (permalink / raw) To: Kumar Gala, Linux Kernel list On Thu, Jan 20, 2005 at 07:38:45PM +0000, Russell King wrote: > > Greg - the name is constructed from "name" + "id num" thusly: > > serial8250 > serial82500 > serial82501 > serial82502 > > When "name" ends in a number, it gets rather confusing. Can we have > an optional delimiter in there when we append the ID number, maybe > something like a '.' or ':' ? Sure, that's fine with me. Someone send me a patch :) thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: serial8250_init and platform_device 2005-01-20 19:50 ` Greg KH @ 2005-01-20 20:10 ` Russell King 2005-01-20 20:25 ` Kumar Gala 2005-02-01 8:41 ` Greg KH 0 siblings, 2 replies; 11+ messages in thread From: Russell King @ 2005-01-20 20:10 UTC (permalink / raw) To: Greg KH; +Cc: Kumar Gala, Linux Kernel list On Thu, Jan 20, 2005 at 11:50:58AM -0800, Greg KH wrote: > On Thu, Jan 20, 2005 at 07:38:45PM +0000, Russell King wrote: > > > > Greg - the name is constructed from "name" + "id num" thusly: > > > > serial8250 > > serial82500 > > serial82501 > > serial82502 > > > > When "name" ends in a number, it gets rather confusing. Can we have > > an optional delimiter in there when we append the ID number, maybe > > something like a '.' or ':' ? > > Sure, that's fine with me. Someone send me a patch :) Like this? - Separate platform device name from platform device number such that names ending with numbers aren't confusing. Signed-off-by: Russell King <rmk@arm.linux.org.uk> --- orig/drivers/base/platform.c Wed Jan 12 10:11:20 2005 +++ linux/drivers/base/platform.c Thu Jan 20 20:08:53 2005 @@ -131,7 +131,7 @@ int platform_device_register(struct plat pdev->dev.bus = &platform_bus_type; if (pdev->id != -1) - snprintf(pdev->dev.bus_id, BUS_ID_SIZE, "%s%u", pdev->name, pdev->id); + snprintf(pdev->dev.bus_id, BUS_ID_SIZE, "%s.%u", pdev->name, pdev->id); else strlcpy(pdev->dev.bus_id, pdev->name, BUS_ID_SIZE); -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: serial8250_init and platform_device 2005-01-20 20:10 ` Russell King @ 2005-01-20 20:25 ` Kumar Gala 2005-02-01 8:41 ` Greg KH 1 sibling, 0 replies; 11+ messages in thread From: Kumar Gala @ 2005-01-20 20:25 UTC (permalink / raw) To: Russell King; +Cc: Linux Kernel list, Greg KH agreed, the lack of a delimiter in the naming was annoying. - kumar On Jan 20, 2005, at 2:10 PM, Russell King wrote: > On Thu, Jan 20, 2005 at 11:50:58AM -0800, Greg KH wrote: > > On Thu, Jan 20, 2005 at 07:38:45PM +0000, Russell King wrote: > > > > > > Greg - the name is constructed from "name" + "id num" thusly: > > > > > > serial8250 > > > serial82500 > > > serial82501 > > > serial82502 > > > > > > When "name" ends in a number, it gets rather confusing. Can we > have > > > an optional delimiter in there when we append the ID number, maybe > > > something like a '.' or ':' ? > > > > Sure, that's fine with me. Someone send me a patch :) > > Like this? > - > > Separate platform device name from platform device number such that > names ending with numbers aren't confusing. > > Signed-off-by: Russell King <rmk@arm.linux.org.uk> > > --- orig/drivers/base/platform.c Wed Jan 12 10:11:20 2005 > +++ linux/drivers/base/platform.c Thu Jan 20 20:08:53 2005 > @@ -131,7 +131,7 @@ int platform_device_register(struct plat > pdev->dev.bus = &platform_bus_type; > > if (pdev->id != -1) > - snprintf(pdev->dev.bus_id, BUS_ID_SIZE, "%s%u", > pdev->name, pdev->id); > + snprintf(pdev->dev.bus_id, BUS_ID_SIZE, "%s.%u", > pdev->name, pdev->id); > else > strlcpy(pdev->dev.bus_id, pdev->name, BUS_ID_SIZE); > > > -- > Russell King > Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ > maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ > 2.6 Serial core ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: serial8250_init and platform_device 2005-01-20 20:10 ` Russell King 2005-01-20 20:25 ` Kumar Gala @ 2005-02-01 8:41 ` Greg KH 1 sibling, 0 replies; 11+ messages in thread From: Greg KH @ 2005-02-01 8:41 UTC (permalink / raw) To: Kumar Gala, Linux Kernel list On Thu, Jan 20, 2005 at 08:10:59PM +0000, Russell King wrote: > On Thu, Jan 20, 2005 at 11:50:58AM -0800, Greg KH wrote: > > On Thu, Jan 20, 2005 at 07:38:45PM +0000, Russell King wrote: > > > > > > Greg - the name is constructed from "name" + "id num" thusly: > > > > > > serial8250 > > > serial82500 > > > serial82501 > > > serial82502 > > > > > > When "name" ends in a number, it gets rather confusing. Can we have > > > an optional delimiter in there when we append the ID number, maybe > > > something like a '.' or ':' ? > > > > Sure, that's fine with me. Someone send me a patch :) > > Like this? > - > > Separate platform device name from platform device number such that > names ending with numbers aren't confusing. > > Signed-off-by: Russell King <rmk@arm.linux.org.uk> Looks good to me, applied. thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: serial8250_init and platform_device 2005-01-20 19:38 ` Russell King 2005-01-20 19:50 ` Greg KH @ 2005-01-20 20:26 ` Kumar Gala 1 sibling, 0 replies; 11+ messages in thread From: Kumar Gala @ 2005-01-20 20:26 UTC (permalink / raw) To: Russell King; +Cc: Linux Kernel list, Greg KH Good, I can understand the need to maintain compatibility until we get ride of SERIAL_PORT_DFNS. - kumar On Jan 20, 2005, at 1:38 PM, Russell King wrote: > On Thu, Jan 20, 2005 at 01:06:55PM -0600, Kumar Gala wrote: > > Russell, > > > > I think this all makes sense to me. I'm just wondering why we would > > have a platform device register in a system for 'legacy ISA' when we > > know the system doesnt have any ports that will fit the category. > > > > As you show in example #2 you have > > > > .../devices/platform/serial82500 > > .../devices/platform/serial8250 > > > > why have the 'serial8250' if you know your system doesnt have any > ports > > that will exist there? > > In this case, it is a placeholder, and needs to be there if you're > using > power management. > > For instance, you may use setserial on /dev/ttyS2 to reconfigure it > to an address where you know a serial port is. Without the > "serial8250" > device, it isn't linked into the device model, and therefore doesn't > receive any power management notifications. > > Once the SERIAL_PORT_DFNS are gone, and we have a more modern interface > than setserial for setting up random ports, this "serial8250" device > will vanish. > > While we're here, you've reminded me about an annoying point about > platform device naming... > > Greg - the name is constructed from "name" + "id num" thusly: > > serial8250 > serial82500 > serial82501 > serial82502 > > When "name" ends in a number, it gets rather confusing. Can we have > an optional delimiter in there when we append the ID number, maybe > something like a '.' or ':' ? > > -- > Russell King > Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ > maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ > 2.6 Serial core ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-02-01 8:52 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-01-20 7:14 serial8250_init and platform_device Kumar Gala 2005-01-20 11:43 ` Russell King 2005-01-20 15:23 ` Kumar Gala 2005-01-20 15:44 ` Russell King 2005-01-20 19:06 ` Kumar Gala 2005-01-20 19:38 ` Russell King 2005-01-20 19:50 ` Greg KH 2005-01-20 20:10 ` Russell King 2005-01-20 20:25 ` Kumar Gala 2005-02-01 8:41 ` Greg KH 2005-01-20 20:26 ` Kumar Gala
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).