On 12:55-20200908, Tero Kristo wrote: > On 08/09/2020 02:48, Nishanth Menon wrote: > > On 19:53-20200907, Lokesh Vutla wrote: > > > > [... I should have responded to the correct patch..] > > > > Besides yaml and compatibility acks, there are a few ancillary > > > > comments to fix up.. Kconfig -> I think we should either stay with > > > > status quo and create a new config option per SoC OR rename the > > > > config to be generic (using j7200 with j721e SoC config is not very > > > > > > Please suggest your preference here. I guess separate defconfig for J7200? > > > > > > I was just scanning through remaining arm64 additions to see what others have > > done. We seem to have two options here: > > a) Just use ARCH_K3 and no specific SoC configs > > b) Specific SoC configs > > In both cases, use += instead of \ to incrementally add dtbs > > > > We have been going with (b) so far, Tero: any specific preference here? > > > > (a) has the aspect of simplicity and reduced dependencies. > > (b) Allows downstream kernels to save just a little bit and focus purely > > on SoC of interest. > > If possible, I think we should aim for a) at least for now. We have the soc > type detection code in place anyways that can be used on driver level. > Creating compile time flags should be avoided imo as much as possible and > just go with runtime detection. I can't see why saving maybe a megabyte of > memory with SoC specific kernels would be of any importance on K3 arch with > the memory amounts we have in our disposal. Agreed on (a). I see one other user (SND) beyond dtb Makefile, So, to order this right, lets first switch the users over from SOC config builds to ARCH_K3, before we drop the Kconfig definition/defconfig update in a follow on rc/version. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
