<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/firmware, branch v4.12.9</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.12.9</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.12.9'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2017-07-21T04:59:07Z</updated>
<entry>
<title>efi: Process the MEMATTR table only if EFI_MEMMAP is enabled</title>
<updated>2017-07-21T04:59:07Z</updated>
<author>
<name>Daniel Kiper</name>
<email>daniel.kiper@oracle.com</email>
</author>
<published>2017-06-22T10:51:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c43499cd0c0f8cbf8aa1b76dc1dd7232d57f211b'/>
<id>urn:sha1:c43499cd0c0f8cbf8aa1b76dc1dd7232d57f211b</id>
<content type='text'>
commit 457ea3f7e97881f937136ce0ba1f29f82b9abdb0 upstream.

Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.

In theory we can check EFI_PARAVIRT too, however,
EFI_MEMMAP looks more targeted and covers more cases.

Signed-off-by: Daniel Kiper &lt;daniel.kiper@oracle.com&gt;
Reviewed-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: andrew.cooper3@citrix.com
Cc: boris.ostrovsky@oracle.com
Cc: jgross@suse.com
Cc: linux-efi@vger.kernel.org
Cc: matt@codeblueprint.co.uk
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/1498128697-12943-2-git-send-email-daniel.kiper@oracle.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge branch 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging</title>
<updated>2017-06-16T08:13:06Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-06-16T08:13:06Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cbfb74973753e109f28705f6b98c8c8cc381b047'/>
<id>urn:sha1:cbfb74973753e109f28705f6b98c8c8cc381b047</id>
<content type='text'>
Pull dmi fixes from Jean Delvare.

* 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
  firmware: dmi_scan: Check DMI structure length
  firmware: dmi: Fix permissions of product_family
  firmware: dmi_scan: Make dmi_walk and dmi_walk_early return real error codes
  firmware: dmi_scan: Look for SMBIOS 3 entry point first
</content>
</entry>
<entry>
<title>firmware: dmi_scan: Check DMI structure length</title>
<updated>2017-06-15T11:46:01Z</updated>
<author>
<name>Jean Delvare</name>
<email>jdelvare@suse.de</email>
</author>
<published>2017-06-15T11:46:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a814c3597a6b6040e2ef9459748081a6d5b7312d'/>
<id>urn:sha1:a814c3597a6b6040e2ef9459748081a6d5b7312d</id>
<content type='text'>
Before accessing DMI data to record it for later, we should ensure
that the DMI structures are large enough to contain the data in
question.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Reviewed-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Cc: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Cc: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Cc: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>firmware: dmi: Fix permissions of product_family</title>
<updated>2017-06-15T11:46:01Z</updated>
<author>
<name>Jean Delvare</name>
<email>jdelvare@suse.de</email>
</author>
<published>2017-06-15T11:46:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e0733e975385d25d88c1384dafb8ea4dcf7513c0'/>
<id>urn:sha1:e0733e975385d25d88c1384dafb8ea4dcf7513c0</id>
<content type='text'>
This is not sensitive information like serial numbers, we can allow
all users to read it.

Fix odd alignment while we're here.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Fixes: c61872c9833d ("firmware: dmi: Add DMI_PRODUCT_FAMILY identification string")
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Reviewed-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Cc: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Cc: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>firmware: dmi_scan: Make dmi_walk and dmi_walk_early return real error codes</title>
<updated>2017-06-15T11:46:00Z</updated>
<author>
<name>Andy Lutomirski</name>
<email>luto@kernel.org</email>
</author>
<published>2017-06-15T11:46:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c926820085437a27b27e78996b2c7a5ad94e8055'/>
<id>urn:sha1:c926820085437a27b27e78996b2c7a5ad94e8055</id>
<content type='text'>
Currently they return -1 on error, which will confuse callers if
they try to interpret it as a normal negative error code.

