* Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
From: Patrick McHardy @ 2006-06-26 22:49 UTC (permalink / raw)
To: Thomas Graf; +Cc: David Miller, netdev
In-Reply-To: <44A05FE0.7070203@trash.net>
Patrick McHardy wrote:
> All my testing (quite a lot) in this area so far suggested that queueing
> at ingress doesn't work and is actually counter-productive. It gets
> worse with increasing signal propagation delays (signal in this case
> means congestion indications). I actually wish I never introduced
> the stupid IMQ device, it raises false hope and a lot of people seem
> to fall for it.
Small clarification: with queueing at ingress I mean queueing after
the bottleneck. It might work if you introduce a virtual bottleneck,
but in that case in my experience the bandwidth limit you have to use
is dependant on the number of TCP flows, so usually you can't specify
a limit that will always work, and its wasteful if there is a smaller
number of TCP flows. The reason why you would do it, limiting or
prioritizing incoming traffic on the _real_ bottleneck, is not
achievable of course. Also noteworthy is that policers don't behave
any better, and any other schemes I've tried (I also experienced a
lot of with TCP rate control) have similar or related problems.
^ permalink raw reply
* Re: IOAT stuff
From: David Miller @ 2006-06-26 22:49 UTC (permalink / raw)
To: rdunlap; +Cc: christopher.leech, andrew.grover, netdev
In-Reply-To: <20060626152939.962b56e6.rdunlap@xenotime.net>
From: "Randy.Dunlap" <rdunlap@xenotime.net>
Date: Mon, 26 Jun 2006 15:29:39 -0700
> drivers/dma/ioatdma.c:830: warning: no return statement in function returning non-void
> drivers/dma/ioatdma.c:830: warning: control reaches end of non-void function
>
> Maybe insert "return" in front of:
>
> pci_module_init(&ioat_pci_drv);
>
> or is there some reason not to do that?
>
> BTW, pci_module_init() is obsolete. Drivers should be using
> pci_register_driver() instead.
>
> PS: IOAT/DMA (whatever) needs a MAINTAINERS entry.
It also still has the cpu hotplug locking bug, which none of the
I/O AT developers have even mentioned that they'd try to fix.
To reiterate, it tries to lock hotplug while holding spinlocks
which is illegal because locking hotplug takes a semaphore which
can sleep.
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Herbert Poetzl @ 2006-06-26 22:54 UTC (permalink / raw)
To: Ben Greear
Cc: Eric W. Biederman, Daniel Lezcano, Andrey Savochkin, linux-kernel,
netdev, serue, haveblue, clg, Andrew Morton, dev, devel, sam,
viro, Alexey Kuznetsov
In-Reply-To: <44A05BFD.6030402@candelatech.com>
On Mon, Jun 26, 2006 at 03:13:17PM -0700, Ben Greear wrote:
> Eric W. Biederman wrote:
>
> >Basically it is just a matter of:
> >if (dest_mac == my_mac1) it is for device 1.
> >If (dest_mac == my_mac2) it is for device 2.
> >etc.
> >
> >At a small count of macs it is trivial to understand it will go
> >fast for a larger count of macs it only works with a good data
> >structure. We don't hit any extra cache lines of the packet,
> >and the above test can be collapsed with other routing lookup tests.
>
> I think you should do this at the layer-2 level, well before you get
> to routing. That will make the virtual mac-vlan work with arbitrary
> protocols and appear very much like a regular ethernet interface.
> This approach worked well with .1q vlans, and with my version of the
> mac-vlan module.
yes, that sounds good to me, any numbers how that
affects networking in general (performance wise and
memory wise, i.e. caches and hashes) ...
> Using the mac-vlan and source-based routing tables, I can give a
> unique 'interface' to each process and have each process able to bind
> to the same IP port, for instance. Using source-based routing (by
> binding to a local IP explicitly and adding a route table for that
> source IP), I can give unique default routes to each interface as
> well. Since we cannot have more than 256 routing tables, this approach
> is currently limitted to around 250 virtual interfaces, but that is
> still a substantial amount.
an typically that would be sufficient IMHO, but
of course, a more 'general' hash tag would be
better in the long run ...
> My mac-vlan patch, redirect-device patch, and other hackings are
> consolidated in this patch:
>
> http://www.candelatech.com/oss/candela_2.6.16.patch
great! thanks!
best,
Herbert
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Ben Greear @ 2006-06-26 23:08 UTC (permalink / raw)
To: Herbert Poetzl
Cc: Eric W. Biederman, Daniel Lezcano, Andrey Savochkin, linux-kernel,
netdev, serue, haveblue, clg, Andrew Morton, dev, devel, sam,
viro, Alexey Kuznetsov
In-Reply-To: <20060626225440.GA7425@MAIL.13thfloor.at>
Herbert Poetzl wrote:
> On Mon, Jun 26, 2006 at 03:13:17PM -0700, Ben Greear wrote:
> yes, that sounds good to me, any numbers how that
> affects networking in general (performance wise and
> memory wise, i.e. caches and hashes) ...
I'll run some tests later today. Based on my previous tests,
I don't remember any significant overhead.
>>Using the mac-vlan and source-based routing tables, I can give a
>>unique 'interface' to each process and have each process able to bind
>>to the same IP port, for instance. Using source-based routing (by
>>binding to a local IP explicitly and adding a route table for that
>>source IP), I can give unique default routes to each interface as
>>well. Since we cannot have more than 256 routing tables, this approach
>>is currently limitted to around 250 virtual interfaces, but that is
>>still a substantial amount.
>
>
> an typically that would be sufficient IMHO, but
> of course, a more 'general' hash tag would be
> better in the long run ...
I'm willing to offer a bounty (hardware, beer, money, ...)
if someone will 'fix' this so we can have 1000 or more routes....
Being able to select these routes at a more global level (without
having to specifically bind to a local IP would be nice as well.)
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)
From: Venkat Yekkirala @ 2006-06-26 23:05 UTC (permalink / raw)
To: jmorris; +Cc: netdev, selinux, davem, sds, paul.moore, eparis
> What we need is a design rationale, some kind of detailed
> discussion of
> what the user requirements are and what the plan is for implementing
> features to meet these requirements.
The following is not extensive in a formal/theoretical sense, but hopefully
addresses the need here.
Needless to say, it is hoped MLS experts and others out there would join this
discussion.
USER REQUIREMENTS:
The broad user requirements for labeled networking would be that of information
labeling and flow control. Specifically,
1. Data labeling:
a. data must be labeled where it originates.
b. data must retain that label (or its interpretation in a given domain)
when conveyed in a trustworthy manner.
2. Flow control:
a. data must be flow controlled at the point it is consumed.
b. data must be flow controlled at the point it simply flows thru.
3. Data processing support:
a. Multi-level processes: provision for a sufficiently privileged/trusted
process (e.g. Multi-level server) to read/write data labeled at
different levels (specifically any/all levels within a given range).
Such trusted/privileged processes would usually operate at a given
level but would be able to read/write data at levels other than the
level they are operating at, as allowed by policy.
b. Multiple single-level processes: provision for a process (usually a
legacy, unmodified, untrusted) to be multi-instantiated, with each
process binding to the same port but running at a different level.
One way to support this is by providing for port polyinstantiation.
c. Multiple multi-level processes: provision for a process to be multi-
instantiated, with each process binding to the same port but running
at a different range (specifically all the levels in the range).
3(b) is a special case of this.
NOTE: We (TCS) have products that currently use 3(a) but not 3(b) or 3(c). As
such our thrust here is geared toward the former along with 1 and 2. There is
currently an ongoing discussion about using network namespaces for port
polyinstantiation at
http://www.redhat.com/archives/redhat-lspp/2006-June/msg00156.html.
PROPOSED DESIGN:
Given the above requirements the following design is proposed:
Socket labeling (SOCK):
1. Label socket to be at the same level as the creating process unless the
process is privileged and has specified a different label (R3a).
2. Create TCP child sockets with the MLS level taken from the peer
context, relying on the existing process-to-socket sendmsg, recvmsg
controls to protect the sockets (R3a).
On the inbound (INBND):
The following applies to traffic destined for local sockets (INPUT) as well as
forwarded traffic (FORWARD).
1. Set the packet's secmark to the iptables context (R1a).
2. If it is an ipsec packet,
Check that data with the ipsec label can "come thru" the "pipe" as
represented by the current secmark (iptables context) (R2b). That is,
check to make sure the ipsec MLS label falls WITHIN the MLS range of
the "pipe", and that the ipsec TE context can "come thru" the TE context
of the "pipe" per TE policy.
Yes: Set the secmark to ipsec label (replacing iptables context
set in step 1) (R1b).
No: Drop packet.
3. If it’s a CIPSO packet (NetLabel),
Check that data with the CIPSO label can "come thru" the "pipe" as
represented by current secmark (ipsec or iptables context) (R2b).
Yes: Set the secmark to CIPSO label (R1b).
No: Drop packet.
4. INPUT ONLY: Check socket can receive the packet. That is, check to
make sure the packet has MLS and TE read access to the packet per
SELinux policy (R1a, R3a, R3b).
5. FORWARD ONLY: Jump to OTBND2 below.
On the outbound (OTBND):
The following applies to locally-generated (OUTPUT) as well as forwarded
(FORWARD) traffic.
1. OUTPUT ONLY:
a. Set secmark of the packet to the label of the socket unless its a
datagram, the process is privileged and is allowed to specify
a different label for the datagram per policy (R1a, R3a, R3c).
b. If there's no real socket to take the label from, and this packet is
in response to a received packet, use the level from the received
packet, taking the TE portion of the context from the pseudo-socket
on whose behalf the packet is being sent.
2. If using CIPSO, set the option derived from Secmark (R1a). Drop packet
if a valid CIPSO option can't be derived.
3. If using IPSec (packet secmark must fall within the range of a xfrm
policy rule), choose a matching SA (again packet label must fall within
the range for the security association) (R2b, R1b). Set the secmark to
ipsec label (replacing the label it was set to in step 1).
4. In the POSTROUTING chain of the mangle table:
a. Determine the iptables context per the iptables POSTROUTING
policy chain in the mangle table. But it WON’T go into the secmark
of the packet like it currently does.
b. Check that the packet can "pass thru" the "pipe" as represented by
the iptables context (R2b). That is, the secmark's MLS label must
fall WITHIN the MLS range of the "pipe", and the secmark's TE context
can "pass thru" the TE context of the "pipe" per TE policy.
NOTE: This means that data may not necessarily have the
ability to go out by itself, just that it can go in an ipsec
pipe and that pipe can go out. You can have traffic that is
only allowed to leave via ipsec this way. data_t can not go out
of iface_t, but it can go into ipsec_pipe_t, which can go out
of iface_t.
User API (UAPI):
1. IPSec xfrms:
a. Specify labels with xfrm policy, association rules.
b. Specify label as part of acquire messages to IKE daemons
so the label can be made a part of the negotiation process.
2. Socket labeling:
a. Specify label to be used for sockets to be created.
3. Datagram labeling:
a. Specify label for a datagram being written.
OUTSTANDING ITEMS (ITEM):
1. Support for granular IPSec associations (INBND2, OTBND3).
2. Use level from incoming packet for outgoing packet when no real socket
present (OTBND1b).
3. TCP child sockets (SOCK2).
4. Checks against iptables context on outbound (OTBND4).
5. Socket labeling (UAPI2).
6. CIPSO (NetLabel) and other legacy labeling mechanisms.
7. Datagram labeling (UAPI3).
8. Port polyinstantiation (INBND4a).
ARCHITECTURAL DIRECTIONS:
Interaction with containers/network namespaces:
I have only cursorily glanced at containers and network namespaces, but
intuitively speaking, they could be defined to operate at different MLS
ranges and meet the above requirements in terms of handling data
that falls within those ranges.
Example:
Container/namespace A: Unclassified to Confidential
Container/namespace B: Secret to Top Secret
If a packet were to arrive with the label Confidential, it would need to be
"routed" to container A. Similarly, a packet labeled Secret would be routed
to namespace B. This would be satisfy Requirement 3c (R3c for short) .
Also, a packet labeled Secret must NOT be allowed to be sent from Container A,
but must be allowed from B, meeting Requirement 2.b (R2b for short).
GAME PLAN FOR PATCHES:
1. Patch for ITEM1, ITEM2, ITEM3 (being worked by TCS) should be out in a few
days.
2. Patch for ITEM4.
3. Patch for ITEM5 has already been done by Eric Paris and is being considered
for upstreaming.
4. Patch for ITEM6: Paul Moore has done a "NetLabel" patch for this and the
patch is currently under review upstream.
5. Patch for ITEM7: TCS currently have no plans to design and implement this.
6. Patch for ITEM8: There's currently an ongoing discussion about possibly
using network namespaces for this purpose. TCS have no plans to work on this
at the current time.
^ permalink raw reply
* Re: [redhat-lspp] Re: [RFC 3/7] NetLabel: CIPSOv4 engine
From: Joe Nall @ 2006-06-26 23:14 UTC (permalink / raw)
To: David Miller
Cc: Paul Moore, jmorris, Stephen Smalley, RedHat LSPP,
linux-security-module, SELinux List, netdev, Steve Grubb
In-Reply-To: <20060622.021223.125894633.davem@davemloft.net>
On Jun 22, 2006, at 4:12 AM, David Miller wrote:
> From: paul.moore@hp.com
> Date: Wed, 21 Jun 2006 15:42:38 -0400
>
>> Add support for the Commercial IP Security Option (CIPSO) to the
>> IPv4 network stack. CIPSO has become a de-facto standard for
>> trusted/labeled networking amongst existing Trusted Operating
>> Systems such as Trusted Solaris, HP-UX CMW, etc. This
>> implementation is designed to be used with the NetLabel subsystem to
>> provide explicit packet labeling to LSM developers.
>
> The thing that concerns me most about CIPSO is that even once users
> migrate to a more SELINUX native approach from this CIPSO stuff, the
> CIPSO code, it's bloat, and it's maintainence burdon will remain.
>
> It's easy to put stuff it, it's impossible to take stuff out even
> once it's largely unused by even it's original target audience.
>
> And that's what I see happening here.
>
> This is why, to be perfectly honest with you, I'd much rather
> something like this stay out-of-tree and people are strongly
> encouraged to use the more native stuff under Linux.
We are looking to replace a number of 20-60 node CMW networks with
lots of applications with an SELinux based network. Since mainstream
support for multilevel X Windows appears a ways off, we are looking
to replace the servers first and use the current CMWs as fat clients.
To make this work we need multilevel networking interoperability
between the SELinux and CMW systems.
We have been testing Paul's CIPSO patch against our existing systems
with good results.
For all of the EAL4 LSPP Linux evaluation work is being done by Red
Hat/IBM/HP/atsec and others to be useful to integrators, there has to
be basic (e.g. CIPSO) multilevel network interoperability with
existing multilevel systems and good (e.g IPSec) multilevel
networking between SELinux systems. Without that support, it will be
like some early Microsoft evaluations (1,2) that were reported to
have been done 'without a network card', a piece of paper describing
the test of a brick.
joe
(1) http://support.novell.com/techcenter/articles/ana19970705.html
(search for 'without')
(2) http://www.aaxnet.com/design/msanti.html (search for 'did not
have a network card')
^ permalink raw reply
* Re: [RFC] [patch 0/6] [Network namespace] introduction
From: Patrick McHardy @ 2006-06-26 23:38 UTC (permalink / raw)
To: dlezcano; +Cc: linux-kernel, netdev, serue, haveblue, clg
In-Reply-To: <20060609210202.215291000@localhost.localdomain>
dlezcano@fr.ibm.com wrote:
> What is missing ?
> -----------------
> The routes are not yet isolated, that implies:
>
> - binding to another container's address is allowed
>
> - an outgoing packet which has an unset source address can
> potentially get another container's address
>
> - an incoming packet can be routed to the wrong container if there
> are several containers listening to the same addr:port
Does that mean that identification of containers for incoming packets
is done by IP address through routing (just had a quick look at the
patches, if I missed something obvious please just point me to it)?
How is code that uses global data without verifying its presence
(and visibility in the container) at initialization time going to be
handled? Netfilter and I think the TC action code contain some examples
for this.
^ permalink raw reply
* Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)
From: James Morris @ 2006-06-27 0:29 UTC (permalink / raw)
To: Venkat Yekkirala; +Cc: netdev, selinux, davem, sds, paul.moore, eparis
In-Reply-To: <44A0684D.9080904@trustedcs.com>
On Mon, 26 Jun 2006, Venkat Yekkirala wrote:
> > What we need is a design rationale, some kind of detailed discussion of what
> > the user requirements are and what the plan is for implementing features to
> > meet these requirements.
>
> The following is not extensive in a formal/theoretical sense, but hopefully
> addresses the need here.
This is great, thanks. Exactly what was needed and much appreciated.
I think the interaction with secmark as you describe sounds good.
> 3. Patch for ITEM5 has already been done by Eric Paris and is being considered
> for upstreaming.
This is in Linus' tree now.
> 5. Patch for ITEM7: TCS currently have no plans to design and implement this.
>
(Datagram labeling)
I guess we'd probably use SCM_SECURITY for this (similar to
IP_CMSG_PASSEC for receiving the label).
Is this enough support for user API support at the kernel level in terms
of setting and getting labels?
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [redhat-lspp] Re: [RFC 3/7] NetLabel: CIPSOv4 engine
From: James Morris @ 2006-06-27 0:33 UTC (permalink / raw)
To: Joe Nall
Cc: David Miller, Paul Moore, jmorris, Stephen Smalley, RedHat LSPP,
linux-security-module, SELinux List, netdev, Steve Grubb
In-Reply-To: <F5329247-1566-4989-954B-A199240DC89F@nall.com>
On Mon, 26 Jun 2006, Joe Nall wrote:
> For all of the EAL4 LSPP Linux evaluation work is being done by Red
> Hat/IBM/HP/atsec and others to be useful to integrators, there has to be basic
> (e.g. CIPSO) multilevel network interoperability with existing multilevel
> systems and good (e.g IPSec) multilevel networking between SELinux systems.
Just to be clear, my understanding is that the native xfrm labeling is
suitable for LSPP evaluation, as distinct from CIPSO being desired by
system integrators from an interoperability point of view.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 02/21] e1000: rework driver hardware reset locking
From: Jeff Garzik @ 2006-06-27 1:42 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Ronciak, John
In-Reply-To: <20060622052009.25497.46358.stgit@gitlost.site>
Kok, Auke wrote:
> @@ -631,6 +627,9 @@ e1000_set_ringparam(struct net_device *n
> tx_ring_size = sizeof(struct e1000_tx_ring) * adapter->num_tx_queues;
> rx_ring_size = sizeof(struct e1000_rx_ring) * adapter->num_rx_queues;
>
> + while (test_and_set_bit(__E1000_RESETTING, &adapter->flags))
> + msleep(1);
This is a bit worrying, but no outright objection. We don't want to see
these accumulate.
^ permalink raw reply
* Re: [PATCH 06/21] e1000: add smart power down code
From: Jeff Garzik @ 2006-06-27 1:43 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Ronciak, John
In-Reply-To: <20060622052018.25497.43884.stgit@gitlost.site>
Kok, Auke wrote:
> Smart Power Down is a power saving feature in newer e1000 hardware. We
> disable it because it causes time to link to be long, but make it a
> user choice.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000/e1000.h | 1 +
> drivers/net/e1000/e1000_main.c | 15 +++++++++++++++
> drivers/net/e1000/e1000_param.c | 25 +++++++++++++++++++++++++
> 3 files changed, 41 insertions(+), 0 deletions(-)
Since it's not default, who will actually use this? Particularly since
it is only a module option, and not supported through ethtool (frown).
Jeff
^ permalink raw reply
* Re: [PATCH 10/21] e1000: force register write flushes to circumvent broken platforms
From: Jeff Garzik @ 2006-06-27 1:47 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Ronciak, John
In-Reply-To: <20060622052027.25497.51513.stgit@gitlost.site>
Kok, Auke wrote:
> A certain AMD64 bridge (8132) has an option to turn on write combining
> which breaks our adapter. To circumvent this we need to flush every write.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000/e1000_hw.c | 24 ++++++++++++++++++++++--
> drivers/net/e1000/e1000_main.c | 18 +++++++++++-------
> 2 files changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
> index 3959039..749d621 100644
> --- a/drivers/net/e1000/e1000_hw.c
> +++ b/drivers/net/e1000/e1000_hw.c
> @@ -705,8 +705,12 @@ e1000_init_hw(struct e1000_hw *hw)
> /* Zero out the Multicast HASH table */
> DEBUGOUT("Zeroing the MTA\n");
> mta_size = E1000_MC_TBL_SIZE;
> - for(i = 0; i < mta_size; i++)
> + for(i = 0; i < mta_size; i++) {
> E1000_WRITE_REG_ARRAY(hw, MTA, i, 0);
> + /* use write flush to prevent Memory Write Block (MWB) from
> + * occuring when accessing our register space */
> + E1000_WRITE_FLUSH(hw);
> + }
NAK. We can't crap up every driver just for one weird piece of hardware.
If this problem falls outside the grounds of mmiowb() [see
Documentation/memory-barriers.txt], then other solutions need to be
looked into... ioremap_nocache() ? Tweaking the MTRR for this region?
Chipset quirk? ...
Jeff
^ permalink raw reply
* Re: [PATCH 11/21] e1000: disable CRC stripping workaround
From: Jeff Garzik @ 2006-06-27 1:48 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Ronciak, John
In-Reply-To: <20060622052029.25497.67575.stgit@gitlost.site>
Kok, Auke wrote:
> CRC stripping is breaking SMBUS-connected BMC's. We disable this
> feature to make it work. This fixes related bugs regarding SOL.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000/e1000_main.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
> index c44ed6f..7787299 100644
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -1628,8 +1628,11 @@ e1000_setup_rctl(struct e1000_adapter *a
> E1000_RCTL_LBM_NO | E1000_RCTL_RDMTS_HALF |
> (adapter->hw.mc_filter_type << E1000_RCTL_MO_SHIFT);
>
> + /* disable hardware stripping of CRC because it breaks
> + * BMC firmware connected over SMBUS
> if (adapter->hw.mac_type > e1000_82543)
> rctl |= E1000_RCTL_SECRC;
> + */
>
> if (adapter->hw.tbi_compatibility_on == 1)
> rctl |= E1000_RCTL_SBP;
> @@ -1696,7 +1699,9 @@ e1000_setup_rctl(struct e1000_adapter *a
> rfctl |= E1000_RFCTL_IPV6_DIS;
> E1000_WRITE_REG(&adapter->hw, RFCTL, rfctl);
>
> - rctl |= E1000_RCTL_DTYP_PS | E1000_RCTL_SECRC;
> + /* disable the stripping of CRC because it breaks
> + * BMC firmware connected over SMBUS */
> + rctl |= E1000_RCTL_DTYP_PS /* | E1000_RCTL_SECRC */;
This is quite ugly. You are basically bloating the code with historic,
dead code, no different than filling the e1000/*.c with '#if 0' regions.
Just delete it, and explain why in the patch description.
Jeff
^ permalink raw reply
* Re: [PATCH 13/21] e1000: add E1000_BIG_ENDIAN symbol
From: Jeff Garzik @ 2006-06-27 1:49 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Ronciak, John
In-Reply-To: <20060622052034.25497.81683.stgit@gitlost.site>
Kok, Auke wrote:
> This adds a private symbol to signify endianess in our driver.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000/e1000_hw.h | 2 +-
> drivers/net/e1000/e1000_osdep.h | 3 +++
> 2 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h
> index 941b47d..376a2ef 100644
> --- a/drivers/net/e1000/e1000_hw.h
> +++ b/drivers/net/e1000/e1000_hw.h
> @@ -351,7 +351,7 @@ struct e1000_host_mng_command_info {
> struct e1000_host_mng_command_header command_header; /* Command Head/Command Result Head has 4 bytes */
> uint8_t command_data[E1000_HI_MAX_MNG_DATA_LENGTH]; /* Command data can length 0..0x658*/
> };
> -#ifdef __BIG_ENDIAN
> +#ifdef E1000_BIG_ENDIAN
> struct e1000_host_mng_dhcp_cookie{
> uint32_t signature;
> uint16_t vlan_id;
> diff --git a/drivers/net/e1000/e1000_osdep.h b/drivers/net/e1000/e1000_osdep.h
> index 048d052..6130a42 100644
> --- a/drivers/net/e1000/e1000_osdep.h
> +++ b/drivers/net/e1000/e1000_osdep.h
> @@ -83,6 +83,9 @@ typedef enum {
> #define DEBUGOUT3 DEBUGOUT2
> #define DEBUGOUT7 DEBUGOUT3
>
> +#ifdef __BIG_ENDIAN
> +#define E1000_BIG_ENDIAN __BIG_ENDIAN
> +#endif
NAK. This is backwards: We don't need wrappers for symbols that the
kernel already provides.
Jeff
^ permalink raw reply
* Re: [PATCH 17/21] e1000: add ich8lan core functions
From: Jeff Garzik @ 2006-06-27 1:52 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Ronciak, John
In-Reply-To: <20060622052043.25497.85145.stgit@gitlost.site>
Kok, Auke wrote:
> This implements the core new functions needed for ich8's internal
> NIC. This includes:
>
> * ich8 specific read/write code
> * flash/nvm access code
> * software semaphore flag functions
> * 10/100 PHY (fe - no gigabit speed) support for low-end versions
> * A workaround for a powerdown sequence problem discovered that
> affects a small number of motherboard.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000/e1000_hw.c | 1000 +++++++++++++++++++++++++++++++++++++++
> drivers/net/e1000/e1000_hw.h | 386 +++++++++++++++
> drivers/net/e1000/e1000_osdep.h | 13 +
> 3 files changed, 1392 insertions(+), 7 deletions(-)
If it takes this much code to support ICH8, it seems like a e1000-ich8.c
would be warranted...
Jeff
^ permalink raw reply
* Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)
From: Paul Moore @ 2006-06-27 1:53 UTC (permalink / raw)
To: Venkat Yekkirala; +Cc: jmorris, netdev, selinux, davem, sds, eparis
In-Reply-To: <44A0684D.9080904@trustedcs.com>
On Monday 26 June 2006 7:05 pm, Venkat Yekkirala wrote:
> USER REQUIREMENTS:
>
> The broad user requirements for labeled networking would be that of
> information labeling and flow control. Specifically,
>
> 1. Data labeling:
> a. data must be labeled where it originates.
> b. data must retain that label (or its interpretation in a given domain)
> when conveyed in a trustworthy manner.
{snip}
> PROPOSED DESIGN:
>
> Given the above requirements the following design is proposed:
>
> On the outbound (OTBND):
>
> The following applies to locally-generated (OUTPUT) as well as forwarded
> (FORWARD) traffic.
>
> 1. OUTPUT ONLY:
> a. Set secmark of the packet to the label of the socket unless its a
> datagram, the process is privileged and is allowed to specify
> a different label for the datagram per policy (R1a, R3a, R3c).
>
> b. If there's no real socket to take the label from, and this packet is
> in response to a received packet, use the level from the received
> packet, taking the TE portion of the context from the pseudo-socket
> on whose behalf the packet is being sent.
>
Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) to take
the label of the process/domain which sends the data to the socket? After
all, the process/domain is the "origin" of the data. This seems to be
particularly important in the case of fork()-then-exec() where you could have
a socket created at a different context from the domain currently writing to
it.
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: [PATCH 18/21] e1000: integrate ich8 support into driver
From: Jeff Garzik @ 2006-06-27 1:54 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Ronciak, John
In-Reply-To: <20060622052046.25497.11216.stgit@gitlost.site>
Kok, Auke wrote:
> @@ -4225,6 +4396,35 @@ e1000_init_eeprom_params(struct e1000_hw
> eeprom->use_eerd = TRUE;
> eeprom->use_eewr = FALSE;
> break;
> + case e1000_ich8lan:
> + {
> + int32_t i = 0;
> + uint32_t flash_size = E1000_READ_ICH8_REG(hw, ICH8_FLASH_GFPREG);
> +
> + eeprom->type = e1000_eeprom_ich8;
> + eeprom->use_eerd = FALSE;
> + eeprom->use_eewr = FALSE;
> + eeprom->word_size = E1000_SHADOW_RAM_WORDS;
> +
> + /* Zero the shadow RAM structure. But don't load it from NVM
> + * so as to save time for driver init */
> + if (hw->eeprom_shadow_ram != NULL) {
> + for (i = 0; i < E1000_SHADOW_RAM_WORDS; i++) {
> + hw->eeprom_shadow_ram[i].modified = FALSE;
> + hw->eeprom_shadow_ram[i].eeprom_word = 0xFFFF;
> + }
> + }
> +
> + hw->flash_base_addr = (flash_size & ICH8_GFPREG_BASE_MASK) *
> + ICH8_FLASH_SECTOR_SIZE;
> +
> + hw->flash_bank_size = ((flash_size >> 16) & ICH8_GFPREG_BASE_MASK) + 1;
> + hw->flash_bank_size -= (flash_size & ICH8_GFPREG_BASE_MASK);
> + hw->flash_bank_size *= ICH8_FLASH_SECTOR_SIZE;
> + hw->flash_bank_size /= 2 * sizeof(uint16_t);
> +
> + break;
> + }
seems to warrant a separate function, called from this callsite (perhaps
stored in e1000-ich8.c?)
> @@ -4645,7 +4845,10 @@ e1000_read_eeprom(struct e1000_hw *hw,
> return ret_val;
> }
>
> - if(eeprom->type == e1000_eeprom_spi) {
> + if (eeprom->type == e1000_eeprom_ich8)
> + return e1000_read_eeprom_ich8(hw, offset, words, data);
> +
> + if (eeprom->type == e1000_eeprom_spi) {
> uint16_t word_in;
> uint8_t read_opcode = EEPROM_READ_OPCODE_SPI;
>
> @@ -4812,7 +5015,10 @@ e1000_is_onboard_nvm_eeprom(struct e1000
>
> DEBUGFUNC("e1000_is_onboard_nvm_eeprom");
>
> - if(hw->mac_type == e1000_82573) {
> + if (hw->mac_type == e1000_ich8lan)
> + return FALSE;
> +
> + if (hw->mac_type == e1000_82573) {
> eecd = E1000_READ_REG(hw, EECD);
>
> /* Isolate bits 15 & 16 */
> @@ -4862,8 +5068,22 @@ e1000_validate_eeprom_checksum(struct e1
> }
> }
>
> - for(i = 0; i < (EEPROM_CHECKSUM_REG + 1); i++) {
> - if(e1000_read_eeprom(hw, i, 1, &eeprom_data) < 0) {
> + if (hw->mac_type == e1000_ich8lan) {
> + /* Drivers must allocate the shadow ram structure for the
> + * EEPROM checksum to be updated. Otherwise, this bit as well
> + * as the checksum must both be set correctly for this
> + * validation to pass.
> + */
> + e1000_read_eeprom(hw, 0x19, 1, &eeprom_data);
> + if ((eeprom_data & 0x40) == 0) {
> + eeprom_data |= 0x40;
> + e1000_write_eeprom(hw, 0x19, 1, &eeprom_data);
> + e1000_update_eeprom_checksum(hw);
> + }
> + }
> +
> + for (i = 0; i < (EEPROM_CHECKSUM_REG + 1); i++) {
> + if (e1000_read_eeprom(hw, i, 1, &eeprom_data) < 0) {
> DEBUGOUT("EEPROM Read Error\n");
> return -E1000_ERR_EEPROM;
> }
> @@ -4889,6 +5109,7 @@ e1000_validate_eeprom_checksum(struct e1
> int32_t
> e1000_update_eeprom_checksum(struct e1000_hw *hw)
> {
> + uint32_t ctrl_ext;
> uint16_t checksum = 0;
> uint16_t i, eeprom_data;
>
> @@ -4907,6 +5128,14 @@ e1000_update_eeprom_checksum(struct e100
> return -E1000_ERR_EEPROM;
> } else if (hw->eeprom.type == e1000_eeprom_flash) {
> e1000_commit_shadow_ram(hw);
> + } else if (hw->eeprom.type == e1000_eeprom_ich8) {
> + e1000_commit_shadow_ram(hw);
> + /* Reload the EEPROM, or else modifications will not appear
> + * until after next adapter reset. */
> + ctrl_ext = E1000_READ_REG(hw, CTRL_EXT);
> + ctrl_ext |= E1000_CTRL_EXT_EE_RST;
> + E1000_WRITE_REG(hw, CTRL_EXT, ctrl_ext);
> + msec_delay(10);
> }
> return E1000_SUCCESS;
> }
> @@ -4946,6 +5175,9 @@ e1000_write_eeprom(struct e1000_hw *hw,
> if(eeprom->use_eewr == TRUE)
> return e1000_write_eeprom_eewr(hw, offset, words, data);
>
> + if (eeprom->type == e1000_eeprom_ich8)
> + return e1000_write_eeprom_ich8(hw, offset, words, data);
> +
> /* Prepare the EEPROM for writing */
> if (e1000_acquire_eeprom(hw) != E1000_SUCCESS)
> return -E1000_ERR_EEPROM;
> @@ -5133,11 +5365,17 @@ e1000_commit_shadow_ram(struct e1000_hw
> uint32_t flop = 0;
> uint32_t i = 0;
> int32_t error = E1000_SUCCESS;
> -
> - /* The flop register will be used to determine if flash type is STM */
> - flop = E1000_READ_REG(hw, FLOP);
> + uint32_t old_bank_offset = 0;
> + uint32_t new_bank_offset = 0;
> + uint32_t sector_retries = 0;
> + uint8_t low_byte = 0;
> + uint8_t high_byte = 0;
> + uint8_t temp_byte = 0;
> + boolean_t sector_write_failed = FALSE;
>
> if (hw->mac_type == e1000_82573) {
> + /* The flop register will be used to determine if flash type is STM */
> + flop = E1000_READ_REG(hw, FLOP);
> for (i=0; i < attempts; i++) {
> eecd = E1000_READ_REG(hw, EECD);
> if ((eecd & E1000_EECD_FLUPD) == 0) {
> @@ -5171,6 +5409,106 @@ e1000_commit_shadow_ram(struct e1000_hw
> }
> }
>
> + if (hw->mac_type == e1000_ich8lan && hw->eeprom_shadow_ram != NULL) {
> + /* We're writing to the opposite bank so if we're on bank 1,
> + * write to bank 0 etc. We also need to erase the segment that
> + * is going to be written */
> + if (!(E1000_READ_REG(hw, EECD) & E1000_EECD_SEC1VAL)) {
> + new_bank_offset = hw->flash_bank_size * 2;
> + old_bank_offset = 0;
> + e1000_erase_ich8_4k_segment(hw, 1);
> + } else {
> + old_bank_offset = hw->flash_bank_size * 2;
> + new_bank_offset = 0;
> + e1000_erase_ich8_4k_segment(hw, 0);
> + }
> +
> + do {
> + sector_write_failed = FALSE;
> + /* Loop for every byte in the shadow RAM,
> + * which is in units of words. */
> + for (i = 0; i < E1000_SHADOW_RAM_WORDS; i++) {
> + /* Determine whether to write the value stored
> + * in the other NVM bank or a modified value stored
> + * in the shadow RAM */
> + if (hw->eeprom_shadow_ram[i].modified == TRUE) {
> + low_byte = (uint8_t)hw->eeprom_shadow_ram[i].eeprom_word;
> + e1000_read_ich8_byte(hw, (i << 1) + old_bank_offset,
> + &temp_byte);
> + udelay(100);
> + error = e1000_verify_write_ich8_byte(hw,
> + (i << 1) + new_bank_offset,
> + low_byte);
> + if (error != E1000_SUCCESS)
> + sector_write_failed = TRUE;
> + high_byte =
> + (uint8_t)(hw->eeprom_shadow_ram[i].eeprom_word >> 8);
> + e1000_read_ich8_byte(hw, (i << 1) + old_bank_offset + 1,
> + &temp_byte);
> + udelay(100);
> + } else {
> + e1000_read_ich8_byte(hw, (i << 1) + old_bank_offset,
> + &low_byte);
> + udelay(100);
> + error = e1000_verify_write_ich8_byte(hw,
> + (i << 1) + new_bank_offset, low_byte);
> + if (error != E1000_SUCCESS)
> + sector_write_failed = TRUE;
> + e1000_read_ich8_byte(hw, (i << 1) + old_bank_offset + 1,
> + &high_byte);
> + }
> +
> + /* If the word is 0x13, then make sure the signature bits
> + * (15:14) are 11b until the commit has completed.
> + * This will allow us to write 10b which indicates the
> + * signature is valid. We want to do this after the write
> + * has completed so that we don't mark the segment valid
> + * while the write is still in progress */
> + if (i == E1000_ICH8_NVM_SIG_WORD)
> + high_byte = E1000_ICH8_NVM_SIG_MASK | high_byte;
> +
> + error = e1000_verify_write_ich8_byte(hw,
> + (i << 1) + new_bank_offset + 1, high_byte);
> + if (error != E1000_SUCCESS)
> + sector_write_failed = TRUE;
> +
> + if (sector_write_failed == FALSE) {
> + /* Clear the now not used entry in the cache */
> + hw->eeprom_shadow_ram[i].modified = FALSE;
> + hw->eeprom_shadow_ram[i].eeprom_word = 0xFFFF;
> + }
> + }
> +
> + /* Don't bother writing the segment valid bits if sector
> + * programming failed. */
> + if (sector_write_failed == FALSE) {
> + /* Finally validate the new segment by setting bit 15:14
> + * to 10b in word 0x13 , this can be done without an
> + * erase as well since these bits are 11 to start with
> + * and we need to change bit 14 to 0b */
> + e1000_read_ich8_byte(hw,
> + E1000_ICH8_NVM_SIG_WORD * 2 + 1 + new_bank_offset,
> + &high_byte);
> + high_byte &= 0xBF;
> + error = e1000_verify_write_ich8_byte(hw,
> + E1000_ICH8_NVM_SIG_WORD * 2 + 1 + new_bank_offset,
> + high_byte);
> + if (error != E1000_SUCCESS)
> + sector_write_failed = TRUE;
> +
> + /* And invalidate the previously valid segment by setting
> + * its signature word (0x13) high_byte to 0b. This can be
> + * done without an erase because flash erase sets all bits
> + * to 1's. We can write 1's to 0's without an erase */
> + error = e1000_verify_write_ich8_byte(hw,
> + E1000_ICH8_NVM_SIG_WORD * 2 + 1 + old_bank_offset,
> + 0);
> + if (error != E1000_SUCCESS)
> + sector_write_failed = TRUE;
> + }
> + } while (++sector_retries < 10 && sector_write_failed == TRUE);
> + }
> +
obviously warrants a separate function for new ich8 code...
^ permalink raw reply
* Re: [PATCH 19/21] e1000: allow user to disable ich8 lock loss workaround
From: Jeff Garzik @ 2006-06-27 1:55 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Ronciak, John
In-Reply-To: <20060622052048.25497.45771.stgit@gitlost.site>
Kok, Auke wrote:
> The workaround for the ich8 lock loss problem is only needed for
> a very small amount of systems. This adds an option for the user
> to disable the workaround.
Does "very small amount" equate to "never in real production machines"?
^ permalink raw reply
* Re: [PATCH] smc91x: disable DMA mode on the logicpd pxa270
From: Jeff Garzik @ 2006-06-27 2:02 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev, nico, mikee, peterb
In-Reply-To: <20060623212436.GB4843@xi.wantstofly.org>
Lennert Buytenhek wrote:
> Enabling PXA DMA for the smc91x on the logicpd pxa270 produces
> unacceptable interference with the TFT panel, so disable it. Also
> delete the lpd270 versions of the SMC_{in,out}[bl]() macros, as they
> aren't used, since the board only supports 16bit accesses.
>
> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
>
> Index: linux-2.6.17-git5/drivers/net/smc91x.h
ACK, but git-applymbox claims the patch is corrupt
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Jeff Garzik @ 2006-06-27 2:06 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev
In-Reply-To: <20060626212547.GE30706@tuxdriver.com>
John W. Linville wrote:
> + assert(bcm->mac_suspended >= 0);
> + if (bcm->mac_suspended == 0) {
> + bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
> + bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
> + bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
> + & ~BCM43xx_SBF_MAC_ENABLED);
> + bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
> + for (i = 100000; i; i--) {
> + tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
> + if (tmp & BCM43xx_IRQ_READY)
> + goto out;
> + udelay(10);
> + }
> + printkl(KERN_ERR PFX "MAC suspend failed\n");
> }
NAK this super-long delay... should be done in a workqueue, looks like?
ACK everything else.
Jeff
^ permalink raw reply
* Re: [PATCH] smc91x: disable DMA mode on the logicpd pxa270
From: Lennert Buytenhek @ 2006-06-27 2:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, nico, mikee, peterb
In-Reply-To: <44A091CC.90607@pobox.com>
On Mon, Jun 26, 2006 at 10:02:52PM -0400, Jeff Garzik wrote:
> >Enabling PXA DMA for the smc91x on the logicpd pxa270 produces
> >unacceptable interference with the TFT panel, so disable it. Also
> >delete the lpd270 versions of the SMC_{in,out}[bl]() macros, as they
> >aren't used, since the board only supports 16bit accesses.
> >
> >Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
> >
> >Index: linux-2.6.17-git5/drivers/net/smc91x.h
>
> ACK, but git-applymbox claims the patch is corrupt
Hmmm, non-quilt style patch better?
==
Enabling PXA DMA for the smc91x on the logicpd pxa270 produces
unacceptable interference with the TFT panel, so disable it. Also
delete the lpd270 versions of the SMC_{in,out}[bl]() macros, as they
aren't used, since the board only supports 16bit accesses.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
--- linux-2.6.17-git10.orig/drivers/net/smc91x.h 2006-06-27 04:05:20.000000000 +0200
+++ linux-2.6.17-git10/drivers/net/smc91x.h 2006-06-27 04:05:47.000000000 +0200
@@ -136,14 +136,9 @@
#define SMC_CAN_USE_32BIT 0
#define SMC_IO_SHIFT 0
#define SMC_NOWAIT 1
-#define SMC_USE_PXA_DMA 1
-#define SMC_inb(a, r) readb((a) + (r))
#define SMC_inw(a, r) readw((a) + (r))
-#define SMC_inl(a, r) readl((a) + (r))
-#define SMC_outb(v, a, r) writeb(v, (a) + (r))
#define SMC_outw(v, a, r) writew(v, (a) + (r))
-#define SMC_outl(v, a, r) writel(v, (a) + (r))
#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l)
#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l)
^ permalink raw reply
* Re: [PATCH] smc91x: disable DMA mode on the logicpd pxa270
From: Lennert Buytenhek @ 2006-06-27 2:14 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, nico, mikee, peterb
In-Reply-To: <20060627020831.GA20393@xi.wantstofly.org>
On Tue, Jun 27, 2006 at 04:08:31AM +0200, Lennert Buytenhek wrote:
> Hmmm, non-quilt style patch better?
I might have an idea what's happening -- the last context line in the
patch should have been a blank line, but it's being eaten somewhere in
transit.
> -#define SMC_inb(a, r) readb((a) + (r))
> #define SMC_inw(a, r) readw((a) + (r))
> -#define SMC_inl(a, r) readl((a) + (r))
> -#define SMC_outb(v, a, r) writeb(v, (a) + (r))
> #define SMC_outw(v, a, r) writew(v, (a) + (r))
> -#define SMC_outl(v, a, r) writel(v, (a) + (r))
> #define SMC_insw(a, r, p, l) readsw((a) + (r), p, l)
> #define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l)
<=== there should have been a blank line here
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Not sure what is causing this. Can you take it from here?
http://www.wantstofly.org/~buytenh/smc91-diff-lpd.diff
thanks,
Lennert
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Larry Finger @ 2006-06-27 2:27 UTC (permalink / raw)
To: Jeff Garzik; +Cc: John W. Linville, netdev, Bcm43xx-dev
In-Reply-To: <44A09289.4040200@garzik.org>
Jeff Garzik wrote:
> John W. Linville wrote:
>> + assert(bcm->mac_suspended >= 0);
>> + if (bcm->mac_suspended == 0) {
>> + bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
>> + bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
>> + bcm43xx_read32(bcm,
>> BCM43xx_MMIO_STATUS_BITFIELD)
>> + & ~BCM43xx_SBF_MAC_ENABLED);
>> + bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy
>> read */
>> + for (i = 100000; i; i--) {
>> + tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
>> + if (tmp & BCM43xx_IRQ_READY)
>> + goto out;
>> + udelay(10);
>> + }
>> + printkl(KERN_ERR PFX "MAC suspend failed\n");
>> }
>
>
> NAK this super-long delay... should be done in a workqueue, looks like?
>
> ACK everything else.
>
That delay was set to try to accommodate my interface when it refused to suspend the MAC, which
resulted in transmit errors. That problem has since been cured by reworking the periodic work
handlers - thus such a long delay should not be needed. The original spec from the clean-room group
was a delay loop of 1000. I'm currently testing that value now. If it passes the test, would a for
(i=1000; i; i--) be acceptable?
Larry
^ permalink raw reply
* Re: [redhat-lspp] Re: [RFC 3/7] NetLabel: CIPSOv4 engine
From: Paul Moore @ 2006-06-27 2:45 UTC (permalink / raw)
To: James Morris
Cc: Joe Nall, David Miller, jmorris, Stephen Smalley, RedHat LSPP,
linux-security-module, SELinux List, netdev, Steve Grubb
In-Reply-To: <Pine.LNX.4.64.0606262031010.26545@d.namei>
On Monday 26 June 2006 8:33 pm, James Morris wrote:
> On Mon, 26 Jun 2006, Joe Nall wrote:
> > For all of the EAL4 LSPP Linux evaluation work is being done by Red
> > Hat/IBM/HP/atsec and others to be useful to integrators, there has to be
> > basic (e.g. CIPSO) multilevel network interoperability with existing
> > multilevel systems and good (e.g IPSec) multilevel networking between
> > SELinux systems.
>
> Just to be clear, my understanding is that the native xfrm labeling is
> suitable for LSPP evaluation, as distinct from CIPSO being desired by
> system integrators from an interoperability point of view.
>
True, but I believe the point Joe was trying to make was that providing
support for only one labeling mechanism would limit the usefulness of the
evaluated configuration. What good is a Common Criteria evaluation if it
doesn't contain the features that user's require?
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: [patch 1/3] natsemi: Add quirks for Aculab E1/T1 PMXc cPCI carrier cards
From: Jeff Garzik @ 2006-06-27 3:49 UTC (permalink / raw)
To: akpm; +Cc: netdev, broonie, jgarzik, thockin
In-Reply-To: <200606250844.k5P8iZkg020788@shell0.pdx.osdl.net>
akpm@osdl.org wrote:
> From: Mark Brown <broonie@sirena.org.uk>
>
> Aculab E1/T1 PMXc cPCI carrier card cards present a natsemi on the cPCI bus
> wired up in a non-standard fashion. This patch provides support in the
> natsemi driver for these cards by implementing a quirk mechanism and using
> that to configure appropriate settings for the card: forcing 100M full duplex,
> having a large EEPROM and using the MII port while ignoring PHYs.
>
> Signed-off-by: Mark Brown <broonie@sirena.org.uk>
> Cc: Tim Hockin <thockin@hockin.org>
> Cc: Jeff Garzik <jgarzik@pobox.com>
>
> [akpm: this is a previously-nacked patch, but the problem is real]
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
> drivers/net/natsemi.c | 94 ++++++++++++++++++++++++--------------
> include/linux/pci_ids.h | 3 +
> 2 files changed, 63 insertions(+), 34 deletions(-)
I checked in a couple patches in preparation for merging this. Please
rediff and resend, and I'll apply.
Jeff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox