[v2,12/12] riscv: defconfig: Enable the Allwinner D1 platform and drivers

  Now that several D1-based boards are supported, enable the platform in
our defconfig. Build in the drivers which are necessary to boot, such as
the pinctrl, MMC, RTC (which provides critical clocks), SPI (for flash),
and watchdog (which may be left enabled by the bootloader). Other common
onboard peripherals are enabled as modules.

Signed-off-by: Samuel Holland <samuel@sholland.org>
---

(no changes since v1)

 arch/riscv/configs/defconfig | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)
  

On Sat, Nov 26, 2022 at 7:47 AM Samuel Holland <samuel@sholland.org> wrote:
>
> Now that several D1-based boards are supported, enable the platform in
> our defconfig. Build in the drivers which are necessary to boot, such as
> the pinctrl, MMC, RTC (which provides critical clocks), SPI (for flash),
> and watchdog (which may be left enabled by the bootloader). Other common
> onboard peripherals are enabled as modules.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
>
> (no changes since v1)
>
>  arch/riscv/configs/defconfig | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> index 05fd5fcf24f9..8dfe0550c0e6 100644
> --- a/arch/riscv/configs/defconfig
> +++ b/arch/riscv/configs/defconfig
> @@ -25,6 +25,7 @@ CONFIG_BLK_DEV_INITRD=y
>  CONFIG_EXPERT=y
>  # CONFIG_SYSFS_SYSCALL is not set
>  CONFIG_PROFILING=y
> +CONFIG_ARCH_SUNXI=y
>  CONFIG_SOC_MICROCHIP_POLARFIRE=y
>  CONFIG_SOC_SIFIVE=y
>  CONFIG_SOC_STARFIVE=y
> @@ -118,22 +119,31 @@ CONFIG_VIRTIO_NET=y
>  CONFIG_MACB=y
>  CONFIG_E1000E=y
>  CONFIG_R8169=y
> +CONFIG_STMMAC_ETH=m
>  CONFIG_MICROSEMI_PHY=y
>  CONFIG_INPUT_MOUSEDEV=y
> +CONFIG_KEYBOARD_SUN4I_LRADC=m
>  CONFIG_SERIAL_8250=y
>  CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_8250_DW=y
>  CONFIG_SERIAL_OF_PLATFORM=y
>  CONFIG_VIRTIO_CONSOLE=y
>  CONFIG_HW_RANDOM=y
>  CONFIG_HW_RANDOM_VIRTIO=y
> +CONFIG_I2C_MV64XXX=m
>  CONFIG_SPI=y
>  CONFIG_SPI_SIFIVE=y
> +CONFIG_SPI_SUN6I=y
>  # CONFIG_PTP_1588_CLOCK is not set
> -CONFIG_GPIOLIB=y
>  CONFIG_GPIO_SIFIVE=y
> +CONFIG_WATCHDOG=y
> +CONFIG_SUNXI_WATCHDOG=y
> +CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
>  CONFIG_DRM=m
>  CONFIG_DRM_RADEON=m
>  CONFIG_DRM_NOUVEAU=m
> +CONFIG_DRM_SUN4I=m
>  CONFIG_DRM_VIRTIO_GPU=m
>  CONFIG_FB=y
>  CONFIG_FRAMEBUFFER_CONSOLE=y
> @@ -146,19 +156,30 @@ CONFIG_USB_OHCI_HCD=y
>  CONFIG_USB_OHCI_HCD_PLATFORM=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_UAS=y
> +CONFIG_USB_MUSB_HDRC=m
> +CONFIG_USB_MUSB_SUNXI=m
> +CONFIG_NOP_USB_XCEIV=m
>  CONFIG_MMC=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_PLTFM=y
>  CONFIG_MMC_SDHCI_CADENCE=y
>  CONFIG_MMC_SPI=y
> +CONFIG_MMC_SUNXI=y
>  CONFIG_RTC_CLASS=y
> +CONFIG_RTC_DRV_SUN6I=y
> +CONFIG_DMADEVICES=y
> +CONFIG_DMA_SUN6I=m
>  CONFIG_VIRTIO_PCI=y
>  CONFIG_VIRTIO_BALLOON=y
>  CONFIG_VIRTIO_INPUT=y
>  CONFIG_VIRTIO_MMIO=y
> +CONFIG_SUN8I_DE2_CCU=m
> +CONFIG_SUN50I_IOMMU=y
Do we need IOMMU?

Others:
Reviewed-by: Guo Ren <guoren@kernel.org>

>  CONFIG_RPMSG_CHAR=y
>  CONFIG_RPMSG_CTRL=y
>  CONFIG_RPMSG_VIRTIO=y
> +CONFIG_PHY_SUN4I_USB=m
> +CONFIG_NVMEM_SUNXI_SID=y
>  CONFIG_EXT4_FS=y
>  CONFIG_EXT4_FS_POSIX_ACL=y
>  CONFIG_EXT4_FS_SECURITY=y
> --
> 2.37.4
>
  

