<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/firmware, branch v3.15.6</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.15.6</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.15.6'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2014-07-01T03:14:04Z</updated>
<entry>
<title>efi-pstore: Fix an overflow on 32-bit builds</title>
<updated>2014-07-01T03:14:04Z</updated>
<author>
<name>Andrzej Zaborowski</name>
<email>andrew.zaborowski@intel.com</email>
</author>
<published>2014-06-09T14:50:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a6d4b786ebfbbb9330b6915b590547d348ec148c'/>
<id>urn:sha1:a6d4b786ebfbbb9330b6915b590547d348ec148c</id>
<content type='text'>
commit 783ee43118dc773bc8b0342c5b230e017d5a04d0 upstream.

In generic_id the long int timestamp is multiplied by 100000 and needs
an explicit cast to u64.

Without that the id in the resulting pstore filename is wrong and
userspace may have problems parsing it, but more importantly files in
pstore can never be deleted and may fill the EFI flash (brick device?).
This happens because when generic pstore code wants to delete a file,
it passes the id to the EFI backend which reinterpretes it and a wrong
variable name is attempted to be deleted.  There's no error message but
after remounting pstore, deleted files would reappear.

Signed-off-by: Andrew Zaborowski &lt;andrew.zaborowski@intel.com&gt;
Acked-by: David Rientjes &lt;rientjes@google.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iscsi_ibft: Fix finding Broadcom specific ibft sign</title>
<updated>2014-05-13T18:54:14Z</updated>
<author>
<name>Vikas Chaudhary</name>
<email>vikas.chaudhary@qlogic.com</email>
</author>
<published>2014-05-13T11:41:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=629c27aa0c930b9c67188cfc625bf6cdd2af6764'/>
<id>urn:sha1:629c27aa0c930b9c67188cfc625bf6cdd2af6764</id>
<content type='text'>
Search for Broadcom specific ibft sign "BIFT"
along with other possible values on UEFI

This patch is fix for regression introduced in
“935a9fee51c945b8942be2d7b4bae069167b4886”.
https://lkml.org/lkml/2011/12/16/353

This impacts Broadcom CNA for iSCSI Boot on UEFI platform.

Signed-off-by: Vikas Chaudhary &lt;vikas.chaudhary@qlogic.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Acked-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
</content>
</entry>
<entry>
<title>Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2014-04-11T18:58:33Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-04-11T18:58:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8eab6cd031c11071cf88138b2fed19beaa216435'/>
<id>urn:sha1:8eab6cd031c11071cf88138b2fed19beaa216435</id>
<content type='text'>
Pull x86 fixes from Peter Anvin:
 "This is a collection of minor fixes for x86, plus the IRET information
  leak fix (forbid the use of 16-bit segments in 64-bit mode)"

NOTE! We may have to relax the "forbid the use of 16-bit segments in
64-bit mode" part, since there may be people who still run and depend on
16-bit Windows binaries under Wine.

But I'm taking this in the current unconditional form for now to see who
(if anybody) screams bloody murder.  Maybe nobody cares.  And maybe
we'll have to update it with some kind of runtime enablement (like our
vm.mmap_min_addr tunable that people who run dosemu/qemu/wine already
need to tweak).

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
  efi: Pass correct file handle to efi_file_{read,close}
  x86/efi: Correct EFI boot stub use of code32_start
  x86/efi: Fix boot failure with EFI stub
  x86/platform/hyperv: Handle VMBUS driver being a module
  x86/apic: Reinstate error IRQ Pentium erratum 3AP workaround
  x86, CMCI: Add proper detection of end of CMCI storms
</content>
</entry>
<entry>
<title>Merge tag 'efi-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent</title>
<updated>2014-04-11T08:25:28Z</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@kernel.org</email>
</author>
<published>2014-04-11T08:25:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3151b942badd059431eff93833cc1e957195b53b'/>
<id>urn:sha1:3151b942badd059431eff93833cc1e957195b53b</id>
<content type='text'>
Pull EFI fixes from Matt Fleming:

