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