linux-toradex.git, branch v3.8.2

Linux 3.8.2

2013-03-03T22:04:08+00:00

xfs: xfs_bmap_add_attrfork_local is too generic

2013-03-03T22:03:40+00:00

commit 1e82379b018ceed0f0912327c60d73107dacbcb3 upstream.

When we are converting local data to an extent format as a result of
adding an attribute, the type of data contained in the local fork
determines the behaviour that needs to occur.

xfs_bmap_add_attrfork_local() already handles the directory data
case specially by using S_ISDIR() and calling out to
xfs_dir2_sf_to_block(), but with verifiers we now need to handle
each different type of metadata specially and different metadata
formats require different verifiers (and eventually block header
initialisation).

There is only a single place that we add and attribute fork to
the inode, but that is in the attribute code and it knows nothing
about the specific contents of the data fork. It is only the case of
local data that is the issue here, so adding code to hadnle this
case in the attribute specific code is wrong. Hence we are really
stuck trying to detect the data fork contents in
xfs_bmap_add_attrfork_local() and performing the correct callout
there.

Luckily the current cases can be determined by S_IS* macros, and we
can push the work off to data specific callouts, but each of those
callouts does a lot of work in common with
xfs_bmap_local_to_extents(). The only reason that this fails for
symlinks right now is is that xfs_bmap_local_to_extents() assumes
the data fork contains extent data, and so attaches a a bmap extent
data verifier to the buffer and simply copies the data fork
information straight into it.

To fix this, allow us to pass a "formatting" callback into
xfs_bmap_local_to_extents() which is responsible for setting the
buffer type, initialising it and copying the data fork contents over
to the new buffer. This allows callers to specify how they want to
format the new buffer (which is necessary for the upcoming CRC
enabled metadata blocks) and hence make xfs_bmap_local_to_extents()
useful for any type of data fork content.

Signed-off-by: Dave Chinner 
Reviewed-by: Mark Tinguely 
Signed-off-by: Ben Myers 
Signed-off-by: Greg Kroah-Hartman

efivarfs: guid part of filenames are case-insensitive

2013-03-03T22:03:40+00:00

commit da27a24383b2b10bf6ebd0db29b325548aafecb4 upstream.

It makes no sense to treat the following filenames as unique,

	VarName-abcdefab-abcd-abcd-abcd-abcdefabcdef
	VarName-ABCDEFAB-ABCD-ABCD-ABCD-ABCDEFABCDEF
	VarName-ABcDEfAB-ABcD-ABcD-ABcD-ABcDEfABcDEf
	VarName-aBcDEfAB-aBcD-aBcD-aBcD-aBcDEfaBcDEf
	... etc ...

since the guid will be converted into a binary representation, which
has no case.

Roll our own dentry operations so that we can treat the variable name
part of filenames ("VarName" in the above example) as case-sensitive,
but the guid portion as case-insensitive. That way, efivarfs will
refuse to create the above files if any one already exists.

Reported-by: Lingzhu Xiang 
Cc: Matthew Garrett 
Cc: Jeremy Kerr 
Cc: Al Viro 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

efivarfs: Validate filenames much more aggressively

2013-03-03T22:03:40+00:00

commit 47f531e8ba3bc3901a0c493f4252826c41dea1a1 upstream.

The only thing that efivarfs does to enforce a valid filename is
ensure that the name isn't too short. We need to strongly sanitise any
filenames, not least because variable creation is delayed until
efivarfs_file_write(), which means we can't rely on the firmware to
inform us of an invalid name, because if the file is never written to
we'll never know it's invalid.

Perform a couple of steps before agreeing to create a new file,

  * hex_to_bin() returns a value indicating whether or not it was able
    to convert its arguments to a binary representation - we should
    check it.

  * Ensure that the GUID portion of the filename is the correct length
    and format.

  * The variable name portion of the filename needs to be at least one
    character in size.

Reported-by: Lingzhu Xiang 
Cc: Matthew Garrett 
Cc: Jeremy Kerr 
Cc: Al Viro 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

ACPI: Overriding ACPI tables via initrd only works with an initrd and on X86

2013-03-03T22:03:39+00:00

commit 565d956a7e191e95d81f515196951715f2616e6b upstream.

Reflect this dependency in Kconfig, to prevent build failures.

Shorten the config description as suggested by Borislav Petkov.

Finding a suitable memory area to store the modified table(s) has been
taken over from arch/x86/kernel/setup.c and makes use of max_low_pfn_mapped:
memblock_find_in_range(0, max_low_pfn_mapped,...)
This one is X86 specific. It may not be hard to extend this functionality
for other ACPI aware architectures if there is need for.

For now make this feature only available for X86 to avoid build failures on
IA64, compare with:
https://bugzilla.kernel.org/show_bug.cgi?id=54091

Signed-off-by: Thomas Renninger 
Link: http://lkml.kernel.org/r/1361538742-67599-3-git-send-email-trenn@suse.de
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, efi: Allow slash in file path of initrd

2013-03-03T22:03:39+00:00

commit deb94101c4fda22e152c2a311210cf09ae51adf6 upstream.

When initrd file didn't put at the same place with stub kernel, we
need give the file path of initrd, but need use backslash to separate
directory and file. It's not friendly to unix/linux user, and not so
intuitive for bootloader forward paramters to efi stub kernel by
chainloading.

This patch add support to handle_ramdisks for allow slash in file path
of initrd, it convert slash to backlash when parsing path.

In additional, this patch also separates print code of efi_char16_t from
efi_printk, and print out the path/filename of initrd when failed to open
initrd file. It's good for debug and discover typo.

Signed-off-by: Lee, Chun-Yi 
Cc: Matthew Garrett 
Cc: H. Peter Anvin 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

usb hid quirks for Masterkit MA901 usb radio

2013-03-03T22:03:39+00:00

commit 0322bd3980b3ebf7dde8474e22614cb443d6479a upstream.

Don't let Masterkit MA901 USB radio be handled by usb hid drivers.
This device will be handled by radio-ma901.c driver.

Signed-off-by: Alexey Klimov 
Acked-by: Hans Verkuil 
Acked-by: Jiri Kosina 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

ahci: Add Device IDs for Intel Wellsburg PCH

2013-03-03T22:03:39+00:00

commit 151743fd8dfb02956c5184b5f4f0f42677eb75bc upstream.

This patch adds the AHCI-mode SATA Device IDs for the Intel Wellsburg PCH

Signed-off-by: James Ralston 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

ahci: AHCI-mode SATA patch for Intel Avoton DeviceIDs

2013-03-03T22:03:39+00:00

commit 29e674dd5c8e781589f09c3ee139c80f6da274e4 upstream.

This patch adds the AHCI and RAID-mode SATA DeviceIDs for the Intel Avoton SOC.

Signed-off-by: Seth Heasley 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

ata_piix: Add Device IDs for Intel Wellsburg PCH

2013-03-03T22:03:39+00:00

commit 3aee8bc52c415aba8148f144e5e5359b0fd75dd1 upstream.

This patch adds the IDE-mode SATA Device IDs for the Intel Wellsburg PCH

Signed-off-by: James Ralston 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman