kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/drivers/firmware/google/coreboot_table.c

259 lines
5.7 KiB
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 287 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license v2 0 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 23 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.115786599@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-29 07:18:01 -07:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:06 -07:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:06 -07:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
driver core: have match() callback in struct bus_type take a const * In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const *. This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant *. For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Alex Elder <elder@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-01 14:07:37 +02:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
driver core: have match() callback in struct bus_type take a const * In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const *. This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant *. For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Alex Elder <elder@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-01 14:07:37 +02:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
driver core: have match() callback in struct bus_type take a const * In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const *. This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant *. For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Alex Elder <elder@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-01 14:07:37 +02:00
firmware: coreboot: Replace tag with id table in driver struct Switch the plain 'tag' field in struct coreboot_driver for the newly created coreboot_device_id struct, which also contains a tag field and has the benefit of allowing modalias generation, and update all coreboot drivers accordingly. While at it, also add the id table for each driver to the module device table to allow automatically loading the module. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240212-coreboot-mod-defconfig-v4-3-d14172676f6d@collabora.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-02-12 09:50:07 -05:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: Replace tag with id table in driver struct Switch the plain 'tag' field in struct coreboot_driver for the newly created coreboot_device_id struct, which also contains a tag field and has the benefit of allowing modalias generation, and update all coreboot drivers accordingly. While at it, also add the id table for each driver to the module device table to allow automatically loading the module. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240212-coreboot-mod-defconfig-v4-3-d14172676f6d@collabora.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-02-12 09:50:07 -05:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
bus: Make remove callback return void 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 <trix@redhat.com> (For fpga) Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> (For drivers/s390 and drivers/vfio) Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> (For ARM, Amba and related parts) Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Chen-Yu Tsai <wens@csie.org> (for sunxi-rsb) Acked-by: Pali Rohár <pali@kernel.org> Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org> (for media) Acked-by: Hans de Goede <hdegoede@redhat.com> (For drivers/platform) Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-By: Vinod Koul <vkoul@kernel.org> Acked-by: Juergen Gross <jgross@suse.com> (For xen) Acked-by: Lee Jones <lee.jones@linaro.org> (For mfd) Acked-by: Johannes Thumshirn <jth@kernel.org> (For mcb) Acked-by: Johan Hovold <johan@kernel.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> (For slimbus) Acked-by: Kirti Wankhede <kwankhede@nvidia.com> (For vfio) Acked-by: Maximilian Luz <luzmaximilian@gmail.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> (For ulpi and typec) Acked-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> (For ipack) Acked-by: Geoff Levand <geoff@infradead.org> (For ps3) Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com> (For thunderbolt) Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> (For intel_th) Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> (For pcmcia) Acked-by: Rafael J. Wysocki <rafael@kernel.org> (For ACPI) Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> (rpmsg and apr) Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> (For intel-ish-hid) Acked-by: Dan Williams <dan.j.williams@intel.com> (For CXL, DAX, and NVDIMM) Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> (For isa) Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (For firewire) Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> (For hid) Acked-by: Thorsten Scherer <t.scherer@eckelmann.de> (For siox) Acked-by: Sven Van Asbroeck <TheSven73@gmail.com> (For anybuss) Acked-by: Ulf Hansson <ulf.hansson@linaro.org> (For MMC) Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Finn Thain <fthain@linux-m68k.org> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20210713193522.1770306-6-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-13 21:35:22 +02:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: google: make coreboot driver's remove callback return void All coreboot drivers return 0 unconditionally in their remove callback. Also the device core ignores the return value of the struct bus_type::remove(), so make the coreboot remove callback return void instead of giving driver authors the illusion they could return an error code here. All drivers are adapted accordingly. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Link: https://lore.kernel.org/r/20210126215339.706021-1-uwe@kleine-koenig.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-26 22:53:39 +01:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: Generate modalias uevent for devices Generate a modalias uevent for devices in the coreboot bus to allow userspace to automatically load the corresponding modules. Acked-by: Brian Norris <briannorris@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240212-coreboot-mod-defconfig-v4-1-d14172676f6d@collabora.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-02-12 09:50:05 -05:00
firmware: coreboot: make coreboot_bus_type const Now that the driver core can properly handle constant struct bus_type, move the coreboot_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240204-bus_cleanup-firmware-v1-1-d1bff946606d@marliere.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-02-04 13:10:18 -03:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: Generate modalias uevent for devices Generate a modalias uevent for devices in the coreboot bus to allow userspace to automatically load the corresponding modules. Acked-by: Brian Norris <briannorris@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240212-coreboot-mod-defconfig-v4-1-d14172676f6d@collabora.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-02-12 09:50:05 -05:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: store owner from modules with coreboot_driver_register() Modules registering driver with coreboot_driver_register() might forget to set .owner field. The field is used by some of other kernel parts for reference counting (try_module_get()), so it is expected that drivers will set it. Solve the problem by moving this task away from the drivers to the core code, just like we did for platform_driver in commit 9447057eaff8 ("platform_device: use a macro instead of platform_driver_register"). Moving the .owner setting code to the core this effectively fixes missing .owner in framebuffer-coreboot, memconsole-coreboot and vpd drivers. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240330-module-owner-coreboot-v1-1-ddba098b6dcf@linaro.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-03-30 20:49:47 +01:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: store owner from modules with coreboot_driver_register() Modules registering driver with coreboot_driver_register() might forget to set .owner field. The field is used by some of other kernel parts for reference counting (try_module_get()), so it is expected that drivers will set it. Solve the problem by moving this task away from the drivers to the core code, just like we did for platform_driver in commit 9447057eaff8 ("platform_device: use a macro instead of platform_driver_register"). Moving the .owner setting code to the core this effectively fixes missing .owner in framebuffer-coreboot, memconsole-coreboot and vpd drivers. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240330-module-owner-coreboot-v1-1-ddba098b6dcf@linaro.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-03-30 20:49:47 +01:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: store owner from modules with coreboot_driver_register() Modules registering driver with coreboot_driver_register() might forget to set .owner field. The field is used by some of other kernel parts for reference counting (try_module_get()), so it is expected that drivers will set it. Solve the problem by moving this task away from the drivers to the core code, just like we did for platform_driver in commit 9447057eaff8 ("platform_device: use a macro instead of platform_driver_register"). Moving the .owner setting code to the core this effectively fixes missing .owner in framebuffer-coreboot, memconsole-coreboot and vpd drivers. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240330-module-owner-coreboot-v1-1-ddba098b6dcf@linaro.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-03-30 20:49:47 +01:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: Remap RAM with memremap() instead of ioremap() This is all system memory, so we shouldn't be mapping this all with ioremap() as these aren't I/O regions. Instead, they're memory regions so we should use memremap(). Pick MEMREMAP_WB so we can map memory from RAM directly if that's possible, otherwise it falls back to ioremap_cache() like is being done here already. This also nicely silences the sparse warnings in this code and reduces the need to copy anything around anymore. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:07 -07:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: coreboot: Remap RAM with memremap() instead of ioremap() This is all system memory, so we shouldn't be mapping this all with ioremap() as these aren't I/O regions. Instead, they're memory regions so we should use memremap(). Pick MEMREMAP_WB so we can map memory from RAM directly if that's possible, otherwise it falls back to ioremap_cache() like is being done here already. This also nicely silences the sparse warnings in this code and reduces the need to copy anything around anymore. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:07 -07:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: Check size of table entry and use flex-array The memcpy() of the data following a coreboot_table_entry couldn't be evaluated by the compiler under CONFIG_FORTIFY_SOURCE. To make it easier to reason about, add an explicit flexible array member to struct coreboot_device so the entire entry can be copied at once. Additionally, validate the sizes before copying. Avoids this run-time false positive warning: memcpy: detected field-spanning write (size 168) of single field "&device->entry" at drivers/firmware/google/coreboot_table.c:103 (size 8) Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://lore.kernel.org/all/03ae2704-8c30-f9f0-215b-7cdf4ad35a9a@molgen.mpg.de/ Cc: Jack Rosenthal <jrosenth@chromium.org> Cc: Guenter Roeck <groeck@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20230107031406.gonna.761-kees@kernel.org Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Link: https://lore.kernel.org/r/20230112230312.give.446-kees@kernel.org
2023-01-12 15:03:16 -08:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: Check size of table entry and use flex-array The memcpy() of the data following a coreboot_table_entry couldn't be evaluated by the compiler under CONFIG_FORTIFY_SOURCE. To make it easier to reason about, add an explicit flexible array member to struct coreboot_device so the entire entry can be copied at once. Additionally, validate the sizes before copying. Avoids this run-time false positive warning: memcpy: detected field-spanning write (size 168) of single field "&device->entry" at drivers/firmware/google/coreboot_table.c:103 (size 8) Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://lore.kernel.org/all/03ae2704-8c30-f9f0-215b-7cdf4ad35a9a@molgen.mpg.de/ Cc: Jack Rosenthal <jrosenth@chromium.org> Cc: Guenter Roeck <groeck@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20230107031406.gonna.761-kees@kernel.org Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Link: https://lore.kernel.org/r/20230112230312.give.446-kees@kernel.org
2023-01-12 15:03:16 -08:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: google: Implement cbmem in sysfs driver 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-<id>. 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-<id>/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 <swboyd@chromium.org> Cc: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: Jack Rosenthal <jrosenth@chromium.org> Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Link: https://lore.kernel.org/r/20221104161528.531248-1-jrosenth@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-04 10:15:28 -06:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: Remap RAM with memremap() instead of ioremap() This is all system memory, so we shouldn't be mapping this all with ioremap() as these aren't I/O regions. Instead, they're memory regions so we should use memremap(). Pick MEMREMAP_WB so we can map memory from RAM directly if that's possible, otherwise it falls back to ioremap_cache() like is being done here already. This also nicely silences the sparse warnings in this code and reduces the need to copy anything around anymore. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:07 -07:00
firmware: coreboot: Expose the coreboot table as a bus This simplifies creating device drivers for hardware or information described in the coreboot table. It also avoids needing to search through the table every time a driver is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24 19:41:16 -06:00
firmware: coreboot: Make bus registration symmetric The bus is registered in module_init() but is unregistered when the platform driver remove() function calls coreboot_table_exit(). That isn't symmetric and it causes the bus to appear on systems that compile this code in, even when there isn't any coreboot firmware on the device. Let's move the registration to the coreboot_table_init() function so that it matches the exit path. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:05 -07:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:06 -07:00
firmware: coreboot: Remap RAM with memremap() instead of ioremap() This is all system memory, so we shouldn't be mapping this all with ioremap() as these aren't I/O regions. Instead, they're memory regions so we should use memremap(). Pick MEMREMAP_WB so we can map memory from RAM directly if that's possible, otherwise it falls back to ioremap_cache() like is being done here already. This also nicely silences the sparse warnings in this code and reduces the need to copy anything around anymore. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:07 -07:00
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:06 -07:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: coreboot: Remap RAM with memremap() instead of ioremap() This is all system memory, so we shouldn't be mapping this all with ioremap() as these aren't I/O regions. Instead, they're memory regions so we should use memremap(). Pick MEMREMAP_WB so we can map memory from RAM directly if that's possible, otherwise it falls back to ioremap_cache() like is being done here already. This also nicely silences the sparse warnings in this code and reduces the need to copy anything around anymore. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:07 -07:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:06 -07:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: coreboot: Remap RAM with memremap() instead of ioremap() This is all system memory, so we shouldn't be mapping this all with ioremap() as these aren't I/O regions. Instead, they're memory regions so we should use memremap(). Pick MEMREMAP_WB so we can map memory from RAM directly if that's possible, otherwise it falls back to ioremap_cache() like is being done here already. This also nicely silences the sparse warnings in this code and reduces the need to copy anything around anymore. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:07 -07:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:06 -07:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: coreboot: Remap RAM with memremap() instead of ioremap() This is all system memory, so we shouldn't be mapping this all with ioremap() as these aren't I/O regions. Instead, they're memory regions so we should use memremap(). Pick MEMREMAP_WB so we can map memory from RAM directly if that's possible, otherwise it falls back to ioremap_cache() like is being done here already. This also nicely silences the sparse warnings in this code and reduces the need to copy anything around anymore. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:07 -07:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:06 -07:00
firmware: coreboot: Register bus in module init 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: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20221019180934.1.If29e167d8a4771b0bf4a39c89c6946ed764817b9@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-19 18:10:53 -07:00
firmware: coreboot: Only populate devices in coreboot_table_init() This function checks the header for sanity, registers a bus, and populates devices for each coreboot table entry. Let's just populate devices here and pull the other bits up into the caller so that this function can be repurposed for pure device creation and registration. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Suggested-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:08 -07:00
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:06 -07:00
firmware: google: Release devices before unregistering the bus Fix a bug where the kernel module can't be loaded after it has been unloaded as the devices are still present and conflicting with the to be created coreboot devices. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Link: https://lore.kernel.org/r/20191118101934.22526-2-patrick.rudolph@9elements.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-18 11:19:29 +01:00
firmware: coreboot: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/d323e4f24bfab3ac1480933deb51e7c5cb025b09.1703693980.git.u.kleine-koenig@pengutronix.de Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2023-12-27 17:26:27 +01:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
firmware: google: Release devices before unregistering the bus Fix a bug where the kernel module can't be loaded after it has been unloaded as the devices are still present and conflicting with the to be created coreboot devices. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Link: https://lore.kernel.org/r/20191118101934.22526-2-patrick.rudolph@9elements.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-18 11:19:29 +01:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:06 -07:00
firmware: Switch back to struct platform_driver::remove() After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/firmware to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/36974feb6035201d53384557259ec72fe311053b.1731397962.git.u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12 09:35:20 +01:00
firmware: coreboot: Collapse platform drivers into bus core The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 13:37:06 -07:00
firmware: coreboot: Register bus in module init 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: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20221019180934.1.If29e167d8a4771b0bf4a39c89c6946ed764817b9@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-19 18:10:53 -07:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00
firmware: google: add missing MODULE_DESCRIPTION() macros make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/gsmi.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/coreboot_table.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/framebuffer-coreboot.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/memconsole.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/memconsole-coreboot.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/memconsole-x86-legacy.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/cbmem.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/vpd-sysfs.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240605-md-drivers-firmware-google-v1-1-18878de97fa5@quicinc.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-06-05 15:07:21 -07:00
firmware: google memconsole: Add coreboot support Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 18:11:27 +02:00