[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150410050543.GA3561@sudip-PC>
Date: Fri, 10 Apr 2015 10:35:43 +0530
From: Sudip Mukherjee <sudipm.mukherjee@...il.com>
To: Wolfram Sang <wsa@...-dreams.de>
Cc: Jean Delvare <jdelvare@...e.de>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rodolfo Giometti <giometti@...eenne.com>,
"James E.J. Bottomley" <JBottomley@...allels.com>,
Mark Brown <broonie@...nel.org>,
Willy Tarreau <willy@...a-x.org>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
netdev@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-spi@...r.kernel.org, devel@...verdev.osuosl.org,
alsa-devel@...a-project.org
Subject: Re: [PATCH 12/14] i2c-parport: return proper error values from attach
On Thu, Apr 09, 2015 at 12:25:28PM +0200, Wolfram Sang wrote:
>
> > It doesn't really matter that the error codes are different, it matters
> > that they are meaningful. As much as possible you should pass error
> > codes from the lower layers. parport_claim_or_block() and
> > i2c_bit_add_bus() return proper error codes so you should record and
> > transmit them.
>
> Oh, surely yes. I assumed they don't and this series is a first step to
> fix this. Should have looked myself. Thanks for jumping in here.
>
I planned this series to be the first step to fix the attach function
which does not return it succeeded or failed. And if attach has failed
then there is no reason that module_init will report success.
But as Greg pointed out that the first step should be to bring the
parallel port in the driver model. I am working on that now, I will
post a v2 of this series once that modification is done, and that will
need extensive testing.
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists