On 2023-01-09 20:30:01, Dmitry Baryshkov wrote: <snip> > The usual problem is that there are two dimensions: with each > generations there are new (and removed) features, but on the other hand > within each generation there are units that are feature-rich and the > ones that are feature-deprived. qcm2290, sm6115, etc. Yes, in that case (as we currently already do) have to duplicate an existing struct and give one of the two a new feature bit. > >>>> Thus SDM comes before SC and SM > >>>> platforms and QCM is kept as the last one. There are no functional > >>>> changes in this patch. > >>>> > >>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > >>>> --- > >>>> > >>>> Yes, I hate such mass-moves too. However the entries in this file are > >>>> slowly becoming uncontrollable. Let's enforce some order now (while it's > >>>> late already, but not _that_ late). > >>> > >>> I agree that something should happen, contributing to this file is > >>> unnecessarily tough. > >> > >> In the IRC conversation Rob suggested playing with includes, but I > >> don't see a good way to implement that. > > > > That would be nice; especially if we accept struct duplication (instead > > of recursively including "earlier" versions where needed, as mentioned > > in IRC that'll spiral out of control). With that one can easily diff > > two include files and understand the differences between SoCs and/or DPU > > hardware revisions (or notice whether a certain configuration might be > > missing/extraneous). > > Let's see what kind of binary growth does it bring. In the end it well > might be that the compiler is smart enough. Curious as well, it might overlap identical structs (identical byte sequence) similar to string interning? - Marijn
