| Message ID | 20190204203747.7376-1-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] ARM: multi_v7_defconfig: Update for dropped options | expand |
Hi Tony, On Mon, Feb 4, 2019 at 9:37 PM Tony Lindgren <tony@atomide.com> wrote: > These are automatically selected with make multi_v7_defconfig, > except for SH_DMAE which is selected only by sound/soc/sh/Kconfig. > > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Geert Uytterhoeven <geert+renesas@glider.be> > Cc: Olof Johansson <olof@lixom.net> > Cc: Russell King <linux@armlinux.org.uk> > Cc: Simon Horman <horms+renesas@verge.net.au> > Signed-off-by: Tony Lindgren <tony@atomide.com> Thanks, this matches similar changes to shmobile_defconfig in commit 4162325afd0d553c ("ARM: shmobile: defconfig: Refresh for v5.0-rc1") in next. Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> I didn't update multi_v7_defconfig to avoid conflicts. IMHO the arm-soc maintainers should handle the refresh of the common config on a regular basis[*]. [*] When is the right time? I'd say it should be the last commit just before the release of rc1 (so all arm-soc submaintainers' trees will have the new base in their for-next branches for the next merge window), but that may be difficult to implement. What do you think? Thanks! Gr{oetje,eeting}s, Geert
On Tue, Feb 05, 2019 at 09:07:38AM +0100, Geert Uytterhoeven wrote: > Hi Tony, > > On Mon, Feb 4, 2019 at 9:37 PM Tony Lindgren <tony@atomide.com> wrote: > > These are automatically selected with make multi_v7_defconfig, > > except for SH_DMAE which is selected only by sound/soc/sh/Kconfig. > > > > Cc: Arnd Bergmann <arnd@arndb.de> > > Cc: Geert Uytterhoeven <geert+renesas@glider.be> > > Cc: Olof Johansson <olof@lixom.net> > > Cc: Russell King <linux@armlinux.org.uk> > > Cc: Simon Horman <horms+renesas@verge.net.au> > > Signed-off-by: Tony Lindgren <tony@atomide.com> > > Thanks, this matches similar changes to shmobile_defconfig in commit > 4162325afd0d553c ("ARM: shmobile: defconfig: Refresh for v5.0-rc1") > in next. > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Simon Horman <horms+renesas@verge.net.au> > > I didn't update multi_v7_defconfig to avoid conflicts. > IMHO the arm-soc maintainers should handle the refresh of the common > config on a regular basis[*]. > > [*] When is the right time? I'd say it should be the last commit just > before the release of rc1 (so all arm-soc submaintainers' trees will > have the new base in their for-next branches for the next merge > window), but that may be difficult to implement. > > What do you think? Thanks! > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds >
* Simon Horman <horms@verge.net.au> [190205 10:58]: > On Tue, Feb 05, 2019 at 09:07:38AM +0100, Geert Uytterhoeven wrote: > > Hi Tony, > > > > On Mon, Feb 4, 2019 at 9:37 PM Tony Lindgren <tony@atomide.com> wrote: > > > These are automatically selected with make multi_v7_defconfig, > > > except for SH_DMAE which is selected only by sound/soc/sh/Kconfig. > > > > > > Cc: Arnd Bergmann <arnd@arndb.de> > > > Cc: Geert Uytterhoeven <geert+renesas@glider.be> > > > Cc: Olof Johansson <olof@lixom.net> > > > Cc: Russell King <linux@armlinux.org.uk> > > > Cc: Simon Horman <horms+renesas@verge.net.au> > > > Signed-off-by: Tony Lindgren <tony@atomide.com> > > > > Thanks, this matches similar changes to shmobile_defconfig in commit > > 4162325afd0d553c ("ARM: shmobile: defconfig: Refresh for v5.0-rc1") > > in next. > > > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> > > Acked-by: Simon Horman <horms+renesas@verge.net.au> > > > > > I didn't update multi_v7_defconfig to avoid conflicts. > > IMHO the arm-soc maintainers should handle the refresh of the common > > config on a regular basis[*]. > > > > [*] When is the right time? I'd say it should be the last commit just > > before the release of rc1 (so all arm-soc submaintainers' trees will > > have the new base in their for-next branches for the next merge > > window), but that may be difficult to implement. > > > > What do you think? Thanks! Yeah I agree we should do it on regular basis just before -rc1 for multi_v7_defconfig. The reasoning being that make savedefconfig is pretty much useless otherwise for generating defconfig patches and the chances of pointless merge conflicts and errors keep increasing until something breaks :) I can attempt to do a late branch of the dropped and moved options refreshed against arm-soc defconfig branch if that helps. Regards, Tony
Hi Tony, On Tue, Feb 5, 2019 at 5:11 PM Tony Lindgren <tony@atomide.com> wrote: > * Simon Horman <horms@verge.net.au> [190205 10:58]: > > On Tue, Feb 05, 2019 at 09:07:38AM +0100, Geert Uytterhoeven wrote: > > > On Mon, Feb 4, 2019 at 9:37 PM Tony Lindgren <tony@atomide.com> wrote: > > > > These are automatically selected with make multi_v7_defconfig, > > > > except for SH_DMAE which is selected only by sound/soc/sh/Kconfig. > > > > > > > > Cc: Arnd Bergmann <arnd@arndb.de> > > > > Cc: Geert Uytterhoeven <geert+renesas@glider.be> > > > > Cc: Olof Johansson <olof@lixom.net> > > > > Cc: Russell King <linux@armlinux.org.uk> > > > > Cc: Simon Horman <horms+renesas@verge.net.au> > > > > Signed-off-by: Tony Lindgren <tony@atomide.com> > > > > > > Thanks, this matches similar changes to shmobile_defconfig in commit > > > 4162325afd0d553c ("ARM: shmobile: defconfig: Refresh for v5.0-rc1") > > > in next. > > > > > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> > > > > Acked-by: Simon Horman <horms+renesas@verge.net.au> > > > > > > > > I didn't update multi_v7_defconfig to avoid conflicts. > > > IMHO the arm-soc maintainers should handle the refresh of the common > > > config on a regular basis[*]. > > > > > > [*] When is the right time? I'd say it should be the last commit just > > > before the release of rc1 (so all arm-soc submaintainers' trees will > > > have the new base in their for-next branches for the next merge > > > window), but that may be difficult to implement. > > > > > > What do you think? Thanks! > > Yeah I agree we should do it on regular basis just before -rc1 > for multi_v7_defconfig. > > The reasoning being that make savedefconfig is pretty much useless > otherwise for generating defconfig patches and the chances of > pointless merge conflicts and errors keep increasing until > something breaks :) That's why I never copy blindly a saved defconfig over multi_v7_defconfig, but diff the saved defconfig before/after, and apply that patch to multi_v7_defconfig.... > I can attempt to do a late branch of the dropped and moved options > refreshed against arm-soc defconfig branch if that helps. That's up to the arm-soc maintainers, I think. Gr{oetje,eeting}s, Geert
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -227,7 +227,6 @@ CONFIG_VIRTIO_NET=y CONFIG_B53_SPI_DRIVER=m CONFIG_B53_MDIO_DRIVER=m CONFIG_B53_MMAP_DRIVER=m -CONFIG_B53_SRAB_DRIVER=m CONFIG_NET_DSA_BCM_SF2=m CONFIG_SUN4I_EMAC=y CONFIG_BCMGENET=m @@ -256,7 +255,6 @@ CONFIG_BROADCOM_PHY=y CONFIG_ICPLUS_PHY=y CONFIG_MARVELL_PHY=y CONFIG_MICREL_PHY=y -CONFIG_REALTEK_PHY=y CONFIG_ROCKCHIP_PHY=y CONFIG_SMSC_PHY=y CONFIG_USB_PEGASUS=y @@ -871,7 +869,6 @@ CONFIG_UNIPHIER_MDMAC=y CONFIG_XILINX_DMA=y CONFIG_QCOM_BAM_DMA=y CONFIG_DW_DMAC=y -CONFIG_SH_DMAE=y CONFIG_RCAR_DMAC=y CONFIG_RENESAS_USB_DMAC=m CONFIG_VIRTIO_PCI=y
These are automatically selected with make multi_v7_defconfig, except for SH_DMAE which is selected only by sound/soc/sh/Kconfig. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Olof Johansson <olof@lixom.net> Cc: Russell King <linux@armlinux.org.uk> Cc: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Tony Lindgren <tony@atomide.com> --- arch/arm/configs/multi_v7_defconfig | 3 --- 1 file changed, 3 deletions(-)