On Fri, Nov 25, 2022 at 05:46:56PM -0600, Samuel Holland wrote:
> Now that several D1-based boards are supported, enable the platform in
> our defconfig. Build in the drivers which are necessary to boot, such as
> the pinctrl, MMC, RTC (which provides critical clocks), SPI (for flash),
> and watchdog (which may be left enabled by the bootloader).

All of that looks good.

> Other common
> onboard peripherals are enabled as modules.

This I am not sure about though. I'll leave that to Palmer since I'm
pretty sure it was him that said it, but I thought the plan was only
turning on stuff required to boot to a console & things that are
generally useful rather than enabling modules for everyone's "random"
drivers. Palmer?

> 
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> 
> (no changes since v1)
> 
>  arch/riscv/configs/defconfig | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> index 05fd5fcf24f9..8dfe0550c0e6 100644
> --- a/arch/riscv/configs/defconfig
> +++ b/arch/riscv/configs/defconfig
> @@ -25,6 +25,7 @@ CONFIG_BLK_DEV_INITRD=y
>  CONFIG_EXPERT=y
>  # CONFIG_SYSFS_SYSCALL is not set
>  CONFIG_PROFILING=y
> +CONFIG_ARCH_SUNXI=y
>  CONFIG_SOC_MICROCHIP_POLARFIRE=y
>  CONFIG_SOC_SIFIVE=y
>  CONFIG_SOC_STARFIVE=y
> @@ -118,22 +119,31 @@ CONFIG_VIRTIO_NET=y
>  CONFIG_MACB=y
>  CONFIG_E1000E=y
>  CONFIG_R8169=y
> +CONFIG_STMMAC_ETH=m
>  CONFIG_MICROSEMI_PHY=y
>  CONFIG_INPUT_MOUSEDEV=y
> +CONFIG_KEYBOARD_SUN4I_LRADC=m
>  CONFIG_SERIAL_8250=y
>  CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_8250_DW=y
>  CONFIG_SERIAL_OF_PLATFORM=y
>  CONFIG_VIRTIO_CONSOLE=y
>  CONFIG_HW_RANDOM=y
>  CONFIG_HW_RANDOM_VIRTIO=y
> +CONFIG_I2C_MV64XXX=m
>  CONFIG_SPI=y
>  CONFIG_SPI_SIFIVE=y
> +CONFIG_SPI_SUN6I=y
>  # CONFIG_PTP_1588_CLOCK is not set
> -CONFIG_GPIOLIB=y
>  CONFIG_GPIO_SIFIVE=y
> +CONFIG_WATCHDOG=y
> +CONFIG_SUNXI_WATCHDOG=y
> +CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
>  CONFIG_DRM=m
>  CONFIG_DRM_RADEON=m
>  CONFIG_DRM_NOUVEAU=m
> +CONFIG_DRM_SUN4I=m
>  CONFIG_DRM_VIRTIO_GPU=m
>  CONFIG_FB=y
>  CONFIG_FRAMEBUFFER_CONSOLE=y
> @@ -146,19 +156,30 @@ CONFIG_USB_OHCI_HCD=y
>  CONFIG_USB_OHCI_HCD_PLATFORM=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_UAS=y
> +CONFIG_USB_MUSB_HDRC=m
> +CONFIG_USB_MUSB_SUNXI=m
> +CONFIG_NOP_USB_XCEIV=m
>  CONFIG_MMC=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_PLTFM=y
>  CONFIG_MMC_SDHCI_CADENCE=y
>  CONFIG_MMC_SPI=y
> +CONFIG_MMC_SUNXI=y
>  CONFIG_RTC_CLASS=y
> +CONFIG_RTC_DRV_SUN6I=y
> +CONFIG_DMADEVICES=y
> +CONFIG_DMA_SUN6I=m
>  CONFIG_VIRTIO_PCI=y
>  CONFIG_VIRTIO_BALLOON=y
>  CONFIG_VIRTIO_INPUT=y
>  CONFIG_VIRTIO_MMIO=y
> +CONFIG_SUN8I_DE2_CCU=m
> +CONFIG_SUN50I_IOMMU=y
>  CONFIG_RPMSG_CHAR=y
>  CONFIG_RPMSG_CTRL=y
>  CONFIG_RPMSG_VIRTIO=y
> +CONFIG_PHY_SUN4I_USB=m
> +CONFIG_NVMEM_SUNXI_SID=y
>  CONFIG_EXT4_FS=y
>  CONFIG_EXT4_FS_POSIX_ACL=y
>  CONFIG_EXT4_FS_SECURITY=y
> -- 
> 2.37.4
>
  

