linux-toradex.git/drivers/firmware/google, branch v6.2-rc2

firmware: google: fix a NULL vs IS_ERR() check in cbmem_entry_probe()

2022-11-23T19:03:14+00:00

The devm_memremap() function returns error pointers on error,
it doesn't return NULL.

Fixes: 19d54020883c ("firmware: google: Implement cbmem in sysfs driver")
Signed-off-by: Peng Wu 
Reviewed-by: Guenter Roeck 
Reviewed-by: Jack Rosenthal 
Link: https://lore.kernel.org/r/20221115091138.51614-1-wupeng58@huawei.com
Signed-off-by: Greg Kroah-Hartman

Merge 6.1-rc6 into char-misc-next

2022-11-21T09:05:34+00:00

We need the char/misc fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

firmware: google: Implement cbmem in sysfs driver

2022-11-10T17:51:56+00:00

The CBMEM area is a downward-growing memory region used by coreboot to
dynamically allocate tagged data structures ("CBMEM entries") that
remain resident during boot.

This implements a driver which exports access to the CBMEM entries
via sysfs under /sys/bus/coreboot/devices/cbmem-.

This implementation is quite versatile.  Examples of how it could be
used are given below:

* Tools like util/cbmem from the coreboot tree could use this driver
  instead of finding CBMEM in /dev/mem directly.  Alternatively,
  firmware developers debugging an issue may find the sysfs interface
  more ergonomic than the cbmem tool and choose to use it directly.

* The crossystem tool, which exposes verified boot variables, can use
  this driver to read the vboot work buffer.

* Tools which read the BIOS SPI flash (e.g., flashrom) can find the
  flash layout in CBMEM directly, which is significantly faster than
  searching the flash directly.

Write access is provided to all CBMEM regions via
/sys/bus/coreboot/devices/cbmem-/mem, as the existing cbmem
tooling updates this memory region, and envisioned use cases with
crossystem can benefit from updating memory regions.

Link: https://issuetracker.google.com/239604743
Cc: Stephen Boyd 
Cc: Tzung-Bi Shih 
Reviewed-by: Guenter Roeck 
Reviewed-by: Julius Werner 
Tested-by: Jack Rosenthal 
Signed-off-by: Jack Rosenthal 
Link: https://lore.kernel.org/r/20221104161528.531248-1-jrosenth@chromium.org
Signed-off-by: Greg Kroah-Hartman

firmware: coreboot: Register bus in module init

2022-11-10T17:47:53+00:00

The coreboot_table driver registers a coreboot bus while probing a
"coreboot_table" device representing the coreboot table memory region.
Probing this device (i.e., registering the bus) is a dependency for the
module_init() functions of any driver for this bus (e.g.,
memconsole-coreboot.c / memconsole_driver_init()).

With synchronous probe, this dependency works OK, as the link order in
the Makefile ensures coreboot_table_driver_init() (and thus,
coreboot_table_probe()) completes before a coreboot device driver tries
to add itself to the bus.

With asynchronous probe, however, coreboot_table_probe() may race with
memconsole_driver_init(), and so we're liable to hit one of these two:

1. coreboot_driver_register() eventually hits "[...] the bus was not
   initialized.", and the memconsole driver fails to register; or
2. coreboot_driver_register() gets past #1, but still races with
   bus_register() and hits some other undefined/crashing behavior (e.g.,
   in driver_find() [1])

We can resolve this by registering the bus in our initcall, and only
deferring "device" work (scanning the coreboot memory region and
creating sub-devices) to probe().

[1] Example failure, using 'driver_async_probe=*' kernel command line:

[    0.114217] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
...
[    0.114307] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc1 #63
[    0.114316] Hardware name: Google Scarlet (DT)
...
[    0.114488] Call trace:
[    0.114494]  _raw_spin_lock+0x34/0x60
[    0.114502]  kset_find_obj+0x28/0x84
[    0.114511]  driver_find+0x30/0x50
[    0.114520]  driver_register+0x64/0x10c
[    0.114528]  coreboot_driver_register+0x30/0x3c
[    0.114540]  memconsole_driver_init+0x24/0x30
[    0.114550]  do_one_initcall+0x154/0x2e0
[    0.114560]  do_initcall_level+0x134/0x160
[    0.114571]  do_initcalls+0x60/0xa0
[    0.114579]  do_basic_setup+0x28/0x34
[    0.114588]  kernel_init_freeable+0xf8/0x150
[    0.114596]  kernel_init+0x2c/0x12c
[    0.114607]  ret_from_fork+0x10/0x20
[    0.114624] Code: 5280002b 1100054a b900092a f9800011 (885ffc01)
[    0.114631] ---[ end trace 0000000000000000 ]---

