| Message ID | 20240124162857.111915-2-afd@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] ARM: multi_v7_defconfig: Add more TI Keystone support | expand |
On 10:28-20240124, Andrew Davis wrote: > TI Keystone devices can and should use the common multi-v7 defconfig. > Currently it is not clear which defconfig should be used and so config > options for Keystone boards are added to either both defconfigs, or only > one or the other. As nice as it is to have a config just for this platform > it is a maintenance burden. As it is not used by generic distros it is not > very useful to continue to maintain. Remove this defconfig. > > Signed-off-by: Andrew Davis <afd@ti.com> > --- > arch/arm/configs/keystone_defconfig | 238 ---------------------------- > 1 file changed, 238 deletions(-) > delete mode 100644 arch/arm/configs/keystone_defconfig > There are a bunch of downstream folks who will have recipe fails etc if we do that. I am not sure we need to go down that route. I know we had intent on multi_v7_defconfig -> but as far as I recollect, at least during armv7 it did'nt exactly pan out as it did on armv8.
On 1/24/24 10:41 AM, Nishanth Menon wrote: > On 10:28-20240124, Andrew Davis wrote: >> TI Keystone devices can and should use the common multi-v7 defconfig. >> Currently it is not clear which defconfig should be used and so config >> options for Keystone boards are added to either both defconfigs, or only >> one or the other. As nice as it is to have a config just for this platform >> it is a maintenance burden. As it is not used by generic distros it is not >> very useful to continue to maintain. Remove this defconfig. >> >> Signed-off-by: Andrew Davis <afd@ti.com> >> --- >> arch/arm/configs/keystone_defconfig | 238 ---------------------------- >> 1 file changed, 238 deletions(-) >> delete mode 100644 arch/arm/configs/keystone_defconfig >> > > There are a bunch of downstream folks who will have recipe fails etc if > we do that. I am not sure we need to go down that route. > That is the point of this patch, we want to stop any remaining downstream folks from using this defconfig. It is not maintained nor updated like the multi_v7_defconfig, any new or needed options will only be added to multi-v7 defconfig. > I know we had intent on multi_v7_defconfig -> but as far as I recollect, > at least during armv7 it did'nt exactly pan out as it did on armv8. > It worked for ARMv8 as it wasn't allowed go spin up custom defconfigs for every random platform. It will work here for many/most platforms just the same if they do what I'm doing here and remove their old unneeded defconfigs. Andrew
On 11:31-20240124, Andrew Davis wrote: > On 1/24/24 10:41 AM, Nishanth Menon wrote: > > On 10:28-20240124, Andrew Davis wrote: > > > TI Keystone devices can and should use the common multi-v7 defconfig. > > > Currently it is not clear which defconfig should be used and so config > > > options for Keystone boards are added to either both defconfigs, or only > > > one or the other. As nice as it is to have a config just for this platform > > > it is a maintenance burden. As it is not used by generic distros it is not > > > very useful to continue to maintain. Remove this defconfig. > > > > > > Signed-off-by: Andrew Davis <afd@ti.com> > > > --- > > > arch/arm/configs/keystone_defconfig | 238 ---------------------------- > > > 1 file changed, 238 deletions(-) > > > delete mode 100644 arch/arm/configs/keystone_defconfig > > > > > > > There are a bunch of downstream folks who will have recipe fails etc if > > we do that. I am not sure we need to go down that route. > > > > That is the point of this patch, we want to stop any remaining downstream > folks from using this defconfig. It is not maintained nor updated like > the multi_v7_defconfig, any new or needed options will only be added to > multi-v7 defconfig. > I am going to have to defer to ARM maintainers what they think.. enabling LPAE etc in common multi_v7_config. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 1/24/24 12:04 PM, Nishanth Menon wrote: > On 11:31-20240124, Andrew Davis wrote: >> On 1/24/24 10:41 AM, Nishanth Menon wrote: >>> On 10:28-20240124, Andrew Davis wrote: >>>> TI Keystone devices can and should use the common multi-v7 defconfig. >>>> Currently it is not clear which defconfig should be used and so config >>>> options for Keystone boards are added to either both defconfigs, or only >>>> one or the other. As nice as it is to have a config just for this platform >>>> it is a maintenance burden. As it is not used by generic distros it is not >>>> very useful to continue to maintain. Remove this defconfig. >>>> >>>> Signed-off-by: Andrew Davis <afd@ti.com> >>>> --- >>>> arch/arm/configs/keystone_defconfig | 238 ---------------------------- >>>> 1 file changed, 238 deletions(-) >>>> delete mode 100644 arch/arm/configs/keystone_defconfig >>>> >>> >>> There are a bunch of downstream folks who will have recipe fails etc if >>> we do that. I am not sure we need to go down that route. >>> >> >> That is the point of this patch, we want to stop any remaining downstream >> folks from using this defconfig. It is not maintained nor updated like >> the multi_v7_defconfig, any new or needed options will only be added to >> multi-v7 defconfig. >> > > I am going to have to defer to ARM maintainers what they think.. > enabling LPAE etc in common multi_v7_config. > We are not enabling LPAE in common multi_v7_config, that can't be done as many plats do not support it. Keystone will use the new multi_v7_lpae_defconfig which was just added: e9faf9b0b07a ("ARM: add multi_v7_lpae_defconfig") That is what prompted me to make this change, we now have a commonish config that works for Keystone. Andrew > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On Wed, Jan 24, 2024, at 19:52, Andrew Davis wrote: > On 1/24/24 12:04 PM, Nishanth Menon wrote: >> On 11:31-20240124, Andrew Davis wrote: >>> On 1/24/24 10:41 AM, Nishanth Menon wrote: >>>> >>>> There are a bunch of downstream folks who will have recipe fails etc if >>>> we do that. I am not sure we need to go down that route. >>>> >>> >>> That is the point of this patch, we want to stop any remaining downstream >>> folks from using this defconfig. It is not maintained nor updated like >>> the multi_v7_defconfig, any new or needed options will only be added to >>> multi-v7 defconfig. >>> >> >> I am going to have to defer to ARM maintainers what they think.. >> enabling LPAE etc in common multi_v7_config. >> > > We are not enabling LPAE in common multi_v7_config, that can't be > done as many plats do not support it. Keystone will use the new > multi_v7_lpae_defconfig which was just added: > > e9faf9b0b07a ("ARM: add multi_v7_lpae_defconfig") > > That is what prompted me to make this change, we now have a > commonish config that works for Keystone. I think adding keystone to multi_v7_defconfig is a good idea here for the reasons you explained. I don't mind keeping the other one around as well though, since keystone is a bit special. Arnd
On 20:56-20240124, Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 19:52, Andrew Davis wrote: > > On 1/24/24 12:04 PM, Nishanth Menon wrote: > >> On 11:31-20240124, Andrew Davis wrote: > >>> On 1/24/24 10:41 AM, Nishanth Menon wrote: > >>>> > >>>> There are a bunch of downstream folks who will have recipe fails etc if > >>>> we do that. I am not sure we need to go down that route. > >>>> > >>> > >>> That is the point of this patch, we want to stop any remaining downstream > >>> folks from using this defconfig. It is not maintained nor updated like > >>> the multi_v7_defconfig, any new or needed options will only be added to > >>> multi-v7 defconfig. > >>> > >> > >> I am going to have to defer to ARM maintainers what they think.. > >> enabling LPAE etc in common multi_v7_config. > >> > > > > We are not enabling LPAE in common multi_v7_config, that can't be > > done as many plats do not support it. Keystone will use the new > > multi_v7_lpae_defconfig which was just added: > > > > e9faf9b0b07a ("ARM: add multi_v7_lpae_defconfig") > > > > That is what prompted me to make this change, we now have a > > commonish config that works for Keystone. > > I think adding keystone to multi_v7_defconfig is a good > idea here for the reasons you explained. I don't mind keeping > the other one around as well though, since keystone is > a bit special. Thanks Arnd. Andrew, Could you respin the series with just patch #1 and with the bloatmeter details added to the commit message (please leave in NFS - that was the standard operation mode for most of CI systems - I'd like to continue leveraging that than have to hand test platforms.
diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig deleted file mode 100644 index 59c4835ffc977..0000000000000 --- a/arch/arm/configs/keystone_defconfig +++ /dev/null @@ -1,238 +0,0 @@ -CONFIG_POSIX_MQUEUE=y -CONFIG_HIGH_RES_TIMERS=y -CONFIG_PREEMPT=y -CONFIG_IKCONFIG=y -CONFIG_IKCONFIG_PROC=y -CONFIG_LOG_BUF_SHIFT=14 -CONFIG_CGROUPS=y -CONFIG_BLK_CGROUP=y -CONFIG_CGROUP_SCHED=y -CONFIG_CGROUP_FREEZER=y -CONFIG_CGROUP_DEVICE=y -CONFIG_CGROUP_CPUACCT=y -CONFIG_BLK_DEV_INITRD=y -# CONFIG_ELF_CORE is not set -# CONFIG_BASE_FULL is not set -CONFIG_KALLSYMS_ALL=y -CONFIG_EXPERT=y -CONFIG_PROFILING=y -CONFIG_ARCH_KEYSTONE=y -CONFIG_ARM_LPAE=y -CONFIG_PCI_KEYSTONE=y -CONFIG_SMP=y -CONFIG_HOTPLUG_CPU=y -CONFIG_ARM_PSCI=y -CONFIG_AEABI=y -CONFIG_HIGHMEM=y -CONFIG_VFP=y -CONFIG_NEON=y -# CONFIG_SUSPEND is not set -CONFIG_PM=y -CONFIG_KPROBES=y -CONFIG_MODULES=y -CONFIG_MODULE_FORCE_LOAD=y -CONFIG_MODULE_UNLOAD=y -CONFIG_MODULE_FORCE_UNLOAD=y -CONFIG_MODVERSIONS=y -# CONFIG_SWAP is not set -CONFIG_CMA=y -CONFIG_NET=y -CONFIG_PACKET=y -CONFIG_UNIX=y -CONFIG_UNIX_DIAG=y -CONFIG_XFRM_USER=y -CONFIG_XFRM_SUB_POLICY=y -CONFIG_XFRM_STATISTICS=y -CONFIG_NET_KEY=y -CONFIG_NET_KEY_MIGRATE=y -CONFIG_INET=y -CONFIG_IP_MULTICAST=y -CONFIG_IP_ADVANCED_ROUTER=y -CONFIG_IP_MULTIPLE_TABLES=y -CONFIG_IP_ROUTE_MULTIPATH=y -CONFIG_IP_ROUTE_VERBOSE=y -CONFIG_IP_PNP=y -CONFIG_IP_PNP_DHCP=y -CONFIG_IP_PNP_BOOTP=y -CONFIG_NET_IPIP=y -CONFIG_NET_IPGRE_DEMUX=y -CONFIG_NET_IPGRE=y -CONFIG_IP_MROUTE=y -CONFIG_IP_MROUTE_MULTIPLE_TABLES=y -CONFIG_IP_PIMSM_V2=y -CONFIG_INET_AH=y -CONFIG_INET_IPCOMP=y -CONFIG_INET6_XFRM_MODE_TRANSPORT=m -CONFIG_INET6_XFRM_MODE_TUNNEL=m -CONFIG_INET6_XFRM_MODE_BEET=m -CONFIG_IPV6_SIT=m -CONFIG_IPV6_MULTIPLE_TABLES=y -CONFIG_IPV6_SUBTREES=y -CONFIG_IPV6_MROUTE=y -CONFIG_IPV6_PIMSM_V2=y -CONFIG_NETFILTER=y -CONFIG_NF_CONNTRACK=y -CONFIG_NF_CT_NETLINK=y -CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y -CONFIG_NETFILTER_XT_TARGET_CONNMARK=y -CONFIG_NETFILTER_XT_TARGET_IDLETIMER=y -CONFIG_NETFILTER_XT_TARGET_MARK=y -CONFIG_NETFILTER_XT_MATCH_COMMENT=y -CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y -CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y -CONFIG_NETFILTER_XT_MATCH_CONNMARK=y -CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y -CONFIG_NETFILTER_XT_MATCH_CPU=y -CONFIG_NETFILTER_XT_MATCH_IPRANGE=y -CONFIG_NETFILTER_XT_MATCH_LENGTH=y -CONFIG_NETFILTER_XT_MATCH_MAC=y -CONFIG_NETFILTER_XT_MATCH_MARK=y -CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y -CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y -CONFIG_NETFILTER_XT_MATCH_STATE=y -CONFIG_NF_CONNTRACK_IPV4=y -CONFIG_IP_NF_IPTABLES=y -CONFIG_IP_NF_MATCH_AH=y -CONFIG_IP_NF_MATCH_ECN=y -CONFIG_IP_NF_MATCH_TTL=y -CONFIG_IP_NF_FILTER=y -CONFIG_IP_NF_TARGET_REJECT=y -CONFIG_IP_NF_MANGLE=y -CONFIG_IP_NF_TARGET_ECN=y -CONFIG_IP_NF_TARGET_TTL=y -CONFIG_IP_NF_RAW=y -CONFIG_IP_NF_ARPTABLES=y -CONFIG_IP_NF_ARPFILTER=y -CONFIG_IP_NF_ARP_MANGLE=y -CONFIG_IP6_NF_IPTABLES=m -CONFIG_IP_SCTP=y -CONFIG_VLAN_8021Q=y -CONFIG_CAN=m -CONFIG_PCI=y -CONFIG_PCI_MSI=y -CONFIG_DEVTMPFS=y -CONFIG_DEVTMPFS_MOUNT=y -CONFIG_TI_SCI_PROTOCOL=y -CONFIG_MTD=y -CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_BLOCK=y -CONFIG_MTD_PLATRAM=y -CONFIG_MTD_M25P80=y -CONFIG_MTD_RAW_NAND=y -CONFIG_MTD_NAND_DAVINCI=y -CONFIG_MTD_SPI_NOR=y -CONFIG_MTD_UBI=y -CONFIG_BLK_DEV_LOOP=y -CONFIG_SRAM=y -CONFIG_EEPROM_AT24=y -CONFIG_SCSI=y -CONFIG_BLK_DEV_SD=y -CONFIG_NETDEVICES=y -CONFIG_TI_CPTS=y -CONFIG_TI_KEYSTONE_NETCP=y -CONFIG_TI_KEYSTONE_NETCP_ETHSS=y -CONFIG_MARVELL_PHY=y -CONFIG_MICREL_PHY=y -CONFIG_DP83867_PHY=y -CONFIG_CAN_C_CAN=m -CONFIG_CAN_C_CAN_PLATFORM=m -CONFIG_INPUT_EVDEV=m -CONFIG_INPUT_MISC=y -CONFIG_INPUT_GPIO_DECODER=m -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y -CONFIG_SERIAL_OF_PLATFORM=y -# CONFIG_HW_RANDOM is not set -CONFIG_I2C=y -# CONFIG_I2C_COMPAT is not set -CONFIG_I2C_CHARDEV=y -CONFIG_I2C_DAVINCI=y -CONFIG_SPI=y -CONFIG_SPI_CADENCE_QUADSPI=y -CONFIG_SPI_DAVINCI=y -CONFIG_SPI_SPIDEV=y -CONFIG_PINCTRL_SINGLE=y -CONFIG_GPIOLIB=y -CONFIG_GPIO_SYSFS=y -CONFIG_GPIO_DAVINCI=y -CONFIG_GPIO_SYSCON=y -CONFIG_GPIO_PCA953X=m -CONFIG_POWER_RESET=y -CONFIG_POWER_RESET_KEYSTONE=y -CONFIG_POWER_SUPPLY=y -# CONFIG_HWMON is not set -CONFIG_WATCHDOG=y -CONFIG_DAVINCI_WATCHDOG=y -CONFIG_REGULATOR=y -CONFIG_REGULATOR_FIXED_VOLTAGE=y -CONFIG_USB=y -CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -CONFIG_USB_MON=y -CONFIG_USB_XHCI_HCD=y -CONFIG_USB_STORAGE=y -CONFIG_USB_DWC3=y -CONFIG_KEYSTONE_USB_PHY=y -CONFIG_NOP_USB_XCEIV=y -CONFIG_MMC=y -CONFIG_MMC_SDHCI=y -CONFIG_MMC_SDHCI_PLTFM=y -CONFIG_MMC_OMAP_HS=y -CONFIG_MMC_SDHCI_OMAP=y -CONFIG_NEW_LEDS=y -CONFIG_LEDS_CLASS=y -CONFIG_LEDS_GPIO=y -CONFIG_LEDS_TRIGGERS=y -CONFIG_LEDS_TRIGGER_ONESHOT=y -CONFIG_LEDS_TRIGGER_HEARTBEAT=y -CONFIG_LEDS_TRIGGER_BACKLIGHT=y -CONFIG_LEDS_TRIGGER_CPU=y -CONFIG_LEDS_TRIGGER_ACTIVITY=y -CONFIG_LEDS_TRIGGER_GPIO=y -CONFIG_DMADEVICES=y -CONFIG_TI_EDMA=y -CONFIG_MAILBOX=y -CONFIG_TI_MESSAGE_MANAGER=y -CONFIG_SOC_TI=y -CONFIG_KEYSTONE_NAVIGATOR_QMSS=y -CONFIG_KEYSTONE_NAVIGATOR_DMA=y -CONFIG_TI_SCI_PM_DOMAINS=y -CONFIG_MEMORY=y -CONFIG_TI_AEMIF=y -CONFIG_PWM=y -CONFIG_PWM_TIECAP=m -CONFIG_KEYSTONE_IRQ=y -CONFIG_RESET_TI_SCI=m -CONFIG_RESET_TI_SYSCON=m -CONFIG_EXT4_FS=y -CONFIG_EXT4_FS_POSIX_ACL=y -CONFIG_FANOTIFY=y -CONFIG_AUTOFS_FS=y -CONFIG_MSDOS_FS=y -CONFIG_VFAT_FS=y -CONFIG_NTFS_FS=y -CONFIG_TMPFS=y -CONFIG_JFFS2_FS=y -CONFIG_JFFS2_FS_WBUF_VERIFY=y -CONFIG_UBIFS_FS=y -CONFIG_CRAMFS=y -CONFIG_NFS_FS=y -CONFIG_NFS_V3_ACL=y -CONFIG_ROOT_NFS=y -CONFIG_NFSD=y -CONFIG_NFSD_V3_ACL=y -CONFIG_NLS_CODEPAGE_437=y -CONFIG_NLS_ISO8859_1=y -CONFIG_CRYPTO_USER=y -CONFIG_CRYPTO_AUTHENC=y -CONFIG_CRYPTO_DES=y -CONFIG_CRYPTO_CBC=y -CONFIG_CRYPTO_CTR=y -CONFIG_CRYPTO_XCBC=y -CONFIG_CRYPTO_ANSI_CPRNG=y -CONFIG_CRYPTO_USER_API_HASH=y -CONFIG_CRYPTO_USER_API_SKCIPHER=y -CONFIG_DMA_CMA=y -CONFIG_PRINTK_TIME=y -CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y -CONFIG_DEBUG_SHIRQ=y -CONFIG_DEBUG_USER=y
TI Keystone devices can and should use the common multi-v7 defconfig. Currently it is not clear which defconfig should be used and so config options for Keystone boards are added to either both defconfigs, or only one or the other. As nice as it is to have a config just for this platform it is a maintenance burden. As it is not used by generic distros it is not very useful to continue to maintain. Remove this defconfig. Signed-off-by: Andrew Davis <afd@ti.com> --- arch/arm/configs/keystone_defconfig | 238 ---------------------------- 1 file changed, 238 deletions(-) delete mode 100644 arch/arm/configs/keystone_defconfig