Am Samstag, 26. November 2022, 17:40:11 CET schrieb Conor Dooley:
> On Fri, Nov 25, 2022 at 05:46:56PM -0600, Samuel Holland wrote:
> > Now that several D1-based boards are supported, enable the platform in
> > our defconfig. Build in the drivers which are necessary to boot, such as
> > the pinctrl, MMC, RTC (which provides critical clocks), SPI (for flash),
> > and watchdog (which may be left enabled by the bootloader).
> 
> All of that looks good.
> 
> > Other common
> > onboard peripherals are enabled as modules.
> 
> This I am not sure about though. I'll leave that to Palmer since I'm
> pretty sure it was him that said it, but I thought the plan was only
> turning on stuff required to boot to a console & things that are
> generally useful rather than enabling modules for everyone's "random"
> drivers. Palmer?

Isn't the defconfig meant as a starting point to get working systems
with minimal config effort? At least that was always the way to go on arm
so far :-) .

So having boot-required drivers built-in with the rest enabled as modules
for supported boards will allow people to boot theirs without headaches.

Disabling unneeded drivers if you're starved for storage space in a special
project is always easier than hunting down all the drivers to enable for a
specific board. 


Heiko


> > Signed-off-by: Samuel Holland <samuel@sholland.org>
> > ---
> > 
> > (no changes since v1)
> > 
> >  arch/riscv/configs/defconfig | 23 ++++++++++++++++++++++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> > index 05fd5fcf24f9..8dfe0550c0e6 100644
> > --- a/arch/riscv/configs/defconfig
> > +++ b/arch/riscv/configs/defconfig
> > @@ -25,6 +25,7 @@ CONFIG_BLK_DEV_INITRD=y
> >  CONFIG_EXPERT=y
> >  # CONFIG_SYSFS_SYSCALL is not set
> >  CONFIG_PROFILING=y
> > +CONFIG_ARCH_SUNXI=y
> >  CONFIG_SOC_MICROCHIP_POLARFIRE=y
> >  CONFIG_SOC_SIFIVE=y
> >  CONFIG_SOC_STARFIVE=y
> > @@ -118,22 +119,31 @@ CONFIG_VIRTIO_NET=y
> >  CONFIG_MACB=y
> >  CONFIG_E1000E=y
> >  CONFIG_R8169=y
> > +CONFIG_STMMAC_ETH=m
> >  CONFIG_MICROSEMI_PHY=y
> >  CONFIG_INPUT_MOUSEDEV=y
> > +CONFIG_KEYBOARD_SUN4I_LRADC=m
> >  CONFIG_SERIAL_8250=y
> >  CONFIG_SERIAL_8250_CONSOLE=y
> > +CONFIG_SERIAL_8250_DW=y
> >  CONFIG_SERIAL_OF_PLATFORM=y
> >  CONFIG_VIRTIO_CONSOLE=y
> >  CONFIG_HW_RANDOM=y
> >  CONFIG_HW_RANDOM_VIRTIO=y
> > +CONFIG_I2C_MV64XXX=m
> >  CONFIG_SPI=y
> >  CONFIG_SPI_SIFIVE=y
> > +CONFIG_SPI_SUN6I=y
> >  # CONFIG_PTP_1588_CLOCK is not set
> > -CONFIG_GPIOLIB=y
> >  CONFIG_GPIO_SIFIVE=y
> > +CONFIG_WATCHDOG=y
> > +CONFIG_SUNXI_WATCHDOG=y
> > +CONFIG_REGULATOR=y
> > +CONFIG_REGULATOR_FIXED_VOLTAGE=y
> >  CONFIG_DRM=m
> >  CONFIG_DRM_RADEON=m
> >  CONFIG_DRM_NOUVEAU=m
> > +CONFIG_DRM_SUN4I=m
> >  CONFIG_DRM_VIRTIO_GPU=m
> >  CONFIG_FB=y
> >  CONFIG_FRAMEBUFFER_CONSOLE=y
> > @@ -146,19 +156,30 @@ CONFIG_USB_OHCI_HCD=y
> >  CONFIG_USB_OHCI_HCD_PLATFORM=y
> >  CONFIG_USB_STORAGE=y
> >  CONFIG_USB_UAS=y
> > +CONFIG_USB_MUSB_HDRC=m
> > +CONFIG_USB_MUSB_SUNXI=m
> > +CONFIG_NOP_USB_XCEIV=m
> >  CONFIG_MMC=y
> >  CONFIG_MMC_SDHCI=y
> >  CONFIG_MMC_SDHCI_PLTFM=y
> >  CONFIG_MMC_SDHCI_CADENCE=y
> >  CONFIG_MMC_SPI=y
> > +CONFIG_MMC_SUNXI=y
> >  CONFIG_RTC_CLASS=y
> > +CONFIG_RTC_DRV_SUN6I=y
> > +CONFIG_DMADEVICES=y
> > +CONFIG_DMA_SUN6I=m
> >  CONFIG_VIRTIO_PCI=y
> >  CONFIG_VIRTIO_BALLOON=y
> >  CONFIG_VIRTIO_INPUT=y
> >  CONFIG_VIRTIO_MMIO=y
> > +CONFIG_SUN8I_DE2_CCU=m
> > +CONFIG_SUN50I_IOMMU=y
> >  CONFIG_RPMSG_CHAR=y
> >  CONFIG_RPMSG_CTRL=y
> >  CONFIG_RPMSG_VIRTIO=y
> > +CONFIG_PHY_SUN4I_USB=m
> > +CONFIG_NVMEM_SUNXI_SID=y
> >  CONFIG_EXT4_FS=y
> >  CONFIG_EXT4_FS_POSIX_ACL=y
> >  CONFIG_EXT4_FS_SECURITY=y
>
  

