Milton Miller wrote:
First, a question especially to Auke and Jeff:
Since this patch both reverts the broken change that is currently in
-rc and creates the fixed driver, I'm not sure I like the subject
stating "on ARM", although that is the feature of the rewrite, and was
the intent of merging the previous patch. This is actually its a fix
for all systems relative to current, including those where dma is not
cache coherent, (unlike a simple revert).
Should we just put a comment about reverting the previous patch early
in the change log?
yes
Something like this:
Fix the e100 receiver handling, supporting cache incoherent DMA.
Discard the concept of setting the S (suspend) bit with the EL bit
introduced in commit d52df4a35af569071fda3f4eb08e47cc7023f094. In
addition to it not setting either bit, the hardware doesn't work that
way.
Thoughts?
the same comment I made about the coding style counts for this too: I will clean
up the patch and gladly adjust the topic, which in this case seems the right
thing to do. I am too grateful that you guys are digging into this so deeply to
send you back with comments on style - I'll gladly fix that up :)
Here is the changelog portion of the latest patch (quoted), with my
comments thrown in:
OK, I will buffer this info and make sure this gets picked up on the final
version.
this opens up another question:
We need to make sure that now that we're getting closer to 2.6.22 we don't end
up killing e100 in it. Should we drop the current fixes in it to be on the safe
side and aim for 2.6.23? I would hate to see an untested codepath breaking e100
on something like ppc or mips... that will be very painful
Jeff, your thoughts on that?
Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
