On Mon, 9 Jan 2023 at 10:34, Marijn Suijten <marijn.suijten@xxxxxxxxxxxxxx> wrote: > > On 2023-01-08 23:11:13, Dmitry Baryshkov wrote: > > Different entries into the catalog were added quite randomly. Enforce > > the sorting order of some kind. It is not alphabetic to prevent the > > patch from growing uncontrollably. > > Why not sort these chronologically based on DPU hardware revision in the > match table at the end of this file? If we keep the SoC name as part of the symbolic name, we will end up in another semi-random order that is a pain to verify. Would you remember that sm6350 comes between sm6115 and qcm2290? I would not :-( And changing all names to dpu_6_5_0_lms would make it easy to add but nearly impossible to follow. > Regardless, this patch is going to > make it hard to properly rebase DPU additions; see for example patch 4/8 > and 5/8 in my second round of DSC fixes. Yes, quite unfortunate. As I wrote, it's already late to apply this patch :-( > > At the same time we should find a solution to the wishy-washy reuse of > structs and defines, which may appear the same initially but become > mismatched as more features are added (see how I had to split out > multiple of these in the INTF TE enablement series). It's a slightly different problem, but yes, I share the pain. > > > 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. -- With best wishes Dmitry
