RE: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Tue, 3 Feb 2015, Peter Chen wrote: How i386 platform chooses which driver is suitable for device? The ehci_pci_init may overwrite what ci_hdrc_host_init does if it runs later? There's nothing special about the i386 platform. _All_ platforms that support PCI use the same matching code to select drivers. (This is true for other buses too, not just for PCI. For example, all platforms use the same matching code for the USB bus.) The device core iterates through all the drivers that are registered on the PCI bus. When it finds a driver that matches the device ID, it calls the driver's probe routine. If the probe routine returns 0 then the core stops iterating; otherwise it keeps iterating through the list of drivers. So in this case it's more or less random. Whichever driver gets registered on the PCI bus first is the one that will be probed first. But with Andy's patch, the ehci-pci driver won't interfere with the ci_hdrc_host driver, even if ehci-pci gets probed first. In fact, ehci_pci_init() will never be called, because ehci_pci_probe() will return - ENODEV immediately. It is module_init(ehci_pci_init) in ehci-pci.c, so ehci_pci_init will always be called. Oops, yes, you're right. I was thinking of ehci_pci_setup, sorry. ehci_pci_init will indeed get called. But it won't overwrite anything in ci_hdrc_host_init. The only thing it touches is its own private ehci_pci_hc_driver structure. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1] ehci-pci: disable for Intel MID platforms
How i386 platform chooses which driver is suitable for device? The ehci_pci_init may overwrite what ci_hdrc_host_init does if it runs later? There's nothing special about the i386 platform. _All_ platforms that support PCI use the same matching code to select drivers. (This is true for other buses too, not just for PCI. For example, all platforms use the same matching code for the USB bus.) The device core iterates through all the drivers that are registered on the PCI bus. When it finds a driver that matches the device ID, it calls the driver's probe routine. If the probe routine returns 0 then the core stops iterating; otherwise it keeps iterating through the list of drivers. So in this case it's more or less random. Whichever driver gets registered on the PCI bus first is the one that will be probed first. But with Andy's patch, the ehci-pci driver won't interfere with the ci_hdrc_host driver, even if ehci-pci gets probed first. In fact, ehci_pci_init() will never be called, because ehci_pci_probe() will return - ENODEV immediately. It is module_init(ehci_pci_init) in ehci-pci.c, so ehci_pci_init will always be called. Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Mon, 2 Feb 2015, Peter Chen wrote: Let's look v2 patch, it bypasses probe at ehci-pci.c, then why ehci_pci_init is still needed to call? The chipidea driver has already done the same thing in ehci_pci_init. You're right; ehci_pci_init isn't needed. But there's no way to eliminate it and still have a universal kernel build. Does the pci id can pass from platform code/table? I don't understand the question. How i386 platform chooses which driver is suitable for device? The ehci_pci_init may overwrite what ci_hdrc_host_init does if it runs later? There's nothing special about the i386 platform. _All_ platforms that support PCI use the same matching code to select drivers. (This is true for other buses too, not just for PCI. For example, all platforms use the same matching code for the USB bus.) The device core iterates through all the drivers that are registered on the PCI bus. When it finds a driver that matches the device ID, it calls the driver's probe routine. If the probe routine returns 0 then the core stops iterating; otherwise it keeps iterating through the list of drivers. So in this case it's more or less random. Whichever driver gets registered on the PCI bus first is the one that will be probed first. But with Andy's patch, the ehci-pci driver won't interfere with the ci_hdrc_host driver, even if ehci-pci gets probed first. In fact, ehci_pci_init() will never be called, because ehci_pci_probe() will return -ENODEV immediately. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Fri, Jan 30, 2015 at 10:49 PM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 30 Jan 2015, Peter Chen wrote: The chipidea driver is structured in an odd way. It looks like the PCI device combines a host controller and a device controller (and maybe even an OTG controller) into a single device. Any problems for that? No, but it is odd and it requires some code to be duplicated. That's why the chipidea driver has to duplicate ehci-pci.c and register various platform devices. If ehci-pci were allowed to bind to the device then the gadget controller (and OTG controller?) would be unusable, because ehci-pci doesn't know how to use them. If the chipidea has host function, it doesn't need any drivers at usb/host/ehci-*.c, the v1 patch for this thread, it just doesn't compile ehci-pci.c, and it should work too. Yes, it will work. But if you go back to the second message in this thread (http://marc.info/?l=linux-usbm=142229289226237w=2) you will see why that patch isn't a good idea: It means that the Intel MID platform cannot use a universal kernel build -- that is, one where every driver is included. Let's look v2 patch, it bypasses probe at ehci-pci.c, then why ehci_pci_init is still needed to call? The chipidea driver has already done the same thing in ehci_pci_init. You're right; ehci_pci_init isn't needed. But there's no way to eliminate it and still have a universal kernel build. Does the pci id can pass from platform code/table? How i386 platform chooses which driver is suitable for device? The ehci_pci_init may overwrite what ci_hdrc_host_init does if it runs later? -- BR, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Fri, 30 Jan 2015, Peter Chen wrote: The chipidea driver is structured in an odd way. It looks like the PCI device combines a host controller and a device controller (and maybe even an OTG controller) into a single device. Any problems for that? No, but it is odd and it requires some code to be duplicated. That's why the chipidea driver has to duplicate ehci-pci.c and register various platform devices. If ehci-pci were allowed to bind to the device then the gadget controller (and OTG controller?) would be unusable, because ehci-pci doesn't know how to use them. If the chipidea has host function, it doesn't need any drivers at usb/host/ehci-*.c, the v1 patch for this thread, it just doesn't compile ehci-pci.c, and it should work too. Yes, it will work. But if you go back to the second message in this thread (http://marc.info/?l=linux-usbm=142229289226237w=2) you will see why that patch isn't a good idea: It means that the Intel MID platform cannot use a universal kernel build -- that is, one where every driver is included. Let's look v2 patch, it bypasses probe at ehci-pci.c, then why ehci_pci_init is still needed to call? The chipidea driver has already done the same thing in ehci_pci_init. You're right; ehci_pci_init isn't needed. But there's no way to eliminate it and still have a universal kernel build. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Thu, 29 Jan 2015, Peter Chen wrote: Then, it is strange. Do we need even two glue layer drivers for pci device? Look at usb/chipidea/ci_hdrc_pci.c it has pci_register_driver, and its host driver will call ehci_init_driver, it is definitely duplicated with usb/host/ehci-pci.c. ehci-pci.c is a driver for a USB Host Controller, whereas ci_hdrc_pci.c is a driver for a USB Device Controller. In fact, it is not, ci_hdrc_pci is the pci glue layer for chipidea driver. I am just wonder andy's v2 change is suitable or not, the right way should not call ehci_pci_init at all. The chipidea driver is structured in an odd way. It looks like the PCI device combines a host controller and a device controller (and maybe even an OTG controller) into a single device. That's why the chipidea driver has to duplicate ehci-pci.c and register various platform devices. If ehci-pci were allowed to bind to the device then the gadget controller (and OTG controller?) would be unusable, because ehci-pci doesn't know how to use them. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Thu, Jan 29, 2015 at 10:44:48AM -0500, Alan Stern wrote: On Thu, 29 Jan 2015, Peter Chen wrote: Then, it is strange. Do we need even two glue layer drivers for pci device? Look at usb/chipidea/ci_hdrc_pci.c it has pci_register_driver, and its host driver will call ehci_init_driver, it is definitely duplicated with usb/host/ehci-pci.c. ehci-pci.c is a driver for a USB Host Controller, whereas ci_hdrc_pci.c is a driver for a USB Device Controller. In fact, it is not, ci_hdrc_pci is the pci glue layer for chipidea driver. I am just wonder andy's v2 change is suitable or not, the right way should not call ehci_pci_init at all. The chipidea driver is structured in an odd way. It looks like the PCI device combines a host controller and a device controller (and maybe even an OTG controller) into a single device. Any problems for that? That's why the chipidea driver has to duplicate ehci-pci.c and register various platform devices. If ehci-pci were allowed to bind to the device then the gadget controller (and OTG controller?) would be unusable, because ehci-pci doesn't know how to use them. If the chipidea has host function, it doesn't need any drivers at usb/host/ehci-*.c, the v1 patch for this thread, it just doesn't compile ehci-pci.c, and it should work too. Let's look v2 patch, it bypasses probe at ehci-pci.c, then why ehci_pci_init is still needed to call? The chipidea driver has already done the same thing in ehci_pci_init. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
Peter Chen peter.c...@freescale.com writes: On Tue, Jan 27, 2015 at 11:21:56AM -0500, Alan Stern wrote: On Tue, 27 Jan 2015, Peter Chen wrote: Please fix this properly. I don't know the right way to fix this. Alan, has you any suggestion? It depends. How did the code before the adfa79d1c06a commit avoid this problem? By simply not enabling CONFIG_USB_EHCI_HCD? Hi Andy, Would you define pci_id at ci_hdrc_pci.c (instead of ehci-pci.c) at your platform code/table to fix this problem? I am not familiar with pci, but it works at other platforms, like ARM. You can't remove the definition of pci_id in ehci-pci.c; if you did then ehci-pci wouldn't bind to PCI controllers. It may turn out that the best way to fix this is to include a quirk in ehci-pci.c to prevent it from binding to the Intel MID on-board EHCI controller. Alan Stern Then, it is strange. Do we need even two glue layer drivers for pci device? Look at usb/chipidea/ci_hdrc_pci.c it has pci_register_driver, and its host driver will call ehci_init_driver, it is definitely duplicated with usb/host/ehci-pci.c. No, what ci_hdrc_pci does is a superset of what ehci_pci does, being a dual role controller and all that. One register window and one interrupt is shared between a device controller, a host controller and an otg controller. Regards, -- Alex -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Wed, 28 Jan 2015, Peter Chen wrote: Hi Andy, Would you define pci_id at ci_hdrc_pci.c (instead of ehci-pci.c) at your platform code/table to fix this problem? I am not familiar with pci, but it works at other platforms, like ARM. You can't remove the definition of pci_id in ehci-pci.c; if you did then ehci-pci wouldn't bind to PCI controllers. It may turn out that the best way to fix this is to include a quirk in ehci-pci.c to prevent it from binding to the Intel MID on-board EHCI controller. Alan Stern Then, it is strange. Do we need even two glue layer drivers for pci device? Look at usb/chipidea/ci_hdrc_pci.c it has pci_register_driver, and its host driver will call ehci_init_driver, it is definitely duplicated with usb/host/ehci-pci.c. ehci-pci.c is a driver for a USB Host Controller, whereas ci_hdrc_pci.c is a driver for a USB Device Controller. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Wed, Jan 28, 2015 at 10:42:53AM -0500, Alan Stern wrote: On Wed, 28 Jan 2015, Peter Chen wrote: Hi Andy, Would you define pci_id at ci_hdrc_pci.c (instead of ehci-pci.c) at your platform code/table to fix this problem? I am not familiar with pci, but it works at other platforms, like ARM. You can't remove the definition of pci_id in ehci-pci.c; if you did then ehci-pci wouldn't bind to PCI controllers. It may turn out that the best way to fix this is to include a quirk in ehci-pci.c to prevent it from binding to the Intel MID on-board EHCI controller. Alan Stern Then, it is strange. Do we need even two glue layer drivers for pci device? Look at usb/chipidea/ci_hdrc_pci.c it has pci_register_driver, and its host driver will call ehci_init_driver, it is definitely duplicated with usb/host/ehci-pci.c. ehci-pci.c is a driver for a USB Host Controller, whereas ci_hdrc_pci.c is a driver for a USB Device Controller. In fact, it is not, ci_hdrc_pci is the pci glue layer for chipidea driver. I am just wonder andy's v2 change is suitable or not, the right way should not call ehci_pci_init at all. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Tue, 27 Jan 2015, Peter Chen wrote: Please fix this properly. I don't know the right way to fix this. Alan, has you any suggestion? It depends. How did the code before the adfa79d1c06a commit avoid this problem? By simply not enabling CONFIG_USB_EHCI_HCD? Hi Andy, Would you define pci_id at ci_hdrc_pci.c (instead of ehci-pci.c) at your platform code/table to fix this problem? I am not familiar with pci, but it works at other platforms, like ARM. You can't remove the definition of pci_id in ehci-pci.c; if you did then ehci-pci wouldn't bind to PCI controllers. It may turn out that the best way to fix this is to include a quirk in ehci-pci.c to prevent it from binding to the Intel MID on-board EHCI controller. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Tue, 27 Jan 2015, Andy Shevchenko wrote: On Tue, 2015-01-27 at 11:21 -0500, Alan Stern wrote: On Tue, 27 Jan 2015, Peter Chen wrote: Please fix this properly. I don't know the right way to fix this. Alan, has you any suggestion? It depends. How did the code before the adfa79d1c06a commit avoid this problem? By simply not enabling CONFIG_USB_EHCI_HCD? Hi Andy, Would you define pci_id at ci_hdrc_pci.c (instead of ehci-pci.c) at your platform code/table to fix this problem? I am not familiar with pci, but it works at other platforms, like ARM. You can't remove the definition of pci_id in ehci-pci.c; if you did then ehci-pci wouldn't bind to PCI controllers. It may turn out that the best way to fix this is to include a quirk in ehci-pci.c to prevent it from binding to the Intel MID on-board EHCI controller. That was one of my thoughts. I would do that way. Then go ahead and write a patch to do this. Regarding to the initial issue, it was along time ago, and I totally forgot what we do to make it working. Thus, it possible that the split does nothing with the problem. If you don't know that the adfa79d1c06a commit caused the problem then your Changelog shouldn't claim that it did. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Tue, Jan 27, 2015 at 11:21:56AM -0500, Alan Stern wrote: On Tue, 27 Jan 2015, Peter Chen wrote: Please fix this properly. I don't know the right way to fix this. Alan, has you any suggestion? It depends. How did the code before the adfa79d1c06a commit avoid this problem? By simply not enabling CONFIG_USB_EHCI_HCD? Hi Andy, Would you define pci_id at ci_hdrc_pci.c (instead of ehci-pci.c) at your platform code/table to fix this problem? I am not familiar with pci, but it works at other platforms, like ARM. You can't remove the definition of pci_id in ehci-pci.c; if you did then ehci-pci wouldn't bind to PCI controllers. It may turn out that the best way to fix this is to include a quirk in ehci-pci.c to prevent it from binding to the Intel MID on-board EHCI controller. Alan Stern Then, it is strange. Do we need even two glue layer drivers for pci device? Look at usb/chipidea/ci_hdrc_pci.c it has pci_register_driver, and its host driver will call ehci_init_driver, it is definitely duplicated with usb/host/ehci-pci.c. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Mon, Jan 26, 2015 at 07:10:42PM +0200, Andy Shevchenko wrote: On some Intel MID platforms the ChipIdea USB controller is used. The EHCI PCI is in conflict with the proper driver. The patch makes a quick fix to get Intel Medfield platforms work back. One would make a proper patch to address the issue. Who is one? You? Someone else? Fixes: adfa79d1c06a (USB: EHCI: make ehci-pci a separate driver) Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/usb/host/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index fafc628..32d735a 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -112,7 +112,7 @@ if USB_EHCI_HCD config USB_EHCI_PCI tristate - depends on PCI + depends on PCI !X86_INTEL_MID You just broke making a universal kernel build for your platform possible, making distro developers very upset with you. Please fix this properly. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Mon, 2015-01-26 at 09:21 -0800, Greg KH wrote: On Mon, Jan 26, 2015 at 07:10:42PM +0200, Andy Shevchenko wrote: On some Intel MID platforms the ChipIdea USB controller is used. The EHCI PCI is in conflict with the proper driver. The patch makes a quick fix to get Intel Medfield platforms work back. One would make a proper patch to address the issue. Who is one? You? Someone else? Not me. Fixes: adfa79d1c06a (USB: EHCI: make ehci-pci a separate driver) Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/usb/host/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index fafc628..32d735a 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -112,7 +112,7 @@ if USB_EHCI_HCD config USB_EHCI_PCI tristate - depends on PCI + depends on PCI !X86_INTEL_MID You just broke making a universal kernel build for your platform possible, making distro developers very upset with you. I agree, though current kernel build doesn't work on the Intel MID anyway (I mean USB support). The mentioned commit broke it and seems no-one cared until now. Please fix this properly. I don't know the right way to fix this. Alan, has you any suggestion? -- Andy Shevchenko andriy.shevche...@intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Mon, 26 Jan 2015, Andy Shevchenko wrote: On Mon, 2015-01-26 at 09:21 -0800, Greg KH wrote: On Mon, Jan 26, 2015 at 07:10:42PM +0200, Andy Shevchenko wrote: On some Intel MID platforms the ChipIdea USB controller is used. The EHCI PCI is in conflict with the proper driver. The patch makes a quick fix to get Intel Medfield platforms work back. One would make a proper patch to address the issue. Who is one? You? Someone else? Not me. Fixes: adfa79d1c06a (USB: EHCI: make ehci-pci a separate driver) Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/usb/host/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index fafc628..32d735a 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -112,7 +112,7 @@ if USB_EHCI_HCD config USB_EHCI_PCI tristate - depends on PCI + depends on PCI !X86_INTEL_MID You just broke making a universal kernel build for your platform possible, making distro developers very upset with you. I agree, though current kernel build doesn't work on the Intel MID anyway (I mean USB support). The mentioned commit broke it and seems no-one cared until now. Please fix this properly. I don't know the right way to fix this. Alan, has you any suggestion? It depends. How did the code before the adfa79d1c06a commit avoid this problem? By simply not enabling CONFIG_USB_EHCI_HCD? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Mon, Jan 26, 2015 at 01:23:47PM -0500, Alan Stern wrote: On Mon, 26 Jan 2015, Andy Shevchenko wrote: On Mon, 2015-01-26 at 09:21 -0800, Greg KH wrote: On Mon, Jan 26, 2015 at 07:10:42PM +0200, Andy Shevchenko wrote: On some Intel MID platforms the ChipIdea USB controller is used. The EHCI PCI is in conflict with the proper driver. The patch makes a quick fix to get Intel Medfield platforms work back. One would make a proper patch to address the issue. Who is one? You? Someone else? Not me. Fixes: adfa79d1c06a (USB: EHCI: make ehci-pci a separate driver) Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/usb/host/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index fafc628..32d735a 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -112,7 +112,7 @@ if USB_EHCI_HCD config USB_EHCI_PCI tristate - depends on PCI + depends on PCI !X86_INTEL_MID You just broke making a universal kernel build for your platform possible, making distro developers very upset with you. I agree, though current kernel build doesn't work on the Intel MID anyway (I mean USB support). The mentioned commit broke it and seems no-one cared until now. Please fix this properly. I don't know the right way to fix this. Alan, has you any suggestion? It depends. How did the code before the adfa79d1c06a commit avoid this problem? By simply not enabling CONFIG_USB_EHCI_HCD? Hi Andy, Would you define pci_id at ci_hdrc_pci.c (instead of ehci-pci.c) at your platform code/table to fix this problem? I am not familiar with pci, but it works at other platforms, like ARM. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
