[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL

[Hemant Agrawal]

On 9/18/2016 3:34 PM, Jan Viktorin wrote:
> On Sun, 18 Sep 2016 09:41:55 +0000
> Hemant Agrawal <hemant.agrawal at nxp.com> wrote:
>
>>> -----Original Message-----
>>> From: Jan Viktorin [mailto:viktorin at rehivetech.com]
>>
>
> [...]
>
>>>> And for each platform/product....
>>>>
>>>>> I agree, that this can sometimes lead to code duplication. Moreover,
>>>>> it opens door for a very non-standard, unsecure and wrong-by-design
>>>>> approaches. I'd like more to provide one or more scan
>>>>> implementations in EAL and do not put this responsibility on PMDs.
>>
>
> Hi Hemant.
>
>>  [Hemant]  A common/default scan function can be added, provided at least one or more  PMD driver support it.
>> w.r.t Jan's original scan function, it was not suitable for any of the NXP SoC's whether ARM or PowerPC.
>>
>> Unable to validate the Jan's scan function on a real platform, we have skipped it for next phase.
>> Addition of a default scan function can only be done in next phase, when we find a suitable SoC PMD driver supporting it.
>
> Quite frankly, the situation is same for me. I still have no clue about
> your approach which seems to be pretty non-standard. I have no way how
> to test it.
>
Yes! Our first sample to test the above proposal is with a specific bus; 
NXP's new generation Layerscape devices use fsl-mc bus.

https://www.kernel.org/doc/readme/drivers-staging-fsl-mc-README.txt

This is neither a platform bus nor a PCI bus. It does not fit the 
default implementation for platform bus.

Our objective is to make the first design of SoC patchset very simple 
and extendable for future. This will improve, when we have more SoC 
vendor participation and sharing their requirements.

Also, we definitely have a plan to provide default implementation for 
buses which are generic or have more than one PMD implementation 
depending on them e.g. use your Platform Bus scan function

> My approach can be tested on any Linux machine with platform devices
> and device-tree enabled. You would see that I detect those devices (I
> don't mean any certain network device, I mean all platform devices) and
> if you provide a driver with a proper compatible string it will be set
> for you.
>
> I presume that I don't have any upstreamable PMD for this at the moment.
>
> From the very generic scan approach, I cannot see, what kernel
> infrastructure are you going to use. We should support at least the
> VFIO-platform which is standard and with IOMMU, it is considered secure.
> Any other approach would require an out-of-tree kernel driver or some
> non-secure access to devices. I don't say it is very wrong, but we
> should be careful about this.
>

I agree with your description and approach when the devices are on 
platform-bus.

We plan to address it in next phase. We have identified another NXP 
device, which uses platform-bus for device detection. We will use that 
for our testing.


>>>>>
>>>>>>
>>>>>>>    detect the devices. This is because SoC may require specific or
>>>>>>>    additional info for device detection. Further, SoC may have
>>>>>>> embedded
>>>>>
>>>>> Can you provide an example for "additional info for device detection"?
>
> Can you?
>
e.g. our fsl-mc bus is more close to PCI bus, where we get object 
identifiers instead of compatible string.


> Regards
> Jan
>
> [...]
>