From: "Shenhar, Talel" <talel@amazon.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
David Miller <davem@davemloft.net>,
gregkh <gregkh@linuxfoundation.org>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Thomas Gleixner <tglx@linutronix.de>,
"Patrick Venture" <venture@google.com>,
Linus Walleij <linus.walleij@linaro.org>,
"Olof Johansson" <olof@lixom.net>,
Maxime Ripard <mripard@kernel.org>,
"Santosh Shilimkar" <ssantosh@kernel.org>,
<paul.kocialkowski@bootlin.com>, <mjourdan@baylibre.com>,
Catalin Marinas <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
DTML <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
David Woodhouse <dwmw@amazon.co.uk>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
<hhhawa@amazon.com>, <ronenk@amazon.com>, <jonnyc@amazon.com>,
<hanochu@amazon.com>, <barakw@amazon.com>
Subject: Re: [PATCH 3/3] arm64: alpine: select AL_POS
Date: Tue, 10 Sep 2019 09:17:11 +0300 [thread overview]
Message-ID: <a616c903-6d3e-cf84-8afb-ade48d5ca68f@amazon.com> (raw)
In-Reply-To: <CAK8P3a0RUHxcpyUJU5bpd8nqpm0Sqhy4aJaoh7K9jVn8zJC6aQ@mail.gmail.com>
On 9/9/2019 6:08 PM, Arnd Bergmann wrote:
> On Mon, Sep 9, 2019 at 3:59 PM Shenhar, Talel <talel@amazon.com> wrote:
>> On 9/9/2019 4:45 PM, Arnd Bergmann wrote:
>>
>> Its not that something will get broken. its error event detector for POS
>> events which allows seeing bad accesses to registers.
>>
>> What is the general rule of which configs to put under select and which
>> under defconfig?
>>
>> I was thinking that "general" SoC support is good under select - those
>> things that we always want.
> I generally want as little as possible to be selected, basically only
> things that are required for linking the kernel and booting it without
> potentially destroying the hardware.
>
> In particular, I want most drivers to be enabled as loadable modules
> if possible. When you have general-purpose distributions support
> your platform, there is no need to have this module built-in while
> running on a different chip, even if you always want to load the
> module when it's running on yours.
>
>> And specific features, e.g. RAID support or features that supported only
>> on specific HW shall go under defconfig.
>>
>> Similar, I see ARCH_LAYERSCAPE selecting EDAC_SUPPORT.
> I think this was done to avoid a link failure. It's also possible that this
> is a mistake and just did not get caught in review.
>
> Arnd
I see.
Will remove this from v2.
WARNING: multiple messages have this Message-ID (diff)
From: "Shenhar, Talel" <talel@amazon.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
David Miller <davem@davemloft.net>,
gregkh <gregkh@linuxfoundation.org>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Thomas Gleixner <tglx@linutronix.de>,
Patrick Venture <venture@google.com>,
Linus Walleij <linus.walleij@linaro.org>,
Olof Johansson <olof@lixom.net>,
Maxime Ripard <mripard@kernel.org>,
Santosh Shilimkar <ssantosh@kernel.org>,
paul.kocialkowski@bootlin.com, mjourdan@baylibre.com,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, DTML <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>Dav
Subject: Re: [PATCH 3/3] arm64: alpine: select AL_POS
Date: Tue, 10 Sep 2019 09:17:11 +0300 [thread overview]
Message-ID: <a616c903-6d3e-cf84-8afb-ade48d5ca68f@amazon.com> (raw)
In-Reply-To: <CAK8P3a0RUHxcpyUJU5bpd8nqpm0Sqhy4aJaoh7K9jVn8zJC6aQ@mail.gmail.com>
On 9/9/2019 6:08 PM, Arnd Bergmann wrote:
> On Mon, Sep 9, 2019 at 3:59 PM Shenhar, Talel <talel@amazon.com> wrote:
>> On 9/9/2019 4:45 PM, Arnd Bergmann wrote:
>>
>> Its not that something will get broken. its error event detector for POS
>> events which allows seeing bad accesses to registers.
>>
>> What is the general rule of which configs to put under select and which
>> under defconfig?
>>
>> I was thinking that "general" SoC support is good under select - those
>> things that we always want.
> I generally want as little as possible to be selected, basically only
> things that are required for linking the kernel and booting it without
> potentially destroying the hardware.
>
> In particular, I want most drivers to be enabled as loadable modules
> if possible. When you have general-purpose distributions support
> your platform, there is no need to have this module built-in while
> running on a different chip, even if you always want to load the
> module when it's running on yours.
>
>> And specific features, e.g. RAID support or features that supported only
>> on specific HW shall go under defconfig.
>>
>> Similar, I see ARCH_LAYERSCAPE selecting EDAC_SUPPORT.
> I think this was done to avoid a link failure. It's also possible that this
> is a mistake and just did not get caught in review.
>
> Arnd
I see.
Will remove this from v2.
WARNING: multiple messages have this Message-ID (diff)
From: "Shenhar, Talel" <talel@amazon.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
mjourdan@baylibre.com, Catalin Marinas <catalin.marinas@arm.com>,
Linus Walleij <linus.walleij@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
jonnyc@amazon.com,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
ronenk@amazon.com, Will Deacon <will@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
DTML <devicetree@vger.kernel.org>,
Maxime Ripard <mripard@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Santosh Shilimkar <ssantosh@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
hanochu@amazon.com,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
barakw@amazon.com, hhhawa@amazon.com,
gregkh <gregkh@linuxfoundation.org>,
paul.kocialkowski@bootlin.com,
Patrick Venture <venture@google.com>,
Olof Johansson <olof@lixom.net>,
David Miller <davem@davemloft.net>,
David Woodhouse <dwmw@amazon.co.uk>
Subject: Re: [PATCH 3/3] arm64: alpine: select AL_POS
Date: Tue, 10 Sep 2019 09:17:11 +0300 [thread overview]
Message-ID: <a616c903-6d3e-cf84-8afb-ade48d5ca68f@amazon.com> (raw)
In-Reply-To: <CAK8P3a0RUHxcpyUJU5bpd8nqpm0Sqhy4aJaoh7K9jVn8zJC6aQ@mail.gmail.com>
On 9/9/2019 6:08 PM, Arnd Bergmann wrote:
> On Mon, Sep 9, 2019 at 3:59 PM Shenhar, Talel <talel@amazon.com> wrote:
>> On 9/9/2019 4:45 PM, Arnd Bergmann wrote:
>>
>> Its not that something will get broken. its error event detector for POS
>> events which allows seeing bad accesses to registers.
>>
>> What is the general rule of which configs to put under select and which
>> under defconfig?
>>
>> I was thinking that "general" SoC support is good under select - those
>> things that we always want.
> I generally want as little as possible to be selected, basically only
> things that are required for linking the kernel and booting it without
> potentially destroying the hardware.
>
> In particular, I want most drivers to be enabled as loadable modules
> if possible. When you have general-purpose distributions support
> your platform, there is no need to have this module built-in while
> running on a different chip, even if you always want to load the
> module when it's running on yours.
>
>> And specific features, e.g. RAID support or features that supported only
>> on specific HW shall go under defconfig.
>>
>> Similar, I see ARCH_LAYERSCAPE selecting EDAC_SUPPORT.
> I think this was done to avoid a link failure. It's also possible that this
> is a mistake and just did not get caught in review.
>
> Arnd
I see.
Will remove this from v2.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-09-10 6:18 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-09 9:10 [PATCH 0/3] Amazon's Annapurna Labs POS Driver Talel Shenhar
2019-09-09 9:10 ` Talel Shenhar
2019-09-09 9:10 ` Talel Shenhar
2019-09-09 9:10 ` [PATCH 1/3] dt-bindings: soc: al-pos: Amazon's Annapurna Labs POS Talel Shenhar
2019-09-09 9:10 ` Talel Shenhar
2019-09-09 9:10 ` Talel Shenhar
2019-09-09 9:10 ` [PATCH 2/3] soc: amazon: al-pos: Introduce Amazon's Annapurna Labs POS driver Talel Shenhar
2019-09-09 9:10 ` Talel Shenhar
2019-09-09 9:10 ` Talel Shenhar
2019-09-09 9:44 ` Arnd Bergmann
2019-09-09 9:44 ` Arnd Bergmann
2019-09-09 9:44 ` Arnd Bergmann
2019-09-09 11:12 ` Shenhar, Talel
2019-09-09 11:12 ` Shenhar, Talel
2019-09-09 11:12 ` Shenhar, Talel
2019-09-09 13:41 ` Arnd Bergmann
2019-09-09 13:41 ` Arnd Bergmann
2019-09-09 13:41 ` Arnd Bergmann
2019-09-09 14:11 ` Shenhar, Talel
2019-09-09 14:11 ` Shenhar, Talel
2019-09-09 14:11 ` Shenhar, Talel
2019-09-09 15:16 ` Arnd Bergmann
2019-09-09 15:16 ` Arnd Bergmann
2019-09-09 15:16 ` Arnd Bergmann
2019-09-10 6:21 ` Shenhar, Talel
2019-09-10 6:21 ` Shenhar, Talel
2019-09-10 6:21 ` Shenhar, Talel
2019-09-09 11:51 ` kbuild test robot
2019-09-09 11:51 ` kbuild test robot
2019-09-09 11:51 ` kbuild test robot
2019-09-09 9:10 ` [PATCH 3/3] arm64: alpine: select AL_POS Talel Shenhar
2019-09-09 9:10 ` Talel Shenhar
2019-09-09 9:10 ` Talel Shenhar
2019-09-09 9:40 ` Arnd Bergmann
2019-09-09 9:40 ` Arnd Bergmann
2019-09-09 9:40 ` Arnd Bergmann
2019-09-09 10:16 ` Shenhar, Talel
2019-09-09 10:16 ` Shenhar, Talel
2019-09-09 10:16 ` Shenhar, Talel
2019-09-09 13:45 ` Arnd Bergmann
2019-09-09 13:45 ` Arnd Bergmann
2019-09-09 13:45 ` Arnd Bergmann
2019-09-09 13:58 ` Shenhar, Talel
2019-09-09 13:58 ` Shenhar, Talel
2019-09-09 13:58 ` Shenhar, Talel
2019-09-09 15:08 ` Arnd Bergmann
2019-09-09 15:08 ` Arnd Bergmann
2019-09-09 15:08 ` Arnd Bergmann
2019-09-10 6:17 ` Shenhar, Talel [this message]
2019-09-10 6:17 ` Shenhar, Talel
2019-09-10 6:17 ` Shenhar, Talel
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=a616c903-6d3e-cf84-8afb-ade48d5ca68f@amazon.com \
--to=talel@amazon.com \
--cc=arnd@arndb.de \
--cc=barakw@amazon.com \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dwmw@amazon.co.uk \
--cc=gregkh@linuxfoundation.org \
--cc=hanochu@amazon.com \
--cc=hhhawa@amazon.com \
--cc=jonnyc@amazon.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mchehab+samsung@kernel.org \
--cc=mjourdan@baylibre.com \
--cc=mripard@kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=olof@lixom.net \
--cc=paul.kocialkowski@bootlin.com \
--cc=robh+dt@kernel.org \
--cc=ronenk@amazon.com \
--cc=ssantosh@kernel.org \
--cc=tglx@linutronix.de \
--cc=venture@google.com \
--cc=will@kernel.org \
/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.