Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <c4bcdf14e0a60a679429eebd439b2380d97dafe9.camel@gmail.com>
Subject: Re: [PATCH v4 1/2] lib: devres: add a helper function for ioremap_uc
From:   Tuowen Zhao <ztuowen@gmail.com>
To:     lee.jones@linaro.org, linux-kernel@vger.kernel.org,
        AceLan Kao <acelan.kao@canonical.com>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Luis Chamberlain <mcgrof@kernel.org>
Date:   Mon, 14 Oct 2019 13:15:53 -0600
In-Reply-To: <201910150232.F7RTW83B%lkp@intel.com>
References: <20191014153344.8996-1-ztuowen@gmail.com>
         <201910150232.F7RTW83B%lkp@intel.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.1 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 2019-10-15 at 02:46 +0800, kbuild test robot wrote:
> -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         GCC_VERSION=7.4.0 make.cross ARCH=sparc64 

Oops, I'm not sure how would we best fix this. Clearly the patch is not
intended for sparc64. Maybe adding devm_ioremap_uc is rather not safe
right now.

Although, We could declare dummies for these architectures like it has
been for powerpc.

I just noticed another driver having this issue, and fixed with direct
calls to ioremap_uc().

3cc2dac5be3f2: drivers/video/fbdev/atyfb: Replace MTRR UC hole with
strong UC

Tuowen