"* Fix EFI boot regression introduced during the merge window where the
   firmware was reading random values from the stack because we were
   passing a pointer to the wrong object type.

 * Kernel corruption has been reported when booting with the EFI boot
   stub which was tracked down to setting a bogus value for
   bp-&gt;hdr.code32_start, resulting in corruption during relocation.

 * Olivier Martin reported that the wrong file handles were being passed
   to efi_file_(read|close), which works for x86 by luck due to the way
   that the FAT driver is implemented, but doesn't work on ARM."

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi: Pass correct file handle to efi_file_{read,close}</title>
<updated>2014-04-10T20:20:03Z</updated>
<author>
<name>Matt Fleming</name>
<email>matt.fleming@intel.com</email>
</author>
<published>2014-04-10T13:11:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=47514c996fac5e6f13ef3a4c5e23f1c5cffabb7b'/>
<id>urn:sha1:47514c996fac5e6f13ef3a4c5e23f1c5cffabb7b</id>
<content type='text'>
We're currently passing the file handle for the root file system to
efi_file_read() and efi_file_close(), instead of the file handle for the
file we wish to read/close.

While this has worked up until now, it seems that it has only been by
pure luck. Olivier explains,

 "The issue is the UEFI Fat driver might return the same function for
  'fh-&gt;read()' and 'h-&gt;read()'. While in our case it does not work with
  a different implementation of EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. In our
  case, we return a different pointer when reading a directory and
  reading a file."

Fixing this actually clears up the two functions because we can drop one
of the arguments, and instead only pass a file 'handle' argument.

Reported-by: Olivier Martin &lt;olivier.martin@arm.com&gt;
Reviewed-by: Olivier Martin &lt;olivier.martin@arm.com&gt;
Reviewed-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Leif Lindholm &lt;leif.lindholm@linaro.org&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'driver-core-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core</title>
<updated>2014-04-01T23:28:19Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-04-01T23:28:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=158e0d3621683ee0cdfeeba56f0e5ddd97ae984f'/>
<id>urn:sha1:158e0d3621683ee0cdfeeba56f0e5ddd97ae984f</id>
<content type='text'>
Pull driver core and sysfs updates from Greg KH:
 "Here's the big driver core / sysfs update for 3.15-rc1.

  Lots of kernfs updates to make it useful for other subsystems, and a
  few other tiny driver core patches.

  All have been in linux-next for a while"

* tag 'driver-core-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (42 commits)
  Revert "sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()"
  kernfs: cache atomic_write_len in kernfs_open_file
  numa: fix NULL pointer access and memory leak in unregister_one_node()
  Revert "driver core: synchronize device shutdown"
  kernfs: fix off by one error.
  kernfs: remove duplicate dir.c at the top dir
  x86: align x86 arch with generic CPU modalias handling
  cpu: add generic support for CPU feature based module autoloading
  sysfs: create bin_attributes under the requested group
  driver core: unexport static function create_syslog_header
  firmware: use power efficient workqueue for unloading and aborting fw load
  firmware: give a protection when map page failed
  firmware: google memconsole driver fixes
  firmware: fix google/gsmi duplicate efivars_sysfs_init()
  drivers/base: delete non-required instances of include &lt;linux/init.h&gt;
  kernfs: fix kernfs_node_from_dentry()
  ACPI / platform: drop redundant ACPI_HANDLE check
  kernfs: fix hash calculation in kernfs_rename_ns()
  kernfs: add CONFIG_KERNFS
  sysfs, kobject: add sysfs wrapper for kernfs_enable_ns()
  ...
</content>
</entry>
<entry>
<title>Merge branch 'x86-asmlinkage-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2014-03-31T21:13:25Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-03-31T21:13:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=176ab02d4916f09d5d8cb63372d142df4378cdea'/>
<id>urn:sha1:176ab02d4916f09d5d8cb63372d142df4378cdea</id>
<content type='text'>
Pull x86 LTO changes from Peter Anvin:
 "More infrastructure work in preparation for link-time optimization
  (LTO).  Most of these changes is to make sure symbols accessed from
  assembly code are properly marked as visible so the linker doesn't
  remove them.

  My understanding is that the changes to support LTO are still not
  upstream in binutils, but are on the way there.  This patchset should
  conclude the x86-specific changes, and remaining patches to actually
  enable LTO will be fed through the Kbuild tree (other than keeping up
  with changes to the x86 code base, of course), although not
  necessarily in this merge window"

