From: Sudip Mukherjee <sudipm.mukherjee@gmail.com> To: Dan Carpenter <dan.carpenter@oracle.com> Cc: Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jean Delvare <jdelvare@suse.de>, Wolfram Sang <wsa@the-dreams.de>, Rodolfo Giometti <giometti@enneenne.com>, "James E.J. Bottomley" <JBottomley@parallels.com>, Mark Brown <broonie@kernel.org>, Willy Tarreau <willy@meta-x.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>, devel@driverdev.osuosl.org, alsa-devel@alsa-project.org, linux-scsi@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, linux-i2c@vger.kernel.org Subject: Re: [PATCH 01/14] parport: return value of attach and parport_register_driver Date: Wed, 8 Apr 2015 17:20:10 +0530 [thread overview] Message-ID: <20150408115010.GA11153@sudip-PC> (raw) In-Reply-To: <20150408113832.GH10964@mwanda> 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? > > 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... to clarify my point more here: any system might have more than one parallel port but the module might decide to use just one. so in that case attach will return 0 for the port that it wishes to use, for others it will be a error code. So in parport_register_driver if we get error codes in all the attach calls then we know that attach has definitely failed, but atleast one 0 means one attach call has succeeded, which will happen in case of staging/panel, net/plip... > > Minor comment: No need to preserve the error code if there are lots > which we miss. We may as well hard code an error code. But that's a > minor thing. Does this actually simplify the driver code? That's the > more important thing. i don't think this will simplify the driver code, but atleast now parport_register_driver() will not report success when we have actually failed. And as a result module_init will also fail which is supposed to be the actual behviour. regards sudip > > regards, > dan carpenter >
WARNING: multiple messages have this Message-ID (diff)
From: Sudip Mukherjee <sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>, Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, Jean Delvare <jdelvare-l3A5Bk7waGM@public.gmane.org>, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>, Rodolfo Giometti <giometti-AVVDYK/kqiJWk0Htik3J/w@public.gmane.org>, "James E.J. Bottomley" <JBottomley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Willy Tarreau <willy-859RlTSWH48dnm+yROfE0A@public.gmane.org>, Jaroslav Kysela <perex-/Fr2/VpizcU@public.gmane.org>, Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH 01/14] parport: return value of attach and parport_register_driver Date: Wed, 8 Apr 2015 17:20:10 +0530 [thread overview] Message-ID: <20150408115010.GA11153@sudip-PC> (raw) In-Reply-To: <20150408113832.GH10964@mwanda> 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? > > 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... to clarify my point more here: any system might have more than one parallel port but the module might decide to use just one. so in that case attach will return 0 for the port that it wishes to use, for others it will be a error code. So in parport_register_driver if we get error codes in all the attach calls then we know that attach has definitely failed, but atleast one 0 means one attach call has succeeded, which will happen in case of staging/panel, net/plip... > > Minor comment: No need to preserve the error code if there are lots > which we miss. We may as well hard code an error code. But that's a > minor thing. Does this actually simplify the driver code? That's the > more important thing. i don't think this will simplify the driver code, but atleast now parport_register_driver() will not report success when we have actually failed. And as a result module_init will also fail which is supposed to be the actual behviour. regards sudip > > regards, > dan carpenter > -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-04-08 11:50 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 [this message] 2015-04-08 11:50 ` Sudip Mukherjee 2015-04-08 12:27 ` Dan Carpenter 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=20150408115010.GA11153@sudip-PC \ --to=sudipm.mukherjee@gmail.com \ --cc=JBottomley@parallels.com \ --cc=alsa-devel@alsa-project.org \ --cc=arnd@arndb.de \ --cc=broonie@kernel.org \ --cc=dan.carpenter@oracle.com \ --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=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.