Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer

[Shilimkar, Santosh]

On Sun, Apr 1, 2012 at 7:09 AM, Ming Lei  wrote:
> On Sun, Apr 1, 2012 at 3:10 AM, Shilimkar, Santosh
>  wrote:
>> On Sat, Mar 31, 2012 at 2:09 PM, Ming Lei  wrote:
>>> On Sat, Mar 31, 2012 at 2:30 PM, Shilimkar, Santosh
 Since you need to recompile the kernel, you can very much tweak the
 clocksource to use GPTIMER with sysl clock. Support for that is still
 in place.
>>>
>>> With current kernel, running 'make menuconfig' can do it, but after applying
>>> Hiremath's patch[1], I have to edit the source code manually to get it, so 
>>> looks
>>> this kind of tweaking is not friendly enough, :-(
>>>
>> It's not friendly but doable. But above can be supported I guess.
>>
>> Since you are talking about doing menuconfig
>> and rebuilding kernel so what can be done is when one disable CPUIDLE
>> and PM, one can disabled 32K source as well. And then 32K clocksource
>> init should fail and fallback on gptimer clock source.
>
> OK, it should work, but looks OMAP_32K_TIMER option has to be kept
> for the usage, which may be a bit divergent to the purpose of the patch set.
>
> So how about introducing a kernel parameter to decide if bypassing
> 32K source and using gptimer source directly, and let which depend
> on PM?
>
We are just doing circles on this patch set. Till the dynamic clock-soucre
switching supported for low power entry exit, the high precision clocksoucre
selection is already broken and very much limited for use

I don't personally like to add features which hardly anybody use and
fundamentally
broken with full kernel.

I let Tony take final call on what's appropriate.

Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8][git pull] mmc: omap: Assorted fixes for 3.4 merge window

[Chris Ball]

Hi,

On Fri, Mar 16 2012, Venkatraman S wrote:
> Chris,
>Here are a group of fixes posted by Felipe and Balaji for the
> OMAP hsmmc driver in the past few days. 
>I've rebased them to the lastest mmc-next and posted them
> here again. These have also been tested on OMAP4 development platform.
>
> Please feel to apply directly or pull if that's convenient.
>
> Changes since yesterday (v1):-
>   Fixed formatting issues as suggested by Felipe
>   Marked some patches for stable.
>
> The following changes since commit 5f0390f10c0e9c9c504cdbf4af802252628a2490:
>
>   mmc: omap_hsmmc: Avoid a regulator voltage change with dt (2012-03-14 
> 11:33:20 -0400)
>
> are available in the git repository at:
>
>   git://github.com/svenkatr/linux.git omap-mmc-pending-for-3.4
>
> for you to fetch changes up to 8d54766b608915035b47616ea564e4e9b4dda29c:
>
>   mmc: omap4: hsmmc: fix module re-insertion (2012-03-16 11:38:41 +0530)

I've just rebased mmc-next on top of 3.4-rc1, and now there are many
conflicts against your tree -- please could you resend patches 3-8
against that base?  I'll take them for 3.4, and will take patches 1-2
for 3.5.

Thanks!

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer

[Ming Lei]

On Sun, Apr 1, 2012 at 3:10 AM, Shilimkar, Santosh
 wrote:
> On Sat, Mar 31, 2012 at 2:09 PM, Ming Lei  wrote:
>> On Sat, Mar 31, 2012 at 2:30 PM, Shilimkar, Santosh
>>> Since you need to recompile the kernel, you can very much tweak the
>>> clocksource to use GPTIMER with sysl clock. Support for that is still
>>> in place.
>>
>> With current kernel, running 'make menuconfig' can do it, but after applying
>> Hiremath's patch[1], I have to edit the source code manually to get it, so 
>> looks
>> this kind of tweaking is not friendly enough, :-(
>>
> It's not friendly but doable. But above can be supported I guess.
>
> Since you are talking about doing menuconfig
> and rebuilding kernel so what can be done is when one disable CPUIDLE
> and PM, one can disabled 32K source as well. And then 32K clocksource
> init should fail and fallback on gptimer clock source.

OK, it should work, but looks OMAP_32K_TIMER option has to be kept
for the usage, which may be a bit divergent to the purpose of the patch set.

So how about introducing a kernel parameter to decide if bypassing
32K source and using gptimer source directly, and let which depend
on PM?

>
> Vaibhav,
> Can you update your patch to support above. The patch which I
> did was doing exactly that but was not using hwmod. The problem with your
> patch is synctimer hwmod lookup on OMAP will never fail if the hwmod
> entry is supported.
>
> So you might better use failure case of omap_init_clocksource_32k() for
> fall back on gptimer source as I tried in my patch. That should support

You patch still doesn't work for the usage because you removed 32K option.


Thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] change lpj in arm smp common code

