From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753972AbbDHM2c (ORCPT ); Wed, 8 Apr 2015 08:28:32 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:35561 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751364AbbDHM23 (ORCPT ); Wed, 8 Apr 2015 08:28:29 -0400 Date: Wed, 8 Apr 2015 15:27:37 +0300 From: Dan Carpenter To: Sudip Mukherjee Cc: devel@driverdev.osuosl.org, Rodolfo Giometti , linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, Arnd Bergmann , Wolfram Sang , Takashi Iwai , Greg Kroah-Hartman , alsa-devel@alsa-project.org, "James E.J. Bottomley" , Jaroslav Kysela , Mark Brown , linux-i2c@vger.kernel.org, Willy Tarreau , linux-spi@vger.kernel.org, netdev@vger.kernel.org, Jean Delvare Subject: Re: [PATCH 01/14] parport: return value of attach and parport_register_driver Message-ID: <20150408122737.GK10964@mwanda> References: <1428492040-5581-1-git-send-email-sudipm.mukherjee@gmail.com> <1428492040-5581-2-git-send-email-sudipm.mukherjee@gmail.com> <20150408113832.GH10964@mwanda> <20150408115010.GA11153@sudip-PC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150408115010.GA11153@sudip-PC> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 08, 2015 at 05:20:10PM +0530, Sudip Mukherjee wrote: > On Wed, Apr 08, 2015 at 02:38:32PM +0300, Dan Carpenter wrote: > > 1) We can't apply this patch on its own so this way of breaking up the > > patches doesn't work. > yes, if the first patch is reverted for any reason all the others need > to be reverted also. so then everything in one single patch? The problem is that patch 1/1 breaks the build. The rule is that we should be able to apply part of a patch series and nothing breaks. If we apply the patch series out of order than things break that's our problem, yes. But if we apply only 1/1 and it breaks, that's a problem with the series. > > > > 2) I was thinking that all the ->attach() calls would have to succeed or > > we would bail. Having some of them succeed and some fail doesn't seem > > like it will simplify the driver code very much. But I can also see > > your point. Hm... My other issue with this patch series which is related to #2 is that it's not clear that anyone is checking the return value and doing correct things with it. Hopefully, when we use the attach_ret() approach then it will be more clear if/how the return value is useful. regards, dan carpenter