On 28/11/2022 21:11, Heiko Stübner wrote:
> Am Samstag, 26. November 2022, 17:40:11 CET schrieb Conor Dooley:
>> On Fri, Nov 25, 2022 at 05:46:56PM -0600, Samuel Holland wrote:
>>> Now that several D1-based boards are supported, enable the platform in
>>> our defconfig. Build in the drivers which are necessary to boot, such as
>>> the pinctrl, MMC, RTC (which provides critical clocks), SPI (for flash),
>>> and watchdog (which may be left enabled by the bootloader).
>>
>> All of that looks good.
>>
>>> Other common
>>> onboard peripherals are enabled as modules.
>>
>> This I am not sure about though. I'll leave that to Palmer since I'm
>> pretty sure it was him that said it, but I thought the plan was only
>> turning on stuff required to boot to a console & things that are
>> generally useful rather than enabling modules for everyone's "random"
>> drivers. Palmer?
> 
> Isn't the defconfig meant as a starting point to get working systems
> with minimal config effort? At least that was always the way to go on arm
> so far :-) .
> 
> So having boot-required drivers built-in with the rest enabled as modules
> for supported boards will allow people to boot theirs without headaches.
> 
> Disabling unneeded drivers if you're starved for storage space in a special
> project is always easier than hunting down all the drivers to enable for a
> specific board. 

I wouldn't mind being able to turn on all the PolarFire SoC stuff and
yeah, that would be the way that arm64 does it. But I do recall hearing
that I should not turn stuff on this way, when I initially tried to
turn stuff on via selects, got a nack and asked if I could do this instead.

But it may be that I misremember, which is why I appealed to the Higher
Powers for clarification :)
  

On Mon, Nov 28, 2022 at 09:17:38PM +0000, Conor Dooley wrote:
> On 28/11/2022 21:11, Heiko Stübner wrote:
> > Am Samstag, 26. November 2022, 17:40:11 CET schrieb Conor Dooley:
> >> On Fri, Nov 25, 2022 at 05:46:56PM -0600, Samuel Holland wrote:
> >>> Now that several D1-based boards are supported, enable the platform in
> >>> our defconfig. Build in the drivers which are necessary to boot, such as
> >>> the pinctrl, MMC, RTC (which provides critical clocks), SPI (for flash),
> >>> and watchdog (which may be left enabled by the bootloader).
> >>
> >> All of that looks good.
> >>
> >>> Other common
> >>> onboard peripherals are enabled as modules.
> >>
> >> This I am not sure about though. I'll leave that to Palmer since I'm
> >> pretty sure it was him that said it, but I thought the plan was only
> >> turning on stuff required to boot to a console & things that are
> >> generally useful rather than enabling modules for everyone's "random"
> >> drivers. Palmer?
> > 
> > Isn't the defconfig meant as a starting point to get working systems
> > with minimal config effort? At least that was always the way to go on arm
> > so far :-) .
> > 
> > So having boot-required drivers built-in with the rest enabled as modules
> > for supported boards will allow people to boot theirs without headaches.
> > 
> > Disabling unneeded drivers if you're starved for storage space in a special
> > project is always easier than hunting down all the drivers to enable for a
> > specific board. 
> 
> I wouldn't mind being able to turn on all the PolarFire SoC stuff and
> yeah, that would be the way that arm64 does it. But I do recall hearing
> that I should not turn stuff on this way, when I initially tried to
> turn stuff on via selects, got a nack and asked if I could do this instead.
> 
> But it may be that I misremember, which is why I appealed to the Higher
> Powers for clarification :)

FWIW, I don't worry too much about modules in defconfig because I always
immediately apply a 'LSMOD=$PWD/L localmodconfig' to it, where the L
file is an lsmod output which only includes modules I need.

