Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
Hi Arnd, On 3/9/2015 5:35 AM, Arnd Bergmann wrote: > On Friday 06 March 2015 10:00:34 Ray Jui wrote: >>> >> >> Although I have not tested it, but to my best knowledge there shouldn't >> be any technical issue by making the PCIe iProc driver a loadable module >> and installing the module later after the kernel finishes booting. >> >> But I wonder why I haven't seen any PCIe host driver being allowed to be >> compiled as module? Maybe there's no obvious benefit of doing that. >> People typically opt to load slave devices as module but tend to keep >> the bus or host devices compiled in. >> >> And to allow a PCI host driver to be compiled as module, some PCI >> functions need to have their symbols exported: >> >> ERROR: "pci_common_swizzle" [drivers/pci/host/pcie-iproc.ko] undefined! >> ERROR: "pci_fixup_irqs" [drivers/pci/host/pcie-iproc.ko] undefined! >> ERROR: "pci_assign_unassigned_bus_resources" >> [drivers/pci/host/pcie-iproc.ko] undefined! >> ERROR: "pci_remove_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined! >> ERROR: "pci_stop_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined! >> ERROR: "pci_create_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined! >> >> Maybe Bjorn can help to shed some light here? Should I go ahead and >> export_symbol these PCI functions and make the iProc PCI driver "tristate"? > > My best guess is that no loadable driver ever tried to use these and > we should indeed just export them. True. I can export those symbols. > > The call to pci_assign_unassigned_bus_resources could be avoided by using > pci_rescan_bus(), which would simplify the driver a little, but for > some reason, nothing else uses that, so I'm not sure about it. > > The pci_remove_root_bus/pci_stop_root_bus calls are rarely used anywhere > else. Are they functional to the point where you could unload a pci > host driver that is a loadable module? If so, that would be > wonderful. It is quite wonderful, :) I added driver remove function support and tested it out. I'm able to install/remove/install the iProc PCIe platform driver as a kernel loadable module. pci_remove_root_bus/pci_stop_root_bus works fine. See logs below. -bash-3.2# insmod pcie-iproc-pltfm.ko [ 54.058546] PCI host bridge /pcie@18012000 ranges: [ 54.064584]IO 0x2800..0x2800 -> 0x [ 54.071003] MEM 0x2000..0x23ff -> 0x2000 [ 54.330194] iproc-pcie 18012000.pcie: PCI host bridge to bus :00 [ 54.338138] pci_bus :00: root bus resource [bus 00-ff] [ 54.344983] pci_bus :00: root bus resource [io 0x-0x] [ 54.352683] pci_bus :00: root bus resource [mem 0x2000-0x23ff] [ 54.361254] iproc-pcie 18012000.pcie: link: UP [ 54.367086] PCI: bus0: Fast back to back transfers disabled [ 54.374046] pci :00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 54.400237] PCI: bus1: Fast back to back transfers disabled [ 54.407274] pci :00:00.0: BAR 8: assigned [mem 0x2000-0x200f] [ 54.415766] pci :01:00.0: BAR 1: assigned [mem 0x2000-0x2007] [ 54.424241] pci :01:00.0: BAR 6: assigned [mem 0x2008-0x200b pref] [ 54.433245] pci :01:00.0: BAR 0: assigned [mem 0x200c-0x200d] [ 54.441710] pci :01:00.0: BAR 3: assigned [mem 0x200e-0x200e3fff] [ 54.450173] pci :01:00.0: BAR 2: no space for [io size 0x0020] [ 54.457979] pci :01:00.0: BAR 2: failed to assign [io size 0x0020] [ 54.466217] pci :00:00.0: PCI bridge to [bus 01] [ 54.472404] pci :00:00.0: bridge window [mem 0x2000-0x200f] [ 54.480945] pcieport :00:00.0: enabling device (0140 -> 0142) [ 54.488767] e1000e :01:00.0: enabling device (0140 -> 0142) [ 54.496315] e1000e :01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 54.507958] e1000e :01:00.0 :01:00.0 (uninitialized): Failed to initialize MSI-X interrupts. Falling back to MSI interru. [ 54.522913] e1000e :01:00.0 :01:00.0 (uninitialized): Failed to initialize MSI interrupts. Falling back to legacy interr. [ 54.643486] e1000e :01:00.0 eth0: registered PHC clock [ 54.650379] e1000e :01:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 68:05:ca:28:19:e8 [ 54.660254] e1000e :01:00.0 eth0: Intel(R) PRO/1000 Network Connection [ 54.668834] e1000e :01:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008 -bash-3.2# rmmod pcie-iproc-pltfm [ 66.465834] e1000e :01:00.0 eth0: removed PHC -bash-3.2# insmod pcie-iproc-pltfm.ko [ 71.043195] PCI host bridge /pcie@18012000 ranges: [ 71.049235]IO 0x2800..0x2800 -> 0x [ 71.055652] MEM 0x2000..0x23ff -> 0x2000 [ 71.315192] iproc-pcie 18012000.pcie: PCI host bridge to bus :00 [ 71.323135] pci_bus :00: root bus resource [bus 00-ff] [ 71.329979] pci_bus :00: root bus resource [io 0x-0x] [ 71.337679] pci_bus :00: root bus resource [mem 0x2000-0x23ff] [ 71
Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
On Friday 06 March 2015 10:00:34 Ray Jui wrote: > > > > Although I have not tested it, but to my best knowledge there shouldn't > be any technical issue by making the PCIe iProc driver a loadable module > and installing the module later after the kernel finishes booting. > > But I wonder why I haven't seen any PCIe host driver being allowed to be > compiled as module? Maybe there's no obvious benefit of doing that. > People typically opt to load slave devices as module but tend to keep > the bus or host devices compiled in. > > And to allow a PCI host driver to be compiled as module, some PCI > functions need to have their symbols exported: > > ERROR: "pci_common_swizzle" [drivers/pci/host/pcie-iproc.ko] undefined! > ERROR: "pci_fixup_irqs" [drivers/pci/host/pcie-iproc.ko] undefined! > ERROR: "pci_assign_unassigned_bus_resources" > [drivers/pci/host/pcie-iproc.ko] undefined! > ERROR: "pci_remove_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined! > ERROR: "pci_stop_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined! > ERROR: "pci_create_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined! > > Maybe Bjorn can help to shed some light here? Should I go ahead and > export_symbol these PCI functions and make the iProc PCI driver "tristate"? My best guess is that no loadable driver ever tried to use these and we should indeed just export them. The call to pci_assign_unassigned_bus_resources could be avoided by using pci_rescan_bus(), which would simplify the driver a little, but for some reason, nothing else uses that, so I'm not sure about it. The pci_remove_root_bus/pci_stop_root_bus calls are rarely used anywhere else. Are they functional to the point where you could unload a pci host driver that is a loadable module? If so, that would be wonderful. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
Hi Dmitry,
On 3/6/2015 9:35 AM, Dmitry Torokhov wrote:
> On Fri, Mar 6, 2015 at 9:26 AM, Ray Jui wrote:
>> Hi Paul,
>>
>> On 3/6/2015 3:00 AM, Paul Bolle wrote:
>>> On Thu, 2015-03-05 at 17:01 -0800, Ray Jui wrote:
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -106,4 +106,21 @@ config PCI_VERSATILE
bool "ARM Versatile PB PCI controller"
depends on ARCH_VERSATILE
+config PCIE_IPROC
+bool "Broadcom iProc PCIe controller"
>>>
>>> bool symbol.
>>>
+help
+ This enables the iProc PCIe core controller support for Broadcom's
+ iProc family of SoCs. An appropriate bus interface driver also needs
+ to be enabled
+
+config PCIE_IPROC_PLTFM
+bool "Broadcom iProc PCIe platform bus driver"
>>>
>>> Another bool symbol.
>>>
+depends on ARCH_BCM_IPROC || COMPILE_TEST
+depends on OF
+select PCIE_IPROC
+default ARCH_BCM_IPROC
+help
+ Say Y here if you want to use the Broadcom iProc PCIe controller
+ through the generic platform bus interface
+
endmenu
>>>
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
>>>
+obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
+obj-$(CONFIG_PCIE_IPROC_PLTFM) += pcie-iproc-pltfm.o
>>>
>>> Both objectfiles will never be part of a module.
>>>
--- /dev/null
+++ b/drivers/pci/host/pcie-iproc-pltfm.c
>>>
+#include
>>>
>>> Is this needed?
>>>
+MODULE_DEVICE_TABLE(of, iproc_pcie_of_match_table);
>>>
>>> This macro will be preprocessed away, won't it?
>>>
+static struct platform_driver iproc_pcie_pltfm_driver = {
+.driver = {
+.name = "iproc-pcie",
+.of_match_table = of_match_ptr(iproc_pcie_of_match_table),
+.suppress_bind_attrs = true,
+},
+.probe = iproc_pcie_pltfm_probe,
+};
+module_platform_driver(iproc_pcie_pltfm_driver);
>>>
>>> Perhaps it's clearer to have make this a call to
>>> platform_driver_register(), put that in a wrapper function, and invoke
>>> that wrapper function through device_initcall() or similar. I haven't
>>> actually tested that, so the details could be off.
>>>
+MODULE_AUTHOR("Ray Jui ");
+MODULE_DESCRIPTION("Broadcom iPROC PCIe platform driver");
+MODULE_LICENSE("GPL v2");
>>>
>>> And these three macros will, effectively, be preprocessed away.
>>>
--- /dev/null
+++ b/drivers/pci/host/pcie-iproc.c
>>>
+#include
>>>
>>> See above.
>>>
+MODULE_AUTHOR("Ray Jui ");
+MODULE_DESCRIPTION("Broadcom iPROC PCIe common driver");
+MODULE_LICENSE("GPL v2");
>>>
>>> Ditto.
>>>
>>>
>>> Paul Bolle
>>>
>>
>> So every single PCIe host driver under drivers/pci/host/* has their
>> config flag of "bool" type, and all of them except pci-keystone-dw.c
>> have these MODULE based macros in their driver. While I agree with you
>> that these macros will preprocessed away while compiled as statically
>> linked in, I thought it's a convention to have these macros in the
>> driver. At least it provides information on the author, driver
>> description, and license (although one can also argue you can find all
>> of those info from the maintainer list, Kconfig, and license header).
>>
>> Would you be able to sort this out with a developer or subsystem
>> maintainer who is familiar with this matter and let us know what is the
>> convention for MODULE macros usage in a driver when its config flag is
>> set to "bool" instead of "tristate"?
>
> Is there a technical reason why the driver can't be a module? We can
> suppress module unloading if unloading properly is hard (i see you
> already suppress unbinding via sysfs), but we should be able to load
> it after kernel booted, no?
>
> Thanks,
> Dmitry
>
Although I have not tested it, but to my best knowledge there shouldn't
be any technical issue by making the PCIe iProc driver a loadable module
and installing the module later after the kernel finishes booting.
But I wonder why I haven't seen any PCIe host driver being allowed to be
compiled as module? Maybe there's no obvious benefit of doing that.
People typically opt to load slave devices as module but tend to keep
the bus or host devices compiled in.
And to allow a PCI host driver to be compiled as module, some PCI
functions need to have their symbols exported:
ERROR: "pci_common_swizzle" [drivers/pci/host/pcie-iproc.ko] undefined!
ERROR: "pci_fixup_irqs" [drivers/pci/host/pcie-iproc.ko] undefined!
ERROR: "pci_assign_unassigned_bus_resources"
[drivers/pci/host/pcie-iproc.ko] undefined!
ERROR: "pci_remove_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
ERROR: "pci_stop_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
ERROR: "pci_create_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
Maybe Bjorn can help to shed some light here? Should I go ahead and
export_symbol these PCI functions and make the iPro
Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
On Fri, Mar 6, 2015 at 9:26 AM, Ray Jui wrote:
> Hi Paul,
>
> On 3/6/2015 3:00 AM, Paul Bolle wrote:
>> On Thu, 2015-03-05 at 17:01 -0800, Ray Jui wrote:
>>> --- a/drivers/pci/host/Kconfig
>>> +++ b/drivers/pci/host/Kconfig
>>> @@ -106,4 +106,21 @@ config PCI_VERSATILE
>>> bool "ARM Versatile PB PCI controller"
>>> depends on ARCH_VERSATILE
>>>
>>> +config PCIE_IPROC
>>> +bool "Broadcom iProc PCIe controller"
>>
>> bool symbol.
>>
>>> +help
>>> + This enables the iProc PCIe core controller support for Broadcom's
>>> + iProc family of SoCs. An appropriate bus interface driver also needs
>>> + to be enabled
>>> +
>>> +config PCIE_IPROC_PLTFM
>>> +bool "Broadcom iProc PCIe platform bus driver"
>>
>> Another bool symbol.
>>
>>> +depends on ARCH_BCM_IPROC || COMPILE_TEST
>>> +depends on OF
>>> +select PCIE_IPROC
>>> +default ARCH_BCM_IPROC
>>> +help
>>> + Say Y here if you want to use the Broadcom iProc PCIe controller
>>> + through the generic platform bus interface
>>> +
>>> endmenu
>>
>>> --- a/drivers/pci/host/Makefile
>>> +++ b/drivers/pci/host/Makefile
>>
>>> +obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>>> +obj-$(CONFIG_PCIE_IPROC_PLTFM) += pcie-iproc-pltfm.o
>>
>> Both objectfiles will never be part of a module.
>>
>>> --- /dev/null
>>> +++ b/drivers/pci/host/pcie-iproc-pltfm.c
>>
>>> +#include
>>
>> Is this needed?
>>
>>> +MODULE_DEVICE_TABLE(of, iproc_pcie_of_match_table);
>>
>> This macro will be preprocessed away, won't it?
>>
>>> +static struct platform_driver iproc_pcie_pltfm_driver = {
>>> +.driver = {
>>> +.name = "iproc-pcie",
>>> +.of_match_table = of_match_ptr(iproc_pcie_of_match_table),
>>> +.suppress_bind_attrs = true,
>>> +},
>>> +.probe = iproc_pcie_pltfm_probe,
>>> +};
>>> +module_platform_driver(iproc_pcie_pltfm_driver);
>>
>> Perhaps it's clearer to have make this a call to
>> platform_driver_register(), put that in a wrapper function, and invoke
>> that wrapper function through device_initcall() or similar. I haven't
>> actually tested that, so the details could be off.
>>
>>> +MODULE_AUTHOR("Ray Jui ");
>>> +MODULE_DESCRIPTION("Broadcom iPROC PCIe platform driver");
>>> +MODULE_LICENSE("GPL v2");
>>
>> And these three macros will, effectively, be preprocessed away.
>>
>>> --- /dev/null
>>> +++ b/drivers/pci/host/pcie-iproc.c
>>
>>> +#include
>>
>> See above.
>>
>>> +MODULE_AUTHOR("Ray Jui ");
>>> +MODULE_DESCRIPTION("Broadcom iPROC PCIe common driver");
>>> +MODULE_LICENSE("GPL v2");
>>
>> Ditto.
>>
>>
>> Paul Bolle
>>
>
> So every single PCIe host driver under drivers/pci/host/* has their
> config flag of "bool" type, and all of them except pci-keystone-dw.c
> have these MODULE based macros in their driver. While I agree with you
> that these macros will preprocessed away while compiled as statically
> linked in, I thought it's a convention to have these macros in the
> driver. At least it provides information on the author, driver
> description, and license (although one can also argue you can find all
> of those info from the maintainer list, Kconfig, and license header).
>
> Would you be able to sort this out with a developer or subsystem
> maintainer who is familiar with this matter and let us know what is the
> convention for MODULE macros usage in a driver when its config flag is
> set to "bool" instead of "tristate"?
Is there a technical reason why the driver can't be a module? We can
suppress module unloading if unloading properly is hard (i see you
already suppress unbinding via sysfs), but we should be able to load
it after kernel booted, no?
Thanks,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
Hi Paul,
On 3/6/2015 3:00 AM, Paul Bolle wrote:
> On Thu, 2015-03-05 at 17:01 -0800, Ray Jui wrote:
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -106,4 +106,21 @@ config PCI_VERSATILE
>> bool "ARM Versatile PB PCI controller"
>> depends on ARCH_VERSATILE
>>
>> +config PCIE_IPROC
>> +bool "Broadcom iProc PCIe controller"
>
> bool symbol.
>
>> +help
>> + This enables the iProc PCIe core controller support for Broadcom's
>> + iProc family of SoCs. An appropriate bus interface driver also needs
>> + to be enabled
>> +
>> +config PCIE_IPROC_PLTFM
>> +bool "Broadcom iProc PCIe platform bus driver"
>
> Another bool symbol.
>
>> +depends on ARCH_BCM_IPROC || COMPILE_TEST
>> +depends on OF
>> +select PCIE_IPROC
>> +default ARCH_BCM_IPROC
>> +help
>> + Say Y here if you want to use the Broadcom iProc PCIe controller
>> + through the generic platform bus interface
>> +
>> endmenu
>
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>
>> +obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>> +obj-$(CONFIG_PCIE_IPROC_PLTFM) += pcie-iproc-pltfm.o
>
> Both objectfiles will never be part of a module.
>
>> --- /dev/null
>> +++ b/drivers/pci/host/pcie-iproc-pltfm.c
>
>> +#include
>
> Is this needed?
>
>> +MODULE_DEVICE_TABLE(of, iproc_pcie_of_match_table);
>
> This macro will be preprocessed away, won't it?
>
>> +static struct platform_driver iproc_pcie_pltfm_driver = {
>> +.driver = {
>> +.name = "iproc-pcie",
>> +.of_match_table = of_match_ptr(iproc_pcie_of_match_table),
>> +.suppress_bind_attrs = true,
>> +},
>> +.probe = iproc_pcie_pltfm_probe,
>> +};
>> +module_platform_driver(iproc_pcie_pltfm_driver);
>
> Perhaps it's clearer to have make this a call to
> platform_driver_register(), put that in a wrapper function, and invoke
> that wrapper function through device_initcall() or similar. I haven't
> actually tested that, so the details could be off.
>
>> +MODULE_AUTHOR("Ray Jui ");
>> +MODULE_DESCRIPTION("Broadcom iPROC PCIe platform driver");
>> +MODULE_LICENSE("GPL v2");
>
> And these three macros will, effectively, be preprocessed away.
>
>> --- /dev/null
>> +++ b/drivers/pci/host/pcie-iproc.c
>
>> +#include
>
> See above.
>
>> +MODULE_AUTHOR("Ray Jui ");
>> +MODULE_DESCRIPTION("Broadcom iPROC PCIe common driver");
>> +MODULE_LICENSE("GPL v2");
>
> Ditto.
>
>
> Paul Bolle
>
So every single PCIe host driver under drivers/pci/host/* has their
config flag of "bool" type, and all of them except pci-keystone-dw.c
have these MODULE based macros in their driver. While I agree with you
that these macros will preprocessed away while compiled as statically
linked in, I thought it's a convention to have these macros in the
driver. At least it provides information on the author, driver
description, and license (although one can also argue you can find all
of those info from the maintainer list, Kconfig, and license header).
Would you be able to sort this out with a developer or subsystem
maintainer who is familiar with this matter and let us know what is the
convention for MODULE macros usage in a driver when its config flag is
set to "bool" instead of "tristate"?
Thanks,
Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
On Thu, 2015-03-05 at 17:01 -0800, Ray Jui wrote:
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -106,4 +106,21 @@ config PCI_VERSATILE
> bool "ARM Versatile PB PCI controller"
> depends on ARCH_VERSATILE
>
> +config PCIE_IPROC
> + bool "Broadcom iProc PCIe controller"
bool symbol.
> + help
> + This enables the iProc PCIe core controller support for Broadcom's
> + iProc family of SoCs. An appropriate bus interface driver also needs
> + to be enabled
> +
> +config PCIE_IPROC_PLTFM
> + bool "Broadcom iProc PCIe platform bus driver"
Another bool symbol.
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + depends on OF
> + select PCIE_IPROC
> + default ARCH_BCM_IPROC
> + help
> + Say Y here if you want to use the Broadcom iProc PCIe controller
> + through the generic platform bus interface
> +
> endmenu
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> +obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
> +obj-$(CONFIG_PCIE_IPROC_PLTFM) += pcie-iproc-pltfm.o
Both objectfiles will never be part of a module.
> --- /dev/null
> +++ b/drivers/pci/host/pcie-iproc-pltfm.c
> +#include
Is this needed?
> +MODULE_DEVICE_TABLE(of, iproc_pcie_of_match_table);
This macro will be preprocessed away, won't it?
> +static struct platform_driver iproc_pcie_pltfm_driver = {
> + .driver = {
> + .name = "iproc-pcie",
> + .of_match_table = of_match_ptr(iproc_pcie_of_match_table),
> + .suppress_bind_attrs = true,
> + },
> + .probe = iproc_pcie_pltfm_probe,
> +};
> +module_platform_driver(iproc_pcie_pltfm_driver);
Perhaps it's clearer to have make this a call to
platform_driver_register(), put that in a wrapper function, and invoke
that wrapper function through device_initcall() or similar. I haven't
actually tested that, so the details could be off.
> +MODULE_AUTHOR("Ray Jui ");
> +MODULE_DESCRIPTION("Broadcom iPROC PCIe platform driver");
> +MODULE_LICENSE("GPL v2");
And these three macros will, effectively, be preprocessed away.
> --- /dev/null
> +++ b/drivers/pci/host/pcie-iproc.c
> +#include
See above.
> +MODULE_AUTHOR("Ray Jui ");
> +MODULE_DESCRIPTION("Broadcom iPROC PCIe common driver");
> +MODULE_LICENSE("GPL v2");
Ditto.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