[Richard Zhao]

On Wed, Feb 29, 2012 at 10:21:19AM -0800, Kevin Hilman wrote:
> Richard Zhao  writes:
> 
> > The two patches were originally in [PATCH V6 0/7] add a generic cpufreq 
> > driver.
> > I seperated them and hope they can go to upstream earlier.
> >
> > Richard Zhao (2):
> >   ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp
> >   cpufreq: OMAP: remove loops_per_jiffy recalculate for smp
> 
> The first one should go into Russell's patch system.  Once he queues
> that, I can queue the OMAP one for the CPUfreq maintainer.
Hi Russel & Kevin,

Could you double check whether you've picked the patch searies?
I can not find them in 3.4rc.

Thanks
Richard
> 
> Kevin
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer

[Shilimkar, Santosh]

On Sat, Mar 31, 2012 at 2:09 PM, Ming Lei  wrote:
> On Sat, Mar 31, 2012 at 2:30 PM, Shilimkar, Santosh
>> Since you need to recompile the kernel, you can very much tweak the
>> clocksource to use GPTIMER with sysl clock. Support for that is still
>> in place.
>
> With current kernel, running 'make menuconfig' can do it, but after applying
> Hiremath's patch[1], I have to edit the source code manually to get it, so 
> looks
> this kind of tweaking is not friendly enough, :-(
>
It's not friendly but doable. But above can be supported I guess.

Since you are talking about doing menuconfig
and rebuilding kernel so what can be done is when one disable CPUIDLE
and PM, one can disabled 32K source as well. And then 32K clocksource
init should fail and fallback on gptimer clock source.

Vaibhav,
Can you update your patch to support above. The patch which I
did was doing exactly that but was not using hwmod. The problem with your
patch is synctimer hwmod lookup on OMAP will never fail if the hwmod
entry is supported.

So you might better use failure case of omap_init_clocksource_32k() for
fall back on gptimer source as I tried in my patch. That should support
the usage mentioned by Ming Lie

Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3 1/3] spi/omap: Remove bus_num usage for instance index

[Shubhrajyoti D]

From: Benoit Cousson 

bus_num was used to reference the mcspi controller instance in a fixed array.
Remove this array and store this information directly inside drvdata structure.

bus_num is now just set if the pdev->id is present or with -1 for dynamic
allocation by SPI core, but the driver does not access it anymore.

Clean some bad comments format, and remove un-needed space.

Signed-off-by: Benoit Cousson 
[Cleanup the OMAP2_MCSPI_MAX_CTRL macro as it is not needed anymore]
Signed-off-by: Shubhrajyoti D 
---
 drivers/spi/spi-omap2-mcspi.c |   75 ++--
 1 files changed, 34 insertions(+), 41 deletions(-)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 33f54cd..1907ed2 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -45,9 +45,6 @@
 
 #define OMAP2_MCSPI_MAX_FREQ   4800
 
-/* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */
-#define OMAP2_MCSPI_MAX_CTRL   4
-
 #define OMAP2_MCSPI_REVISION   0x00
 #define OMAP2_MCSPI_SYSSTATUS  0x14
 #define OMAP2_MCSPI_IRQSTATUS  0x18