Thanks,
drew

> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
  

On 29 November 2022 06:49:25 GMT, Andrew Jones <ajones@ventanamicro.com> wrote:
>On Mon, Nov 28, 2022 at 09:17:38PM +0000, Conor Dooley wrote:
>> On 28/11/2022 21:11, Heiko Stübner wrote:
>> > Am Samstag, 26. November 2022, 17:40:11 CET schrieb Conor Dooley:
>> >> On Fri, Nov 25, 2022 at 05:46:56PM -0600, Samuel Holland wrote:
>> >>> Now that several D1-based boards are supported, enable the platform in
>> >>> our defconfig. Build in the drivers which are necessary to boot, such as
>> >>> the pinctrl, MMC, RTC (which provides critical clocks), SPI (for flash),
>> >>> and watchdog (which may be left enabled by the bootloader).
>> >>
>> >> All of that looks good.
>> >>
>> >>> Other common
>> >>> onboard peripherals are enabled as modules.
>> >>
>> >> This I am not sure about though. I'll leave that to Palmer since I'm
>> >> pretty sure it was him that said it, but I thought the plan was only
>> >> turning on stuff required to boot to a console & things that are
>> >> generally useful rather than enabling modules for everyone's "random"
>> >> drivers. Palmer?
>> > 
>> > Isn't the defconfig meant as a starting point to get working systems
>> > with minimal config effort? At least that was always the way to go on arm
>> > so far :-) .
>> > 
>> > So having boot-required drivers built-in with the rest enabled as modules
>> > for supported boards will allow people to boot theirs without headaches.
>> > 
>> > Disabling unneeded drivers if you're starved for storage space in a special
>> > project is always easier than hunting down all the drivers to enable for a
>> > specific board. 
>> 
>> I wouldn't mind being able to turn on all the PolarFire SoC stuff and
>> yeah, that would be the way that arm64 does it. But I do recall hearing
>> that I should not turn stuff on this way, when I initially tried to
>> turn stuff on via selects, got a nack and asked if I could do this instead.
>> 
>> But it may be that I misremember, which is why I appealed to the Higher
>> Powers for clarification :)
>
>FWIW, I don't worry too much about modules in defconfig because I always
>immediately apply a 'LSMOD=$PWD/L localmodconfig' to it, where the L
>file is an lsmod output which only includes modules I need.

idk, defconfig to me is not about you or I, it's about A Developer that gets an SBC or a devkit and their experience.
Or alternatively, someone's CI ;)
I'd like to put everything in, but I recall that being shot down, that's all.
  

On Mon, 28 Nov 2022 22:54:18 PST (-0800), Conor Dooley wrote:
>
>
> On 29 November 2022 06:49:25 GMT, Andrew Jones <ajones@ventanamicro.com> wrote:
>>On Mon, Nov 28, 2022 at 09:17:38PM +0000, Conor Dooley wrote:
>>> On 28/11/2022 21:11, Heiko Stübner wrote:
>>> > Am Samstag, 26. November 2022, 17:40:11 CET schrieb Conor Dooley:
>>> >> On Fri, Nov 25, 2022 at 05:46:56PM -0600, Samuel Holland wrote:
>>> >>> Now that several D1-based boards are supported, enable the platform in
>>> >>> our defconfig. Build in the drivers which are necessary to boot, such as
>>> >>> the pinctrl, MMC, RTC (which provides critical clocks), SPI (for flash),
>>> >>> and watchdog (which may be left enabled by the bootloader).
>>> >>
>>> >> All of that looks good.
>>> >>
>>> >>> Other common
>>> >>> onboard peripherals are enabled as modules.
>>> >>
>>> >> This I am not sure about though. I'll leave that to Palmer since I'm
>>> >> pretty sure it was him that said it, but I thought the plan was only
>>> >> turning on stuff required to boot to a console & things that are
>>> >> generally useful rather than enabling modules for everyone's "random"
>>> >> drivers. Palmer?
>>> > 
>>> > Isn't the defconfig meant as a starting point to get working systems
>>> > with minimal config effort? At least that was always the way to go on arm
>>> > so far :-) .
>>> > 
>>> > So having boot-required drivers built-in with the rest enabled as modules
>>> > for supported boards will allow people to boot theirs without headaches.
>>> > 
>>> > Disabling unneeded drivers if you're starved for storage space in a special
>>> > project is always easier than hunting down all the drivers to enable for a
>>> > specific board. 
>>> 
>>> I wouldn't mind being able to turn on all the PolarFire SoC stuff and
>>> yeah, that would be the way that arm64 does it. But I do recall hearing
>>> that I should not turn stuff on this way, when I initially tried to
>>> turn stuff on via selects, got a nack and asked if I could do this instead.
>>> 
>>> But it may be that I misremember, which is why I appealed to the Higher
>>> Powers for clarification :)
>>
>>FWIW, I don't worry too much about modules in defconfig because I always
>>immediately apply a 'LSMOD=$PWD/L localmodconfig' to it, where the L
>>file is an lsmod output which only includes modules I need.
>
> idk, defconfig to me is not about you or I, it's about A Developer that gets an SBC or a devkit and their experience.
> Or alternatively, someone's CI ;)
> I'd like to put everything in, but I recall that being shot down, that's all.