Fixes: b81e3140e412 ("firmware: coreboot: Make bus registration symmetric")
Cc: 
Signed-off-by: Brian Norris 
Reviewed-by: Guenter Roeck 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20221019180934.1.If29e167d8a4771b0bf4a39c89c6946ed764817b9@changeid
Signed-off-by: Greg Kroah-Hartman

firmware: google: Test spinlock on panic path to avoid lockups

2022-09-24T12:59:44+00:00

Currently the gsmi driver registers a panic notifier as well as
reboot and die notifiers. The callbacks registered are called in
atomic and very limited context - for instance, panic disables
preemption and local IRQs, also all secondary CPUs (not executing
the panic path) are shutdown.

With that said, taking a spinlock in this scenario is a dangerous
invitation for lockup scenarios. So, fix that by checking if the
spinlock is free to acquire in the panic notifier callback - if not,
bail-out and avoid a potential hang.

Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
Cc: Andrew Morton 
Cc: Ard Biesheuvel 
Cc: David Gow 
Cc: Greg Kroah-Hartman 
Cc: Julius Werner 
Cc: Petr Mladek 
Reviewed-by: Evan Green 
Signed-off-by: Guilherme G. Piccoli 
Link: https://lore.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com
Signed-off-by: Greg Kroah-Hartman

firmware: google: Properly state IOMEM dependency

2022-03-18T13:18:15+00:00

The Google Coreboot implementation requires IOMEM functions
(memmremap, memunmap, devm_memremap), but does not specify this is its
Kconfig. This results in build errors when HAS_IOMEM is not set, such as
on some UML configurations:

/usr/bin/ld: drivers/firmware/google/coreboot_table.o: in function `coreboot_table_probe':
coreboot_table.c:(.text+0x311): undefined reference to `memremap'
/usr/bin/ld: coreboot_table.c:(.text+0x34e): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/memconsole-coreboot.o: in function `memconsole_probe':
memconsole-coreboot.c:(.text+0x12d): undefined reference to `memremap'
/usr/bin/ld: memconsole-coreboot.c:(.text+0x17e): undefined reference to `devm_memremap'
/usr/bin/ld: memconsole-coreboot.c:(.text+0x191): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_section_destroy.isra.0':
vpd.c:(.text+0x300): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_section_init':
vpd.c:(.text+0x382): undefined reference to `memremap'
/usr/bin/ld: vpd.c:(.text+0x459): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_probe':
vpd.c:(.text+0x59d): undefined reference to `memremap'
/usr/bin/ld: vpd.c:(.text+0x5d3): undefined reference to `memunmap'
collect2: error: ld returned 1 exit status

Fixes: a28aad66da8b ("firmware: coreboot: Collapse platform drivers into bus core")
Acked-By: anton ivanov 
Acked-By: Julius Werner 
Signed-off-by: David Gow 
Link: https://lore.kernel.org/r/20220225041502.1901806-1-davidgow@google.com
Signed-off-by: Greg Kroah-Hartman

firmware: Update Kconfig help text for Google firmware

2021-12-21T09:12:31+00:00

The help text for GOOGLE_FIRMWARE states that it should only be
enabled when building a kernel for Google's own servers.  However,
many of the drivers dependent on it are also useful on Chromebooks or
on any platform using coreboot.

Update the help text to reflect this double duty.

Fixes: d384d6f43d1e ("firmware: google memconsole: Add coreboot support")
Reviewed-by: Julius Werner 
Signed-off-by: Ben Hutchings 
Link: https://lore.kernel.org/r/20180618225540.GD14131@decadent.org.uk
Signed-off-by: Greg Kroah-Hartman

bus: Make remove callback return void

2021-07-21T09:53:42+00:00

The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.

This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were fixed that were caused by drivers
returning an error code in the expectation that the driver won't go
away.

With struct bus_type::remove returning void it's prevented that newly
implemented buses return an ignored error code and so don't anticipate
wrong expectations for driver authors.

