From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bart Van Assche Subject: Re: next Feb 13 drivers/scsi/aha1542.ko build break Date: Fri, 13 Feb 2009 20:35:55 +0100 Message-ID: References: <20090213175526.d0590862.sfr@canb.auug.org.au> <49955D00.2020707@in.ibm.com> <4995BA4B.9050209@oracle.com> <4995C66E.1000800@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4995C66E.1000800@cisco.com> Sender: linux-scsi-owner@vger.kernel.org To: Joe Eykholt Cc: Randy Dunlap , "Sachin P. Sant" , Stephen Rothwell , linux-next@vger.kernel.org, LKML , linux-scsi List-Id: linux-next.vger.kernel.org (resending as plain text) On Fri, Feb 13, 2009 at 8:13 PM, Joe Eykholt wrote: > The kernel infrastructure should fix that without requiring the driver to change. > Drivers ought to be allowed to divide. > > I've also seen this in another driver that divided a u64 by a constant. > I noticed that linux/math64.h provides div_u64(), but it seems awkward to call > that when the compiler generates a call to __udivdi3 (apparently). > > Can't we just provide __udivdi3, since gcc generates that call? > Otherwise, problems like this will continue to crop up. A complete list of integer functions to which gcc generates calls can be found here: http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gccint/Integer-library-routines.html Some links to past discussions about this subject: * http://lkml.org/lkml/2003/7/2/5 * http://lkml.org/lkml/2004/9/23/376 Bart.