Signed-off-by: Andy Lutomirski &lt;luto@kernel.org&gt;
Signed-off-by: Darren Hart (VMware) &lt;dvhart@infradead.org&gt;
Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
</content>
</entry>
<entry>
<title>firmware: dmi_scan: Look for SMBIOS 3 entry point first</title>
<updated>2017-06-15T11:46:00Z</updated>
<author>
<name>Jean Delvare</name>
<email>jdelvare@suse.de</email>
</author>
<published>2017-06-15T11:46:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c9aba14362a6eec583819ec8f4b872c1816f5cbe'/>
<id>urn:sha1:c9aba14362a6eec583819ec8f4b872c1816f5cbe</id>
<content type='text'>
Since version 3.0.0 of the SMBIOS specification, there can be
multiple entry points in memory, pointing to one or two DMI tables.
If both a 32-bit ("_SM_") entry point and a 64-bit ("_SM3_") entry
point are present, the specification requires that the latter points
to a table which is a super-set of the table pointed to by the
former. Therefore we should give preference to the 64-bit ("_SM3_")
entry point.

However, currently the code is picking the first valid entry point
it finds. Per specification, we should look for a 64-bit ("_SM3_")
entry point first, and if we can't find any, look for a 32-bit
("_SM_" or "_DMI_") entry point. Modify the code to do that.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
</content>
</entry>
<entry>
<title>Merge tag 'char-misc-4.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc</title>
<updated>2017-06-11T18:29:15Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-06-11T18:29:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9cd9cb0ba3e9e55120d25be3a45ffafd299b1b14'/>
<id>urn:sha1:9cd9cb0ba3e9e55120d25be3a45ffafd299b1b14</id>
<content type='text'>
Pull char/misc driver fixes from Greg KH:
 "Here are some small driver fixes for 4.12-rc5. Nothing major here,
  just some small bugfixes found by people testing, and a MAINTAINERS
  file update for the genwqe driver.

  All have been in linux-next with no reported issues"

[ The cxl driver fix came in through the powerpc tree earlier ]

* tag 'char-misc-4.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  cxl: Avoid double free_irq() for psl,slice interrupts
  mei: make sysfs modalias format similar as uevent modalias
  drivers: char: mem: Fix wraparound check to allow mappings up to the end
  MAINTAINERS: Change maintainer of genwqe driver
  goldfish_pipe: use GFP_ATOMIC under spin lock
  firmware: vpd: do not leak kobjects
  firmware: vpd: avoid potential use-after-free when destroying section
  firmware: vpd: do not leave freed section attributes to the list
</content>
</entry>
<entry>
<title>efi: Fix boot panic because of invalid BGRT image address</title>
<updated>2017-06-09T12:50:11Z</updated>
<author>
<name>Dave Young</name>
<email>dyoung@redhat.com</email>
</author>
<published>2017-06-09T08:45:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=792ef14df5c585c19b2831673a077504a09e5203'/>
<id>urn:sha1:792ef14df5c585c19b2831673a077504a09e5203</id>
<content type='text'>
Maniaxx reported a kernel boot crash in the EFI code, which I emulated
by using same invalid phys addr in code:

  BUG: unable to handle kernel paging request at ffffffffff280001
  IP: efi_bgrt_init+0xfb/0x153
  ...
  Call Trace:
   ? bgrt_init+0xbc/0xbc
   acpi_parse_bgrt+0xe/0x12
   acpi_table_parse+0x89/0xb8
   acpi_boot_init+0x445/0x4e2
   ? acpi_parse_x2apic+0x79/0x79
   ? dmi_ignore_irq0_timer_override+0x33/0x33
   setup_arch+0xb63/0xc82
   ? early_idt_handler_array+0x120/0x120
   start_kernel+0xb7/0x443
   ? early_idt_handler_array+0x120/0x120
   x86_64_start_reservations+0x29/0x2b
   x86_64_start_kernel+0x154/0x177
   secondary_startup_64+0x9f/0x9f

There is also a similar bug filed in bugzilla.kernel.org:

  https://bugzilla.kernel.org/show_bug.cgi?id=195633

