Some versions of GCC apparently expect this to be provided by libgcc.
Updates from Mikey to fix 32 bit version and adding "r" to registers.
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Michael Neuling <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
On allocation failure, it would fail to free the old attrs array which
was no longer referenced by anything (since it would free the old
module_param_attrs struct on the way out).
Comment the suspicious-looking krealloc() usage to explain why it *isn't*
actually buggy, despite looking like a classic realloc() usage bug.
Signed-off-by: David Woodhouse <[email protected]>
If krealloc() returns NULL, it *doesn't* free the original. So any code
of the form 'foo = krealloc(foo, …);' is almost certainly a bug.
Signed-off-by: David Woodhouse <[email protected]>
This builds on David Woodhouse's original Btrfs raid5/6 implementation.
The code has changed quite a bit, blame Chris Mason for any bugs.
Read/modify/write is done after the higher levels of the filesystem have
prepared a given bio. This means the higher layers are not responsible
for building full stripes, and they don't need to query for the topology
of the extents that may get allocated during delayed allocation runs.
It also means different files can easily share the same stripe.
But, it does expose us to incorrect parity if we crash or lose power
while doing a read/modify/write cycle. This will be addressed in a
later commit.
Scrub is unable to repair crc errors on raid5/6 chunks.
Discard does not work on raid5/6 (yet)
The stripe size is fixed at 64KiB per disk. This will be tunable
in a later commit.
Signed-off-by: Chris Mason <[email protected]>
We'll want to merge writes so they can fill a full RAID[56] stripe, but
not necessarily reads.
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
We have historically hard-coded entry points in head.S just so it's easy
to build the executable/bzImage headers with references to them.
Unfortunately, this leads to boot loaders abusing these "known" addresses
even when they are *explicitly* told that they "should look at the ELF
header to find this address, as it may change in the future". And even
when the address in question *has* actually been changed in the past,
without fanfare or thought to compatibility.
Thus we have bootloaders doing stunningly broken things like jumping
to offset 0x200 in the kernel startup code in 64-bit mode, *hoping*
that startup_64 is still there (it has moved at least once
before). And hoping that it's actually a 64-bit kernel despite the
fact that we don't give them any indication of that fact.
This patch should hopefully remove the temptation to abuse internal
addresses in future, where sternly worded comments have not sufficed.
Instead of having hard-coded addresses and saying "please don't abuse
these", we actually pull the addresses out of the ELF payload into
zoffset.h, and make build.c shove them back into the right places in
the bzImage header.
Rather than including zoffset.h into build.c and thus having to rebuild
the tool for every kernel build, we parse it instead. The parsing code
is small and simple.
This patch doesn't actually move any of the interesting entry points, so
any offending bootloader will still continue to "work" after this patch
is applied. For some version of "work" which includes jumping into the
compressed payload and crashing, if the bzImage it's given is a 32-bit
kernel. No change there then.
[ hpa: some of the issues in the description are addressed or
retconned by the 2.12 boot protocol. This patch has been edited to
only remove fixed addresses that were *not* thus retconned. ]
Signed-off-by: David Woodhouse <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: H. Peter Anvin <[email protected]>
Cc: Matt Fleming <[email protected]>
If the bootloader calls the EFI handover entry point as a standard function
call, then it'll have a return address on the stack. We need to pop that
before calling efi_main(), or the arguments will all be out of position on
the stack.
Signed-off-by: David Woodhouse <[email protected]>
Cc: <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: H. Peter Anvin <[email protected]>
Cc: Matt Fleming <[email protected]>
When booting under OVMF we have precisely one GOP device, and it
implements the ConOut protocol.
We break out of the loop when we look at it... and then promptly abort
because 'first_gop' never gets set. We should set first_gop *before*
breaking out of the loop. Yes, it doesn't really mean "first" any more,
but that doesn't matter. It's only a flag to indicate that a suitable
GOP was found.
In fact, we'd do just as well to initialise 'width' to zero in this
function, then just check *that* instead of first_gop. But I'll do the
minimal fix for now (and for stable@).
Signed-off-by: David Woodhouse <[email protected]>
Cc: <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: H. Peter Anvin <[email protected]>
Cc: Matt Fleming <[email protected]>
The dma_pte_free_pagetable() function will only free a page table page
if it is asked to free the *entire* 2MiB range that it covers. So if a
page table page was used for one or more small mappings, it's likely to
end up still present in the page tables... but with no valid PTEs.
This was fine when we'd only be repopulating it with 4KiB PTEs anyway
but the same virtual address range can end up being reused for a
*large-page* mapping. And in that case were were trying to insert the
large page into the second-level page table, and getting a complaint
from the sanity check in __domain_mapping() because there was already a
corresponding entry. This was *relatively* harmless; it led to a memory
leak of the old page table page, but no other ill-effects.
Fix it by calling dma_pte_clear_range (hopefully redundant) and
dma_pte_free_pagetable() before setting up the new large page.
Signed-off-by: David Woodhouse <[email protected]>
Tested-by: Ravi Murty <[email protected]>
Tested-by: Sudeep Dutt <[email protected]>
Cc: [email protected] [3.0+]
Signed-off-by: Linus Torvalds <[email protected]>
The FPGA can't handled unaligned DMA (yet). So copy into an aligned buffer,
if skb->data isn't suitably aligned.
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Since GCC 4.4, there have been __builtin_bswap32() and __builtin_bswap16()
intrinsics. A __builtin_bswap16() came a little later (4.6 for PowerPC,
48 for other platforms).
By using these instead of the inline assembler that most architectures
have in their __arch_swabXX() macros, we let the compiler see what's
actually happening. The resulting code should be at least as good, and
much *better* in the cases where it can be combined with a nearby load
or store, using a load-and-byteswap or store-and-byteswap instruction
(e.g. lwbrx/stwbrx on PowerPC, movbe on Atom).
When GCC is sufficiently recent *and* the architecture opts in to using
the intrinsics by setting CONFIG_ARCH_USE_BUILTIN_BSWAP, they will be
used in preference to the __arch_swabXX() macros. An architecture which
does not set ARCH_USE_BUILTIN_BSWAP will continue to use its own
hand-crafted macros.
Signed-off-by: David Woodhouse <[email protected]>
Acked-by: H. Peter Anvin <[email protected]>
- Flush pending TX skbs from the queue rather than waiting for them all to
complete (suggested by Krzysztof Mazur <[email protected]>).
- Clear ATM_VF_ADDR only when the PKT_PCLOSE packet has been submitted.
- Don't clear ATM_VF_READY at all — vcc_destroy_socket() does that for us.
Signed-off-by: David Woodhouse <[email protected]>
We don't need to schedule the wakeup tasklet on *every* unlock; only if we
actually blocked the channel in the first place.
Signed-off-by: David Woodhouse <[email protected]>
Acked-by: Krzysztof Mazur <[email protected]>
The br2684 code used module_put() during unassignment from vcc with
hope that we have BKL. This assumption is no longer true.
Now owner field in atmvcc is used to move this module_put()
to vcc_destroy_socket().
Signed-off-by: David Woodhouse <[email protected]>
Acked-by: Krzysztof Mazur <[email protected]>
Now that we can return zero from pppoatm_send() for reasons *other* than
the queue being full, that means we can't depend on a subsequent call to
pppoatm_pop() waking the queue, and we might leave it stalled
indefinitely.
Use the ->release_cb() callback to wake the queue after the sock is
unlocked.
Signed-off-by: David Woodhouse <[email protected]>
Acked-by: Krzysztof Mazur <[email protected]>
The immediate use case for this is that it will allow us to ensure that a
pppoatm queue is woken after it has to drop a packet due to the sock being
locked.
Note that 'release_cb' is called when the socket is *unlocked*. This is
not to be confused with vcc_release() — which probably ought to be called
vcc_close().
Signed-off-by: David Woodhouse <[email protected]>
Acked-by: Krzysztof Mazur <[email protected]>
We should no longer be calling the old pop routine for the vcc, after
vcc_release() has completed. Make sure we wait for any pending TX skbs
to complete, by waiting for our own PKT_PCLOSE control skb to be sent.
Signed-off-by: David Woodhouse <[email protected]>
This code was broken because it assumed that all MTD devices were map-based.
Disable it for now, until it can be fixed properly for the next merge window.
Signed-off-by: David Woodhouse <[email protected]>
We need the following 2 patches from the 'net-next' tree for the BCMA flash
driver:
371a004 bcma: detect and register NAND flash device
d57ef3a bcma: detect and register serial flash device
and this is why we are merging the net-next tree (presumably persistent)
up to commit '371a004'.
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
We really don't want this to work in the general case; device drivers
*shouldn't* care whether they are behind an IOMMU or not. But the
integrated graphics is a special case, because the IOMMU and the GTT are
all kind of smashed into one and generally horrifically buggy, so it's
reasonable for the graphics driver to want to know when the IOMMU is
active for the graphics hardware.
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
Signed-off-by: Keith Packard <[email protected]>
We really don't want this to work in the general case; device drivers
*shouldn't* care whether they are behind an IOMMU or not. But the
integrated graphics is a special case, because the IOMMU and the GTT are
all kind of smashed into one and generally horrifically buggy, so it's
reasonable for the graphics driver to want to know when the IOMMU is
active for the graphics hardware.
Signed-off-by: David Woodhouse <[email protected]>
We were mapping an extra byte (and hence usually an extra page):
iommu_prepare_identity_map() expects to be given an 'end' argument which
is the last byte to be mapped; not the first byte *not* to be mapped.
Signed-off-by: David Woodhouse <[email protected]>
In commit 2a48fc0ab2 ('block: autoconvert
trivial BKL users to private mutex'), Arnd replaced the BKL usage with a
mutex. However, Maxim has already provided a better fix in commit
480792b7bf ('mtd: blktrans: kill BKL'),
which was simply to remove the BKL without replacing it — since he'd
already made it do all necessary locking for itself.
Signed-off-by: David Woodhouse <[email protected]>
Conflicts:
drivers/mtd/mtd_blkdevs.c
Merge Grant's device-tree bits so that we can apply the subsequent fixes.
Signed-off-by: David Woodhouse <[email protected]>
This reverts commit 432dc821c9.
The individual CFI geometry options were carefully set up to get sane
default values if the CFI_ADV_OPTIONS wasn't set, and it wasn't
appropriate to move them into an if/endif block.
Signed-off-by: David Woodhouse <[email protected]>
If i915 opregion is present, the acpi_video driver doesn't register
itself immediately; it defers that until the i915 opregion code is done.
But if that *fails*, the acpi_video driver was never getting registered.
And thus I have no backlight support on my Lenovo IdeaPad S10-3.
Call acpi_video_register() on the failure path, and it works again.
Signed-off-by: David Woodhouse <[email protected]>
Acked-by: Jesse Barnes <[email protected]>
Acked-by: Matthew Garrett <[email protected]>
drivers/pci/intel-iommu.c: In function 'dma_pte_addr':
drivers/pci/intel-iommu.c:239: warning: passing argument 1 of '__cmpxchg64' from incompatible pointer type
It seems that __cmpxchg64() now cares about the type of its pointer argument,
so give it a (uint64_t *) instead of a pointer to a structure which contains
only that.
Signed-off-by: David Woodhouse <[email protected]>
drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in initializer
drivers/power/olpc_battery.c:387: warning: excess elements in struct initializer
drivers/power/olpc_battery.c:387: warning: (near initialization for 'olpc_bat_eeprom.attr')
The .owner field has been dropped from the attr struct.
Signed-off-by: David Woodhouse <[email protected]>
We were seeing faults in the solos-pci receive tasklet when packets
arrived for a VCC which was currently being closed:
[18842.727906] EIP: [<e082f490>] br2684_push+0x19/0x234 [br2684] SS:ESP 0068:dfb89d14
[18845.090712] [<c13ecff3>] ? do_page_fault+0x0/0x2e1
[18845.120042] [<e082f490>] ? br2684_push+0x19/0x234 [br2684]
[18845.153530] [<e084fa13>] solos_bh+0x28b/0x7c8 [solos_pci]
[18845.186488] [<e084f711>] ? solos_irq+0x2d/0x51 [solos_pci]
[18845.219960] [<c100387b>] ? handle_irq+0x3b/0x48
[18845.247732] [<c10265cb>] ? irq_exit+0x34/0x57
[18845.274437] [<c1025720>] tasklet_action+0x42/0x69
[18845.303247] [<c102643f>] __do_softirq+0x8e/0x129
[18845.331540] [<c10264ff>] do_softirq+0x25/0x2a
[18845.358274] [<c102664c>] _local_bh_enable_ip+0x5e/0x6a
[18845.389677] [<c102666d>] local_bh_enable+0xb/0xe
[18845.417944] [<e08490a8>] ppp_unregister_channel+0x32/0xbb [ppp_generic]
[18845.458193] [<e08731ad>] pppox_unbind_sock+0x18/0x1f [pppox]
This patch uses an RCU-inspired approach to fix it. In the RX tasklet's
find_vcc() function we first refuse to use a VCC which already has the
ATM_VF_READY bit cleared. And in the VCC close function, we synchronise
with the tasklet to ensure that it can't still be using the VCC before
we continue and allow the VCC to be destroyed.
Signed-off-by: David Woodhouse <[email protected]>
Tested-by: Nathan Williams <[email protected]>
Cc: [email protected]
Signed-off-by: David S. Miller <[email protected]>
Certain revisions of this chipset appear to be broken. There is a shadow
GTT which mirrors the real GTT but contains pre-translated physical
addresses, for performance reasons. When a GTT update happens, the
translations are done once and the resulting physical addresses written
back to the shadow GTT.
Except sometimes, the physical address is actually written back to the
_real_ GTT, not the shadow GTT. Thus we start to see faults when that
physical address is fed through translation again.
Signed-off-by: David Woodhouse <[email protected]>
Only build the parts which are actually needed, and turn the DMA support
(which is currently hard-coded off) into a config option (still forced off).
Signed-off-by: David Woodhouse <[email protected]>
... by killing the gratuitous 'res_nand' early_param() and turning it
into a module_param() called 'reserved_mb' instead.
Signed-off-by: David Woodhouse <[email protected]>
New inodes need to be locked as we're creating them, so they don't get used
by other things (like NFSd) before they're ready.
Pointed out by Al Viro.
Signed-off-by: David Woodhouse <[email protected]>
fix memory leak introduced by the patch 6e03a201bb:
firmware: speed up request_firmware()
1. vfree won't release pages there were allocated explicitly and mapped
using vmap. The memory has to be vunmap-ed and the pages needs
to be freed explicitly
2. page array is moved into the 'struct
firmware' so that we can free it from release_firmware()
and not only in fw_dev_release()
The fix doesn't break the firmware load speed.
Cc: Johannes Berg <[email protected]>
Cc: Ming Lei <[email protected]>
Cc: Catalin Marinas <[email protected]>
Singed-off-by: Kay Sievers <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Tomas Winkler <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
This reverts commit 66803762 ("mtd: mxc_nand: add RESET command support").
Support for NAND_CMD_RESET was added separately in commit d4840180
("mtd: mxc_nand: set NFC registers after reset"), causing a build error:
drivers/mtd/nand/mxc_nand.c: In function 'mxc_nand_command':
drivers/mtd/nand/mxc_nand.c:689: error: duplicate case value
drivers/mtd/nand/mxc_nand.c:606: error: previously used here
Signed-off-by: David Woodhouse <[email protected]>
We're about to call this from a bunch of places which already hold
c->erase_completion_lock, so add an assertion and change its existing
callers to do the same.
Signed-off-by: David Woodhouse <[email protected]>
jffs2_garbage_collect_pass() would previously return -EAGAIN if it
couldn't find anything to garbage collect from, and there were blocks on
the erase_pending_list. If the blocks were actually in the process of
being erased, though, then they wouldn't be on that list. Check for
nr_erasing_blocks being non-zero instead.
Fix jffs2_reserve_space() to wait for the in-progress erases to
complete, when jffs2_garbage_collect_pass() returns -EAGAIN.
And fix jffs2_erase_succeeded() to actually wake up the erase_wait wq
that jffs2_reserve_space() is now using.
Signed-off-by: David Woodhouse <[email protected]>
Doh. Pointed out by Guillaume LECERF <[email protected]> since I managed
to miss it in my test builds. S'what I get for hacking at 2am, I suppose.
Signed-off-by: David Woodhouse <[email protected]>
Accept values of 2-5 for TopBottom, where the newly-added 4 and 5 values
mean a uniform layout. It does indicate WP layout but we don't handle that.
Also don't say "broken" when swapping erase regions in a top-boot chip.
That got retrospectively documented in the spec.
Signed-off-by: David Woodhouse <[email protected]>
drivers/mtd/nand/denali.c:1427: error: conflicting types for ‘enable_dma’
arch/powerpc/include/asm/dma.h:189: note: previous definition of ‘enable_dma’ was here
Signed-off-by: David Woodhouse <[email protected]>
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Reported-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Randy Dunlap observed a build problem with the following config:
CONFIG_SM_FTL=y
CONFIG_SM_FTL_MUSEUM=y
CONFIG_MTD_NAND=m
The ECC calculation routines are then built as a module, but referenced
by the sm_ftl code in the kernel, resulting in a build failure. The
simple fix is to make CONFIG_SM_FTL depend on MTD_NAND unconditionally
-- it's pointless without hardware support anyway.
Fix some typos which Randy pointed out, too.
Reported-By: Randy Dunlap <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
(and remove the CONFIG_MTD_NAND_SMARTMEDIA option which isn't going to be
used now that we're doing it this way)
Signed-off-by: David Woodhouse <[email protected]>
Ever since jffs2_garbage_collect_metadata() was first half-written in
February 2001, it's been broken on architectures where 'char' is signed.
When garbage collecting a symlink with target length above 127, the payload
length would end up negative, causing interesting and bad things to happen.
Cc: [email protected]
Signed-off-by: David Woodhouse <[email protected]>
The hotplug notifier will call find_domain() to see if the device in
question has been assigned an IOMMU domain. However, this should never
be called for devices with a "dummy" domain, such as graphics devices
when intel_iommu=igfx_off is set and the corresponding IOMMU isn't even
initialised. If you do that, it'll oops as it dereferences the (-1)
pointer.
The notifier function should check iommu_no_mapping() for the
device before doing anything else.
Cc: [email protected]
Signed-off-by: David Woodhouse <[email protected]>
Some HP BIOSes report an RMRR region (a region which needs a 1:1 mapping
in the IOMMU for a given device) which has an end address lower than its
start address. Detect that and warn, rather than triggering the
BUG() in dma_pte_clear_range().
Cc: [email protected]
Signed-off-by: David Woodhouse <[email protected]>
The BIOS errors where an IOMMU is reported either at zero or a bogus
address are causing problems even when the IOMMU is disabled -- because
interrupt remapping uses the same hardware. Ensure that the checks get
applied for the interrupt remapping initialisation too.
Cc: [email protected]
Signed-off-by: David Woodhouse <[email protected]>
Chris Wright has some patches which let us fall back to swiotlb nicely
if IOMMU initialisation fails. But those are a bit much for 2.6.32.
Instead, let's shift the check for the biggest problem, the HP and Acer
BIOS bug which reports a DMAR at physical address zero. That one can
actually be checked much earlier -- before we even admit to having
detected an IOMMU in the first place. So the swiotlb init goes ahead as
we want.
Signed-off-by: David Woodhouse <[email protected]>
This reverts commit 71b7d0d90d.
The problem which that commit attempted to fix was a bootloader issue,
which had been misunderstood. The 'fix' causes lots of false bad blocks
for existing users with sane firmware.
Thanks to Mathieu Berland for diagnosing the problem coherently.
Signed-off-by: David Woodhouse <[email protected]>
We want this to happen after the PCI quirks, which are now running at
the very end of the fs_initcalls.
This works around the BIOS problems which were originally addressed by
commit db8be50c43 ('USB: Work around BIOS
bugs by quiescing USB controllers earlier'), which was reverted in
commit d93a8f829f.
Signed-off-by: David Woodhouse <[email protected]>
Having this as a device_initcall() means that some real device drivers
can actually initialise _before_ the quirks are run, which is wrong.
We want it to run _before_ device_initcall(), but _after_ fs_initcall(),
since some arch-specific PCI initialisation like pcibios_assign_resources()
is done at fs_initcall().
We could use rootfs_initcall() but I actually want to use that for the
IOMMU initialisation, which has to come after the quirks, but still
before the real devices. So use fs_initcall_sync() instead -- since this
is entirely synchronous, it doesn't hurt that it'll escape the
synchronisation.
Signed-off-by: David Woodhouse <[email protected]>
This function may have done more in the past, but all it does now is
apply the PCI_FIXUP_FINAL quirks. So name it sensibly and put it where
it belongs.
Signed-off-by: David Woodhouse <[email protected]>
Asus decided to ship a BIOS which configures sound DMA to go via the
dedicated IOMMU unit, but assigns precisely zero TLB entries to that
unit. Which causes the whole thing to deadlock, including the DMA
traffic on the _other_ IOMMU units. Nice one.
Signed-off-by: David Woodhouse <[email protected]>
We may end up doing DMA to/from these. Until the new MTD API fixes the
issues, this should stop things from falling over.
Original idea from Gilles Casse <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
As with orion_nand in commit f33dabbe79
("register orion_nand using platform_driver_probe()"), avoid .init.text
problems by using platform_device_probe(). This isn't going to be
hotplugged anyway.
Reported-by: Uwe Kleine-König <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Just make it depend on BROKEN for now, in case people scream really loud
about it (and because we might want to keep some of this logic for an
upcoming BIOS workaround, so I don't just want to rip it out entirely
just yet). But for graphics devices, it really ought to be unnecessary.
Signed-off-by: David Woodhouse <[email protected]>
If end_pfn is equal to (unsigned long)-1, then the loop will never end.
Seen on 32-bit kernel, but could have happened on 64-bit too once we get
hardware that supports 64-bit guest addresses.
Change both functions to a 'do {} while' loop with the test at the end,
and check for the PFN having wrapper round to zero.
Reported-by: Benjamin LaHaise <[email protected]>
Tested-by: Benjamin LaHaise <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
This means we're limited to 44-bit addresses on 32-bit kernels, and
makes it sane for us to use 'unsigned long' for PFNs throughout.
Which is just as well, really, since we already do that.
Reported-by: Benjamin LaHaise <[email protected]>
Tested-by: Benjamin LaHaise <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Since commit 19943b0e30 ('intel-iommu:
Unify hardware and software passthrough support'), hardware passthrough
mode will do the same as software passthrough mode was doing -- it'll
still use the IOMMU normally for devices which can't address all of
memory. This means that we don't need to bother with swiotlb.
Signed-off-by: David Woodhouse <[email protected]>
David Woodhouse