Reviewed-by: Tom Rix  (For fpga)
Reviewed-by: Mathieu Poirier 
Reviewed-by: Cornelia Huck  (For drivers/s390 and drivers/vfio)
Acked-by: Russell King (Oracle)  (For ARM, Amba and related parts)
Acked-by: Mark Brown 
Acked-by: Chen-Yu Tsai  (for sunxi-rsb)
Acked-by: Pali Rohár 
Acked-by: Mauro Carvalho Chehab  (for media)
Acked-by: Hans de Goede  (For drivers/platform)
Acked-by: Alexandre Belloni 
Acked-By: Vinod Koul 
Acked-by: Juergen Gross  (For xen)
Acked-by: Lee Jones  (For mfd)
Acked-by: Johannes Thumshirn  (For mcb)
Acked-by: Johan Hovold 
Acked-by: Srinivas Kandagatla  (For slimbus)
Acked-by: Kirti Wankhede  (For vfio)
Acked-by: Maximilian Luz 
Acked-by: Heikki Krogerus  (For ulpi and typec)
Acked-by: Samuel Iglesias Gonsálvez  (For ipack)
Acked-by: Geoff Levand  (For ps3)
Acked-by: Yehezkel Bernat  (For thunderbolt)
Acked-by: Alexander Shishkin  (For intel_th)
Acked-by: Dominik Brodowski  (For pcmcia)
Acked-by: Rafael J. Wysocki  (For ACPI)
Acked-by: Bjorn Andersson  (rpmsg and apr)
Acked-by: Srinivas Pandruvada  (For intel-ish-hid)
Acked-by: Dan Williams  (For CXL, DAX, and NVDIMM)
Acked-by: William Breathitt Gray  (For isa)
Acked-by: Stefan Richter  (For firewire)
Acked-by: Benjamin Tissoires  (For hid)
Acked-by: Thorsten Scherer  (For siox)
Acked-by: Sven Van Asbroeck  (For anybuss)
Acked-by: Ulf Hansson  (For MMC)
Acked-by: Wolfram Sang  # for I2C
Acked-by: Sudeep Holla 
Acked-by: Geert Uytterhoeven 
Acked-by: Dmitry Torokhov 
Acked-by: Finn Thain 
Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20210713193522.1770306-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman

kernel.h: split out panic and oops helpers

2021-07-01T18:06:04+00:00

kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.

There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by moving out panic_notifier.h
- unload kernel.h from something which has its own domain

At the same time convert users tree-wide to use new headers, although for
the time being include new header back to kernel.h to avoid twisted
indirected includes for existing users.

[akpm@linux-foundation.org: thread_info.h needs limits.h]
[andriy.shevchenko@linux.intel.com: ia64 fix]
  Link: https://lkml.kernel.org/r/20210520130557.55277-1-andriy.shevchenko@linux.intel.com

Link: https://lkml.kernel.org/r/20210511074137.33666-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko 
Reviewed-by: Bjorn Andersson 
Co-developed-by: Andrew Morton 
Acked-by: Mike Rapoport 
Acked-by: Corey Minyard 
Acked-by: Christian Brauner 
Acked-by: Arnd Bergmann 
Acked-by: Kees Cook 
Acked-by: Wei Liu 
Acked-by: Rasmus Villemoes 
Signed-off-by: Andrew Morton 
Acked-by: Sebastian Reichel 
Acked-by: Luis Chamberlain 
Acked-by: Stephen Boyd 
Acked-by: Thomas Bogendoerfer 
Acked-by: Helge Deller  # parisc
Signed-off-by: Linus Torvalds

firmware: google: Enable s0ix logging by default

2021-04-02T14:30:21+00:00

Many moons ago, support was added to the SMI handlers to log s0ix entry
and exit. Early iterations of firmware on Apollo Lake correctly returned
"unsupported" for this new command they did not recognize, but
unfortunately also contained a quirk where this command would cause them
to power down rather than resume from s0ix.

Fixes for this quirk were pushed out long ago, so all APL devices still
in the field should have updated firmware. As such, we no longer need to
have the s0ix_logging_enable be opt-in, where every new platform has to
add this to their kernel commandline parameters. Change it to be on by
default.

In theory we could remove the parameter altogether: updated versions of
Chrome OS containing a kernel with this change would also be coupled
with firmware that behaves properly with these commands. Eventually we
should probably do that. For now, convert this to an opt-out parameter
so there's an emergency valve for people who are deliberately running
old firmware, or as an escape hatch in case of unforeseen regressions.

Signed-off-by: Evan Green 
Link: https://lore.kernel.org/r/20210401140430.1.Ie141e6044d9b0d5aba72cb08857fdb43660c54d3@changeid
Signed-off-by: Greg Kroah-Hartman