The commands are conceptually writes, and in the case of IDE and SCSI
commands actually are writes. They were only reads because we thought
that would interact better with the elevators. Now the elevators know
about discard requests, that advantage no longer exists.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
If the tree roots hit read errors during mount, btrfs is not properly
erroring out. We need to check the uptodate bits after
reading in the tree root node.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
It was never actually doing anything anyway (see the loop condition),
and it would be difficult to make it work for RAID[56].
Even if it was actually working, it's checking for the wrong thing
anyway. Instead of checking whether we list a block which _doesn't_ land
at the relevant physical location, it should be checking that we _have_
listed all the logical blocks which refer to the required physical
location on all devices.
This function is only called from remove_sb_from_cache() to ensure that
we reserve the logical blocks which would reside at the same physical
location as the superblock copies. So listing more blocks than we need
is actually OK.
With RAID[56] we're going to throw away an entire stripe for each block
we have to ignore, so we _are_ going to list blocks other than the
ones which actually contain the superblock.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
This fixes kernel.org bug #13584. The IOVA code attempted to optimise
the insertion of new ranges into the rbtree, with the unfortunate result
that some ranges just didn't get inserted into the tree at all. Then
those ranges would be handed out more than once, and things kind of go
downhill from there.
Introduced after 2.6.25 by ddf02886cb
("PCI: iova RB tree setup tweak").
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: mark gross <mgross@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We can run a 32-bit kernel on boxes with an IOMMU, so we need
pci_unmap_addr() etc. to work -- without it, drivers will leak mappings.
To be honest, this whole thing looks like it's more pain than it's
worth; I'm half inclined to remove the no-op #else case altogether.
But this is the minimal fix, which just does the right thing if
CONFIG_DMAR is set.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: stable@kernel.org [ for 2.6.30 ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There's no need to preserve this abstraction; it used to let us use
hardware crc32c support directly, but libcrc32c is already doing that for us
through the crypto API -- so we're already using the Intel crc32c
acceleration where appropriate.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Commit c45d6320 ("fix reference counting of ftdi_private") stopped
ftdi_sio_port_remove() from directly freeing the port-private data, with
the intention if the port was still open, it would be freed when
ftdi_close() is eventually called and releases the last refcount on the
structure.
That's all very well, but ftdi_sio_port_remove() still contains a call
to usb_set_serial_port_data(port, NULL) -- so by the time we get to
ftdi_close() for the port which was unplugged, it _still_ oopses on
dereferencing that NULL pointer, as it did before (and does in 2.6.29).
The fix is just not to clear the private data in ftdi_sio_port_remove().
Then the refcount is properly reduced to zero when the final kref_put()
happens in ftdi_close().
Remove a bogus comment too, while we're at it. And stop doing things
inside "if (priv)" -- it must _always_ be there.
Based loosely on an earlier patch by Daniel Mack, and suggestions by
Alan Stern.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Daniel Mack <daniel@caiaq.de>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Rather than calling vmalloc() repeatedly to grow the firmware image as
we receive data from userspace, just allocate and fill individual pages.
Then vmap() the whole lot in one go when we're done.
A quick test with a 337KiB iwlagn firmware shows the time taken for
request_firmware() going from ~32ms to ~5ms after I apply this patch.
[v2: define PAGE_KERNEL_RO as PAGE_KERNEL where necessary, use min_t()]
[v3: kunmap() takes the struct page *, not the virtual address]
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Sachin Sant <sachinp@in.ibm.com>
PAGE_MASK is 0xFFFFF000 on i386 -- even with PAE.
So it's not sufficient to ensure that you use phys_addr_t or uint64_t
everywhere you handle physical addresses -- you also have to avoid using
the construct 'addr & PAGE_MASK', because that will strip the high 32
bits of the address.
This patch avoids that problem by using PHYSICAL_PAGE_MASK instead of
PAGE_MASK where appropriate. It leaves '& PAGE_MASK' in a few instances
that don't matter -- where it's being used on the virtual bus addresses
we're dishing out, which are 32-bit anyway.
Since PHYSICAL_PAGE_MASK is not present on other architectures, we have
to define it (to PAGE_MASK) if it's not already defined.
Maybe it would be better just to fix PAGE_MASK for i386/PAE?
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 14f7dd63 ("Copy XFS readdir hack into nfsd code") introduced a
bug to generic code which had been extant for a long time in the XFS
version -- it started to call through into lookup_one_len() and hence
into the file systems' ->lookup() methods without i_mutex held on the
directory.
This patch fixes it by locking the directory's i_mutex again before
calling the filldir functions. The original deadlocks which commit
14f7dd63 was designed to avoid are still avoided, because they were due
to fs-internal locking, not i_mutex.
While we're at it, fix the return type of nfsd_buffered_readdir() which
should be a __be32 not an int -- it's an NFS errno, not a Linux errno.
And return nfserrno(-ENOMEM) when allocation fails, not just -ENOMEM.
Sparse would have caught that, if it wasn't so busy bitching about
__cold__.
Commit 05f4f678 ("nfsd4: don't do lookup within readdir in recovery
code") introduced a similar problem with calling lookup_one_len()
without i_mutex, which this patch also addresses. To fix that, it was
necessary to fix the called functions so that they expect i_mutex to be
held; that part was done by J. Bruce Fields.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Umm-I-can-live-with-that-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: J. R. Okajima <hooanon05@yahoo.co.jp>
Tested-by: J. Bruce Fields <bfields@citi.umich.edu>
LKML-Reference: <8036.1237474444@jrobl>
Cc: stable@kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
This build failure:
| drivers/pci/dmar.c:47: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘dmar_tbl_size’
| drivers/pci/dmar.c:62: warning: ‘struct acpi_dmar_device_scope’ declared inside parameter list
| drivers/pci/dmar.c:62: warning: its scope is only this definition or declaration, which is probably not what you want
Triggers due to this commit:
d0b03bd: x2apic/intr-remap: decouple interrupt remapping from x2apic
Which exposed a pre-existing but dormant fragility of the 'select X86_X2APIC'
it moved around and turned that fragility into a build failure.
Replace it with a proper 'depends on' construct.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
LKML-Reference: <1239084280.22733.404.camel@macbook.infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
If we fix a few highmem-related thinkos and a couple of printk format
warnings, the Intel IOMMU driver works fine in a 32-bit kernel.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Impact: saves stacktrace of a dma mapping and prints it if there is an error
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This adds a function to dump the DMA mappings that the debugging code is
aware of -- either for a single device, or for _all_ devices.
This can be useful for debugging -- sticking a call to it in the DMA
page fault handler, for example, to see if the faulting address _should_
be mapped or not, and hence work out whether it's IOMMU bugs we're
seeing, or driver bugs.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This is the cause of the DMA faults and disk corruption that people have
been seeing. Some chipsets neglect to report the RWBF "capability" --
the flag which says that we need to flush the chipset write-buffer when
changing the DMA page tables, to ensure that the change is visible to
the IOMMU.
Override that bit on the affected chipsets, and everything is happy
again.
Thanks to Chris and Bhavesh and others for helping to debug.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Chris Wright <chrisw@sous-sol.org>
Reviewed-by: Bhavesh Davda <bhavesh@vmware.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Update employer's care-of address in CREDITS file, and remove references
to some _very_ old stuff I'd forgotten I'd ever done.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit e51af66308, which was
wrongly hoovered up and submitted about a month after a better fix had
already been merged.
The better fix is commit cbda1ba898
("PCI/iommu: blacklist DMAR on Intel G31/G33 chipsets"), where we do
this blacklisting based on the DMI identification for the offending
motherboard, since sometimes this chipset (or at least a chipset with
the same PCI ID) apparently _does_ actually have an IOMMU.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Avoid calling the underlying ->readdir() again when we reached the end
already; keep going round the loop only if we stopped due to our own
buffer being full.
[AV: tidy the things up a bit, while we are there]
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Use new MODULE_DEVICE_TABLE(dmi, ...) facility. There's no need for
every driver to screw it up for themselves, when the alias can be
generated automatically.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This makes modpost handle MODULE_DEVICE_TABLE(dmi, xxxx).
I had to change the string pointers in the match table to char arrays,
and picked a size of 79 bytes almost at random -- do we need to make it
bigger than that? I was a bit concerned about the 'bloat' this
introduces into the match tables, but they should all be __initdata so
it shouldn't matter too much.
(Actually, modpost does go through the relocations and look at most of
them; it wouldn't be impossible to make it handle string pointers -- but
doesn't seem to be worth the effort, since they're __initdata).
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This seems to work if I tell it that it's a mbp3. Not sure if there are
actually any differences.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
when they don't. Avoid the resulting crashes when it doesn't work as
expected.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
HAVE_AOUT doesn't quite do the same thing as the recently removed
ARCH_SUPPORTS_AOUT config option. That was set even on platforms where
binfmt_aout isn't supported, although it's not entirely clear why.
So it's best just to introduce a new symbol, handled consistently with
other similar HAVE_xxx symbols; with a simple 'select' in the arch Kconfig.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
when they don't. Avoid the resulting crashes when it doesn't work as
expected.
I'd still be grateful if someone could test it on a DG33BU with the old
BIOS though, since I've killed mine. I tested the DMI version, but not
this one.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Including <linux/fcntl.h> in the user-visible part of this header has
caused build regressions with headers from 2.6.27-rc. Move it down to
the #ifdef __KERNEL__ part, which is the only place it's needed. Move
some other kernel-only things down there too, while we're at it.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I won't say 'fix', because they still look broken, although this will at
least allow 'make ARCH=CRIS headers_install' to _complete_.
For headers which are exported, we should probably choose between
asm/arch-v10 and asm/arch-v32 by something that GCC defines -- we can't
rely on a generated symlink. And we certainly can't export an arch/
directory which doesn't even exist.
And the only thing that we seem to include from the arch/ directory is
<asm/arch/ptrace.h> from <asm/ptrace.h> ... and that isn't exported in
either arch-v10 or arch-v32 _anyway_.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The exported copy of videodev2.h contains this line:
#define #include <sys/time.h>
This is because for some reason it defines __user for itself -- despite
the fact that we remove all instances of __user when exporting headers.
_All_ pointers in userspace are user pointers. Fix it by removing the
unnecessary '#define __user' from the file.
The new headers ivtv.h and ivtvfb.h would have the same problem... if
whoever put them there had actually remembered to add them to the Kbuild
file while he was at it. Fix those too, and export them as was
presumably intended.
Note that includes of <linux/compiler.h> are also stripped by the header
export process, so those don't need to be conditional.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The microcode stores its date in a uint32_t in some weird order
approximating pdp-endian. Rather than printing it like that, print it
properly in ISO standard form.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Provide a .gitignore file, and fix a typo which prevented some of the
generated binary files from being removed on 'make clean'.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reported-and-tested-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We're not updating the tg3 driver to use request_firmware() yet, but a
reference to its firmware accidentally slipped in as part of commit
c4667746 ("dabusb: use request_firmware()"). Remove it again.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reported-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When CONFIG_EXTRA_FIRMWARE_DIR gets changed, the filename in the .S file
(which uses .incbin to include the binary) needs to change. When we
renamed the BUILTIN_FIRMWARE_DIR option to EXTRA_FIRMWARE_DIR, we forgot
to update the manual dependency in firmware/Makefile, so it was
depending on a non-existent file in include/config/
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since it had various regions to be loaded to separate addresses, and it
wanted to do them in fairly small chunks anyway, switch it to use the
new ihex code. Encode the start address in the first record.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Chas Williams <chas@cmf.nrl.navy.mil>
Some drivers could do with using records like Intel HEX, but with each
record being larger than 256 bytes. This has been possible in the binary
representation (struct ihex_binrec) in the kernel since the beginning --
at least of the the current version of history. But we haven't been able
to represent that in the .HEX files which get converted to .fw files.
This adds a '-w' option to ihex2fw to make it interpret the first _two_
bytes of each line as the record length, instead of only one byte. And
adds makefile rules for %.H16->%.fw which use that.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Not the straight conversion to binary which objcopy can do for us, but
actually representing each record with its original {addr, length},
because some drivers need that information preserved.
Fix up 'firmware_install' to be able to build $(hostprogs-y) too.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Provide a helper to load the file and validate it in one call, to
simplify error handling in the drivers which are going to use it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Some devices need their firmware as a set of {address, len, data...}
records in some specific order rather than a simple blob.
The normal way of doing this kind of thing is 'ihex', which is a text
format and not entirely suitable for use in the kernel.
This provides a binary representation which is very similar, but much
more compact -- and a helper routine to skip to the next record,
because the alignment constraints mean that everybody will screw it up
for themselves otherwise.
Also a helper function which can verify that a 'struct firmware'
contains a valid set of ihex records, and that following them won't run
off the end of the loaded data.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
For 'make modules_install', install any firmware required by
the modules which are being installed.
Also add a 'make firmware_install' target which doesn't depend on the
configuration, but installs _all_ available in-kernel-tree firmware into
$(INSTALL_FW_PATH), which defaults to /lib/firmware. This is intended
for distributors to make arch-independent (and config-independent)
packages containing firmware.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This will control whether we build firmware into the kernel image for
_every_ driver which we convert to request_firmware(), to avoid a
proliferation of 'CONFIG_XXX_FIRMWARE' options for each one.
Default to 'y' for now, which is the wrong thing to do but people seem
to be insisting on it and refusing to even review patches until it's
done. And it does preserve the existing behaviour for built-in drivers.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
This allows arbitrary firmware files to be included in the static kernel
where the firmware loader can find them without requiring userspace to
be alive.
(Updated and CONFIG_EXTRA_FIRMWARE_DIR added with lots of help from
Johannes Berg).
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Some drivers have their own hacks to bypass the kernel's firmware loader
and build their firmware into the kernel; this renders those unnecessary.
Other drivers don't use the firmware loader at all, because they always
want the firmware to be available. This allows them to start using the
firmware loader.
A third set of drivers already use the firmware loader, but can't be
used without help from userspace, which sometimes requires an initrd.
This allows them to work in a static kernel.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
In preparation for supporting firmware files linked into the static
kernel, make fw->data const to ensure that users aren't modifying it (so
that we can pass a pointer to the original in-kernel copy, rather than
having to copy it).
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Standardise both in-kernel and loaded firmware to be stored as
little-endian instead of host-endian.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
The maestro3 driver is byte-swapping its firmware to be host-endian in
advance, when it doesn't seem to be necessary -- we could just use
le16_to_cpu() as we load it.
Doing that means that we need to switch the in-tree firmware to be
little-endian too.
Take the least intrusive way of doing this, which is to switch the
existing snd_m3_convert_from_le() function to convert _to_ little-endian
instead, and use it on the in-tree firmware instead of the loaded
firmware. It's a bit suboptimal but doesn't matter much right now
because we're about to remove the special cases for the in-tree version
anyway.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
...which means allocating our own copy when we want to modify it.
(stupid thinko fixed by mkrufky)
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
This file is only included where it makes sense now, so there's no need
for the CONFIG_ARCH_SUPPORTS_AOUT conditional -- and that conditional is
bad, because we want to export <linux/a.out.h> to userspace.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In commit d20894a237 ("Remove a.out
interpreter support in ELF loader"), Andi removed support for a.out
interpreters from the ELF loader, which was only ever needed for the
transition from a.out to ELF.
This removes the last traces of that support, in particular the
inclusion of <linux/a.out.h>.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We only need it for the /sbin/loader hack for OSF/1 executables, and we
don't want to include it otherwise.
While we're at it, remove the redundant '&& CONFIG_ARCH_SUPPORTS_AOUT'
in the ifdef around that code. It's already dependent on __alpha__, and
CONFIG_ARCH_SUPPORTS_AOUT is hard-coded to 'y' there.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This hooks up the platform-specific [gs]et_rtc_time functions so that
kernels using CONFIG_RTC_CLASS have RTC support on most PowerPC platforms.
A new driver, and one which we've been shipping in Fedora for a while
already, since otherwise RTC support breaks.
[akpm@linux-foundation.org: fix Kconfig indenting]
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Acked-by: David Brownell <david-b@pacbell.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
These were removed in commit 26d507fcfe:
> -#define V4L2_CID_HCENTER (V4L2_CID_BASE+22)
> -#define V4L2_CID_VCENTER (V4L2_CID_BASE+23)
> -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+24) /*
> last CID + 1 */
> +
> +/* Deprecated, use V4L2_CID_PAN_RESET and V4L2_CID_TILT_RESET */
> +#define V4L2_CID_HCENTER_DEPRECATED (V4L2_CID_BASE+22)
> +#define V4L2_CID_VCENTER_DEPRECATED (V4L2_CID_BASE+23)
But there was no warning in Documentation/feature-removal-schedule.txt
and I'm receiving reports that it's breaking userspace apps (the
gstreamer-v4l2 plugin breaks in Fedora rawhide). You can't just pull
things from the published userspace API like that.
Please can we revert the addition of _DEPRECATED to these ioctl
definitions. Perhaps we can add a runtime warning if they actually get
used? Or a compile-time warning if we can manage that?
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
David Woodhouse