From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: OMAP34xx Date: Sun, 5 Feb 2012 10:59:40 -0800 Message-ID: <20120205185939.GN1426@atomide.com> References: <20120204185453.GB17309@n2100.arm.linux.org.uk> <20120204190109.GL20333@atomide.com> <20120204203453.GD17309@n2100.arm.linux.org.uk> <20120205172528.GA17029@n2100.arm.linux.org.uk> <20120205174700.GU20333@atomide.com> <20120205180812.GH17309@n2100.arm.linux.org.uk> <20120205183316.GL1426@atomide.com> <20120205184139.GI17309@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-02-ewr.mailhop.org ([204.13.248.72]:22912 "EHLO mho-02-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754870Ab2BES7o (ORCPT ); Sun, 5 Feb 2012 13:59:44 -0500 Content-Disposition: inline In-Reply-To: <20120205184139.GI17309@n2100.arm.linux.org.uk> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Russell King - ARM Linux Cc: Tero Kristo , linux-omap@vger.kernel.org, Arnd Bergmann , Olof Johansson * Russell King - ARM Linux [120205 10:10]: > On Sun, Feb 05, 2012 at 10:33:16AM -0800, Tony Lindgren wrote: > > * Russell King - ARM Linux [120205 09:37]: > > > So in the meantime, people should put up with the kernel reporting an > > > "Error" at error-message level at boot time because they didn't configure > > > something? > > > > > > No, it needs fixing, because it doesn't justify being an error. It's > > > wrong, plain and simple. Again, if you don't want to send it during > > > -rc, I'll send it to Linus as a patch for him to decide whether he wants > > > to take it as -rc material. > > > > Hmm, maybe I misunderstood you. > > > > Certainly fixing the "Error" makes sense for -rc, but are also thinking > > about adding error checking to all platform_device_register() calls? > > I do think they're valid for -rc, because should it fail, things won't > work as one desires. OK, this easily gets into the area where we might get flames from Linus like "fixing features during -rc that never worked properly before".. > I did stop short of fixing it properly - and by "properly" I mean that > if we fail to register the platform data for the device, then we should > not register the device itself. That involves a change of behaviour in > the setup of the system which _might_ cause a regression. > > Whereas, merely printing an error for a failure to register a device > wouldn't be a regression (it might uncover another error, but that's > arguably a good thing.) OK that sounds safe to me. > The last bit of "properly" which needs discussion is concerning whether > we should even be trying to register this devices platform data and > device structure if WL12XX_PLATFORM_DATA is not enabled - if this is > not enabled the platform data won't be stored, and presumably the > wireless driver will be missing some vital platform data. That sounds like the way to go to me. > It seems silly to have the device registered without the platform data, > so that if the module is built for the kernel, it could be inserted and > bound to that device... > > So even for this apparantly simple looking issue, there's some searching > questions that need answering. I doubt that there's anything else behind it except trying to leave out some ifdefs. Regards, Tony