@@ -111,6 +108,16 @@ struct omap2_mcspi_dma {
 #define DMA_MIN_BYTES  160
 
 
+/*
+ * Used for context save and restore, structure members to be updated whenever
+ * corresponding registers are modified.
+ */
+struct omap2_mcspi_regs {
+   u32 modulctrl;
+   u32 wakeupenable;
+   struct list_head cs;
+};
+
 struct omap2_mcspi {
struct work_struct  work;
/* lock protects queue and registers */
@@ -122,8 +129,9 @@ struct omap2_mcspi {
unsigned long   phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma  *dma_channels;
-   struct  device  *dev;
+   struct device   *dev;
struct workqueue_struct *wq;
+   struct omap2_mcspi_regs ctx;
 };
 
 struct omap2_mcspi_cs {
@@ -135,17 +143,6 @@ struct omap2_mcspi_cs {
u32 chconf0;
 };
 
-/* used for context save and restore, structure members to be updated whenever
- * corresponding registers are modified.
- */
-struct omap2_mcspi_regs {
-   u32 modulctrl;
-   u32 wakeupenable;
-   struct list_head cs;
-};
-
-static struct omap2_mcspi_regs omap2_mcspi_ctx[OMAP2_MCSPI_MAX_CTRL];
-
 #define MOD_REG_BIT(val, mask, set) do { \
if (set) \
val |= mask; \
@@ -236,9 +233,12 @@ static void omap2_mcspi_force_cs(struct spi_device *spi, 
int cs_active)
 
 static void omap2_mcspi_set_master_mode(struct spi_master *master)
 {
+   struct omap2_mcspi  *mcspi = spi_master_get_devdata(master);
+   struct omap2_mcspi_regs *ctx = &mcspi->ctx;
u32 l;
 
-   /* setup when switching from (reset default) slave mode
+   /*
+* Setup when switching from (reset default) slave mode
 * to single-channel master mode
 */
l = mcspi_read_reg(master, OMAP2_MCSPI_MODULCTRL);
@@ -247,24 +247,20 @@ static void omap2_mcspi_set_master_mode(struct spi_master 
*master)
MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_SINGLE, 1);
mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
 
-   omap2_mcspi_ctx[master->bus_num - 1].modulctrl = l;
+   ctx->modulctrl = l;
 }
 
 static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
 {
-   struct spi_master *spi_cntrl;
-   struct omap2_mcspi_cs *cs;
-   spi_cntrl = mcspi->master;
+   struct spi_master   *spi_cntrl = mcspi->master;
+   struct omap2_mcspi_regs *ctx = &mcspi->ctx;
+   struct omap2_mcspi_cs   *cs;
 
/* McSPI: context restore */
-   mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
-   omap2_mcspi_ctx[spi_cntrl->bus_num - 1].modulctrl);
+   mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL, ctx->modulctrl);
+   mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE, ctx->wakeupenable);
 
-   mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
-   omap2_mcspi_ctx[spi_cntrl->bus_num - 1].wakeupenable);
-
-   list_for_each_entry(cs, &omap2_mcspi_ctx[spi_cntrl->bus_num - 1].cs,
-   node)
+   list_for_each_entry(cs, &ctx->cs, node)
__raw_writel(cs->chconf0, cs->base + OMAP2_MCSPI_CHCONF0);
 }
 static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
@@ -777,7 +773,8 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
 static int omap2_mcspi_setup(struct spi_device *spi)
 {
int ret;
-   struct omap2_mcspi  *mcspi;
+   struct omap2_mcspi  *mcspi = spi_master_get_devdata(spi->master);
+   struct omap2_mcspi_regs *ctx = &mcspi->ctx;
struct omap2_mcspi_dma  *mcspi_dma;
struct omap2_mcspi_cs   *cs = spi->controller_state;
 
@@ -787,7 +784,6 @@ static int omap2_mcspi_setup(struct spi_device *spi)
return -EINVAL;
}
 
