Re: [PATCH v5 04/19] net: e100: Replace PCI pool old API

From: Romain Perier
Date: Thu Mar 09 2017 - 04:59:04 EST


Hello,


Le 09/03/2017 à 08:01, Peter Senna Tschudin a écrit :
> On Wed, Mar 08, 2017 at 02:40:25PM -0800, Jeff Kirsher wrote:
>> On Wed, 2017-03-08 at 17:19 +0100, Romain Perier wrote:
>>> The PCI pool API is deprecated. This commit replaces the PCI pool old
>>> API by the appropriate function with the DMA pool API.
>>>
>>> Signed-off-by: Romain Perier <romain.perier@xxxxxxxxxxxxx>
>>> Acked-by: Peter Senna Tschudin <peter.senna@xxxxxxxxxxxxx>
>>> Tested-by: Peter Senna Tschudin <peter.senna@xxxxxxxxxxxxx>
>>> ---
>>> drivers/net/ethernet/intel/e100.c | 12 ++++++------
>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@xxxxxxxxx>
>>
>> My only concern is:
>> - what hardware did this get tested with? Since this affects all e100
>> parts, it would be hard to believe that all the affected hardware was
>> used in testing.
> This was tested by compilation only(See
> https://lkml.org/lkml/2017/2/8/661). However this series removes macro
> definitions of the old pci_pool interface and replace call sites by what
> the macra was calling.
>
> Here are the macros that this series removes from include/pci.h:
>
> #define pci_pool dma_pool
> #define pci_pool_create(name, pdev, size, align, allocation) \
> dma_pool_create(name, &pdev->dev, size, align, allocation)
> #define pci_pool_destroy(pool) dma_pool_destroy(pool)
> #define pci_pool_alloc(pool, flags, handle) dma_pool_alloc(pool, flags, handle)
> #define pci_pool_zalloc(pool, flags, handle) \
> dma_pool_zalloc(pool, flags, handle)
> #define pci_pool_free(pool, vaddr, addr) dma_pool_free(pool, vaddr, add
>
> So this should not affect run time.
We cannot test a patch like this one on all affected platforms/drivers
(at runtime). Simply because we have not the hw. As Peter said, we
tested this by compilation only for now via make allyesconfig. That's up
to the maintainer of the subsystem to test and ack this, imho.
I agree with Peter, this should not affect runtime (as semantically it's
compatible and have been validated statically and semantically by your
compiler)

Regards,
Romain