From: Dan Carpenter <dan.carpenter@oracle.com> To: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: devel@driverdev.osuosl.org, Rodolfo Giometti <giometti@enneenne.com>, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>, Wolfram Sang <wsa@the-dreams.de>, Takashi Iwai <tiwai@suse.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, alsa-devel@alsa-project.org, "James E.J. Bottomley" <JBottomley@parallels.com>, Jaroslav Kysela <perex@perex.cz>, Mark Brown <broonie@kernel.org>, linux-i2c@vger.kernel.org, Willy Tarreau <willy@meta-x.org>, linux-spi@vger.kernel.org, netdev@vger.kernel.org, Jean Delvare <jdelvare@suse.de> Subject: Re: [PATCH 01/14] parport: return value of attach and parport_register_driver Date: Wed, 8 Apr 2015 15:27:37 +0300 [thread overview] Message-ID: <20150408122737.GK10964@mwanda> (raw) In-Reply-To: <20150408115010.GA11153@sudip-PC> 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
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com> To: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: devel@driverdev.osuosl.org, Rodolfo Giometti <giometti@enneenne.com>, linux-scsi@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>, Wolfram Sang <wsa@the-dreams.de>, Takashi Iwai <tiwai@suse.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, "James E.J. Bottomley" <JBottomley@parallels.com>, Jaroslav Kysela <perex@perex.cz>, Mark Brown <broonie@kernel.org>, linux-i2c@vger.kernel.org, Willy Tarreau <willy@meta-x.org>, alsa-devel@alsa-project.org, netdev@vger.kernel.org, Jean Delvare <jdelvare@suse.de> Subject: Re: [PATCH 01/14] parport: return value of attach and parport_register_driver Date: Wed, 8 Apr 2015 15:27:37 +0300 [thread overview] Message-ID: <20150408122737.GK10964@mwanda> (raw) In-Reply-To: <20150408115010.GA11153@sudip-PC> 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
next prev parent reply other threads:[~2015-04-08 12:28 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-04-08 11:20 [PATCH 00/14] parport: check success of attach call Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 01/14] parport: return value of attach and parport_register_driver Sudip Mukherjee 2015-04-08 11:38 ` Dan Carpenter 2015-04-08 11:38 ` Dan Carpenter 2015-04-08 11:44 ` Dan Carpenter 2015-04-08 11:44 ` Dan Carpenter 2015-04-08 12:14 ` Sudip Mukherjee 2015-04-08 12:14 ` Sudip Mukherjee 2015-04-08 11:50 ` Sudip Mukherjee 2015-04-08 11:50 ` Sudip Mukherjee 2015-04-08 12:27 ` Dan Carpenter [this message] 2015-04-08 12:27 ` Dan Carpenter 2015-04-08 17:56 ` Willy Tarreau 2015-04-08 17:56 ` Willy Tarreau 2015-04-08 11:20 ` [PATCH 02/14] ALSA: portman2x4: return proper error values from attach Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 13:32 ` Sergei Shtylyov 2015-04-08 13:32 ` Sergei Shtylyov 2015-04-08 13:40 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 03/14] ALSA: mts64: " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 04/14] staging: panel: " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 05/14] spi: lm70llp: " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 06/14] spi: butterfly: " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 07/14] [SCSI] ppa: " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 08/14] [SCSI] imm: " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 09/14] pps: " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 10/14] " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 11/14] net: plip: " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 12/14] i2c-parport: " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee 2015-04-09 7:13 ` Wolfram Sang 2015-04-09 7:13 ` Wolfram Sang 2015-04-09 9:33 ` Jean Delvare 2015-04-09 10:25 ` Wolfram Sang 2015-04-09 10:25 ` Wolfram Sang 2015-04-10 5:05 ` Sudip Mukherjee 2015-04-10 5:05 ` Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 13/14] ppdev: " Sudip Mukherjee 2015-04-08 11:20 ` [PATCH 14/14] char: lp: " Sudip Mukherjee 2015-04-08 11:20 ` Sudip Mukherjee
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150408122737.GK10964@mwanda \ --to=dan.carpenter@oracle.com \ --cc=JBottomley@parallels.com \ --cc=alsa-devel@alsa-project.org \ --cc=arnd@arndb.de \ --cc=broonie@kernel.org \ --cc=devel@driverdev.osuosl.org \ --cc=giometti@enneenne.com \ --cc=gregkh@linuxfoundation.org \ --cc=jdelvare@suse.de \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=perex@perex.cz \ --cc=sudipm.mukherjee@gmail.com \ --cc=tiwai@suse.de \ --cc=willy@meta-x.org \ --cc=wsa@the-dreams.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.