| Message ID | 1568020220-7758-4-git-send-email-talel@amazon.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Amazon's Annapurna Labs POS Driver | expand |
On Mon, Sep 9, 2019 at 11:14 AM Talel Shenhar <talel@amazon.com> wrote: > > Amazon's Annapurna Labs SoCs uses al-pos driver, enable it. > > Signed-off-by: Talel Shenhar <talel@amazon.com> > --- > arch/arm64/Kconfig.platforms | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index 4778c77..bd86b15 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -25,6 +25,7 @@ config ARCH_SUNXI > config ARCH_ALPINE > bool "Annapurna Labs Alpine platform" > select ALPINE_MSI if PCI > + select AL_POS > help > This enables support for the Annapurna Labs Alpine > Soc family. Generally I think this kind of thing should go into the defconfig rather than being hard-selected. There might be users that want to not enable the driver. Arnd
On 9/9/2019 12:40 PM, Arnd Bergmann wrote: > On Mon, Sep 9, 2019 at 11:14 AM Talel Shenhar <talel@amazon.com> wrote: >> Amazon's Annapurna Labs SoCs uses al-pos driver, enable it. >> >> Signed-off-by: Talel Shenhar <talel@amazon.com> >> --- >> arch/arm64/Kconfig.platforms | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms >> index 4778c77..bd86b15 100644 >> --- a/arch/arm64/Kconfig.platforms >> +++ b/arch/arm64/Kconfig.platforms >> @@ -25,6 +25,7 @@ config ARCH_SUNXI >> config ARCH_ALPINE >> bool "Annapurna Labs Alpine platform" >> select ALPINE_MSI if PCI >> + select AL_POS >> help >> This enables support for the Annapurna Labs Alpine >> Soc family. > Generally I think this kind of thing should go into the defconfig > rather than being hard-selected. There might be users that > want to not enable the driver. > > Arnd The reason for selecting it is because this is a driver that we will always want for ARCH_ALPINE.
On Mon, Sep 9, 2019 at 12:17 PM Shenhar, Talel <talel@amazon.com> wrote: > On 9/9/2019 12:40 PM, Arnd Bergmann wrote: > > On Mon, Sep 9, 2019 at 11:14 AM Talel Shenhar <talel@amazon.com> wrote: > >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > >> index 4778c77..bd86b15 100644 > >> --- a/arch/arm64/Kconfig.platforms > >> +++ b/arch/arm64/Kconfig.platforms > >> @@ -25,6 +25,7 @@ config ARCH_SUNXI > >> config ARCH_ALPINE > >> bool "Annapurna Labs Alpine platform" > >> select ALPINE_MSI if PCI > >> + select AL_POS > >> help > >> This enables support for the Annapurna Labs Alpine > >> Soc family. > > Generally I think this kind of thing should go into the defconfig > > rather than being hard-selected. There might be users that > > want to not enable the driver. > > The reason for selecting it is because this is a driver that we will > always want for ARCH_ALPINE. Can you put the exact requirement (other than "we want this") in the changelog text then? It's still not clear to me what breaks without this driver. Arnd
On 9/9/2019 4:45 PM, Arnd Bergmann wrote: > On Mon, Sep 9, 2019 at 12:17 PM Shenhar, Talel <talel@amazon.com> wrote: >> On 9/9/2019 12:40 PM, Arnd Bergmann wrote: >>> On Mon, Sep 9, 2019 at 11:14 AM Talel Shenhar <talel@amazon.com> wrote: >>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms >>>> index 4778c77..bd86b15 100644 >>>> --- a/arch/arm64/Kconfig.platforms >>>> +++ b/arch/arm64/Kconfig.platforms >>>> @@ -25,6 +25,7 @@ config ARCH_SUNXI >>>> config ARCH_ALPINE >>>> bool "Annapurna Labs Alpine platform" >>>> select ALPINE_MSI if PCI >>>> + select AL_POS >>>> help >>>> This enables support for the Annapurna Labs Alpine >>>> Soc family. >>> Generally I think this kind of thing should go into the defconfig >>> rather than being hard-selected. There might be users that >>> want to not enable the driver. >> The reason for selecting it is because this is a driver that we will >> always want for ARCH_ALPINE. > Can you put the exact requirement (other than "we want this") > in the changelog text then? It's still not clear to me what breaks > without this driver. > > Arnd 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. 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. Will love to hear the general rule for select vs defconfig.
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
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.
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 4778c77..bd86b15 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -25,6 +25,7 @@ config ARCH_SUNXI config ARCH_ALPINE bool "Annapurna Labs Alpine platform" select ALPINE_MSI if PCI + select AL_POS help This enables support for the Annapurna Labs Alpine Soc family.
Amazon's Annapurna Labs SoCs uses al-pos driver, enable it. Signed-off-by: Talel Shenhar <talel@amazon.com> --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+)