From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Doug Anderson <dianders@chromium.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>,
Sachin Kamat <sachin.kamat@samsung.com>,
Tomasz Figa <t.figa@samsung.com>, Olof Johansson <olof@lixom.net>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Date: Mon, 11 Aug 2014 18:23:01 +0200 [thread overview]
Message-ID: <53E8EDE5.4000807@collabora.co.uk> (raw)
In-Reply-To: <CAD=FV=XfvzKJO-enwH95hi_mGT6AhXq-R9WHjvhRrDdNtdmazA@mail.gmail.com>
Hello,
On 08/11/2014 05:59 PM, Doug Anderson wrote:
> Bartlomiej,
>
> On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
>>
>> Hi,
>>
>> On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote:
>>> Hello Bartlomiej,
>>>
>>> On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
>>> >> index fc7d168..c390bb9 100644
>>> >> --- a/arch/arm/configs/exynos_defconfig
>>> >> +++ b/arch/arm/configs/exynos_defconfig
>>> >> @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
>>> >> CONFIG_I2C_S3C2410=y
>>> >> CONFIG_DEBUG_GPIO=y
>>> >> CONFIG_POWER_SUPPLY=y
>>> >> +CONFIG_BATTERY_SBS=m
>>> >
>>> > Why not make it "=y"?
>>> >
>>> > Rationale:
>>> > - currently no hardware related option uses "=m" in exynos_defconfig
>>> > - it would match the SBS option usage in multi_v7_defconfig
>>> >
>>> >> CONFIG_CHARGER_TPS65090=y
>>> >> # CONFIG_HWMON is not set
>>> >> CONFIG_THERMAL=y
>>> >
>>>
>>> I know but personally I think this should be changed. The idea of having a multi
>>> platform kernel is to build a single kernel image that can be used to boot
>>> different platforms. Not all platforms have a SBS-compliant battery so this
>>> support shouldn't be built in the kernel image IMHO.
>>>
>>> This also matches to what real users will do since distributions most likely
>>> will have a minimal kernel and every possible hardware support will be enabled
>>> as a loadable kernel module. This is what distros do for other platforms too.
>>>
>>> If someone has a different use case and wants a kernel image that is optimized
>>> for a particular platform then she has to create its own defconfig anyways.
>>
>> Distributions usually use their own configs anyway and the current most
>> popular use case for exynos_defconfig (not multi_v7_defconfig) seems to
>> be to build kernel image alone and use it without any modules:
>>
>> $ grep "=m" arch/arm/configs/exynos_defconfig
>> CONFIG_DM_CRYPT=m
>>
>> $ grep "=m" .config
>> CONFIG_NET_IP_TUNNEL=m
>> CONFIG_INET_TUNNEL=m
>> CONFIG_IPV6=m
>> CONFIG_INET6_XFRM_MODE_TRANSPORT=m
>> CONFIG_INET6_XFRM_MODE_TUNNEL=m
>> CONFIG_INET6_XFRM_MODE_BEET=m
>> CONFIG_IPV6_SIT=m
>> CONFIG_DM_CRYPT=m
>> CONFIG_CRYPTO_RNG=m
>> CONFIG_CRYPTO_ANSI_CPRNG=m
>>
>> What I'm trying to say is that there is a high probability that people
>> will continue to use just the kernel image for exynos_defconfig and
>> will therefore miss SBS battery support altogether (which is only 3.6
>> kB of code more in the kernel image so there is no much gain in making
>> it modular currently).
>
> I'm not against making it =y for exynos_defconfig. I do pretty
> strongly agree that the multi_v7 version should be =m eventually,
> though. We'd need to do everything we can to make that kernel
> smaller.
>
Same for me. I don't have such a strong opinion about this so if you think that
I should re-spin to change to =m, I will.
I do think that we should try to keep the delta between exynos_defconfig and
multi_v7_defconfig as small as possible and eventually even get rid of
exynos_defconfig. Since building everything as built-in and having a config
targeted to a single platform is not aligned with the effort to have support for
multi platforms kernels.
> -Doug
>
Best regards,
Javier
WARNING: multiple messages have this Message-ID (diff)
From: javier.martinez@collabora.co.uk (Javier Martinez Canillas)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support
Date: Mon, 11 Aug 2014 18:23:01 +0200 [thread overview]
Message-ID: <53E8EDE5.4000807@collabora.co.uk> (raw)
In-Reply-To: <CAD=FV=XfvzKJO-enwH95hi_mGT6AhXq-R9WHjvhRrDdNtdmazA@mail.gmail.com>
Hello,
On 08/11/2014 05:59 PM, Doug Anderson wrote:
> Bartlomiej,
>
> On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
>>
>> Hi,
>>
>> On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote:
>>> Hello Bartlomiej,
>>>
>>> On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
>>> >> index fc7d168..c390bb9 100644
>>> >> --- a/arch/arm/configs/exynos_defconfig
>>> >> +++ b/arch/arm/configs/exynos_defconfig
>>> >> @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
>>> >> CONFIG_I2C_S3C2410=y
>>> >> CONFIG_DEBUG_GPIO=y
>>> >> CONFIG_POWER_SUPPLY=y
>>> >> +CONFIG_BATTERY_SBS=m
>>> >
>>> > Why not make it "=y"?
>>> >
>>> > Rationale:
>>> > - currently no hardware related option uses "=m" in exynos_defconfig
>>> > - it would match the SBS option usage in multi_v7_defconfig
>>> >
>>> >> CONFIG_CHARGER_TPS65090=y
>>> >> # CONFIG_HWMON is not set
>>> >> CONFIG_THERMAL=y
>>> >
>>>
>>> I know but personally I think this should be changed. The idea of having a multi
>>> platform kernel is to build a single kernel image that can be used to boot
>>> different platforms. Not all platforms have a SBS-compliant battery so this
>>> support shouldn't be built in the kernel image IMHO.
>>>
>>> This also matches to what real users will do since distributions most likely
>>> will have a minimal kernel and every possible hardware support will be enabled
>>> as a loadable kernel module. This is what distros do for other platforms too.
>>>
>>> If someone has a different use case and wants a kernel image that is optimized
>>> for a particular platform then she has to create its own defconfig anyways.
>>
>> Distributions usually use their own configs anyway and the current most
>> popular use case for exynos_defconfig (not multi_v7_defconfig) seems to
>> be to build kernel image alone and use it without any modules:
>>
>> $ grep "=m" arch/arm/configs/exynos_defconfig
>> CONFIG_DM_CRYPT=m
>>
>> $ grep "=m" .config
>> CONFIG_NET_IP_TUNNEL=m
>> CONFIG_INET_TUNNEL=m
>> CONFIG_IPV6=m
>> CONFIG_INET6_XFRM_MODE_TRANSPORT=m
>> CONFIG_INET6_XFRM_MODE_TUNNEL=m
>> CONFIG_INET6_XFRM_MODE_BEET=m
>> CONFIG_IPV6_SIT=m
>> CONFIG_DM_CRYPT=m
>> CONFIG_CRYPTO_RNG=m
>> CONFIG_CRYPTO_ANSI_CPRNG=m
>>
>> What I'm trying to say is that there is a high probability that people
>> will continue to use just the kernel image for exynos_defconfig and
>> will therefore miss SBS battery support altogether (which is only 3.6
>> kB of code more in the kernel image so there is no much gain in making
>> it modular currently).
>
> I'm not against making it =y for exynos_defconfig. I do pretty
> strongly agree that the multi_v7 version should be =m eventually,
> though. We'd need to do everything we can to make that kernel
> smaller.
>
Same for me. I don't have such a strong opinion about this so if you think that
I should re-spin to change to =m, I will.
I do think that we should try to keep the delta between exynos_defconfig and
multi_v7_defconfig as small as possible and eventually even get rid of
exynos_defconfig. Since building everything as built-in and having a config
targeted to a single platform is not aligned with the effort to have support for
multi platforms kernels.
> -Doug
>
Best regards,
Javier
next prev parent reply other threads:[~2014-08-11 16:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 11:06 [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support Javier Martinez Canillas
2014-08-11 11:06 ` Javier Martinez Canillas
2014-08-11 12:40 ` Bartlomiej Zolnierkiewicz
2014-08-11 12:40 ` Bartlomiej Zolnierkiewicz
2014-08-11 12:52 ` Javier Martinez Canillas
2014-08-11 12:52 ` Javier Martinez Canillas
2014-08-11 15:42 ` Bartlomiej Zolnierkiewicz
2014-08-11 15:42 ` Bartlomiej Zolnierkiewicz
2014-08-11 15:59 ` Doug Anderson
2014-08-11 15:59 ` Doug Anderson
2014-08-11 16:23 ` Javier Martinez Canillas [this message]
2014-08-11 16:23 ` Javier Martinez Canillas
2014-08-11 17:28 ` Bartlomiej Zolnierkiewicz
2014-08-11 17:28 ` Bartlomiej Zolnierkiewicz
2014-08-11 17:36 ` Doug Anderson
2014-08-11 17:36 ` Doug Anderson
2014-08-11 17:38 ` Javier Martinez Canillas
2014-08-11 17:38 ` Javier Martinez Canillas
2014-08-11 15:13 ` Doug Anderson
2014-08-11 15:13 ` Doug Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53E8EDE5.4000807@collabora.co.uk \
--to=javier.martinez@collabora.co.uk \
--cc=b.zolnierkie@samsung.com \
--cc=dianders@chromium.org \
--cc=kgene.kim@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=olof@lixom.net \
--cc=sachin.kamat@samsung.com \
--cc=t.figa@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.