Hello Ferruh,

Replying on behalf of Hemant...

On 08/01/19 7:40 PM, Ferruh Yigit wrote:
> On 12/27/2018 6:23 AM, Hemant Agrawal wrote:
>> From: Pankaj Chauhan <pankaj.chau...@nxp.com>
>>
>> This is required to map any accelerator memory
>> and PCI address to VFIO using QDMA.
>>
>> Signed-off-by: Minghuan Lian <minghuan.l...@nxp.com>
>> Signed-off-by: Pankaj Chauhan <pankaj.chau...@nxp.com>
> 
> This requires either sign-off or ack from 'bus/fslmc' maintainers, which are:
>       M: Hemant Agrawal <hemant.agra...@nxp.com>
> 
> 
> 
>       M: Shreyansh Jain <shreyansh.j...@nxp.com>
> 
> I think Hemant sending the patchset implies that this has been reviewed by him
> but this information get lost in git, so better to explicitly provide 
> review/ack
> tags whenever appropriate.

What I will do is, re-spin the complete series (with error below 
fixed...) and send again. All the patches are on FSLMC/DPAA2 drivers 
only so probably Hemant's or my Acks would work directly.

> 
> <...>
> 
>> +    printf("PCIe vfio map 0x%llx:0x%llx, size 0x%llx\n", dma_map.vaddr,
>> +            dma_map.iova, dma_map.size);
> 
> This is causing build error [1], but why at first place using 'printf()' 
> instead
> of logging macros?

I will fix this.

> 
> [1]
> .../drivers/bus/fslmc/fslmc_vfio.c: In function ‘rte_fslmc_vfio_mem_dmamap’:
> .../drivers/bus/fslmc/fslmc_vfio.c:376:29: error: format ‘%llx’ expects 
> argument
> of type ‘long long unsigned int’, but argument 2 has type ‘__u64’ {aka ‘long
> unsigned int’} [-Werror=format=]
>    printf("PCIe vfio map 0x%llx:0x%llx, size 0x%llx\n", dma_map.vaddr,
>                            ~~~^                         ~~~~~~~~~~~~~
>                            %lx
> 
> <...>
> 
>> +DPDK_19.02 {
>> +    global:
>> +
>> +    rte_fslmc_vfio_mem_dmamap;
> 
> Is this need to be an API? Who is the consumer of this API, I don't see anyone
> calls this function?
> 

This API (internal to FSLMC) was added for one of NXP's internal 
software stack over DPDK. As this is an internal API, I don't think it 
would pollute the outer namespace - isn't it? And, I think its consumers 
won't necessarily be within DPDK stack.

Or, if this is conflicting case, I will remove this patch (it is 
independent) and send again. Let me know your reservation.

-
Shreyansh

Reply via email to