On 01/11/2024 08:47, Dmitry Baryshkov wrote: > On Fri, Nov 01, 2024 at 08:26:04AM +0100, Krzysztof Kozlowski wrote: >> On Fri, Nov 01, 2024 at 02:49:22AM +0200, Dmitry Baryshkov wrote: >>> The patterns for individual SoC families grew up to be pretty complex, >>> containing lots of special cases and optional suffixes. Split them per >>> the suffix to make it easier to extend SoC patterns. >> >> This is doing something quite different - split is not important here. >> Instead you narrow the patterns significantly and disallow things like >> msm8994pro, sc8280p or sc8280px, and allow things like sa5200p. > > Just for the sake of correctness, msm8994pro is still allowed, if I'm > not mistaken. > >> I don't see here much of pattern simplifying - dropping (pro)? really >> makes little difference. > > Patterns are simplified by being explicit. E.g. in the previous > iteration I completely didn't notice the intersection of the |p that I > have added with the existing [a-z][a-z]? pattern. If you think that > sa5200p should be disallowed, I can tune the numeric part of the > pattern. And sc8280p / sc8280px should not be allowed in the first > place, such platforms don't exist. I am fine with this, but extend the commit msg with some good rationale. Have in mind that the point of this pattern was *not* to validate SoCs names. sa5200p is fine, sc8180p is fine and all others are fine, sc8280z as well, because we do not want to grow this pattern with every new model. The only, single point of this entire binding is to disallow incorrect order of block names in compatible. Not validate the SoC names. If you need narrower patterns to achieve that objective, sure. If you need narrower patterns to validate SoC names, then nope. Best regards, Krzysztof
