From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754072AbbKLNty (ORCPT ); Thu, 12 Nov 2015 08:49:54 -0500 Received: from mout.kundenserver.de ([217.72.192.73]:64277 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753478AbbKLNtv (ORCPT ); Thu, 12 Nov 2015 08:49:51 -0500 From: Arnd Bergmann To: Fengguang Wu Cc: Mark Rutland , devicetree@vger.kernel.org, Pawel Moll , Ian Campbell , Vinod Koul , jcm@redhat.com, timur@codeaurora.org, agross@codeaurora.org, linux-kernel@vger.kernel.org, Sinan Kaya , Rob Herring , kbuild-all@01.org, Kumar Gala , dmaengine@vger.kernel.org, linux-arm-msm@vger.kernel.org, Dan Williams , linux-arm-kernel@lists.infradead.org, cov@codeaurora.org Subject: Re: [kbuild-all] [PATCH V3 4/4] dma: add Qualcomm Technologies HIDMA channel driver Date: Thu, 12 Nov 2015 14:49 +0100 Message-ID: <4850864.TsBisV6LLx@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151112082015.GA9099@wfg-t540p.sh.intel.com> References: <201511090323.GmbQltpW%fengguang.wu@intel.com> <4119660.BobUIRMK6T@wuerfel> <20151112082015.GA9099@wfg-t540p.sh.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:J7QwyW7pLwUGOwJ1uEn39svHe+BRyB1deSnqa2ddsvz3RWxneJC h5ZWYWSGaR+5WpVvl0Uvm2GL4Il+YsP2PzcDNM995zh9HdR0EHVUA3NkFZ9SX+EKccoypfn 822qtbPD8M/rXXsErgiH7uBVxuVa3Q5LDDyf50LE99xArrfsFiVnEvvsz6DFrN6j7znMXm7 o/L4K5UXZBrHH/ReYgkRQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:OZAwSHAvxvE=:OkdETCDZ3m9I/HxvdsXdhe HKjR1I+7MltGt4vw8gjGxJ2ADqxwcPs1uVfau/GPO6BB5CnptHr9hlABfJbFVeUxjxZ1I+8+N XIA08xltO7/fRysHr4HIMgD/1P0aYjGbg3smsFNFweeXwCodxnM54ivHqjrOCEBo8BKxvw9n5 hbRcSRaCLX2n30qAvqgRnL6IfaQ6ilN5YzznuHr9uFMKb5FikkXvbu9XI0w7uqq28ybq0Ut5d /Dt5zGvOxmnS7oi5rXahzt3wBAEDleuLjPtREFm+OZBBA6LFGC3iLswjJSbsJwb28fDy98vyF 9EOhPH5UDy0nItmHjxHc0BrMBzCb9QOIOqGTghU13n0kKQr7JX26JlR14uCYJi1v5BPqZ4IRU AJyt88Q3r/n0C+YtOY8r7WJQ/gGPm3d6KdEu3JO/WcTQBFGdfMYg7e6QFkVBopSE/qB9UGycP GP8eoA/cYO/9ETlNyOS8rQydKAWZSDHA6IMDjmFGvuKWjSp148dB8xSvQhQGVw63pN3AqtbUJ R1U+UiE+DsfGUsmdtRjbB/syS5HW6YtFDvOB4uhcEXITeNhPJw6MDH/1xyDifiufnP1F8wyNz 4Hkc66XU/GPSX9k6VCkcrcXYzdamk62gpUeNXPciyU3eKk4LN6xKpuTc6rMMZv4l9cICN9DlC m/Wbz8S8GjdIGAaMHS70Ap1kcDX+fgSinNx5D5jxp5iCT+LxGzS2SR11YFaQ3RI701bCvFecW nwbiBY17ONtJ7FLM Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 12 November 2015 16:20:15 Fengguang Wu wrote: > Hi Arnd, > > On Wed, Nov 11, 2015 at 09:42:00AM +0100, Arnd Bergmann wrote: > > On Wednesday 11 November 2015 10:21:03 Fengguang Wu wrote: > > > Hi Sinan, > > > > > > Sorry please ignore this warning -- it's actually a problem specific > > > to the mn10300 arch. I'll disable such warning in mn10300 in future. > > > > I just tried to find what happened here. mn10300 appears to define > > the type based on the gcc version: > > > > #if __GNUC__ == 4 > > typedef unsigned int __kernel_size_t; > > typedef signed int __kernel_ssize_t; > > #else > > typedef unsigned long __kernel_size_t; > > typedef signed long __kernel_ssize_t; > > #endif > > > > while gcc defines it based on whether you are using a Linux targetted > > gcc or a bare-metal one: > > > > gcc/config/mn10300/linux.h:#undef SIZE_TYPE > > gcc/config/mn10300/mn10300.h:#undef SIZE_TYPE > > gcc/config/mn10300/mn10300.h:#define SIZE_TYPE "unsigned int" > > > > I can think of two reasons why it went wrong here: > > > > a) You are using gcc-5.x, and the check in the kernel should be ">=" > > rather than "==". We should probably fix that regardless > > > > b) You are using a bare-metal gcc rather than a Linux version. > > > I couldn't find an mn10300 gcc on kernel.org, which one do you use? > > I used this mn10300 compiler: > > https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_am33_2.0-linux.tar.xz Ok, so this is not gcc-5.x (i.e. we are not hitting the first problem), but it uses this definition: ./lib/gcc/am33_2.0-linux/4.9.0/include/stddef.h:#define __SIZE_TYPE__ long unsigned int which does not match what the kernel expects. I see I have the same thing in my locally built am33_2.0-linux-gcc-4.9.3. I have just tried this again with a newly built am33_2.0-linux-gcc-5.2.1, and that indeed avoids almost all warnings for the mn10300 kernel. I suspect this is really a combination of two bugs that cancel each other out, but if you do the same update on your system, you will get the results you want and will no longer see the bogus warning. Arnd