From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753247AbZHSVhW (ORCPT ); Wed, 19 Aug 2009 17:37:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753172AbZHSVhV (ORCPT ); Wed, 19 Aug 2009 17:37:21 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:33822 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753114AbZHSVhU convert rfc822-to-8bit (ORCPT ); Wed, 19 Aug 2009 17:37:20 -0400 From: "Rafael J. Wysocki" To: Stephen Rothwell Subject: Re: linux-next: suspend tree build warnings Date: Wed, 19 Aug 2009 23:38:03 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.31-rc6-rjw; KDE/4.3.0; x86_64; ; ) Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, pm list , Alan Stern , Mauro Carvalho Chehab , linux-media@vger.kernel.org References: <20090819172419.2cf53008.sfr@canb.auug.org.au> In-Reply-To: <20090819172419.2cf53008.sfr@canb.auug.org.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Message-Id: <200908192338.03910.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 19 August 2009, Stephen Rothwell wrote: > Hi Rafael, Hi, > Today's linux-next build (x86_64 allmodconfig) produced these warnings: > > drivers/media/dvb/frontends/dib7000p.c: In function ‘dib7000p_i2c_enumeration’: > drivers/media/dvb/frontends/dib7000p.c:1315: warning: the frame size of 2256 bytes is larger than 2048 bytes > drivers/media/dvb/frontends/dib3000mc.c: In function ‘dib3000mc_i2c_enumeration’: > drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2160 bytes is larger than 2048 bytes > > Introduced by commit 99307958cc9c1b0b2e0dad4bbefdafaf9ac5a681 ("PM: > Introduce core framework for run-time PM of I/O devices (rev. 17)"). Well. This commit increases the size of struct device quite a bit and both of the drivers above create a "state" object on the stack that contains struct device among other things. I think they should allocate these objects using kmalloc() and I don't know what I can do about this, really. Maybe except for modifying the drivers to use kmalloc(). Thanks, Rafael