The whole "who is defconfig for" discussion always ends up kind of 
vague, but IIUC it's generally aimed at kernel hackers as opposed to end 
users -- so it's not meant to be a disto config, that's why we have 
things like the debug options turned on.  I tend to think of it as a "if 
a patch submitter is going to test only one config, then what do I want 
in it?" and let that determine what goes in defconfig.

IMO having defconfig contain the drivers necessary to boot every common 
dev board as =y, and having =m for anything else on those boards also 
seem reasonable.  That will make the transition from vendor/distro 
kernels to upstream a bit smoother, which is always good.  I guess 
there's some slight build time and image size issues, but aside from 
some very small systems that shouldn't be too bad for kernel developers 
-- and if we really end up with another popular system with 6MiB of RAM 
we can just stick another tiny defconfig in there for it.

I actually don't use modules when doing kernel development because I 
find it easier to track things when they're packed into a single binary, 
but I don't think it's necessary to steer everyone that way.

Adding some of the Arm folks here, in case they have thoughts.  The best 
bet is probably to try and do something similar, though my worry is that 
the answer is something like "target standard platforms" and we don't 
have any.
  

On Wed, Nov 30, 2022, at 21:24, Palmer Dabbelt wrote:
> On Mon, 28 Nov 2022 22:54:18 PST (-0800), Conor Dooley wrote:
>>
>> idk, defconfig to me is not about you or I, it's about A Developer that gets an SBC or a devkit and their experience.
>> Or alternatively, someone's CI ;)
>> I'd like to put everything in, but I recall that being shot down, that's all.
>
> The whole "who is defconfig for" discussion always ends up kind of 
> vague, but IIUC it's generally aimed at kernel hackers as opposed to end 
> users -- so it's not meant to be a disto config, that's why we have 
> things like the debug options turned on.  I tend to think of it as a "if 
> a patch submitter is going to test only one config, then what do I want 
> in it?" and let that determine what goes in defconfig.
>
> IMO having defconfig contain the drivers necessary to boot every common 
> dev board as =y, and having =m for anything else on those boards also 
> seem reasonable.  That will make the transition from vendor/distro 
> kernels to upstream a bit smoother, which is always good.  I guess 
> there's some slight build time and image size issues, but aside from 
> some very small systems that shouldn't be too bad for kernel developers 
> -- and if we really end up with another popular system with 6MiB of RAM 
> we can just stick another tiny defconfig in there for it.
>
> I actually don't use modules when doing kernel development because I 
> find it easier to track things when they're packed into a single binary, 
> but I don't think it's necessary to steer everyone that way.
>
> Adding some of the Arm folks here, in case they have thoughts.  The best 
> bet is probably to try and do something similar, though my worry is that 
> the answer is something like "target standard platforms" and we don't 
> have any.

I think this is handled very inconsistently across architectures. On
32-bit arm, we used to have a board specific defconfig for each machine,
but of course that never scaled to the number of supported machines.

The important defconfig files we have these days are the arm64
one, and on arm32 we have the ones that are mutually incompatible,
in particular one for armv7 and one for armv5, each enabling as
many machines as possible, plus usually one per SoC vendor that
is more specialized.

If you want to formalize it a bit more than this,  I would recommend
having more fragments, e.g. one for typical debugging options,
one for things that are needed to boot both Fedora and Debian
userland, etc.

      Arnd
  

On Wed, 30 Nov 2022 12:24:08 -0800 (PST)
Palmer Dabbelt <palmer@dabbelt.com> wrote:

Hi,

