netdev - Re: [net 0/8] gianfar: ARM port driver updates (1/2)

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] [day] [month] [year] [list]

Message-Id: <20141006.150733.173099081334515077.davem@davemloft.net>
Date:	Mon, 06 Oct 2014 15:07:33 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	claudiu.manoil@...escale.com
Cc:	netdev@...r.kernel.org, Li.Xiubo@...escale.com,
	Shruti@...escale.com
Subject: Re: [net 0/8] gianfar: ARM port driver updates (1/2)

From: Claudiu Manoil <claudiu.manoil@...escale.com>
Date: Mon, 6 Oct 2014 10:55:42 +0300

> On 10/6/2014 4:27 AM, David Miller wrote:
>> From: Claudiu Manoil <claudiu.manoil@...escale.com>
>> Date: Fri, 3 Oct 2014 19:02:41 +0300
>>
>>> This is the first round of driver protability fixes and clean-up
>>> with the main purpose to make gianfar portable on ARM, for the ARM
>>> based SoC that integrates the eTSEC ethernet controller - "ls1021a".
>>> The patches primarily address compile time errors, when compiling
>>> gianfar on ARM.  They replace PPC specific functions and macros
>>> with architecture independent ones, solve arch specific header
>>> inclusions, guard code that relates to PPC only, and even address
>>> some simple endianess issues (see MAC address setup patch).
>>> The patches addressing the bulk of remaining endianess issues,
>>> like handling DMA fields (BD and FCB), will follow with the sencond
>>> round.
>>> These patches were verified on the ls1021a SoC.
>>
>> If more endianness fixes are necessary and "will follow with the
>> second round", I do not see how you could have verified specifically
>> these changes on the ls1021a.
>>
> 
> Hi David,
> 
> What I did is to split the initial patchset in 2, to ease up the
> review
> process.
> This first part is fairly straightforward, these patches make
> localized
> code changes and can be more easily ported among different kernel
> versions.  The second part has fewer patches but touches more code,
> because it handles endianess conversions for all the reads/writes to
> the buffer descriptors.  Please let me now if you have objections to
> this approach.
> As for testing, we have our internal kernel tree for ARM supporting
> ls1021a, and these gianfar patches have been there for a while and
> tested.  Now it's time to upstream (a cleaned-up version of) them.
> (see git.freescale.com/git/cgit.cgi/layerscape/ls1021a/linux.git/)
> Please note that the current (upstream) net tree does not include the
> support for ls1021a (which is to be propagated via the arm tree).

I'm merely saying that it's inaccurate to say that you "verified" this
specific patch series on that chip, when in fact the second upcoming
series is necessary as well for the driver to work on that chip properly.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html