The crash is caused by this commit:

  7b0a911478c7 efi/x86: Move the EFI BGRT init code to early init code

The root cause is the firmware on those machines provides invalid BGRT
image addresses.

In a kernel before above commit BGRT initializes late and uses ioremap()
to map the image address. Ioremap validates the address, if it is not a
valid physical address ioremap() just fails and returns. However in current
kernel EFI BGRT initializes early and uses early_memremap() which does not
validate the image address, and kernel panic happens.

According to ACPI spec the BGRT image address should fall into
EFI_BOOT_SERVICES_DATA, see the section 5.2.22.4 of below document:

  http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf

Fix this issue by validating the image address in efi_bgrt_init(). If the
image address does not fall into any EFI_BOOT_SERVICES_DATA areas we just
bail out with a warning message.

Reported-by: Maniaxx &lt;tripleshiftone@gmail.com&gt;
Signed-off-by: Dave Young &lt;dyoung@redhat.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: linux-efi@vger.kernel.org
Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
Link: http://lkml.kernel.org/r/20170609084558.26766-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2017-06-02T15:51:53Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-06-02T15:51:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f56f88ee3fa1c3080f6ba122a597e75f0d5ab969'/>
<id>urn:sha1:f56f88ee3fa1c3080f6ba122a597e75f0d5ab969</id>
<content type='text'>
Pull EFI fixes from Ingo Molnar:
 "Misc fixes:

   - three boot crash fixes for uncommon configurations

   - silence a boot warning under virtualization

   - plus a GCC 7 related (harmless) build warning fix"

* 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi/bgrt: Skip efi_bgrt_init() in case of non-EFI boot
  x86/efi: Correct EFI identity mapping under 'efi=old_map' when KASLR is enabled
  x86/efi: Disable runtime services on kexec kernel if booted with efi=old_map
  efi: Remove duplicate 'const' specifiers
  efi: Don't issue error message when booted under Xen
</content>
</entry>
<entry>
<title>Merge tag 'pinctrl-v4.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl</title>
<updated>2017-05-29T17:05:19Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-05-29T17:05:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3f173bde7e4320211e77a83f936fb754e7591006'/>
<id>urn:sha1:3f173bde7e4320211e77a83f936fb754e7591006</id>
<content type='text'>
Pull pin control fixes from Linus Walleij:
 "Here is an overdue pull request for pin control fixes, the most
  prominent feature is to make Intel Chromebooks (and I suspect any
  other Cherryview-based Intel thing) happy again, which we really want
  to see.

  There is a patch hitting drivers/firmware/* that I was uncertain to
  who actually manages, but I got Andy Shevchenko's and Dmitry Torokov's
  review tags on it and I trust them both 100% to do the right thing for
  Intel platform drivers.

  Summary:

   - Make a few Intel Chromebooks with Cherryview DMI firmware work
     smoothly.

   - A fix for some bogus allocations in the generic group management
     code.

   - Some GPIO descriptor lookup table stubs. Merged through the pin
     control tree for administrative reasons.

   - Revert the "bi-directional" and "output-enable" generic properties:
     we need more discussions around this. It seems other SoCs are using
     input/output gate enablement and these terms are not correct.

   - Fix mux and drive strength atomically in the MXS driver.

   - Fix the SPDIF function on sunxi A83T.

   - OF table terminators and other small fixes"

* tag 'pinctrl-v4.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
  pinctrl: sunxi: Fix SPDIF function name for A83T
  pinctrl: mxs: atomically switch mux and drive strength config
  pinctrl: cherryview: Extend the Chromebook DMI quirk to Intel_Strago systems
  firmware: dmi: Add DMI_PRODUCT_FAMILY identification string
  pinctrl: core: Fix warning by removing bogus code
  gpiolib: Add stubs for gpiod lookup table interface
  Revert "pinctrl: generic: Add bi-directional and output-enable"
  pinctrl: cherryview: Add terminate entry for dmi_system_id tables
</content>
</entry>
</feed>