* 'x86-asmlinkage-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (25 commits)
  Kbuild, lto: Handle basic LTO in modpost
  Kbuild, lto: Disable LTO for asm-offsets.c
  Kbuild, lto: Add a gcc-ld script to let run gcc as ld
  Kbuild, lto: add ld-version and ld-ifversion macros
  Kbuild, lto: Drop .number postfixes in modpost
  Kbuild, lto, workaround: Don't warn for initcall_reference in modpost
  lto: Disable LTO for sys_ni
  lto: Handle LTO common symbols in module loader
  lto, workaround: Add workaround for initcall reordering
  lto: Make asmlinkage __visible
  x86, lto: Disable LTO for the x86 VDSO
  initconst, x86: Fix initconst mistake in ts5500 code
  initconst: Fix initconst mistake in dcdbas
  asmlinkage: Make trace_hardirqs_on/off_caller visible
  asmlinkage, x86: Fix 32bit memcpy for LTO
  asmlinkage Make __stack_chk_failed and memcmp visible
  asmlinkage: Mark rwsem functions that can be called from assembler asmlinkage
  asmlinkage: Make main_extable_sort_needed visible
  asmlinkage, mutex: Mark __visible
  asmlinkage: Make trace_hardirq visible
  ...
</content>
</entry>
<entry>
<title>x86, efi: Abstract x86 efi_early calls</title>
<updated>2014-03-26T18:30:03Z</updated>
<author>
<name>Matt Fleming</name>
<email>matt.fleming@intel.com</email>
</author>
<published>2014-03-22T10:09:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=204b0a1a4b92612c957a042df1a3be0e9cc79391'/>
<id>urn:sha1:204b0a1a4b92612c957a042df1a3be0e9cc79391</id>
<content type='text'>
The ARM EFI boot stub doesn't need to care about the efi_early
infrastructure that x86 requires in order to do mixed mode thunking. So
wrap everything up in an efi_call_early() macro.

This allows x86 to do the necessary indirection jumps to call whatever
firmware interface is necessary (native or mixed mode), but also allows
the ARM folks to mask the fact that they don't support relocation in the
boot stub and need to pass 'sys_table_arg' to every function.

[ hpa: there are no object code changes from this patch ]

Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Link: http://lkml.kernel.org/r/20140326091011.GB2958@console-pimps.org
Cc: Roy Franz &lt;roy.franz@linaro.org&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>Merge remote-tracking branch 'tip/x86/efi-mixed' into efi-for-mingo</title>
<updated>2014-03-05T18:15:37Z</updated>
<author>
<name>Matt Fleming</name>
<email>matt.fleming@intel.com</email>
</author>
<published>2014-03-05T18:15:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=994448f1afa6689bafbebaf7412b23b541b41ef5'/>
<id>urn:sha1:994448f1afa6689bafbebaf7412b23b541b41ef5</id>
<content type='text'>
Conflicts:
	arch/x86/kernel/setup.c
	arch/x86/platform/efi/efi.c
	arch/x86/platform/efi/efi_64.c
</content>
</entry>
<entry>
<title>x86/efi: Build our own EFI services pointer table</title>
<updated>2014-03-04T21:25:03Z</updated>
<author>
<name>Matt Fleming</name>
<email>matt.fleming@intel.com</email>
</author>
<published>2014-01-10T15:27:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=54b52d87268034859191d671505bb1cfce6bd74d'/>
<id>urn:sha1:54b52d87268034859191d671505bb1cfce6bd74d</id>
<content type='text'>
It's not possible to dereference the EFI System table directly when
booting a 64-bit kernel on a 32-bit EFI firmware because the size of
pointers don't match.

In preparation for supporting the above use case, build a list of
function pointers on boot so that callers don't have to worry about
converting pointer sizes through multiple levels of indirection.

Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
</entry>
</feed>
