From: Jani Nikula <jani.nikula@linux.intel.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Hsin-Yi Wang <hsinyi@chromium.org>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Jessica Zhang <quic_jesszhan@quicinc.com>,
Sam Ravnborg <sam@ravnborg.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 6/6] drm/panel-edp: Fix AUO 0x405c panel naming and add a variant
Date: Fri, 08 Mar 2024 00:35:01 +0200 [thread overview]
Message-ID: <87sf11vffu.fsf@intel.com> (raw)
In-Reply-To: <CAD=FV=UKWd743ZWOgkP4Sn_aq9ca97QygdEcS93=tcGa7r7s8g@mail.gmail.com>
On Thu, 07 Mar 2024, Doug Anderson <dianders@chromium.org> wrote:
> On Thu, Mar 7, 2024 at 12:28 PM Jani Nikula <jani.nikula@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/CAA8EJpr7LHvqeGXhbFQ8KNn0LGDuv19cw0i04qVUz51TJeSQrA@mail.gmail.com/
--
Jani Nikula, Intel
prev parent reply other threads:[~2024-03-07 22:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 19:55 [PATCH v5 0/6] Match panel with identity Hsin-Yi Wang
2024-03-06 19:55 ` [PATCH v5 1/6] drm_edid: Add a function to get EDID base block Hsin-Yi Wang
2024-03-06 23:29 ` Doug Anderson
2024-03-07 12:50 ` Jani Nikula
2024-03-06 19:55 ` [PATCH v5 2/6] drm/edid: Clean up drm_edid_get_panel_id() Hsin-Yi Wang
2024-03-06 23:29 ` Doug Anderson
2024-03-07 12:51 ` Jani Nikula
2024-03-06 19:55 ` [PATCH v5 3/6] drm/edid: Add a function to match EDID with identity Hsin-Yi Wang
2024-03-06 23:29 ` Doug Anderson
2024-03-07 0:20 ` Hsin-Yi Wang
2024-03-07 0:37 ` Doug Anderson
2024-03-07 13:20 ` Jani Nikula
2024-03-07 19:34 ` Hsin-Yi Wang
2024-03-07 22:36 ` Jani Nikula
2024-03-06 19:55 ` [PATCH v5 4/6] drm/edid: Match edid quirks " Hsin-Yi Wang
2024-03-06 23:29 ` Doug Anderson
2024-03-06 19:55 ` [PATCH v5 5/6] drm/panel-edp: Match edp_panels with panel identity Hsin-Yi Wang
2024-03-06 23:30 ` Doug Anderson
2024-03-06 19:55 ` [PATCH v5 6/6] drm/panel-edp: Fix AUO 0x405c panel naming and add a variant Hsin-Yi Wang
2024-03-06 23:30 ` Doug Anderson
2024-03-07 13:28 ` Jani Nikula
2024-03-07 20:18 ` Hsin-Yi Wang
2024-03-07 20:27 ` Jani Nikula
2024-03-07 21:46 ` Doug Anderson
2024-03-07 22:35 ` Jani Nikula [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sf11vffu.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dianders@chromium.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hsinyi@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=quic_jesszhan@quicinc.com \
--cc=sam@ravnborg.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.