> On Mon, 28 Nov 2022 22:54:18 PST (-0800), Conor Dooley wrote:
> >
> >
> > On 29 November 2022 06:49:25 GMT, Andrew Jones <ajones@ventanamicro.com> wrote:  
> >>On Mon, Nov 28, 2022 at 09:17:38PM +0000, Conor Dooley wrote:  
> >>> On 28/11/2022 21:11, Heiko Stübner wrote:  
> >>> > Am Samstag, 26. November 2022, 17:40:11 CET schrieb Conor Dooley:  
> >>> >> On Fri, Nov 25, 2022 at 05:46:56PM -0600, Samuel Holland wrote:  
> >>> >>> Now that several D1-based boards are supported, enable the platform in
> >>> >>> our defconfig. Build in the drivers which are necessary to boot, such as
> >>> >>> the pinctrl, MMC, RTC (which provides critical clocks), SPI (for flash),
> >>> >>> and watchdog (which may be left enabled by the bootloader).  
> >>> >>
> >>> >> All of that looks good.
> >>> >>  
> >>> >>> Other common
> >>> >>> onboard peripherals are enabled as modules.  
> >>> >>
> >>> >> This I am not sure about though. I'll leave that to Palmer since I'm
> >>> >> pretty sure it was him that said it, but I thought the plan was only
> >>> >> turning on stuff required to boot to a console & things that are
> >>> >> generally useful rather than enabling modules for everyone's "random"
> >>> >> drivers. Palmer?  
> >>> > 
> >>> > Isn't the defconfig meant as a starting point to get working systems
> >>> > with minimal config effort? At least that was always the way to go on arm
> >>> > so far :-) .
> >>> > 
> >>> > So having boot-required drivers built-in with the rest enabled as modules
> >>> > for supported boards will allow people to boot theirs without headaches.
> >>> > 
> >>> > Disabling unneeded drivers if you're starved for storage space in a special
> >>> > project is always easier than hunting down all the drivers to enable for a
> >>> > specific board.   
> >>> 
> >>> I wouldn't mind being able to turn on all the PolarFire SoC stuff and
> >>> yeah, that would be the way that arm64 does it. But I do recall hearing
> >>> that I should not turn stuff on this way, when I initially tried to
> >>> turn stuff on via selects, got a nack and asked if I could do this instead.
> >>> 
> >>> But it may be that I misremember, which is why I appealed to the Higher
> >>> Powers for clarification :)  
> >>
> >>FWIW, I don't worry too much about modules in defconfig because I always
> >>immediately apply a 'LSMOD=$PWD/L localmodconfig' to it, where the L
> >>file is an lsmod output which only includes modules I need.  
> >
> > idk, defconfig to me is not about you or I, it's about A Developer that gets an SBC or a devkit and their experience.
> > Or alternatively, someone's CI ;)
> > I'd like to put everything in, but I recall that being shot down, that's all.  
> 
> The whole "who is defconfig for" discussion always ends up kind of 
> vague, but IIUC it's generally aimed at kernel hackers as opposed to end 
> users -- so it's not meant to be a disto config, that's why we have 
> things like the debug options turned on.  I tend to think of it as a "if 
> a patch submitter is going to test only one config, then what do I want 
> in it?" and let that determine what goes in defconfig.

Yes, this is also the guideline for arm64. On top of that it's supposed
to be a sane common config to be used to reproduce bugs. A common
question from maintainers is "Does it happen with defconfig?". If not,
what does it take on top of defconfig to get there?
The idea is that people can run the same config and thus the same image
on *their* boards, regardless of the particular platform.

> IMO having defconfig contain the drivers necessary to boot every common 
> dev board as =y, and having =m for anything else on those boards also 
> seem reasonable.  That will make the transition from vendor/distro 
> kernels to upstream a bit smoother, which is always good.  I guess 
> there's some slight build time and image size issues, but aside from 
> some very small systems that shouldn't be too bad for kernel developers 
> -- and if we really end up with another popular system with 6MiB of RAM 
> we can just stick another tiny defconfig in there for it.
> 
> I actually don't use modules when doing kernel development because I 
> find it easier to track things when they're packed into a single binary, 

Originally arm64 included most drivers as [=y], but this grew too big
quickly, so it was scaled back to be able to boot from the board's mass
storage (SD card, SATA, NVMe), with non-essential drivers included as
modules. And yes, most people just build and use the Image, which keeps
the build effort reasonable.
Also required features to make systemd happy, and to enable other core
distro features, were included, so that such kernels can boot distro
userland without losing significant functionality.

> but I don't think it's necessary to steer everyone that way.
> 
> Adding some of the Arm folks here, in case they have thoughts.  The best 
> bet is probably to try and do something similar, though my worry is that 
> the answer is something like "target standard platforms" and we don't 
> have any.