-   mcspi = spi_master_get_devdata(sp

[PATCHv3 3/3] spi: omap2-mcspi: Trivial optimisation

[Shubhrajyoti D]

Trivial optimisation of tmp variable by directly writing the value
to the register.

Cc :  Tarun Kanti DebBarma 
Signed-off-by: Shubhrajyoti D 
---
 drivers/spi/spi-omap2-mcspi.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 0b0da2f..f374eee 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1050,16 +1050,15 @@ static int __init omap2_mcspi_master_setup(struct 
omap2_mcspi *mcspi)
 {
struct spi_master   *master = mcspi->master;
struct omap2_mcspi_regs *ctx = &mcspi->ctx;
-   u32 tmp;
int ret = 0;
 
ret = omap2_mcspi_enable_clocks(mcspi);
if (ret < 0)
return ret;
 
-   tmp = OMAP2_MCSPI_WAKEUPENABLE_WKEN;
-   mcspi_write_reg(master, OMAP2_MCSPI_WAKEUPENABLE, tmp);
-   ctx->wakeupenable = tmp;
+   mcspi_write_reg(master, OMAP2_MCSPI_WAKEUPENABLE,
+   OMAP2_MCSPI_WAKEUPENABLE_WKEN);
+   ctx->wakeupenable = OMAP2_MCSPI_WAKEUPENABLE_WKEN;
 
omap2_mcspi_set_master_mode(master);
omap2_mcspi_disable_clocks(mcspi);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3 2/3] spi: omap2-mcspi: add support for pm_runtime autosuspend

[Shubhrajyoti D]

Adds support for configuring the omap2-mcspi driver use autosuspend for
runtime power management. This can reduce the latency in starting an
spi transfer by not suspending the device immediately following
completion of a transfer. If another transfer then takes place before
the autosuspend timeout (2 secs), the call to resume the device can
return immediately saving some save/ restore cycles.

Acked-by: Govindraj.R 
Signed-off-by: Shubhrajyoti D 
---
 drivers/spi/spi-omap2-mcspi.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 1907ed2..0b0da2f 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -44,6 +44,7 @@
 #include 
 
 #define OMAP2_MCSPI_MAX_FREQ   4800
+#define SPI_AUTOSUSPEND_TIMEOUT2000
 
 #define OMAP2_MCSPI_REVISION   0x00
 #define OMAP2_MCSPI_SYSSTATUS  0x14
@@ -265,7 +266,8 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi 
*mcspi)
 }
 static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
 {
-   pm_runtime_put_sync(mcspi->dev);
+   pm_runtime_mark_last_busy(mcspi->dev);
+   pm_runtime_put_autosuspend(mcspi->dev);
 }
 
 static int omap2_mcspi_enable_clocks(struct omap2_mcspi *mcspi)
@@ -1212,6 +1214,8 @@ static int __devinit omap2_mcspi_probe(struct 
platform_device *pdev)
if (status < 0)
goto dma_chnl_free;
 
+   pm_runtime_use_autosuspend(&pdev->dev);
+   pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(&pdev->dev);
 
if (status || omap2_mcspi_master_setup(mcspi) < 0)
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3 0/3] spi: omap2-mcspi: driver updates

[Shubhrajyoti D]

The patch series does the following cleanups
- Makes the driver use autosuspend
- Folds Benoit's bus_num removal patch in the series
- The tmp variable is used to write this can be optimised 
 as it is not needed if the value is directly written.
 Acknowledge  Tarun for the suggestion.

This is also available through
git : git://gitorious.org/linus-tree/linus-tree.git
branch  : spi_next

Rebased to Grant's spi/next branch.

 

Benoit Cousson (1):
  spi/omap: Remove bus_num usage for instance index

Shubhrajyoti D (2):
  spi: omap2-mcspi: add support for pm_runtime autosuspend
  spi: omap2-mcspi: Trivial optimisation

 drivers/spi/spi-omap2-mcspi.c |   86 +++-
 1 files changed, 41 insertions(+), 45 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 0/6] spi: omap2-mcspi: driver updates

[Shubhrajyoti]

