[ Upstream commit: 36ca34cc ]

Noticed by Paul Marks <paul@pmarks.net>.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[ Upstream commit: 58163393 ]

We should not conditionalize VA range checks on MAP_FIXED.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[CRYPTO] eseqiv: Fix off-by-one encryption

[ Upstream commit: 46f8153c ]

After attaching the IV to the head during encryption, eseqiv does not
increase the encryption length by that amount.  As such the last block
of the actual plain text will be left unencrypted.

Fortunately the only user of this code hifn currently crashes so this
shouldn't affect anyone :)

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[CRYPTO] authenc: Fix async crypto crash in crypto_authenc_genicv()

[ Upstream commit: 16161329 ]

crypto_authenc_givencrypt_done uses req->data as struct aead_givcrypt_request,
while it really points to a struct aead_request, causing this crash:

BUG: unable to handle kernel paging request at 6b6b6b6b
IP: [<dc87517b>] :authenc:crypto_authenc_genicv+0x23/0x109
*pde = 00000000
Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
Modules linked in: hifn_795x authenc esp4 aead xfrm4_mode_tunnel sha1_generic hmac crypto_hash]

Pid: 3074, comm: ping Not tainted (2.6.25 #4)
EIP: 0060:[<dc87517b>] EFLAGS: 00010296 CPU: 0
EIP is at crypto_authenc_genicv+0x23/0x109 [authenc]
EAX: daa04690 EBX: daa046e0 ECX: dab0a100 EDX: daa046b0
ESI: 6b6b6b6b EDI: dc872054 EBP: c033ff60 ESP: c033ff0c
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process ping (pid: 3074, ti=c033f000 task=db883a80 task.ti=dab6c000)
Stack: 00000000 daa046b0 c0215a3e daa04690 dab0a100 00000000 ffffffff db9fd7f0
       dba208c0 dbbb1720 00000001 daa04720 00000001 c033ff54 c0119ca9 dc852a75
       c033ff60 c033ff60 daa046e0 00000000 00000001 c033ff6c dc87527b 00000001
Call Trace:
 [<c0215a3e>] ? dev_alloc_skb+0x14/0x29
 [<c0119ca9>] ? printk+0x15/0x17
 [<dc87527b>] ? crypto_authenc_givencrypt_done+0x1a/0x27 [authenc]
 [<dc850cca>] ? hifn_process_ready+0x34a/0x352 [hifn_795x]
 [<dc8353c7>] ? rhine_napipoll+0x3f2/0x3fd [via_rhine]
 [<dc851a56>] ? hifn_check_for_completion+0x4d/0xa6 [hifn_795x]
 [<dc851ab9>] ? hifn_tasklet_callback+0xa/0xc [hifn_795x]
 [<c011d046>] ? tasklet_action+0x3f/0x66
 [<c011d230>] ? __do_softirq+0x38/0x7a
 [<c0105a5f>] ? do_softirq+0x3e/0x71
 [<c011d17c>] ? irq_exit+0x2c/0x65
 [<c010e0c0>] ? smp_apic_timer_interrupt+0x5f/0x6a
 [<c01042e4>] ? apic_timer_interrupt+0x28/0x30
 [<dc851640>] ? hifn_handle_req+0x44a/0x50d [hifn_795x]
 ...

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[CRYPTO] cryptd: Correct kzalloc error test

[ Upstream commit: b1145ce3 ]

Normally, kzalloc returns NULL or a valid pointer value, not a value to be
tested using IS_ERR.

Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[CRYPTO] api: Fix scatterwalk_sg_chain

[ Upstream commit: 8ec970d8 ]

When I backed out of using the generic sg chaining (as it isn't currently
portable) and introduced scatterwalk_sg_chain/scatterwalk_sg_next I left
out the sg_is_last check in the latter.  This causes it to potentially
dereference beyond the end of the sg array.

As most uses of scatterwalk_sg_next are bound by an overall length, this
only affected the chaining code in authenc and eseqiv. Thanks to Patrick
McHardy for identifying this problem.

This patch also clears the "last" bit on the head of the chained list as
it's no longer last.  This also went missing in scatterwalk_sg_chain and
is present in sg_chain.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This is a backport of the noted commit which is in 2.6.26-rc1
now.  This is necessary to enable pci=bfsort automatically on a number
of Dell and HP servers, as well as pci=assign-busses for a few other
systems, which was broken between 2.6.22 and 2.6.23.

commit 0df18ff3 upstream

x86 PCI: call dmi_check_pciprobe()

this change:

| commit 08f1c192
| Author: Muli Ben-Yehuda <muli@il.ibm.com>
| Date:   Sun Jul 22 00:23:39 2007 +0300
|
|    x86-64: introduce struct pci_sysdata to facilitate sharing of ->sysdata
|
|    This patch introduces struct pci_sysdata to x86 and x86-64, and
|    converts the existing two users (NUMA, Calgary) to use it.
|
|    This lays the groundwork for having other users of sysdata, such as
|    the PCI domains work.
|
|    The Calgary bits are tested, the NUMA bits just look ok.

replaces pcibios_scan_root with pci_scan_bus_parented...

but in pcibios_scan_root we have a DMI check:

dmi_check_system(pciprobe_dmi_table);

when when have several peer root buses this could be called multiple
times (which is bad), so move that call to pci_access_init().

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 21a75d77 upstream.

This fixes some TX/RX related locking issues.
With this patch applied, some of the PHY transmission errors are fixed.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The ARM kprobes arithmetic immediate instruction decoder
(space_cccc_001x()) was accidentally zero'ing out not only the Rn and
Rd arguments, but the lower nibble of the immediate argument as well
-- this patch fixes this.

Mainline commit: a3fd133c

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

It is more useful to flush the cache with the actual buffer address
rather than the address containing a pointer to the buffer.

Mainline commit: 8f79ff0c

Signed-off-by: Nicolas Pitre <nico@marvell.com>
Acked-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2e35af14 upstream

This fixes operation of dual-PHY (A/B/G) devices.
Do not anounce the A-PHY to mac80211, as that's not supported, yet.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit bc775eac upstream

If CONFIG_PPC_MPC5121 is not set, then the of_device_id table for the
mpc5200 serial driver will not get terminated with a NULL entry.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d5dee5c3 upstream

Quota files cannot have tails because quota_write and quota_read functions do
not support them. So far when quota files did have tail, we just refused to
turn quotas on it. Sadly this check has been wrong and so there are now plenty
installations where quota files don't have NOTAIL flag set and so now after
fixing the check, they suddently fail to turn quotas on. Since it's easy to
unpack the tail from kernel, do this from reiserfs_quota_on() which solves the
problem and is generally nicer to users anyway.

Signed-off-by: Jan Kara <jack@suse.cz>
Reported-by:  <urhausen@urifabi.net>
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit: b328ca18 upstream

Gautham R Shenoy reported:

 > While running the usual CPU-Hotplug stress tests on linux-2.6.25,
 > I noticed the following in the console logs.
 >
 > This is a wee bit difficult to reproduce. In the past 10 runs I hit this
 > only once.
 >
 > ------------[ cut here ]------------
 >
 > WARNING: at kernel/sched.c:962 hrtick+0x2e/0x65()
 >
 > Just wondering if we are doing a good job at handling the cancellation
 > of any per-cpu scheduler timers during CPU-Hotplug.

This looks like its indeed not cancelled at all and migrates the it to
another cpu. Fix it via a proper hotplug notifier mechanism.

Reported-by: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit: 02c6be61 upstream

If utimensat() is called with both times set to UTIME_NOW or one of them to
UTIME_NOW and the other to UTIME_OMIT, then it will update the file time
without any permission checking.

I don't think this can be used for anything other than a local DoS, but could
be quite bewildering at that (e.g.  "Why was that large source tree rebuilt
when I didn't modify anything???")

This affects all kernels from 2.6.22, when the utimensat() syscall was
introduced.

Fix by doing the same permission checking as for the "times == NULL" case.

Thanks to Michael Kerrisk, whose utimensat-non-conformances-and-fixes.patch in
-mm also fixes this (and breaks other stuff), only he didn't realize the
security implications of this bug.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Ulrich Drepper <drepper@redhat.com>
Cc: Michael Kerrisk <mtk-manpages@gmx.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit: 6a51830e upstream

rdev->mddev is no longer valid upon return from entry->store() when the
'remove' command is given.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit: 86051ca5 upstream

usemap must be initialized only when pfn is within zone.  If not, it corrupts
memory.

And this patch also reduces the number of calls to set_pageblock_migratetype()
from
	(pfn & (pageblock_nr_pages -1)
to
	!(pfn & (pageblock_nr_pages-1)
it should be called once per pageblock.

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Shi Weihua <shiwh@cn.fujitsu.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0fda6b40 upstream

Patch to fix huge number of wakeups reported due to recent changes in
processor_idle.c. The problem was that the entry_method determination was
broken due to one of the recent commits (bc71bec9) causing
C1 entry to not to go to halt.

http://lkml.org/lkml/2008/3/22/124



Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0b2bac2f upstream.

fcntl_setlk()/close() race prevention has a subtle hole - we need to
make sure that if we *do* have an fcntl/close race on SMP box, the
access to descriptor table and inode->i_flock won't get reordered.

As it is, we get STORE inode->i_flock, LOAD descriptor table entry vs.
STORE descriptor table entry, LOAD inode->i_flock with not a single
lock in common on both sides.  We do have BKL around the first STORE,
but check in locks_remove_posix() is outside of BKL and for a good
reason - we don't want BKL on common path of close(2).

Solution is to hold ->file_lock around fcheck() in there; that orders
us wrt removal from descriptor table that preceded locks_remove_posix()
on close path and we either come first (in which case eviction will be
handled by the close side) or we'll see the effect of close and do
eviction ourselves.  Note that even though it's read-only access,
we do need ->file_lock here - rcu_read_lock() won't be enough to
order the things.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 214b7049 upstream.

We have a race between fcntl() and close() that can lead to
dnotify_struct inserted into inode's list *after* the last descriptor
had been gone from current->files.

Since that's the only point where dnotify_struct gets evicted, we are
screwed - it will stick around indefinitely.  Even after struct file in
question is gone and freed.  Worse, we can trigger send_sigio() on it at
any later point, which allows to send an arbitrary signal to arbitrary
process if we manage to apply enough memory pressure to get the page
that used to host that struct file and fill it with the right pattern...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 62035542 in mainline.

Yeah, in practice they both mean "root", but Alan correctly points out
that anybody who gets to do raw IO space accesses should really be using
CAP_SYS_RAWIO rather than CAP_NET_ADMIN.

Pointed-out-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0c96c597 upstream

The scheduler hrtimer bits in 2.6.25 introduced a circular lock
dependency in a rare code path:

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.25-sched-devel.git-x86-latest.git #19
-------------------------------------------------------
X/2980 is trying to acquire lock:
 (&rq->rq_lock_key#2){++..}, at: [<ffffffff80230146>] task_rq_lock+0x56/0xa0

but task is already holding lock:
 (&cpu_base->lock){++..}, at: [<ffffffff80257ae1>] lock_hrtimer_base+0x31/0x60

which lock already depends on the new lock.

The scenario which leads to this is:

posix-timer signal is delivered
 -> posix-timer is rearmed
    timer is already expired in hrtimer_enqueue()
     -> softirq is raised

To prevent this we need to move the raise of the softirq out of the
base->lock protected code path.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 9d9ad4b5 upstream

This bug was introduced in the 2.6.24 lguest merge, where
MSI-X vector allocation will eventually fail.  The cause is the new
bit array tracking used vectors is not getting cleared properly on
IRQ destruction on the 32-bit APIC code.

This can be seen easily using the ixgbe 10 GbE driver on multi-core
systems by simply loading and unloading the driver a few times.
Depending on the number of available vectors on the host system, the
MSI-X allocation will eventually fail, and the driver will only be
able to use legacy interrupts.

Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2444e56b upstream


OSF/1 brk(2) was broken by following one-liner in sys_brk()
(commit 4cc6028d):

-	if (brk < mm->end_code)
+	if (brk < mm->start_brk)
		goto out;

The problem is that osf_set_program_attributes()
does update mm->end_code, but not mm->start_brk,
which still contains inappropriate value left from
binary loader, so brk() always fails.

Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit: 666301e6 upstream


Commit 63a8651f ([SCSI] qla2xxx:
Correct infinite-login-retry issue.) introduced a small
regression where a successful relogin would result in an fcport's
loop_id to be incorrectly reset to FC_NO_LOOP_ID.  Only clear-out
loopid, if retries have been 'truly' exhausted.

Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit: bc5698f3 upstream

After PXE boot, the iw_nes driver does a full reset to ensure the card
is in a clean state.  However, it doesn't wait for firmware to
complete its work before issuing a port reset to enable the ports,
which leads to problems bringing up the ports.

The solution is to wait for firmware to complete its work before
proceeding with port reset.

This bug was flagged by Roland Dreier <rolandd@cisco.com>.

Signed-off-by: Chien Tung <ctung@neteffect.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d7b41a24 upstream

When using hrtimer with timer->cb_mode == HRTIMER_CB_SOFTIRQ
in some cases the clockevent is not programmed.
This happens, if:
 - a timer is rearmed while it's state is HRTIMER_STATE_CALLBACK
 - hrtimer_reprogram() returns -ETIME, when it is called after
   CALLBACK is finished. This occurs if the new timer->expires
   is in the past when CALLBACK is done.
In this case, the timer needs to be removed from the tree and put
onto the pending list again.

The patch is against 2.6.22.5, but AFAICS, it is relevant
for 2.6.25 also (in run_hrtimer_pending()).

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 556637cd upstream


After the loop in walk_pte_range() pte might point to the first address after
the pmd it walks.  The pte_unmap() is then applied to something bad.

Spotted by Roel Kluin and Andreas Schwab.

Signed-off-by: Johannes Weiner <hannes@saeurebad.de>
Cc: Roel Kluin <12o3l@tiscali.nl>
Cc: Andreas Schwab <schwab@suse.de>
Acked-by: Matt Mackall <mpm@selenic.com>
Acked-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 1ecf0d0c upstream

When loops reaches 0 the postfix decrement still subtracts, so the subsequent
test fails.

Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Acked-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Johannes Weiner <hannes@saeurebad.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 77459b05 upstream


Fix bogus #include in rtc-pcf8583, so it compiles on platforms that
don't support PC clone RTCs.  (Original issue noted by Adrian Bunk.)

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Adrian Bunk <bunk@kernel.org>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e92adcba upstream

This patch wakes up a thread waiting in io_getevents if another thread
destroys the context.  This was tested using a small program that spawns a
thread to wait in io_getevents while the parent thread destroys the io context
and then waits for the getevents thread to exit.  Without this patch, the
program hangs indefinitely.  With the patch, the program exits as expected.

Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Cc: Zach Brown <zach.brown@oracle.com>
Cc: Christopher Smith <x@xman.org>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Commit f946dffe upstream

Noticed by davem.

Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 6131a260 upstream


Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 1033b3ea upstream

Some mainboards/CPUs don't allow DMA masks bigger than a certain limit.
Some VIA crap^h^h^h^hdevices have an upper limit of 0xFFFFFFFF. So in this
case a 64-bit b43 device would always fail to acquire the mask.
Implement a workaround to fallback to lower DMA mask, as we can always
also support a lower mask.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 9fc38458 upstream

This adds more workarounds for devices with broken BT bits.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 1855ba78 upstream.

This adds a workaround for invalid bluetooth SPROM settings
on ASUS PCI cards.
This will stop the microcode from poking with the BT GPIO line.
This fixes data transmission on this device, as the BT GPIO line
is used for something TX related on this device
(probably the power amplifier or the radio).
This also adds a modparam knob to help debugging this in the future,
as more devices with this bug may show up.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 4503183a upstream

In the SSB SPROM a field set to all ones means the value
is not defined in the SPROM.
In case of the boardflags, we need to set them to zero
to avoid confusing drivers. Drivers will only check the
flags by ANDing.


Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Gabor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>