Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp931387imm; Fri, 14 Sep 2018 08:27:52 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbeqA2wMrSBBzqUS0DHFKhmXqCPqfgcoq208k5gKHu68gIgGkbdWvxcCfjLATiFVonAhDjj X-Received: by 2002:a17:902:9a0c:: with SMTP id v12-v6mr12943864plp.159.1536938872677; Fri, 14 Sep 2018 08:27:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1536938872; cv=pass; d=google.com; s=arc-20160816; b=IHMJXBCAQSvXXI1GEgikZJZkOCfUyOqpKUbMwJWVIBeA+frhsZXIgXxqI7zQZzH/sq yKxrjUZ1JuAE2w1kvAwNtHIUwbjYlTIcIHpAmQ47dGFM2n8d9dlt9CsxFpzi1H0svqWz bWysIbvSyDuZdKxjfKUx4i514iOwreSF4DN3r08zb8JHvTahLyTzDmxTrQy1/vpcdCzO r1IacrPu3C+1/XnrUKFr9b+A5abvsiVU58TfZ2EACVdVg5wA0200QaXzEsBPHgLIrIUq ySvD+XE1Ej0TYbkvaBKAWEkj4foaQQreTUjgIRQqf2nlIxAjH4tnRwiDxZ0v08ElOAJP YbcA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature; bh=GffmJL4ug1bbgMOriT1yrq5qGaWnYnM7NZH4UB+IXVc=; b=G739mqo4HRCtULF1eoUK13aIDtFeC8UdPaEj0ErILvn5LN2dMq7QLS0D+LJSYVHPZj sVw4eZTAz6b1Bi6X0bY1daII5z95BRAPDdoIV1kG6t/eMWeo3gAgrpluyN4xNlrMNG3N Sf2L6xMGOcBLQ6Sqm4UBSyPODQFmQQ1vpbzysjHQiLmhPaEInFEh1rfqzyU9GUHiA9sa bCk3Gnz1Jzs3uurLG/i+2JeIL19S11aYGEEXcx+/Z73IFv1g9p4Ro6+g+PdfNhtVK5Hf bIpfopq3STUtPAQbZkLskX0eAKnSDIByTuA6mN4ZTdljs0G6ctRt/e8tUpl0+jHEhIMv lCjw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@az8.co header.s=dkimmail header.b=cK7l9acd; arc=pass (i=1 spf=pass spfdomain=az8.co dkim=pass dkdomain=az8.co dmarc=pass fromdomain=az8.co>); spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=az8.co Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b7-v6si7694436pfj.245.2018.09.14.08.27.37; Fri, 14 Sep 2018 08:27:52 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@az8.co header.s=dkimmail header.b=cK7l9acd; arc=pass (i=1 spf=pass spfdomain=az8.co dkim=pass dkdomain=az8.co dmarc=pass fromdomain=az8.co>); spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=az8.co Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728239AbeINUmS (ORCPT + 99 others); Fri, 14 Sep 2018 16:42:18 -0400 Received: from sender-of-o52.zoho.com ([135.84.80.217]:21447 "EHLO sender-of-o52.zoho.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726902AbeINUmS (ORCPT ); Fri, 14 Sep 2018 16:42:18 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1536938811; cv=none; d=zoho.com; s=zohoarc; b=fY3SukZrduNRG/cDYdN9ly+P/3ZCJlzpvo0OO4tCZt/sLZX8oJJB4aQUZdKUoKm5ebsbnNAIFrWIxlxf9A2hI7/mNSGyFaTWNCKjqg/p+8QikOMa9EMBSkJ/89kgMuKNFzHOQ55sQqSR3nJm6FIOg8tELnZmstbddRFRUV5A970= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1536938811; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=GffmJL4ug1bbgMOriT1yrq5qGaWnYnM7NZH4UB+IXVc=; b=gMWpqeXXtKX9Ts+GHMVkfZNjV3sfGfrxfpiq2hpoTqp07NQj45qGRS0MzmEYP2QUKGWyiYFfna3tWqtx2LY/P4HP7UVb0CE+ArPRfvC5w8NDbLJVktS2Gbrd8HyP9ZMRnidvEZ0N32Fk4CWvT+XFGt0OIV/5KhGJ5ndmNmlVDF4= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=az8.co; spf=pass smtp.mailfrom=afonsobordado@az8.co; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1536938811; s=dkimmail; d=az8.co; i=afonsobordado@az8.co; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Type:Mime-Version:Content-Transfer-Encoding; l=1080; bh=GffmJL4ug1bbgMOriT1yrq5qGaWnYnM7NZH4UB+IXVc=; b=cK7l9acdBWKONt27E/G2NJZCjD+ghpq44u/+yMQyeuXD0R9IAiFdEJO47dra1xsU B9Gw1dupgsIHwGogR0o3HYPYZMlLsi9tsp/nP3D8LL+uZHstlyCY/X3aX83hH4lN7WO yl+rMnEZeAr6vPPloXPQkhURmmv4yVtOVxRA4S04= Received: from AYYLMAO (bl9-77-228.dsl.telepac.pt [85.242.77.228]) by mx.zohomail.com with SMTPS id 1536938809664252.82219194395782; Fri, 14 Sep 2018 08:26:49 -0700 (PDT) Message-ID: <2cd9b1674ae88f153a5afe65c151cabf308e4fe7.camel@az8.co> Subject: Re: [PATCH v4 4/5] iio: fxas21002c: add ODR/Scale support From: Afonso Bordado To: Himanshu Jha Cc: kbuild-all@01.org, jic23@kernel.org, knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Date: Fri, 14 Sep 2018 16:26:44 +0100 In-Reply-To: <20180912182350.GA13032@himanshu-Vostro-3559> References: <20180911150011.31964-4-afonsobordado@az8.co> <201809121715.5Babt1QC%fengguang.wu@intel.com> <20180912182350.GA13032@himanshu-Vostro-3559> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-ZohoMailClient: External Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Thanks for your help with this. > And I suspect it may be originating from your code snippet: > > #define FXAS21002C_SCALE(scale) (IIO_DEGREE_TO_RAD(62500U >> > (scale))) > > and looking at the implementation: > > include/linux/iio/iio.h > /** > * IIO_DEGREE_TO_RAD() - Convert degree to rad > * @deg: A value in degree > * > * Returns the given value converted from degree to rad > */ > #define IIO_DEGREE_TO_RAD(deg) (((deg) * 314159ULL + 9000000ULL) / > 18000000ULL) > > This '/' operator might be the culprit! > > Just for checking that the error, remove the macro declaration > `FXAS21002C_SCALE` > plus its usage and re-cross compile using `make ARCH=i386`. > > In my case I used the `div64_s64` function handles builds for both > 32/64 > arch accordingly. Yes, this is indeed the culprit. If `div64_s64` works the same way, I wonder if the best option is to change the macro definition. I can provide a patch for this along with changing the rest of the definitions. However i would like some confirmation before starting this.