<snip> > > >> >> > >> >> > > >> >> > The patch still holds true for CRC though as it is listed > >> >> > separately below > >> >> > https://urldefense.proofpoint.com/v2/url?u=https- > >> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a- > >> >2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB- > >> >fmvgGV3o- > >> > >>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc > >W > >> > >>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c&e > >= > >> >> > profile/exploration-tools/feature-names-for-a-profile > >> >CRC is mandatory starting in V8.1, refer to Arm-ARM document. > >> > > >> >> > > >> >> > Also, looks like sve2 support in n2 core might be optional as > >> >> > per > >> >above doc? > >> >> I need to check on this. Some of the info here might not be public > >yet. > >> >I found [1]. SVE2 is mandatory feature. > >> > > >> > >> I see thanks for the info I will remove extension from cnxk. > >> > >> Do you think the extension infra is still useful for other cases? i.e. > >older cores > >> or cases where vendor wants to enable some extensions by default? > >> > >> I found a document[1] which describes about extensions not enabled > >by > >> default but supported by a given march. > >> In case of n2 I think memory tagging is one such feature > >I think the reference is providing a different information than what > >you are trying to achieve here. > > > >It looks like you are trying to address a use case where in the same > >CPU IP has different features enabled/disabled on different SoCs. > >This is a valid use case from crypto perspective (due to export control > >reasons) where-in 2 different SoCs might have crypto enabled/disabled. > >I am not sure if other features can be enabled/disabled. But, Crypto > >feature is a good enough reason to address such a use case. > > Yes, that's my intension apologies if the commit log doesn't clarify it > properly. > > > > >IMO, we should capture the SoC specific details in SoC specific files, > >in this case in 'arm64_cn10k_linux_gcc'. I believe there were some > >challenges in doing this. > > Since, all the flags are populated through soc_* variable and > arm64_cn10k_linux_gcc also translates to soc_cn10k I believe the extensions > should be reported through > soc_* variables. IMO, there will be more SoCs in the future. I prefer to not grow meson.build. > > Also, do you think +crypto needs to be removed from default n2 config as its > optional? Agree. Better to move it to SoC specific configuration.
> > >Juraj, do you remember the exact issue? > > > >> > >> [1]https://urldefense.proofpoint.com/v2/url?u=https- > >3A__developer.arm.com_tools-2Dand-2Dsoftware_open-2Dsource- > >2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB- > >fmvgGV3o-g_fjLhk5Pupi9ijohpc&m=0oZnXDnO- > >oYL9lESEaZt_nH_kK8Nc3m0tvdEPpKeFZc&s=WxrPoWhkM2QIFGEKezPK > >D9oEn7nGFvvgS2ul9ZYx-Kg&e= > >> software/developer-tools/gnu-toolchain/architecture-support > >> > >> > >> >[1] https://urldefense.proofpoint.com/v2/url?u=https- > >> >3A__developer.arm.com_ip- > >> >2Dproducts_processors_neoverse_neoverse- > >> > >>2Dn2&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB > >- > >> >fmvgGV3o- > >> > >>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc > >W > >> >d9nAmM&s=kP_X-Co0cl4pZ64BZqy5rAFUlkMZE- > >3EhTVBabm3SW8&e= > >> > > >> ><snip>
