From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753024AbdARMaL convert rfc822-to-8bit (ORCPT ); Wed, 18 Jan 2017 07:30:11 -0500 Received: from mga02.intel.com ([134.134.136.20]:21359 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751256AbdARMaK (ORCPT ); Wed, 18 Jan 2017 07:30:10 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,249,1477983600"; d="scan'208";a="810332638" From: Jani Nikula To: Sreedhar Donelli , daniel.vetter@intel.com, linux-kernel@vger.kernel.org Cc: airlied@linux.ie, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Subject: Re: drm/i915: avoid "may be used uninitialized" warnings In-Reply-To: <87bmv44vn6.fsf@intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <87bmv44vn6.fsf@intel.com> Date: Wed, 18 Jan 2017 14:30:06 +0200 Message-ID: <87inpc360h.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 18 Jan 2017, Jani Nikula wrote: > On Wed, 18 Jan 2017, Sreedhar Donelli wrote: >> compilation issue on kernel-4.10-rc4 is resolved and i created a patch file. >> please find the attachment for patch file. > > There are several issues with this contribution. Please learn to use git > send-email to send your patches. Don't attach them. You need to write a > proper commit message. That commit message needs to include a > Signed-off-by tag. You absolutely can't have a disclaimer about > confidential/privileged with the patch. See > Documentation/process/submitting-patches.rst. > > On the content, there are no issues in the code, the compiler just seems > unable to figure it out. If we were to "fix" this, for sure we don't > need the superfluous changes included in this patch. This came out less polite than I intended. Apologies. Please do pay attention to the submitting-patches.rst document when contributing. BR, Jani. >> >> I have taken this issue from below link >> >> https://lkml.org/lkml/2017/1/16/89 >> >> >> >> Thanks & Regards >> Sreedhar Donelli >> Tata Consultancy Services >> Ph:-   +91 8019039399 >> Cell:- +91 8019039399 >> Mailto: sreedhar.donelli@tcs.com >> Website: http://www.tcs.com >> ____________________________________________ >> Experience certainty. IT Services >> Business Solutions >> Consulting >> ____________________________________________ >> >> =====-----=====-----===== >> Notice: The information contained in this e-mail >> message and/or attachments to it may contain >> confidential or privileged information. If you are >> not the intended recipient, any dissemination, use, >> review, distribution, printing or copying of the >> information contained in this e-mail message >> and/or attachments to it are strictly prohibited. If >> you have received this communication in error, >> please notify us by reply e-mail or telephone and >> immediately and permanently delete the message >> and any attachments. Thank you >> >> >> diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c >> --- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c 2017-01-17 18:18:56.564887392 +0530 >> +++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c 2017-01-17 19:18:50.524978315 +0530 >> @@ -2364,7 +2364,7 @@ >> struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm); >> struct sgt_iter sgt_iter; >> gen8_pte_t __iomem *gtt_entries; >> - gen8_pte_t gtt_entry; >> + gen8_pte_t gtt_entry = I915_NULL_PTE; >> dma_addr_t addr; >> int rpm_atomic_seq; >> int i = 0; >> @@ -2385,8 +2385,10 @@ >> * of NUMA access patterns. Therefore, even with the way we assume >> * hardware should work, we must keep this posting read for paranoia. >> */ >> - if (i != 0) >> + if (i != 0){ >> + gen8_pte_t last_gtt_entry = readq(>t_entries[i-1]); >> WARN_ON(readq(>t_entries[i-1]) != gtt_entry); >> + } >> >> /* This next bit makes the above posting read even more important. We >> * want to flush the TLBs only after we're certain all the PTE updates >> @@ -2439,7 +2441,7 @@ >> struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm); >> struct sgt_iter sgt_iter; >> gen6_pte_t __iomem *gtt_entries; >> - gen6_pte_t gtt_entry; >> + gen6_pte_t gtt_entry = I915_NULL_PTE; >> dma_addr_t addr; >> int rpm_atomic_seq; >> int i = 0; >> @@ -2453,14 +2455,17 @@ >> iowrite32(gtt_entry, >t_entries[i++]); >> } >> >> - /* XXX: This serves as a posting read to make sure that the PTE has >> + /* >> + * XXX: This serves as a posting read to make sure that the PTE has >> * actually been updated. There is some concern that even though >> * registers and PTEs are within the same BAR that they are potentially >> * of NUMA access patterns. Therefore, even with the way we assume >> * hardware should work, we must keep this posting read for paranoia. >> */ >> - if (i != 0) >> + if (i != 0) { >> + gen8_pte_t last_gtt_entry = readl(>t_entries[i-1]); >> WARN_ON(readl(>t_entries[i-1]) != gtt_entry); >> + } >> >> /* This next bit makes the above posting read even more important. We >> * want to flush the TLBs only after we're certain all the PTE updates >> diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h >> --- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h 2017-01-17 18:18:56.564887392 +0530 >> +++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h 2017-01-17 19:19:57.196980002 +0530 >> @@ -54,6 +54,7 @@ >> #define GEN6_PTE_UNCACHED (1 << 1) >> #define GEN6_PTE_VALID (1 << 0) >> >> +#define I915_NULL_PTE 0 >> #define I915_PTES(pte_len) (PAGE_SIZE / (pte_len)) >> #define I915_PTE_MASK(pte_len) (I915_PTES(pte_len) - 1) >> #define I915_PDES 512 -- Jani Nikula, Intel Open Source Technology Center