From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C151C43334 for ; Tue, 26 Jul 2022 06:11:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231477AbiGZGLh (ORCPT ); Tue, 26 Jul 2022 02:11:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229749AbiGZGLg (ORCPT ); Tue, 26 Jul 2022 02:11:36 -0400 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA7C41EEEE; Mon, 25 Jul 2022 23:11:33 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id e15so16529228edj.2; Mon, 25 Jul 2022 23:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5iTBFaujydfzjNtZ+tuEW42yh94kmq7eTQthHnu+Umc=; b=DFreK31JfLkd3fAd0uB7CR6gjxpG6yBsGmnlSdQdVK9K9Iop3MmbjSc5l5Mqska/9F 6zDsLVWtd4iSJbART2yOrMPnU6eocnuJbVN14OsRvUxL4fHsO7Wrgfc2UhIcTUjufoph 2DxioqWBkat/Lt1MPd86qgmI4fJ9X5pOYvgIQ3L8XLGI4V6pl/+7xrFDCD36BkcmbO3v msDZGsDArMOOY56AIoIP2Boyoi0IybH+bd3McBS1U0EmQcx61Apt04nGaujtweQDBRAO 5Sbq2NspvHrUHv6ggNUA5i+nF0w1W6dwyWvXZUzuukyS0Uo/f8jv4B+Fz7jfoW/fM0P7 F9hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5iTBFaujydfzjNtZ+tuEW42yh94kmq7eTQthHnu+Umc=; b=BlAlzcA1MUrg7S4dIEucIEGjRfOoqen2XN9v1xrd8WPiwPJelPEvZOR53CSMHOw0bS LGPA/U59ua6BMhoSECfgEy8/EGGiWBNZTPZx6e5vieTMcci3UmYoHtJ1RCf55sWLhBx+ rXgNbESeMDWnbdMW+CswYe9gyP+/J7gOdHu2Mg8EI0UOZkeHbMqJhCJnGbcHfXsxNk5g Idy7Qx+FB8B7qOCVeygWdcE0P63QFG01kWmbdxxKyy5YvBsNwpzBUaEY2Opgbe/i2UiH VaZHwzNV2u8wg9zeFKb+oFo6zT5agqi/2ygo5Gb/TgS7wX3D20qqI+/5/i6qMDEX9mL2 /CMQ== X-Gm-Message-State: AJIora9zbTMUbMaiUEu6d/Zud6rLXqVauQLyybsfYT/7geaGZBcHnKy9 UOgRBdN6J1k/CawajG6tSRJH2fjrEtTKswoBluYXHfMBpj7Lyw== X-Google-Smtp-Source: AGRyM1sDJR+2SWBXIadraV+/yk5L7Vs9denzeP6s+Yyxwc5C8W1vNP4hRGI/bOS7pUxW1lVGaWNV5mppOqxOjOJF8tE= X-Received: by 2002:a05:6402:d05:b0:435:b2a6:94eb with SMTP id eb5-20020a0564020d0500b00435b2a694ebmr16409469edb.87.1658815891980; Mon, 25 Jul 2022 23:11:31 -0700 (PDT) MIME-Version: 1.0 References: <20220722102407.2205-1-peterwu.pub@gmail.com> <20220722102407.2205-13-peterwu.pub@gmail.com> In-Reply-To: From: Andy Shevchenko Date: Tue, 26 Jul 2022 08:10:55 +0200 Message-ID: Subject: Re: [PATCH v6 12/13] leds: flash: mt6370: Add MediaTek MT6370 flashlight support To: szuni chen Cc: ChiaEn Wu , Lee Jones , Daniel Thompson , Jingoo Han , Pavel Machek , Rob Herring , Krzysztof Kozlowski , Matthias Brugger , Sebastian Reichel , Chunfeng Yun , Greg Kroah-Hartman , Jonathan Cameron , Lars-Peter Clausen , Liam Girdwood , Mark Brown , Guenter Roeck , "Krogerus, Heikki" , Helge Deller , ChiaEn Wu , Alice Chen , cy_huang , dri-devel , Linux LED Subsystem , devicetree , linux-arm Mailing List , "moderated list:ARM/Mediatek SoC support" , Linux Kernel Mailing List , Linux PM , USB , linux-iio , "open list:FRAMEBUFFER LAYER" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org On Tue, Jul 26, 2022 at 6:15 AM szuni chen wrote: ... > > > +#define MT6370_ITORCH_MIN_UA 25000 > > > +#define MT6370_ITORCH_STEP_UA 12500 > > > +#define MT6370_ITORCH_MAX_UA 400000 > > > +#define MT6370_ITORCH_DOUBLE_MAX_UA 800000 > > > +#define MT6370_ISTRB_MIN_UA 50000 > > > +#define MT6370_ISTRB_STEP_UA 12500 > > > +#define MT6370_ISTRB_MAX_UA 1500000 > > > +#define MT6370_ISTRB_DOUBLE_MAX_UA 3000000 > > > > Perhaps _uA would be better and consistent across your series > > regarding current units. > > Yes, _uA will be more consistent, but in general, using upper case in > the define macro is a convention, doesn't it? There is general convention, but there are also: 1) common sense; 2) usage in practice (e.g. _US, etc for *seconds and _HZ for *frequency). My common sense tells me that it is convenient to use mA,uA, etc. Plus "in practice" it's related to use as in your series and elsewhere. But of course it's minor to me, decide yourself. ... > > > + /* > > > + * For the flash to turn on/off, need to wait for HW ramping up/down time > > > > we need > > > > > + * 5ms/500us to prevent the unexpected problem. > > > + */ > > > + if (!prev && curr) > > > + usleep_range(5000, 6000); > > > + else if (prev && !curr) > > > + udelay(500); > > > > This still remains unanswered, why in the first place we allow > > switching, and a busy loop in the other place? > > If I refine the description to > "For the flash to turn on/off, need to wait for 5ms/500us analog settling time. > If any flash led is already used, then the analog is settled done, we > don't need to wait again." > is it answer the question? No. I'm talking from the Linux APIs perspective. There is a huge difference between those branches. Please, conduct research, read documentation to understand what my question is about. -- With Best Regards, Andy Shevchenko From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1F11FC433EF for ; Tue, 26 Jul 2022 06:11:37 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4C4CB10E10C; Tue, 26 Jul 2022 06:11:35 +0000 (UTC) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by gabe.freedesktop.org (Postfix) with ESMTPS id D949810E382 for ; Tue, 26 Jul 2022 06:11:33 +0000 (UTC) Received: by mail-ed1-x52f.google.com with SMTP id f15so8042672edc.4 for ; Mon, 25 Jul 2022 23:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5iTBFaujydfzjNtZ+tuEW42yh94kmq7eTQthHnu+Umc=; b=DFreK31JfLkd3fAd0uB7CR6gjxpG6yBsGmnlSdQdVK9K9Iop3MmbjSc5l5Mqska/9F 6zDsLVWtd4iSJbART2yOrMPnU6eocnuJbVN14OsRvUxL4fHsO7Wrgfc2UhIcTUjufoph 2DxioqWBkat/Lt1MPd86qgmI4fJ9X5pOYvgIQ3L8XLGI4V6pl/+7xrFDCD36BkcmbO3v msDZGsDArMOOY56AIoIP2Boyoi0IybH+bd3McBS1U0EmQcx61Apt04nGaujtweQDBRAO 5Sbq2NspvHrUHv6ggNUA5i+nF0w1W6dwyWvXZUzuukyS0Uo/f8jv4B+Fz7jfoW/fM0P7 F9hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5iTBFaujydfzjNtZ+tuEW42yh94kmq7eTQthHnu+Umc=; b=M5gZa6/FViMTaJZIvFyMhUaNePgfH2ugfqze7BberuwcI3kRUUMWgM8iz0+PpgyLIT MXa5eAjZl2/7sOUuWceinz1X6cPbclSjvAdyUgNM8X+ThVNP1pZDv6R2VaJEhLuE6l0a LoMCy28Qfb2nfvJp5MQD/4trAOHX2f3PaycMOxHDu8s0BAeUJEfFj2C0aUx4Zg9Ps7rf /j/yOn0kPAhsDgMXeBPqksVRR7LkYDwGQlo8vmw95GKTkje6nX5Pfgcr0g8fwtS7Du5q fB5Hct0ED6G9SobEEkSVfp5aiAfLwj17IjCbpY8YYe6m6FLPK8Ma1cA7W/asnC4tv/gt eEmQ== X-Gm-Message-State: AJIora8UvzTAWaMqOlwNJgX7sYRpra+GLSkcTArCkZEm+diS3nijSEfD ruT3O8b0Fq91Yb3WEg00IlQhSqOKY+qpjdUBNis= X-Google-Smtp-Source: AGRyM1sDJR+2SWBXIadraV+/yk5L7Vs9denzeP6s+Yyxwc5C8W1vNP4hRGI/bOS7pUxW1lVGaWNV5mppOqxOjOJF8tE= X-Received: by 2002:a05:6402:d05:b0:435:b2a6:94eb with SMTP id eb5-20020a0564020d0500b00435b2a694ebmr16409469edb.87.1658815891980; Mon, 25 Jul 2022 23:11:31 -0700 (PDT) MIME-Version: 1.0 References: <20220722102407.2205-1-peterwu.pub@gmail.com> <20220722102407.2205-13-peterwu.pub@gmail.com> In-Reply-To: From: Andy Shevchenko Date: Tue, 26 Jul 2022 08:10:55 +0200 Message-ID: Subject: Re: [PATCH v6 12/13] leds: flash: mt6370: Add MediaTek MT6370 flashlight support To: szuni chen Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "open list:FRAMEBUFFER LAYER" , "Krogerus, Heikki" , Pavel Machek , Alice Chen , linux-iio , dri-devel , Liam Girdwood , cy_huang , Krzysztof Kozlowski , Lee Jones , Linux LED Subsystem , Daniel Thompson , Helge Deller , Rob Herring , Chunfeng Yun , Guenter Roeck , devicetree , Linux PM , Mark Brown , "moderated list:ARM/Mediatek SoC support" , Matthias Brugger , ChiaEn Wu , linux-arm Mailing List , Jingoo Han , USB , Sebastian Reichel , Linux Kernel Mailing List , ChiaEn Wu , Greg Kroah-Hartman , Jonathan Cameron Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Jul 26, 2022 at 6:15 AM szuni chen wrote: ... > > > +#define MT6370_ITORCH_MIN_UA 25000 > > > +#define MT6370_ITORCH_STEP_UA 12500 > > > +#define MT6370_ITORCH_MAX_UA 400000 > > > +#define MT6370_ITORCH_DOUBLE_MAX_UA 800000 > > > +#define MT6370_ISTRB_MIN_UA 50000 > > > +#define MT6370_ISTRB_STEP_UA 12500 > > > +#define MT6370_ISTRB_MAX_UA 1500000 > > > +#define MT6370_ISTRB_DOUBLE_MAX_UA 3000000 > > > > Perhaps _uA would be better and consistent across your series > > regarding current units. > > Yes, _uA will be more consistent, but in general, using upper case in > the define macro is a convention, doesn't it? There is general convention, but there are also: 1) common sense; 2) usage in practice (e.g. _US, etc for *seconds and _HZ for *frequency). My common sense tells me that it is convenient to use mA,uA, etc. Plus "in practice" it's related to use as in your series and elsewhere. But of course it's minor to me, decide yourself. ... > > > + /* > > > + * For the flash to turn on/off, need to wait for HW ramping up/down time > > > > we need > > > > > + * 5ms/500us to prevent the unexpected problem. > > > + */ > > > + if (!prev && curr) > > > + usleep_range(5000, 6000); > > > + else if (prev && !curr) > > > + udelay(500); > > > > This still remains unanswered, why in the first place we allow > > switching, and a busy loop in the other place? > > If I refine the description to > "For the flash to turn on/off, need to wait for 5ms/500us analog settling time. > If any flash led is already used, then the analog is settled done, we > don't need to wait again." > is it answer the question? No. I'm talking from the Linux APIs perspective. There is a huge difference between those branches. Please, conduct research, read documentation to understand what my question is about. -- With Best Regards, Andy Shevchenko From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B5530C43334 for ; Tue, 26 Jul 2022 06:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Ski5EqPKh2skOdUhiyHgK9otZJRIe/kJuBVwKO1lcSU=; b=y5qehTtqkDt/XK dQdCaiBO3xnYxCmInlnHZ91S0hOyTXLa16XzgNP28iK2WhPlUUQT5FjIvQI2Fb+SjFn8wdboXFUlS mkaYWDUOH+6g9tS2aUi+nDlGSFdnJv2TWc0UYzc6ryp9dF8+nPcL1mzHEnO70k18LK2uR300AA+vF 7/Z2wAwBwxQjzC5RtwrSubA7myijmhMYAn1pthmsfSWhW2lMLpfrSQNsrxKxTfN/Zfs8ZER43iZ3W 9X9saQXrULMVba6YCaAEHwI6lplCgP8CPsgykE7IQQOghJ4CEuzXqDk4eDb1QKOQbrrpKsr2TFGvR hS9+t3ISBbYnhtUfYYMA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGDnD-008eua-7d; Tue, 26 Jul 2022 06:11:43 +0000 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGDn4-008eqY-2w; Tue, 26 Jul 2022 06:11:41 +0000 Received: by mail-ed1-x52c.google.com with SMTP id w5so4071415edd.13; Mon, 25 Jul 2022 23:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5iTBFaujydfzjNtZ+tuEW42yh94kmq7eTQthHnu+Umc=; b=DFreK31JfLkd3fAd0uB7CR6gjxpG6yBsGmnlSdQdVK9K9Iop3MmbjSc5l5Mqska/9F 6zDsLVWtd4iSJbART2yOrMPnU6eocnuJbVN14OsRvUxL4fHsO7Wrgfc2UhIcTUjufoph 2DxioqWBkat/Lt1MPd86qgmI4fJ9X5pOYvgIQ3L8XLGI4V6pl/+7xrFDCD36BkcmbO3v msDZGsDArMOOY56AIoIP2Boyoi0IybH+bd3McBS1U0EmQcx61Apt04nGaujtweQDBRAO 5Sbq2NspvHrUHv6ggNUA5i+nF0w1W6dwyWvXZUzuukyS0Uo/f8jv4B+Fz7jfoW/fM0P7 F9hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5iTBFaujydfzjNtZ+tuEW42yh94kmq7eTQthHnu+Umc=; b=F8ywcHrbqU4zP0fZmFgphxStWqrGitaUkGFmP4Ev7ezHUDoP5yd//7KhyY5EoHDJry oaOt8E394d1CuKyXmg4nP8H2Rbu1+knEPgbT1oCjvcUy8vFmqtXNpZPvTKcQrMMim6L2 /KoQrW0YhKo7k2Pnn8d0YVU1khNTrAYhQQyaNALI7n1phIO4LJS1R5H27iGkEal4eRpD oedjwehiGfgkfQX9LriWYR3kjAKkyehNoS6qqkh6nfPYpc2aIq9T3Bjt2Y7ILvlsZvmE FI73vBfltl4W+6KYzCwY6KrDaZFzmuc+CZBIP3gfkhzi/buKfmm3wmqigKG2zlonTvUz xMzg== X-Gm-Message-State: AJIora+vIwYwntLfFq61hRuCHI939SfIcQ+ku4cEYdK9d0A0H4hz3EYh hU3g4hLlziUXyoL1i3qEJ+xv6rbVeikmCmldz+s= X-Google-Smtp-Source: AGRyM1sDJR+2SWBXIadraV+/yk5L7Vs9denzeP6s+Yyxwc5C8W1vNP4hRGI/bOS7pUxW1lVGaWNV5mppOqxOjOJF8tE= X-Received: by 2002:a05:6402:d05:b0:435:b2a6:94eb with SMTP id eb5-20020a0564020d0500b00435b2a694ebmr16409469edb.87.1658815891980; Mon, 25 Jul 2022 23:11:31 -0700 (PDT) MIME-Version: 1.0 References: <20220722102407.2205-1-peterwu.pub@gmail.com> <20220722102407.2205-13-peterwu.pub@gmail.com> In-Reply-To: From: Andy Shevchenko Date: Tue, 26 Jul 2022 08:10:55 +0200 Message-ID: Subject: Re: [PATCH v6 12/13] leds: flash: mt6370: Add MediaTek MT6370 flashlight support To: szuni chen Cc: ChiaEn Wu , Lee Jones , Daniel Thompson , Jingoo Han , Pavel Machek , Rob Herring , Krzysztof Kozlowski , Matthias Brugger , Sebastian Reichel , Chunfeng Yun , Greg Kroah-Hartman , Jonathan Cameron , Lars-Peter Clausen , Liam Girdwood , Mark Brown , Guenter Roeck , "Krogerus, Heikki" , Helge Deller , ChiaEn Wu , Alice Chen , cy_huang , dri-devel , Linux LED Subsystem , devicetree , linux-arm Mailing List , "moderated list:ARM/Mediatek SoC support" , Linux Kernel Mailing List , Linux PM , USB , linux-iio , "open list:FRAMEBUFFER LAYER" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220725_231134_174134_4E3CFE88 X-CRM114-Status: GOOD ( 22.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jul 26, 2022 at 6:15 AM szuni chen wrote: ... > > > +#define MT6370_ITORCH_MIN_UA 25000 > > > +#define MT6370_ITORCH_STEP_UA 12500 > > > +#define MT6370_ITORCH_MAX_UA 400000 > > > +#define MT6370_ITORCH_DOUBLE_MAX_UA 800000 > > > +#define MT6370_ISTRB_MIN_UA 50000 > > > +#define MT6370_ISTRB_STEP_UA 12500 > > > +#define MT6370_ISTRB_MAX_UA 1500000 > > > +#define MT6370_ISTRB_DOUBLE_MAX_UA 3000000 > > > > Perhaps _uA would be better and consistent across your series > > regarding current units. > > Yes, _uA will be more consistent, but in general, using upper case in > the define macro is a convention, doesn't it? There is general convention, but there are also: 1) common sense; 2) usage in practice (e.g. _US, etc for *seconds and _HZ for *frequency). My common sense tells me that it is convenient to use mA,uA, etc. Plus "in practice" it's related to use as in your series and elsewhere. But of course it's minor to me, decide yourself. ... > > > + /* > > > + * For the flash to turn on/off, need to wait for HW ramping up/down time > > > > we need > > > > > + * 5ms/500us to prevent the unexpected problem. > > > + */ > > > + if (!prev && curr) > > > + usleep_range(5000, 6000); > > > + else if (prev && !curr) > > > + udelay(500); > > > > This still remains unanswered, why in the first place we allow > > switching, and a busy loop in the other place? > > If I refine the description to > "For the flash to turn on/off, need to wait for 5ms/500us analog settling time. > If any flash led is already used, then the analog is settled done, we > don't need to wait again." > is it answer the question? No. I'm talking from the Linux APIs perspective. There is a huge difference between those branches. Please, conduct research, read documentation to understand what my question is about. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel