netdev - Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7ea15639-740d-8837-07e2-acdd91b49df4@kernel.org>
Date:   Tue, 4 Dec 2018 17:23:12 +1000
From:   Greg Ungerer <gerg@...nel.org>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     sean.wang@...iatek.com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com, f.fainelli@...il.com,
        netdev@...r.kernel.org, John Crispin <john@...ozen.org>,
        neil@...wn.name,
        René van Dorst <opensource@...rst.com>
Subject: Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

Hi Bjorn,

On 3/12/18 9:34 pm, Bjørn Mork wrote:
> [ fixed Johns address - the openwrt.org email was apparently never restored? ]
> 
> Greg Ungerer <gerg@...nel.org> writes:
> 
>> The following change helped alot, but I still get some problems under
>> sustained load and some types of port setups. Still trying to figure
>> out what exactly is going on.
>>
>> --- a/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> +++ b/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> @@ -1750,8 +1750,8 @@ static irqreturn_t mtk_handle_irq_rx(int irq, void *_eth)
>>         if (likely(napi_schedule_prep(&eth->rx_napi))) {
>>                  __napi_schedule(&eth->rx_napi);
>> -               mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
>>          }
>> +       mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
>>         return IRQ_HANDLED;
>>   }
>> @@ -1762,11 +1762,53 @@ static irqreturn_t mtk_handle_irq_tx(int irq, void *_eth)
>>         if (likely(napi_schedule_prep(&eth->tx_napi))) {
>>                  __napi_schedule(&eth->tx_napi);
>> -               mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
>>          }
>> +       mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
>>         return IRQ_HANDLED;
>>   }
> 
> Yes, sorry I didn't point to that as well.  Just to be clear:  I have no
> clue how this thing is actually wired up, or if you could use three
> interrupts on the MT7621 too. I just messed with it until I got
> something to work, based on Renés original idea and code.

Understood.

By way of progress I have found that making the single IRQ handler
look like this is better than the last patch:

static irqreturn_t mtk_handle_irq(int irq, void *_eth)
{
         struct mtk_eth *eth = _eth;
         irqreturn_t rc = IRQ_NONE;

         if (mtk_r32(eth, MTK_PDMA_INT_MASK) & MTK_RX_DONE_INT) {
                 if (mtk_r32(eth, MTK_PDMA_INT_STATUS) & MTK_RX_DONE_INT)
                         rc = mtk_handle_irq_rx(irq, _eth);
         }

         if (mtk_r32(eth, MTK_QDMA_INT_MASK) & MTK_TX_DONE_INT) {
                 if (mtk_r32(eth, MTK_QMTK_INT_STATUS) & MTK_TX_DONE_INT)
                         rc = mtk_handle_irq_tx(irq, _eth);
         }

         return rc;
}

So not calling the RX or TX handlers if their interrupts
where not masked on. For some work loads that is quite reliable.
Flood ping through one port and out the other can get a lof of
packets through.

However I still get dev_watchdog timeouts after a while and with
more mixed packet loads. Seems like something is racing on the
TX path side.

Regards
Greg



>> Anyway, this really looks like the right approach to me. This driver is
>> clearly capable of supporting the mt7621 ethernet ports. No need for the
>> staging driver.
> 
> Great! Thanks for doing this.
> 
> I did make a feeble attempt at testing this with current mainline
> myself, but the only MT7621 board I have is using NAND flash.  So I
> started trying to forward port the mtk-nand2 driver from OpenWrt. And
> failed. Probably a simple mixup while trying to adjust to the many
> changes in the raw NAND API between v4.14 and v.4.20.  Then I
> optimistically attempted to use the mainline mtk-nand driver instead,
> assuming it would be as simple as with the mtk-eth driver.  Which it
> wasn't, of course. I guess there are a lot of things I do not understand
> wrt flash and HW ECC etc...
> 
> Short version: I won't be able to test the mainline mtk-eth driver with
> MT7621 on newer kernels before smarter people like John upgrade the
> OpenWrt kernel.
> 
> 
> Bjørn
>