[Intel-gfx] [igvt-g-dev] [bug report] drm/i915/gvt: vGPU display virtualization

[Zhenyu Wang]

On 2016.11.11 08:28:28 +0000, Chris Wilson wrote:
> On Fri, Nov 11, 2016 at 04:08:58PM +0800, Zhenyu Wang wrote:
> > 
> > On 2016.11.10 15:54:51 +0300, Dan Carpenter wrote:
> > > Hello Zhi Wang,
> > > 
> > > The patch 04d348ae3f0a: "drm/i915/gvt: vGPU display virtualization"
> > > from Apr 25, 2016, leads to the following static checker warning:
> > > 
> > > 	drivers/gpu/drm/i915/gvt/edid.c:506 intel_gvt_i2c_handle_aux_ch_write()
> > > 	warn: odd binop '0x0 & 0xff'
> > > 
> > > drivers/gpu/drm/i915/gvt/edid.c
> > >    501          /* write the return value in AUX_CH_DATA reg which includes:
> > >    502           * ACK of I2C_WRITE
> > >    503           * returned byte if it is READ
> > >    504           */
> > >    505  
> > >    506          aux_data_for_write |= (GVT_AUX_I2C_REPLY_ACK & 0xff) << 24;
> > > 
> > > GVT_AUX_I2C_REPLY_ACK is 0 << 6.  Which is weird.  The whole line is a
> > > no-op.
> > 
> > This is from DP spec for AUX i2c ack reply defined as 0 that we emulated
> > to reply. I think it's ok to keep as more explicitly to show reply command.
> 
> The line is confusing though: you imply that REPLY_ACK is > 256 and that
> you only want the low 8bits stuffed into the high 8bits of the dword.
> Sounds very weird for the definition, and you wonder whether it is safe.
> 
> 	aux_data_for_write |= GVT_AUX_I2C_REPLY_ACK << 24;
> 
> is still a no-op but should not affend too many sensibilities.

Will change like that. Thanks.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20161111/97a212f2/attachment.sig>