From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 5F6111B1B5 for <dev@dpdk.org>; Fri, 6 Oct 2017 15:37:40 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0854D20BA1; Fri, 6 Oct 2017 09:37:40 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 06 Oct 2017 09:37:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=+CEbQ6SB8hL1sDU qAtSSqWhE4WUCTcKz5uweAeFyXrg=; b=KufpBbkQ1TGyWsXz6GcOqkTEojiwotV tQcsxyVV0Z6IX6R2kaDZDCAtosNtyeozpNg7yCKMwknuhGqOUkIKInmodwJbzDrW VcdjBFeoNHtPQGhKu8Xu8DDFx+sQ1jk7xcTJ5nU26UoeqDqHixI1gk3ABcwNgO0b 7v7vJlOnmIX0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=+CEbQ6SB8hL1sDUqAtSSqWhE4WUCTcKz5uweAeFyXrg=; b=McPYhKCd 07O7QPpBi9DeODrYKDLB36wf3p0oaN1dmvL5UZ7669EQsYp0g/D15bfL+11F/lqd ywdPwd4ILXhLV2uUjOff31SIhLvvHXm6VpNFCGrw03w26wCwnF+a8BA6VYiRCaj9 TJr022hgzBGJL0Ldq8/QFtFDZs2KdwZxUe9llyipzrLxGH83Q+5vOgcq+O0a2PHG G5nosJr/r3Aj19f4ACb61AjFTIM4ANXBdmTcW4ExXNaX5cFSRghpJvkQHOx0zUro Zqay6QAItgeeknp8bSttBnZo0wZkEbtMWF7peFB3Phk0hHFX1mlrhe3T6U3yPbIp 5ub4CubLyn5W/w== X-ME-Sender: <xms:I4fXWQnnpaNR627MP3JRH5nM2znE-itoQ28DbpGtXU0jglrb-ZNhrg> X-Sasl-enc: ynBOBmQPVh/lnX3XaGoGwFhaUM0kRkrxiMyJnYi8OXwR 1507297059 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A9D7C7E65B; Fri, 6 Oct 2017 09:37:39 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Shreyansh Jain <shreyansh.jain@nxp.com> Cc: dev@dpdk.org, Jan Blunck <jblunck@infradead.org>, Hemant Agrawal <hemant.agrawal@nxp.com> Date: Fri, 06 Oct 2017 15:37:38 +0200 Message-ID: <10403057.Ll0Xg1E4J1@xps> In-Reply-To: <f096be1a-7053-a836-e296-feacfb676925@nxp.com> References: <20170812102220.27773-1-shreyansh.jain@nxp.com> <2075457.Vvey9mxHue@xps> <f096be1a-7053-a836-e296-feacfb676925@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] eal: bus scan and probe never fail X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 06 Oct 2017 13:37:40 -0000 06/10/2017 15:12, Shreyansh Jain: > On Friday 06 October 2017 04:51 AM, Thomas Monjalon wrote: > > 19/09/2017 20:51, Jan Blunck: > >> On Mon, Sep 18, 2017 at 1:36 PM, Hemant Agrawal <hemant.agrawal@nxp.com> wrote: > >>> Tested-by: Hemant Agrawal <hemant.agrawal@nxp.com> > >>> > >>> > >>> On 8/12/2017 3:52 PM, Shreyansh Jain wrote: > >>>> > >>>> Bus scan is responsible for finding devices over *all* buses. > >>>> Some of these buses might not be able to scan but that should > >>>> not prevent other buses to be scanned. > >>>> > >> > >> If scanning the bus fails this is signaling an error. In that case we > >> might even want to unregister the bus. > > > > A scan error seems important enough to be reported to the caller. > > OK to continue scanning other buses, but an error code should be returned. > > Isn't that counter intuitive if the scanning continues after error and > an error is expected to be returned from it? > What if there are more than one error? Which one is reported. Both are reported with the same code. Anyway, there is no way to know which bus is failing, except from log. > As for cleanup, bus un-registration is not correct. Scan has failed, > which might mean some assumption that bus took for scanning for devices > doesn't exist for time being or present platform. Either way, I think > whatever rollback needs to be done for scan failure, would be done by > the bus->scan() implementation. > > Let me know what you think - I will make changes to the patch and push > again. We may need more opinion here. Mine is that we should not hide a scan failure. I would return an error code if any of the scan has failed, but would process every scans.