From mboxrd@z Thu Jan  1 00:00:00 1970
From: Shreyansh Jain <shreyansh.jain@nxp.com>
Subject: Re: [PATCHv5 04/33] bus/fslmc: introducing fsl-mc bus
	driver
Date: Fri, 20 Jan 2017 10:35:17 +0530
Message-ID: <2533f939-d037-d2fa-719a-abb4f989e7d2@nxp.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>
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: <thomas.monjalon@6wind.com>, <bruce.richardson@intel.com>,
 <john.mcnamara@intel.com>, <jerin.jacob@caviumnetworks.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>, Hemant Agrawal
 <hemant.agrawal@nxp.com>, <dev@dpdk.org>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM02-CY1-obe.outbound.protection.outlook.com
 (mail-cys01nam02on0069.outbound.protection.outlook.com [104.47.37.69])
 by dpdk.org (Postfix) with ESMTP id 54D472B9B
 for <dev@dpdk.org>; Fri, 20 Jan 2017 06:01:55 +0100 (CET)
In-Reply-To: <55ece068-d1b9-acb1-d279-a6da5e594614@intel.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 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.

>
>> +	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;
>> +}
>
> <...>
>