[PATCH] usb: chipidea: core: Add missing module owner field
Signed-off-by: Alexander Shiyan
---
drivers/usb/chipidea/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index ca6831c..8c49220 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -680,6 +680,7 @@ static struct platform_driver ci_hdrc_driver = {
.remove = ci_hdrc_remove,
.driver = {
.name = "ci_hdrc",
+ .owner = THIS_MODULE,
},
};
--
1.8.3.2
--
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: USB OTG support on mx27pdk
Sun, 20 Apr 2014 00:48:28 + от Peter Chen :
> > -Original Message-
> > From: Fabio Estevam [mailto:feste...@gmail.com]
> > Sent: Sunday, April 20, 2014 1:10 AM
> > To: Chen Peter-B29397
> > Cc: Michael Grzeschik; Alexander Shiyan; linux-arm-
> > ker...@lists.infradead.org; linux-usb@vger.kernel.org; Sascha Hauer;
> > chris.ru...@gtsys.com.hk; Guo Shawn-R65073
> > Subject: Re: USB OTG support on mx27pdk
> >
> > On Sat, Apr 19, 2014 at 4:32 AM, Peter Chen
> > wrote:
> > > The below patch is intended to fix above issues for all platforms,
> > > I have tested it at imx6 platform, if possible, have a test at
> > imx25/imx27
> > > please.
> >
> > I don't see any patch below, but anyway I have managed to fix the
> > issue on mx27 at dts level.
> >
>
> https://github.com/hzpeterchen/linux-usb/commit/c1f42ea27ed3f5d988c63da7849d2e6b445b4fbc
>
> Your problem is different with sasche's, which hang the system due to
> no phy clk. The chris's patch should not cause the oops.
For me, nothing has changed.
The driver works on i.MX27 PCM970 RDK with the patch as well as without it.
---
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [PATCH 4/8] ARM: mvebu: Add USB3 UTMI support
Hi, On Fri, Apr 18, 2014 at 12:22:39PM +0200, Gregory CLEMENT wrote: > The usb3-utmi registers allow to configure the internal USB PHY of the > Armada 380/385 SoCs. A small initialization is needed to be able to use > the USB3 ports. > > Signed-off-by: Gregory CLEMENT looks like this should be a generic drivers/phy/phy-utmi.c driver -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/8] xhci-platform: Add a new controller using xhci: Armada 38x
On Fri, Apr 18, 2014 at 12:22:38PM +0200, Gregory CLEMENT wrote: > Extend the compatible string list with xhci-armada-380. It is used to > describe xhci controller which is in the Armada 38x SoCs. > > Signed-off-by: Gregory CLEMENT > --- > Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt > b/Documentation/devicetree/bindings/usb/usb-xhci.txt > index 90f8f607d125..c49c14037afe 100644 > --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt > +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt > @@ -1,7 +1,8 @@ > USB xHCI controllers > > Required properties: > - - compatible: should be "generic-xhci" (deprecated: "xhci-platform"). > + - compatible: should be on of "generic-xhci", should be "one" of. > +"marvell,xhci-armada-380" (deprecated: "xhci-platform"). and this gives me a better idea, instead of using the quirk I suggested before, match against this compatible: if (of_device_is_compatible(dev, "marvell,xhci-armada-380") xhci_marvel_mbus_init_quirk(dev); -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/8] usb: host: xhci-plat: Add support for the Armada 38x glue code
On Fri, Apr 18, 2014 at 12:22:37PM +0200, Gregory CLEMENT wrote:
> For the armada 38x SoCs which come with an xhci controller, specific
> initialization must be done during probe, especially in relation with
> the MBus windows initialization. This patch adds this support.
>
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/usb/host/Kconfig | 7 +++
> drivers/usb/host/Makefile | 1 +
> drivers/usb/host/xhci-mvebu.c | 105
> ++
> drivers/usb/host/xhci-mvebu.h | 21 +
> drivers/usb/host/xhci-plat.c | 10
> 5 files changed, 144 insertions(+)
> create mode 100644 drivers/usb/host/xhci-mvebu.c
> create mode 100644 drivers/usb/host/xhci-mvebu.h
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 3d9e54062d62..e70943fac4a1 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -29,6 +29,13 @@ if USB_XHCI_HCD
> config USB_XHCI_PLATFORM
> tristate
>
> +config USB_XHCI_MVEBU
> + tristate "xHCI support for Marvell Armada 38x"
> + select USB_XHCI_PLATFORM
> + ---help---
> + Say 'Y' to enable the support for the xHCI host controller
> + found in Marvell Armada 38x ARM SOCs.
> +
> endif # USB_XHCI_HCD
>
> config USB_EHCI_HCD
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 7530468c9a4f..7a8db7f7dc01 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -19,6 +19,7 @@ xhci-hcd-$(CONFIG_PCI) += xhci-pci.o
>
> ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
> xhci-hcd-y += xhci-plat.o
> + xhci-hcd-$(CONFIG_USB_XHCI_MVEBU) += xhci-mvebu.o
> endif
>
> obj-$(CONFIG_USB_WHCI_HCD) += whci/
> diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
> new file mode 100644
> index ..dc9c7648ab65
> --- /dev/null
> +++ b/drivers/usb/host/xhci-mvebu.c
> @@ -0,0 +1,105 @@
> +/*
> + * Copyright (C) 2014 Marvell
> + * Author: Gregory CLEMENT
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "xhci.h"
> +
> +#define USB3_MAX_WINDOWS 4
> +#define USB3_WIN_CTRL(w) (0x0 + ((w) * 8))
> +#define USB3_WIN_BASE(w) (0x4 + ((w) * 8))
> +
> +static void __init mv_usb3_conf_mbus_windows(void __iomem *base,
> + const struct mbus_dram_target_info *dram)
> +{
> + int win;
> +
> + /* Clear all existing windows */
> + for (win = 0; win < USB3_MAX_WINDOWS; win++) {
> + writel(0, base + USB3_WIN_CTRL(win));
> + writel(0, base + USB3_WIN_BASE(win));
> + }
> +
> + /* Program each DRAM CS in a seperate window */
> + for (win = 0; win < dram->num_cs; win++) {
> + const struct mbus_dram_window *cs = dram->cs + win;
> +
> + writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
> +(dram->mbus_dram_target_id << 4) | 1,
> +base + USB3_WIN_CTRL(win));
> +
> + writel((cs->base & 0x), base + USB3_WIN_BASE(win));
> + }
> +}
> +
> +int xhci_mvebu_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + void __iomem*base;
> + const struct mbus_dram_target_info *dram;
> + int ret;
> + struct clk *clk;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!res)
> + return -ENODEV;
> +
> + /*
> + * We don't use devm_ioremap() because this mapping should
> + * only exists for the duration of this probe function.
> + */
> + base = ioremap(res->start, resource_size(res));
> + if (!base)
> + return -ENODEV;
> +
> + clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(clk)) {
> + iounmap(base);
> + return PTR_ERR(clk);
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret < 0) {
> + iounmap(base);
> + return ret;
> + }
it's best to teach generic xhci-plat about clocks, just make it
optional.
> + dram = mv_mbus_dram_info();
> + mv_usb3_conf_mbus_windows(base, dram);
> +
> + /*
> + * This memory area was only needed to configure the MBus
> + * windows, and is therefore no longer useful.
> + */
> + iounmap(base);
so I suppose MBus is the Marvell interconnect, am I right ? Wouldn't you
be duplicating this sort of initialization for most drivers ?
> + ret = common_xhci_plat_probe(pdev, clk);
I would much rather reverse this, instead of exposing xhci-plat's probe,
turn this mbus initialization into a quirk which will ioremap the extra
resource, initialize some registers and iounmap it.
> diff --git a/drivers/usb/host/xhci-mvebu.h b/drivers/usb/host/xhci-mvebu.h
> new file mode
Re: [PATCH 1/8] usb: host: xhci-plat: Allow to register glue code using the device tree
Hi,
On Fri, Apr 18, 2014 at 12:22:36PM +0200, Gregory CLEMENT wrote:
> This patch allow to register specific glue code for xhci controller.
> It creates a structure called xhci_plat_ops to register functions
> specific to an SoC. Currently there are only probe() and remove() but
What SoC-specific code do you need ?
> it can be extended later, it was the point to create such a structure.
>
> Each compatible string can then be associated to an instance of this
> structure. In the non device tree case a default structure is used.
>
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/usb/host/xhci-plat.c | 72
> +---
> drivers/usb/host/xhci.h | 4 +++
> 2 files changed, 72 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 151901ce1ba9..8029cc82edc4 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "xhci.h"
>
> @@ -85,7 +86,7 @@ static const struct hc_driver xhci_plat_xhci_driver = {
> .bus_resume = xhci_bus_resume,
> };
>
> -static int xhci_plat_probe(struct platform_device *pdev)
> +int common_xhci_plat_probe(struct platform_device *pdev, void *priv)
no, I rather not see this sort of hack.
--
balbi
signature.asc
Description: Digital signature
RE: USB OTG support on mx27pdk
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Sunday, April 20, 2014 1:10 AM
> To: Chen Peter-B29397
> Cc: Michael Grzeschik; Alexander Shiyan; linux-arm-
> ker...@lists.infradead.org; linux-usb@vger.kernel.org; Sascha Hauer;
> chris.ru...@gtsys.com.hk; Guo Shawn-R65073
> Subject: Re: USB OTG support on mx27pdk
>
> On Sat, Apr 19, 2014 at 4:32 AM, Peter Chen
> wrote:
> > The below patch is intended to fix above issues for all platforms,
> > I have tested it at imx6 platform, if possible, have a test at
> imx25/imx27
> > please.
>
> I don't see any patch below, but anyway I have managed to fix the
> issue on mx27 at dts level.
>
https://github.com/hzpeterchen/linux-usb/commit/c1f42ea27ed3f5d988c63da7849d2e6b445b4fbc
Your problem is different with sasche's, which hang the system due to
no phy clk. The chris's patch should not cause the oops.
Peter
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: External hard drive connection issues with xHCI
On Sat, 19 Apr 2014, Dainius (GreatEmerald) wrote:
> Hi,
> I have an external hard drive (well, actually a case for an internal
> one, but this may not be relevant) that connects to the PC via USB3.
> However, I've been experiencing erratic behaviour with it. So far
> there have been two issues.
>
> One is that if I boot with the cable plugged in already, then it fails
> to mount the volume (or, indeed, report that it even exists). However,
> if I either remove the cable and replug it into another USB3 socket or
> if I plug it in only after it's done booting, then everything is fine
> and I can see and mount the volume. I'll attach the dmesg errors about
> it.
>
> The other issue is rather peculiar. When I get it mounted, doing
> certain I/O tasks (I'm testing with btrfs send/receive) results in the
> device disconnecting and unmounting (the key error seems to be "xHCI
> xhci_drop_endpoint called with disabled ep 8801aced5d40"). When
> it's connected through a USB2 port, I also get errors ("reset
> high-speed USB device number 6 using ehci-pci"), but they don't result
> in unmounting the volume. And if I do large file copying instead of
> btrfs send/receive, then everything works fine even when connected
> through USB3. I'll also attach the error logs in question.
>
> I also tested this with a separate USB2 cable, and the results are the
> same as when I use the USB3 cable but connect it to a USB2 port.
That's to be expected. More to the point would be to test with a USB-2
cable connected to a USB-3 port.
> I'm currently using kernel 3.10.11.
You really should upgrade to 3.14. I don't know whether all the
changes to xhci-hcd have been back-ported to the stable kernels.
> Any ideas about what could be causing this behaviour with USB3?
Not much idea regarding the USB-3 problems. Under USB-2, you can try
to find out the reason for the resets by collecting a usbmon trace.
(It's probably the same as the reason for the USB-3 resets.) See the
kernel source file Documentation/usb/usbmon.txt for instructions.
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: USB OTG support on mx27pdk
On Sat, Apr 19, 2014 at 4:32 AM, Peter Chen wrote: > The below patch is intended to fix above issues for all platforms, > I have tested it at imx6 platform, if possible, have a test at imx25/imx27 > please. I don't see any patch below, but anyway I have managed to fix the issue on mx27 at dts level. -- 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
External hard drive connection issues with xHCI
Hi,
I have an external hard drive (well, actually a case for an internal
one, but this may not be relevant) that connects to the PC via USB3.
However, I've been experiencing erratic behaviour with it. So far
there have been two issues.
One is that if I boot with the cable plugged in already, then it fails
to mount the volume (or, indeed, report that it even exists). However,
if I either remove the cable and replug it into another USB3 socket or
if I plug it in only after it's done booting, then everything is fine
and I can see and mount the volume. I'll attach the dmesg errors about
it.
The other issue is rather peculiar. When I get it mounted, doing
certain I/O tasks (I'm testing with btrfs send/receive) results in the
device disconnecting and unmounting (the key error seems to be "xHCI
xhci_drop_endpoint called with disabled ep 8801aced5d40"). When
it's connected through a USB2 port, I also get errors ("reset
high-speed USB device number 6 using ehci-pci"), but they don't result
in unmounting the volume. And if I do large file copying instead of
btrfs send/receive, then everything works fine even when connected
through USB3. I'll also attach the error logs in question.
I also tested this with a separate USB2 cable, and the results are the
same as when I use the USB3 cable but connect it to a USB2 port.
I'm currently using kernel 3.10.11.
Any ideas about what could be causing this behaviour with USB3?
[0.921676] xhci_hcd :00:14.0: setting latency timer to 64
[0.921680] xhci_hcd :00:14.0: xHCI Host Controller
[0.921687] xhci_hcd :00:14.0: new USB bus registered, assigned bus
number 3
[0.921771] xhci_hcd :00:14.0: cache line size of 64 is not supported
[0.921794] xhci_hcd :00:14.0: irq 43 for MSI/MSI-X
[0.921843] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[0.921845] usb usb3: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[0.921846] usb usb3: Product: xHCI Host Controller
[0.921848] usb usb3: Manufacturer: Linux 3.11.10-7-desktop xhci_hcd
[0.921849] usb usb3: SerialNumber: :00:14.0
[0.922074] xHCI xhci_add_endpoint called for root hub
[0.922076] xHCI xhci_check_bandwidth called for root hub
[0.922099] hub 3-0:1.0: USB hub found
[0.922106] hub 3-0:1.0: 4 ports detected
[0.923854] xhci_hcd :00:14.0: xHCI Host Controller
[0.923858] xhci_hcd :00:14.0: new USB bus registered, assigned bus
number 4
[0.923876] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[0.923878] usb usb4: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[0.923880] usb usb4: Product: xHCI Host Controller
[0.923881] usb usb4: Manufacturer: Linux 3.11.10-7-desktop xhci_hcd
[0.923882] usb usb4: SerialNumber: :00:14.0
[0.923956] xHCI xhci_add_endpoint called for root hub
[0.923957] xHCI xhci_check_bandwidth called for root hub
[0.923977] hub 4-0:1.0: USB hub found
[0.923983] hub 4-0:1.0: 4 ports detected
[1.294519] usb 3-4: new high-speed USB device number 2 using xhci_hcd
[6.294532] xhci_hcd :00:14.0: Timeout while waiting for address device
command
[ 11.495571] xhci_hcd :00:14.0: Timeout while waiting for address device
command
[ 11.696552] usb 3-4: device not accepting address 2, error -62
[ 11.849577] usb 3-4: new high-speed USB device number 3 using xhci_hcd
[ 16.849611] xhci_hcd :00:14.0: Timeout while waiting for address device
command
[ 22.050578] xhci_hcd :00:14.0: Timeout while waiting for address device
command
[ 22.251554] usb 3-4: device not accepting address 3, error -62
[ 22.404569] usb 3-4: new high-speed USB device number 4 using xhci_hcd
[ 27.404495] xhci_hcd :00:14.0: Timeout while waiting for address device
command
[ 32.605405] xhci_hcd :00:14.0: Timeout while waiting for address device
command
[ 32.806420] usb 3-4: device not accepting address 4, error -62
[ 32.959422] usb 3-4: new high-speed USB device number 5 using xhci_hcd
[ 37.959351] xhci_hcd :00:14.0: Timeout while waiting for address device
command
[ 43.160272] xhci_hcd :00:14.0: Timeout while waiting for address device
command
[ 43.361278] usb 3-4: device not accepting address 5, error -62
[ 43.361321] hub 3-0:1.0: unable to enumerate USB device on port 413:01:31 kernel: usb 4-4: new SuperSpeed USB device number 2 using xhci_hcd
13:01:31 kernel: usb 4-4: New USB device found, idVendor=05e3, idProduct=0731
13:01:31 kernel: usb 4-4: New USB device strings: Mfr=3, Product=4,
SerialNumber=5
13:01:31 kernel: usb 4-4: Product: USB to S-ATA
13:01:31 kernel: usb 4-4: Manufacturer: Genesyslogic
13:01:31 kernel: usb 4-4: SerialNumber: 0497
13:01:32 mtp-probe[9781]: checking bus 4, device 2:
"/sys/devices/pci:00/:00:14.0/usb4/4-4"
13:01:32 mtp-probe[9781]: bus: 4, device: 2 was not an MTP device
13:01:32 kernel: usb-storage 4-4:1.0: USB Mass Storage device detected
13:01:32 kernel: s
Re: [PATCH v2 05/13] extcon: extcon-class: improve extcon client API
Hi, On Mon, Apr 14, 2014 at 01:46:16PM +0200, Robert Baldyga wrote: > dev_info(&pdev->dev, > - "OMAP USB OTG controller rev %d.%d (%s, id=%d, vbus=%d)\n", > - (rev >> 4) & 0xf, rev & 0xf, config->extcon, otg_dev->id, > + "OMAP USB OTG controller rev %d.%d (id=%d, vbus=%d)\n", > + (rev >> 4) & 0xf, rev & 0xf, otg_dev->id, >otg_dev->vbus); This change is unrelated to the patch and not needed. A. -- 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: BBB gadgetfs freeze patch
I have the same problem but it did not occur when the usb cable was detached. -- 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: USB OTG support on mx27pdk
> > On Wed, Apr 16, 2014 at 09:53:34AM -0300, Fabio Estevam wrote: > > On Wed, Apr 16, 2014 at 8:58 AM, Alexander Shiyan > wrote: > > > > > I can tell immediately without further testing, > > > this will not work without the USB support in the bootoader because > > > we do not have DT support for ULPI. > > > > The generic nop usb phy should work just fine. > > > > I have tried Uwe's suggestion from a previous post and reverted: > > > > commit cd0b42c2a6d2a74244f0053f8960f5dad5842278 > > Author: Chris Ruehl > > Date: Fri Jan 10 13:51:30 2014 +0800 > > > > usb: chipidea: put hw_phymode_configure before ci_usb_phy_init > > > > hw_phymode_configure configures the PORTSC registers and allow the > > following phy_inits to operate on the right parameters. This fix a > problem > > where the UPLI (ISP1504) could not be detected, because the > Viewport was not > > available and read the viewport return 0's only. > > > > Signed-off-by: Chris Ruehl > > Signed-off-by: Peter Chen > > Signed-off-by: Greg Kroah-Hartman > > > > > > Then USB OTG port detected the USB pen driver fine: > > > > usbcore: registered new interface driver usb-storage > > 10024000.usb supply vbus not found, using dummy regulator > > ci_hdrc ci_hdrc.0: EHCI Host Controller > > ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 > > ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 > > hub 1-0:1.0: USB hub found > > hub 1-0:1.0: 1 port detected > > ... > > scsi 0:0:0:0: Direct-Access ChipsBnk Flash Disk 2.00 PQ: 0 > ANSI: 2 > > sd 0:0:0:0: [sda] 1035200 512-byte logical blocks: (530 MB/505 MiB) > > sd 0:0:0:0: [sda] Write Protect is off > > sd 0:0:0:0: [sda] No Caching mode page found > > sd 0:0:0:0: [sda] Assuming drive cache: write through > > sda: sda1 > > sd 0:0:0:0: [sda] Attached SCSI removable disk > > > > If I understand correctly commit cd0b42c2a was only needed because > > Chris was trying to add DT support for ULPI, which never got merged > > into mainline. > > > > If we use the generic nop usb phy instead, we should just revert this > commit. > > > > Any objections? > > Yes, when this patch got reverted it will probably break usb support > on mx6 machines. We have seen different behaviour on several mxc/mxs > machines regarding the order of PORTSC and phy configuration. > > We will probably need to test all platforms before reordering this > function call again and again for every machine using this driver. > The below patch is intended to fix above issues for all platforms, I have tested it at imx6 platform, if possible, have a test at imx25/imx27 please. 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
