netdev - Re: [PATCH 3/3] net: ethernet: sun4i-emac: Read rxhdr in CPU byte-order

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: <20161114185934.2wfwyrv6buvnrja7@lukather>
Date:   Mon, 14 Nov 2016 19:59:34 +0100
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Michael Weiser <michael.weiser@....de>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH 3/3] net: ethernet: sun4i-emac: Read rxhdr in CPU
 byte-order

On Mon, Nov 14, 2016 at 06:58:07PM +0100, Michael Weiser wrote:
> The EMAC EMAC_RX_IO_DATA_REG data register is dual-purpose: On one hand
> it is used to move actual packet data off the wire. This will be in
> wire-format and accepted as such by higher layers such as IP. Therefore
> it is correctly read as-is (i.e. raw) using readsl.
> 
> On the other hand it provides metadata about incoming transfers to the
> driver such as length and checksum validation status. This data is
> little-endian, always and it is interpreted by the driver. Therefore it
> needs to be swapped to CPU endianness to make sense to the driver. This
> is already done for the "receive header" but not rxhdr.
> 
> Read rxhdr using readl in order for sun4i-emac to work correctly when
> running a big-endian kernel.
> 
> Signed-off-by: Michael Weiser <michael.weiser@....de>
> Cc: Maxime Ripard <maxime.ripard@...e-electrons.com>
> Cc: netdev@...r.kernel.org

Acked-by: Maxime Ripard <maxime.ripard@...e-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)