On Thu, 07 Mar 2024, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > On Thu, Mar 7, 2024 at 12:28 PM Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: >> If there's one thing that's for sure, EDIDs are full of stuff like this, >> across the board. >> >> Ignoring the whitespace at the end seemed reasonable, initially, to me >> too. But the question is, if we start catering for this, what else >> should we cater for? Do we keep adding "reasonable" interpretations, or >> just go by the spec? > > Personally, I don't really care a whole lot either way. If I had to > make a judgement call I think it's a little cleaner the way Hsin-Yi > has it where we ignore whitespace at the end. Given that Dmitry also > suggested ignoring whitespace at the end [1] I guess I'd believe that > he also feels it's a little cleaner that way. However, If the only way > to get the patch series landed is to put the space at the end of the > name in panel-edp.c then I'm OK with that. > > In terms of what else we should cater to, I guess we'd have to answer > that question when it comes up, with a bias against adding more > special case rules. _Hopefully_ it won't be common that we even need > this code and it will be the exception rather than the rule that > panels with incompatible timings have the same panel ID anyway... > > In any case, hopefully the above explains my opinion on this. If you > feel strongly that we should remove the code handling whitespace at > the end then so be it. If you're on the fence then I guess I'd say > let's keep it... No, I don't feel strongly, let's go with this. It's not like it's cast in stone either. BR, Jani. > > > [1] https://lore.kernel.org/lkml/CAA8EJpr7LHvqeGXhbFQ8KNn0LGDuv19cw0i04qVUz51TJeSQrA@xxxxxxxxxxxxxx/ -- Jani Nikula, Intel