No such thing on arm64 either :-(

Cheers,
Andre
  

在 2022-11-26星期六的 08:24 +0800，Guo Ren写道：
> On Sat, Nov 26, 2022 at 7:47 AM Samuel Holland <samuel@sholland.org>
> wrote:
> > 
> > Now that several D1-based boards are supported, enable the platform
> > in
> > our defconfig. Build in the drivers which are necessary to boot,
> > such as
> > the pinctrl, MMC, RTC (which provides critical clocks), SPI (for
> > flash),
> > and watchdog (which may be left enabled by the bootloader). Other
> > common
> > onboard peripherals are enabled as modules.
> > 
> > Signed-off-by: Samuel Holland <samuel@sholland.org>
> > ---
> > 
> > (no changes since v1)
> > 
> >  arch/riscv/configs/defconfig | 23 ++++++++++++++++++++++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/riscv/configs/defconfig
> > b/arch/riscv/configs/defconfig
> > index 05fd5fcf24f9..8dfe0550c0e6 100644
> > --- a/arch/riscv/configs/defconfig
> > +++ b/arch/riscv/configs/defconfig
> > @@ -25,6 +25,7 @@ CONFIG_BLK_DEV_INITRD=y
> >  CONFIG_EXPERT=y
> >  # CONFIG_SYSFS_SYSCALL is not set
> >  CONFIG_PROFILING=y
> > +CONFIG_ARCH_SUNXI=y
> >  CONFIG_SOC_MICROCHIP_POLARFIRE=y
> >  CONFIG_SOC_SIFIVE=y
> >  CONFIG_SOC_STARFIVE=y
> > @@ -118,22 +119,31 @@ CONFIG_VIRTIO_NET=y
> >  CONFIG_MACB=y
> >  CONFIG_E1000E=y
> >  CONFIG_R8169=y
> > +CONFIG_STMMAC_ETH=m
> >  CONFIG_MICROSEMI_PHY=y
> >  CONFIG_INPUT_MOUSEDEV=y
> > +CONFIG_KEYBOARD_SUN4I_LRADC=m
> >  CONFIG_SERIAL_8250=y
> >  CONFIG_SERIAL_8250_CONSOLE=y
> > +CONFIG_SERIAL_8250_DW=y
> >  CONFIG_SERIAL_OF_PLATFORM=y
> >  CONFIG_VIRTIO_CONSOLE=y
> >  CONFIG_HW_RANDOM=y
> >  CONFIG_HW_RANDOM_VIRTIO=y
> > +CONFIG_I2C_MV64XXX=m
> >  CONFIG_SPI=y
> >  CONFIG_SPI_SIFIVE=y
> > +CONFIG_SPI_SUN6I=y
> >  # CONFIG_PTP_1588_CLOCK is not set
> > -CONFIG_GPIOLIB=y
> >  CONFIG_GPIO_SIFIVE=y
> > +CONFIG_WATCHDOG=y
> > +CONFIG_SUNXI_WATCHDOG=y
> > +CONFIG_REGULATOR=y
> > +CONFIG_REGULATOR_FIXED_VOLTAGE=y
> >  CONFIG_DRM=m
> >  CONFIG_DRM_RADEON=m
> >  CONFIG_DRM_NOUVEAU=m
> > +CONFIG_DRM_SUN4I=m
> >  CONFIG_DRM_VIRTIO_GPU=m
> >  CONFIG_FB=y
> >  CONFIG_FRAMEBUFFER_CONSOLE=y
> > @@ -146,19 +156,30 @@ CONFIG_USB_OHCI_HCD=y
> >  CONFIG_USB_OHCI_HCD_PLATFORM=y
> >  CONFIG_USB_STORAGE=y
> >  CONFIG_USB_UAS=y
> > +CONFIG_USB_MUSB_HDRC=m
> > +CONFIG_USB_MUSB_SUNXI=m
> > +CONFIG_NOP_USB_XCEIV=m
> >  CONFIG_MMC=y
> >  CONFIG_MMC_SDHCI=y
> >  CONFIG_MMC_SDHCI_PLTFM=y
> >  CONFIG_MMC_SDHCI_CADENCE=y
> >  CONFIG_MMC_SPI=y
> > +CONFIG_MMC_SUNXI=y
> >  CONFIG_RTC_CLASS=y
> > +CONFIG_RTC_DRV_SUN6I=y
> > +CONFIG_DMADEVICES=y
> > +CONFIG_DMA_SUN6I=m
> >  CONFIG_VIRTIO_PCI=y
> >  CONFIG_VIRTIO_BALLOON=y
> >  CONFIG_VIRTIO_INPUT=y
> >  CONFIG_VIRTIO_MMIO=y
> > +CONFIG_SUN8I_DE2_CCU=m
> > +CONFIG_SUN50I_IOMMU=y
> Do we need IOMMU?

It's utilized by some peripherals, e.g. the display engine.

> 
> Others:
> Reviewed-by: Guo Ren <guoren@kernel.org>
> 
> >  CONFIG_RPMSG_CHAR=y
> >  CONFIG_RPMSG_CTRL=y
> >  CONFIG_RPMSG_VIRTIO=y
> > +CONFIG_PHY_SUN4I_USB=m
> > +CONFIG_NVMEM_SUNXI_SID=y
> >  CONFIG_EXT4_FS=y
> >  CONFIG_EXT4_FS_POSIX_ACL=y
> >  CONFIG_EXT4_FS_SECURITY=y
> > --
> > 2.37.4
> > 
> 
>