All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.