From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [PATCHv5 04/33] bus/fslmc: introducing fsl-mc bus
	driver
Date: Fri, 20 Jan 2017 11:39:57 +0000
Message-ID: <228e240f-cc6e-870d-5245-39f9343ef28d@intel.com>
References: <1484679174-4174-1-git-send-email-hemant.agrawal@nxp.com>
 <1484832240-2048-1-git-send-email-hemant.agrawal@nxp.com>
 <1484832240-2048-7-git-send-email-hemant.agrawal@nxp.com>
 <55ece068-d1b9-acb1-d279-a6da5e594614@intel.com>
 <2533f939-d037-d2fa-719a-abb4f989e7d2@nxp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: thomas.monjalon@6wind.com, bruce.richardson@intel.com,
 john.mcnamara@intel.com, jerin.jacob@caviumnetworks.com
To: Shreyansh Jain <shreyansh.jain@nxp.com>,
 Hemant Agrawal <hemant.agrawal@nxp.com>, dev@dpdk.org
Return-path: <dev-bounces@dpdk.org>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
 by dpdk.org (Postfix) with ESMTP id 226942BA7
 for <dev@dpdk.org>; Fri, 20 Jan 2017 12:40:00 +0100 (CET)
In-Reply-To: <2533f939-d037-d2fa-719a-abb4f989e7d2@nxp.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 1/20/2017 5:05 AM, Shreyansh Jain wrote:
> On Friday 20 January 2017 12:38 AM, Ferruh Yigit wrote:
>> On 1/19/2017 1:23 PM, Hemant Agrawal wrote:
>>> The fslmc bus driver is a rte_bus driver which scans the fsl-mc bus
>>> for NXP DPAA2 SoCs.
>>>
>>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>>> ---
>>
>> <...>
>>
>>> +#
>>> +# library name
>>> +#
>>> +LIB = librte_pmd_fslmcbus.a
>>
>> Since now there is a bus folder/driver, what do you think nameming
>> library with librte_bus_ prefix, like: librte_bus_fslmc.a
>>
>> <...>
>>
>>> +
>>> +static int
>>> +rte_fslmc_probe(void)
>>> +{
>>> +	int ret = -1;
>>
>> If any bus->probe() fails, rte_bus_probe() breaks and returns error,
>> which cause app to exit.
>> Here if there is no device or driver in the bus, function is returning
>> error, I guess it should be returning zero for this case.
> 
> It is a nice point of discussion (even in the bus patch). Should Bus 
> iteration for scan/probe fail if any bus implementation fails?
> 
> In the initial series I had placed a 'TODO' in the bus patch to get some 
> comments - I couldn't make a decision so the final bus scan/probe loop 
> 'fails if any bus fails whether in scan or probe'.
> 
> I think that EAL should continue looping over buses irrespective of bus 
> failure - specially removing such dependencies on bus implementations to 
> return a valid code compatible with EAL's design.

Agree to fix this in eal.

> 
>>
>>> +	struct rte_dpaa2_device *dev;
>>> +	struct rte_dpaa2_driver *drv;
>>> +
>>> +	TAILQ_FOREACH(dev, &rte_fslmc_bus.device_list, next) {
>>> +		TAILQ_FOREACH(drv, &rte_fslmc_bus.driver_list, next) {
>>> +			ret = rte_fslmc_match(drv, dev);
>>> +			if (ret)
>>> +				continue;
>>> +
>>> +			if (!drv->probe)
>>> +				continue;
>>> +
>>> +			ret = drv->probe(drv, dev);
>>> +			if (ret)
>>> +				FSLMC_BUS_LOG(ERR, "Unable to probe.\n");
>>> +			break;
>>> +		}
>>> +	}
>>> +	return ret;
>>> +}
>>
>> <...>
>>
>