On Thu, 07 Mar 2024, Doug Anderson <diand...@chromium.org> wrote: > On Thu, Mar 7, 2024 at 12:28 PM Jani Nikula <jani.nik...@linux.intel.com> > 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/caa8ejpr7lhvqegxhbfq8knn0lgduv19cw0i04qvuz51tjes...@mail.gmail.com/ -- Jani Nikula, Intel
