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