netdev - Re: [PATCH 1/8][BNX2X] resubmit as attachments: add bnx2x to Kconfig and Makefile

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]

Date:	Wed, 10 Oct 2007 02:34:08 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eliezert@...adcom.com
Cc:	jeff@...zik.org, netdev@...r.kernel.org, mchan@...adcom.com
Subject: Re: [PATCH 1/8][BNX2X] resubmit as attachments: add bnx2x to
 Kconfig and Makefile

From: "Eliezer Tamir" <eliezert@...adcom.com>
Date: Tue, 09 Oct 2007 18:20:01 +0200

> Almost all of the zero-filled tables will be removed.
> The rest of the registers do need to be initialized.
> 
> I agree that the number of registers that needs to be initialized is
> huge, but that is caused by the way the hardware was designed.
> 
> The values for the initialization come from several sources:
> Some are derived from HW code (the XML files used to derive the verilog
> code),
> Others (along with much of the machine generated .h files) are generated
> at microcode build time, adding a microcode routine will cause the init
> values to change, using a new variable can cause an .h file to change.
> In the last group which is very small, are registers that are controlled
> by the driver.
> 
> The values in this file really are machine generated, they really are
> not meant to be modified directly by editing the file.
> 
> The registers that are under the driver's control are in the main .c
> and .h files.
...
> The idle check code is not a manufacturing test, it is meant to help
> debug the driver and microcode.
> If the driver sends an invalid command to one of the CPUs which then
> chokes on it, this will tell you which one of them died and the general
> whereabouts of the problem. (ingress CPU X is stuck because output queue
> Y is full)
 ...
> ( Michael has showed me the trick of how to post with evolution, so I
> hope that the mangled patch problem is behind us and I think that I can
> now post everything without a problem, Hallelujah!)

Thanks for the explanations, I look forward to your next
submission.
-
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