On Tue, Apr 09, 2019 at 08:44:26PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-04-09 15:40:54)
> > From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> >
> > It's much easier to figure out why the SDVO encoder refuses to cooperate
> > if we can see what status we got back.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_sdvo.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > b/drivers/gpu/drm/i915/intel_sdvo.c
> > index d5a95eca23ba..5d928f6d0028 100644
> > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > @@ -516,7 +516,7 @@ static bool intel_sdvo_read_response(struct intel_sdvo
> > *intel_sdvo,
> > u8 status;
> > int i, pos = 0;
> > #define BUF_LEN 256
> > - char buffer[BUF_LEN];
> > + char buffer[BUF_LEN] = {};
>
> I should stop quibbling over a 256b memset.
Hmm. I wonder if 256 bytes isn't a bit excessive actually.
Max 8 responses 3 chars each, and 21 or so bytes for the status string.
Comes to a total of 45 chars. A bit more for intel_sdvo_debug_write()
since it wants to print the command name.
>
> > /*
> > @@ -581,7 +581,8 @@ static bool intel_sdvo_read_response(struct intel_sdvo
> > *intel_sdvo,
> > return true;
> >
> > log_fail:
> > - DRM_DEBUG_KMS("%s: R: ... failed\n", SDVO_NAME(intel_sdvo));
> > + DRM_DEBUG_KMS("%s: R: ... failed %s\n",
> > + SDVO_NAME(intel_sdvo), buffer);
>
> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
> -Chris
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
