netdev - Re: Waiting for the PHY to complete auto-negotiation

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: <yw1xy3m9tjp5.fsf@mansr.com>
Date:   Mon, 11 Dec 2017 14:36:54 +0000
From:   Måns Rullgård <mans@...sr.com>
To:     Mason <slash.tmp@...e.fr>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>, netdev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>
Subject: Re: Waiting for the PHY to complete auto-negotiation

Mason <slash.tmp@...e.fr> writes:

> + Mans
>
> On 09/12/2017 19:49, Florian Fainelli wrote:
>
>> Having any HW state machine requiring X number of clock cycles to
>> guarantee a full transition to a stopped state is not unusual, however,
>> the fact that you need to send 5 packets to guarantee an EOC descriptor
>> is hit is completely unusual. Ideally there is a single bit that tells
>> the DMA engine: you are enabled, do your thing, or you are now disabled,
>> and you must stop all accesses to DRAM *now*.

That's how sane hardware works.  This hardware is not sane.

>> So what would be the correct way to quiesce that controller according to
>> your HW folks?
>
> He (it's a single person) offered to run some RTL-level simulations,
> but then moved on to more important tasks. At some point he wrote:
>
>> If you reset the DMA enable in the middle of a DMA, the hardware
>> state machine doesn't return to the IDLE state if it has more
>> descriptors to process. It should be noted that the RX DMA has been
>> designed by our IP vendor with no intention of stopping the DMA in
>> the middle of its operation.
>
> While the documentation for the IP states:
>
>> Receive DMA Channel Disabling
>> 
>> When the entire receive frame has been read from the Receive FIFO and
>> sent over the AMBA bus, the DMA operation ends, and the Receive DMA
>> Channel is automatically disabled.  To do this, hardware resets the
>> Enable bit in the Receive Channel Control Register to "0" after the
>> last data has been read from the Receive FIFO and sent over the AMBA
>> bus.
>> 
>> When operating in descriptor mode, upon completion of a receive frame
>> DMA operation, if the descriptor chain has not ended when a receive
>> frame DMA operation completes, the next receive frame DMA operation
>> begins.  The last descriptor in a descriptor chain is indicated by
>> having its End Of Chain- EOC, flag set to "1".  If this EOC flag is
>> "0", to begin the next receive frame DMA operation, the next
>> descriptor is automatically retrieved and used to configure the
>> Receive DMA Channel.  The Receive DMA Channel is then automatically
>> re-enabled and the next receive frame DMA operation begins.
>> 
>> In descriptor mode, an AMBA bus error can occur when reading receive
>> descriptor data.  If this happens, receive descriptor processing ends
>> and the Receive DMA Channel is turned off.  The Descriptor Error bit
>> in the Receive Status Register is set to "1".
>
> I don't see how sending "fake" packets through the loop back would be
> considered "resetting the DMA enable in the middle of a DMA".
> (I'm afraid the HW dev didn't grasp what the driver is doing.)
>
> I suppose I should test forcefully setting the enable bit to 0 in
> the driver, and see if hell breaks loose.

You can't.  When the enable bit is 1, writes to that register are
ignored.  It goes back to 0 automatically when the hw runs out of
descriptors.

-- 
Måns Rullgård