On Saturday 31 March 2012 11:14 AM, Grant Likely wrote:
> On Fri, 30 Mar 2012 15:50:16 +0530, Shubhrajyoti D  
> wrote:
>> The patch series does the following cleanups
>> - Converts the spi to module_platform_driver
>> - Use the devm functions so that the freeing need not 
>>   be done in the driver.
>> - Makes the driver use autosuspend
>> - Folds Benoit's bus_num removal patch in the series
>>
>> Changes from v1
>> - Makes the driver use autosuspend
>> - Folds Benoit's bus_num removal patch in the series
>>
>> Changes from v2
>> - The tmp variable is used to write this can be optimised 
>>  as it is not needed if the value is directly written.
>>  Acknowledge  Tarun for the suggestion.
>>
>> This is also available through
>> git : git://gitorious.org/linus-tree/linus-tree.git
>> branch  : spi
>>
>> This is targeted for v3.5. 
> Okay, now is a good time to talk about git pull request workflow.  10
> days ago you published a git tree and I replied that I had pulled it
> into mine.  Now you've got a new branch with the patches from the old
> branch rebased onto a new head.  Compairing your branch with mine now
> looks like this:
>
> $ git fetch git://gitorious.org/linus-tree/linus-tree.git spi
> remote: Counting objects: 34, done.
> remote: Compressing objects: 100% (28/28), done.
> remote: Total 30 (delta 24), reused 6 (delta 2)
> Unpacking objects: 100% (30/30), done.
> From git://gitorious.org/linus-tree/linus-tree
>  * branchspi-> FETCH_HEAD
> $ git show-branch --topic origin spi/next FETCH_HEAD
> ! [origin] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc
>  ! [spi/next] Merge branch 'spi' of git://gitorious.org/linus-tree/linus-tree 
> into spi/next
>   ! [FETCH_HEAD] spi: omap2-mcspi: Trivial optimisation
> ---
>   + [FETCH_HEAD] spi: omap2-mcspi: Trivial optimisation
>   + [FETCH_HEAD^] spi: omap2-mcspi: add support for pm_runtime autosuspend
>   + [FETCH_HEAD~2] spi: omap2-mcspi: use devm_* functions
>   + [FETCH_HEAD~3] spi: omap2-mcspi: convert to module_platform_driver
>   + [FETCH_HEAD~4] spi: omap2-mcspi: make it behave as a module
>   + [FETCH_HEAD~5] spi/omap: Remove bus_num usage for instance index
>  -  [spi/next] Merge branch 'spi' of 
> git://gitorious.org/linus-tree/linus-tree into spi/next
>  +  [spi/next^2] OMAP : SPI : use devm_* functions
>  +  [spi/next^2^] spi: omap2-mcspi: convert to module_platform_driver
>  +  [spi/next^2~2] spi: omap2-mcspi: make it behave as a module
> +++ [origin~189] Linux 3.3
>
> I cannot merge this branch.  If I did it would result in 2 commits for
> each of the commits from the original branch.  You'll need go back and
> rebase the new commits on top of the old base or on top of my current
> spi/next branch[1]
>
> [1] git://git.secretlab.ca/git/linux-2.6 spi/next
>
> I've already published that branch, so I will not rebase it either to
> remove the original commits.  The new commits must go on top.
>
> Next time, *don't* rebase a branch that has been pulled.  It should be
> left alone and new commits added on top of it.
Apologies for this time.
Yes will take care henceforth.
>   If your in the
> situation where mainline has commits that you need to bring into the
> branch, then *merge* mainline into your branch (preferably at a tagged
> release point), or ask me to merge in mainline to give you a new
> baseline to work from.
>
> One option I do have is to apply only the patches I'm missing to my
> tree, but I'm not going to because I don't actually know if patches
> 1, 2, or 3 have changed since the version that I've posted.  It's
> safer for me to get you to rebase back onto the proper base and post
> only the new patches.  Your cover letter should state specifically
> which branch the patches apply on top of.
Will send another pull request.


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer

[Ming Lei]

On Sat, Mar 31, 2012 at 2:30 PM, Shilimkar, Santosh
> Since you need to recompile the kernel, you can very much tweak the
> clocksource to use GPTIMER with sysl clock. Support for that is still
> in place.

With current kernel, running 'make menuconfig' can do it, but after applying
Hiremath's patch[1], I have to edit the source code manually to get it, so looks
this kind of tweaking is not friendly enough, :-(

[1], http://marc.info/?l=linux-arm-kernel&m=133311647410324&w=2

Thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html