From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932170AbWDFTlV (ORCPT ); Thu, 6 Apr 2006 15:41:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932173AbWDFTlV (ORCPT ); Thu, 6 Apr 2006 15:41:21 -0400 Received: from mx2.suse.de ([195.135.220.15]:55230 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S932170AbWDFTlV (ORCPT ); Thu, 6 Apr 2006 15:41:21 -0400 Date: Thu, 06 Apr 2006 21:41:10 +0200 Message-ID: From: Takashi Iwai To: Rene Herman Cc: ALSA devel , Linux Kernel Subject: Re: [ALSA 1/2] continue on IS_ERR from platform device registration In-Reply-To: <44347822.9050206@keyaccess.nl> References: <44347822.9050206@keyaccess.nl> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta25) (eggplant) (+CVS-20060326) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Thu, 06 Apr 2006 04:08:34 +0200, Rene Herman wrote: > > Rene Herman wrote: > > > Yes. I don't see a significantly cleaner solution then than the > > slightly hackish "using drvdata as a private success flag" that I > > posted before. Example patch versus snd_adlib attached again. This > > seems to work well. > > > > Takashi: do you agree? If the probe() method return is not going to > > be propagated up, there are few other options. > > > > (Continuing the loop on IS_ERR(device) is then also a bit > > questionable again as the IS_ERR then signifies an eror in the bowels > > of the device model, but I feel it's still the correct thing to do) > > If you do agree, here's both patches generated against 2.6.17-rc1-mm1. > First, the continue on IS_ERR one again. Well, I'm not so confident that it's the way to go. The problem is that currently the ALSA ISA driver wants to refuse loading (and modprobe returns an error) when no devices are found at loading time. On 2.2/2.4 kernels, PCI drivers also show the same behavior, but it was changed for a good reason. Then, shouldn't be the ISA drivers changed to follow the same style? That is, we keep pnp_driver and platform_driver regardless probe calls succeeded or not. They can be, in theory, later bound/activated over sysfs. At least it would make the code more simpler, I guess. Takashi