-----Original Message-----
From: Thomas Monjalon [mailto:thomas@monjalon.net]
Sent: Friday, September 22, 2017 7:49 PM
To: Shreyansh Jain <redacted>
Cc: dev@dpdk.org; ferruh.yigit@intel.com; Hemant Agrawal
[off-list ref]
Subject: Re: [PATCH v4 00/41] Introduce NXP DPAA Bus, Mempool and PMD

22/09/2017 16:00, Shreyansh Jain:

quoted

From: Thomas Monjalon [mailto:thomas@monjalon.net]

quoted

At the beginning of fslmc work, I had understood that every NXP SoC were
connecting components with the same principle which we could call the
"Freescale bus".
Then you came with this bus named bus/fslmc, not bus/dpaa2.
Now I am confused. What is the exact scope of fslmc? Is it just DPAA2?

My memory is poor. I will have to look through the old emails what happened

- but I recall there was a discussion in initial phases about the naming.
"fslmc" came out as a name that is what is the real name of the DPAA2 bus.
There was initial a confusion if name of bus in Linux Kernel should match or
not - but, we realized that bus is *not* device and device name is "dpaa2".

quoted

As for whether fslmc would cover multiple SoC - that is still true. There

are multiple SoCs within the DPAA2 umbrella. LS20XX, LS108X series and some
more - all of which use the FSLMC bus (DPAA2 architecture, on FSLMC bus,
having 'dpaa2' devices).

quoted

There is another architecture, an old one, which are still popular. This is

platform type bus which is aptly named 'dpaa' - and here the confusion of bus
name and device doesn't appear. (DPAA bus, using DPAA architecture, exposing
'dpaa' devices).

quoted

Exact scope of FSLMC is just DPAA2 architecture based SoCs. There are many

here with new coming up.

quoted

Exact scope of DPAA bus is just DPAA architecture based SoCs. There are

many here.

quoted

Does this clear your doubt to some extent?

Yes it is a lot clearer! Thanks

Now that I better understand, I think flsmc bus should have been named
dpaa2 bus. Is it too late?

:)

I resonate your thought that drivers/bus/dpaa2, drivers/mempool/dpaa2, drivers/net/dpaa2, drivers/crypto/dpaa2_sec would have been more uniform. But again, that would have misled a lot of DPAA2 users into thinking bus name is 'dpaa2' which is not the case.
And anyways, the changes required in the code to reflect this name change are not worthwhile.
I would prefer to go as is.