[PATCH 1/6] net: macb: use dummy descriptor for RBQP

[Eugen.Hristev at microchip.com]

On 17.12.2020 07:22, Padmarao Begari - I30397 wrote:
> Hi Eugen,
> 
> This series of patches break my side of work(patches) so you need to 
> create patches after my patches are going into master branch because my 
> patches are already reviewed and tested.

Hi,

Could you please detail the breakage ?
I saw a pull request with your patches that was NAK-ed, if your two macb 
patches are tested and reviewed I could apply them to the atmel tree as 
well and send them, if your PR is delayed. But we are interested to have 
our sama7g5 series pushed as well, so we need to know if it's ok on your 
side, and what is wrong with the sama7g5 series.

Thanks!
Eugen
> 
> Regards
> Padmarao
> ------------------------------------------------------------------------
> *From:* Eugen Hristev - M18282 <Eugen.Hristev at microchip.com>
> *Sent:* Wednesday, December 16, 2020 12:24 PM
> *To:* anup.patel at wdc.com <anup.patel at wdc.com>; bin.meng at windriver.com 
> <bin.meng at windriver.com>; Padmarao Begari - I30397 
> <Padmarao.Begari at microchip.com>
> *Cc:* Claudiu Beznea - M18063 <Claudiu.Beznea at microchip.com>; 
> joe.hershberger at ni.com <joe.hershberger at ni.com>; u-boot at lists.denx.de 
> <u-boot at lists.denx.de>
> *Subject:* Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP
> On 03.12.2020 11:25, Claudiu Beznea wrote:
>> In case of multiple queues on RX side the queue scheduler
>> will try to use all the available configured queues (with
>> descriptors having TX_USED bit cleared). If at least one RBQP
>> points to a descriptor with a valid used bit configuration then
>> the reception may block as this may point to any memory. To avoid
>> this scenario all the queues (except queue zero) were disabled by
>> setting DMA descriptors with used bit set on proper RBQP. The driver
>> anyway uses only queue 0 for TX/RX.
>> 
>> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
>> ---
> 
> Hi Anup, Bin, Padmarao,
> 
> I noticed on the mailing list that you have been actively working and
> testing the Macb driver on various platforms, we have this series
> outstanding and I want to make sure that it does not break anything on
> your side, so it would be appreciated if you could have a look or test
> it before it goes into master branch.
> 
> Thanks !
> Eugen
> 
> 
>>   drivers/net/macb.c | 4 +++-
>>   drivers/net/macb.h | 2 ++
>>   2 files changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>> index b80a259ff757..836eb85ec96a 100644
>> --- a/drivers/net/macb.c
>> +++ b/drivers/net/macb.c
>> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct macb_device *macb)
>>        flush_dcache_range(macb->dummy_desc_dma, macb->dummy_desc_dma +
>>                        ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE, PKTALIGN));
>>   
>> -     for (i = 1; i < num_queues; i++)
>> +     for (i = 1; i < num_queues; i++) {
>>                gem_writel_queue_TBQP(macb, macb->dummy_desc_dma, i - 1);
>> +             gem_writel_queue_RBQP(macb, macb->dummy_desc_dma, i - 1);
>> +     }
>>   
>>        return 0;
>>   }
>> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
>> index 9b16383eba46..28c7fe306883 100644
>> --- a/drivers/net/macb.h
>> +++ b/drivers/net/macb.h
>> @@ -768,5 +768,7 @@
>>   #define GEM_RX_CSUM_CHECKED_MASK            2
>>   #define gem_writel_queue_TBQP(port, value, queue_num)       \
>>        writel((value), (port)->regs + GEM_TBQP(queue_num))
>> +#define gem_writel_queue_RBQP(port, value, queue_num)        \
>> +     writel((value), (port)->regs + GEM_RBQP(queue_num))
>>   
>>   #endif /* __DRIVERS_MACB_H__ */
>> 
>