summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)Author
2018-03-20fw_cfg: add a public uapi headerMarc-André Lureau
Create a common header file for well-known values and structures to be shared by the Linux kernel with qemu or other projects. It is based from qemu/docs/specs/fw_cfg.txt which references qemu/include/hw/nvram/fw_cfg_keys.h "for the most up-to-date and authoritative list" & vmcoreinfo.txt. Those files don't have an explicit license, but qemu/hw/nvram/fw_cfg.c is BSD-license, so Michael S. Tsirkin suggested to use the same license. The patch intentionally left out DMA & vmcoreinfo structures & defines, which are added in the commits making usage of it. Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-20fw_cfg: handle fw_cfg_read_blob() errorMarc-André Lureau
fw_cfg_read_blob() may fail, but does not return error. This may lead to surprising behaviours, like populating zero file entries (in register_file() or during read). Return an error if ACPI locking failed. Also, the following DMA read/write extension will add more error paths that should be handled appropriately. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-20fw_cfg: remove inline from fw_cfg_read_blob()Marc-André Lureau
The function is not small and getting bigger. Let the compiler decide instead. No profiling done, hopefully unnecessary. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-20fw_cfg: fix sparse warnings around FW_CFG_FILE_DIR readMarc-André Lureau
Use struct fw_cfg_files to read the directory size, fixing the sparse warnings: drivers/firmware/qemu_fw_cfg.c:485:17: warning: cast to restricted __be32 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-20fw_cfg: fix sparse warning reading FW_CFG_IDMarc-André Lureau
Use a restricted type for reading FW_CFG_ID, fixing sparse warning: drivers/firmware/qemu_fw_cfg.c:540:22: warning: cast to restricted __le32 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-20fw_cfg: fix sparse warnings with fw_cfg_fileMarc-André Lureau
Modify fw_cfg_sysfs_entry to store entry values, instead of reusing the restricted types. Fixes warnings such as: $ make C=1 CF=-D__CHECK_ENDIAN__ drivers/firmware/qemu_fw_cfg.o drivers/firmware/qemu_fw_cfg.c:491:29: warning: incorrect type in assignment (different base types) drivers/firmware/qemu_fw_cfg.c:491:29: expected restricted __be32 [usertype] size drivers/firmware/qemu_fw_cfg.c:491:29: got unsigned int drivers/firmware/qemu_fw_cfg.c:492:31: warning: incorrect type in assignment (different base types) drivers/firmware/qemu_fw_cfg.c:492:31: expected restricted __be16 [usertype] select drivers/firmware/qemu_fw_cfg.c:492:31: got int Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-20fw_cfg: fix sparse warnings in fw_cfg_sel_endianness()Marc-André Lureau
Dispatch to the appropriate iowrite() instead of casting restricted type to u16. - if fw_cfg_is_mmio: before: iowrite16(cpu_to_be16(key)) after: iowrite16be(key) - if !fw_cfg_is_mmio: before: iowrite16(cpu_to_le16(key)) after: iowrite16(key) which is equivalent on little-endian systems, where fw_cfg IO is supported. Fixes: $ make C=1 CF=-D__CHECK_ENDIAN__ drivers/firmware/qemu_fw_cfg.o drivers/firmware/qemu_fw_cfg.c:55:33: warning: restricted __be16 degrades to integer drivers/firmware/qemu_fw_cfg.c:55:52: warning: restricted __le16 degrades to integer Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-18Merge branch 'efi-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fix from Thomas Gleixner: "A single fix to prevent partially initialized pointers in mixed mode (64bit kernel on 32bit UEFI)" * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/libstub/tpm: Initialize pointer variables to zero for mixed mode
2018-03-14platform/x86: Fix dell driver init orderDarren Hart (VMware)
Update the initcall ordering to satisfy the following dependency ordering: 1. DCDBAS, ACPI_WMI 2. DELL_SMBIOS, DELL_RBTN 3. DELL_LAPTOP, DELL_WMI By assigning them to the following initcall levels: subsys_initcall: DCDBAS, ACPI_WMI module_init: DELL_SMBIOS, DELL_RBTN late_initcall: DELL_LAPTOP, DELL_WMI Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Mario.Limonciello@dell.com Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2018-03-14firmware, DMI: Add function to look up a handle and return DIMM sizeTony Luck
When we first scan the SMBIOS table, save the size of the DIMM. Provide a function for other code (EDAC driver) to look up the size of a DIMM from its SMBIOS handle. Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Tony Luck <tony.luck@intel.com> Cc: Aristeu Rozanski <aris@redhat.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: linux-acpi@vger.kernel.org Cc: linux-nvdimm@lists.01.org Link: http://lkml.kernel.org/r/20180312182430.10335-5-tony.luck@intel.com Signed-off-by: Borislav Petkov <bp@suse.de>
2018-03-13efi/libstub/tpm: Initialize pointer variables to zero for mixed modeArd Biesheuvel
As reported by Jeremy Cline, running the new TPM libstub code in mixed mode (i.e., 64-bit kernel on 32-bit UEFI) results in hangs when invoking the TCG2 protocol, or when accessing the log_tbl pool allocation. The reason turns out to be that in both cases, the 64-bit pointer variables are not fully initialized by the 32-bit EFI code, and so we should take care to zero initialize these variables beforehand, or we'll end up dereferencing bogus pointers. Reported-by: Jeremy Cline <jeremy@jcline.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: hdegoede@redhat.com Cc: jarkko.sakkinen@linux.intel.com Cc: javierm@redhat.com Cc: linux-efi@vger.kernel.org Cc: tweek@google.com Link: http://lkml.kernel.org/r/20180313140922.17266-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-12efi: Use string literals for efi_char16_t variable initializersArd Biesheuvel
Now that we unambiguously build the entire kernel with -fshort-wchar, it is no longer necessary to open code efi_char16_t[] initializers as arrays of characters, and we can move to the L"xxx" notation instead. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Lukas Wunner <lukas@wunner.de> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180312084500.10764-6-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-12efi/esrt: Fix handling of early ESRT table mappingArd Biesheuvel
As reported by Tyler, efi_esrt_init() will return without releasing the ESRT table header mapping if it encounters a table with an unexpected version. Replacing the 'return' with 'goto err_memunmap' would fix this particular occurrence, but, as it turns out, the code is rather peculiar to begin with: - it never uses the header mapping after memcpy()'ing out its contents, - it maps and unmaps the entire table without ever looking at the contents. So let's refactor this code to unmap the table header right after the memcpy() so we can get rid of the error handling path altogether, and drop the second mapping entirely. Reported-by: Tyler Baicar <tbaicar@codeaurora.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180312084500.10764-5-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-12efi: Use efi_mm in x86 as well as ARMSai Praneeth
Presently, only ARM uses mm_struct to manage EFI page tables and EFI runtime region mappings. As this is the preferred approach, let's make this data structure common across architectures. Specially, for x86, using this data structure improves code maintainability and readability. Tested-by: Bhupesh Sharma <bhsharma@redhat.com> [ardb: don't #include the world to get a declaration of struct mm_struct] Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Lee, Chun-Yi <jlee@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ravi Shankar <ravi.v.shankar@intel.com> Cc: Ricardo Neri <ricardo.neri@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180312084500.10764-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09FIRMWARE: bcm47xx_nvram: Replace mac address parsingAndy Shevchenko
Replace sscanf() with mac_pton(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Cc: David S. Miller <davem@davemloft.net> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17982/ Signed-off-by: James Hogan <jhogan@kernel.org>
2018-03-09efi/apple-properties: Use memremap() instead of ioremap()Andy Shevchenko
The memory we are accessing through virtual address has no IO side effects. Moreover, for IO memory we have to use special accessors, which we don't use. Due to above, convert the driver to use memremap() instead of ioremap(). Tested-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180308080020.22828-12-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09efi: Reorder pr_notice() with add_device_randomness() callArd Biesheuvel
Currently, when we receive a random seed from the EFI stub, we call add_device_randomness() to incorporate it into the entropy pool, and issue a pr_notice() saying we are about to do that, e.g., [ 0.000000] efi: RNG=0x87ff92cf18 [ 0.000000] random: fast init done [ 0.000000] efi: seeding entropy pool Let's reorder those calls to make the output look less confusing: [ 0.000000] efi: seeding entropy pool [ 0.000000] efi: RNG=0x87ff92cf18 [ 0.000000] random: fast init done Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180308080020.22828-11-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09efi/arm*: Stop printing addresses of virtual mappingsArd Biesheuvel
With the recent %p -> %px changes, we now get something like this in the kernel boot log on ARM/arm64 EFI systems: Remapping and enabling EFI services. EFI remap 0x00000087fb830000 => (ptrval) EFI remap 0x00000087fbdb0000 => (ptrval) EFI remap 0x00000087fffc0000 => (ptrval) The physical addresses of the UEFI runtime regions will also be printed when booting with the efi=debug command line option, and the virtual addresses can be inspected via /sys/kernel/debug/efi_page_tables (if enabled). So let's just remove the lines above. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180308080020.22828-4-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09efi/apple-properties: Remove redundant attribute initialization from ↵Andy Shevchenko
unmarshal_key_value_pairs() There is no need to artificially supply a property length and fake data if property has type of boolean. Remove redundant piece of data and code. Reviewed-and-tested-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180308080020.22828-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09efi/arm*: Only register page tables when they existMark Rutland
Currently the arm/arm64 runtime code registers the runtime servies pagetables with ptdump regardless of whether runtime services page tables have been created. As efi_mm.pgd is NULL in these cases, attempting to dump the efi page tables results in a NULL pointer dereference in the ptdump code: /sys/kernel/debug# cat efi_page_tables [ 479.522600] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 479.522715] Mem abort info: [ 479.522764] ESR = 0x96000006 [ 479.522850] Exception class = DABT (current EL), IL = 32 bits [ 479.522899] SET = 0, FnV = 0 [ 479.522937] EA = 0, S1PTW = 0 [ 479.528200] Data abort info: [ 479.528230] ISV = 0, ISS = 0x00000006 [ 479.528317] CM = 0, WnR = 0 [ 479.528317] user pgtable: 4k pages, 48-bit VAs, pgd = 0000000064ab0cb0 [ 479.528449] [0000000000000000] *pgd=00000000fbbe4003, *pud=00000000fb66e003, *pmd=0000000000000000 [ 479.528600] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 479.528664] Modules linked in: [ 479.528699] CPU: 0 PID: 2457 Comm: cat Not tainted 4.15.0-rc3-00065-g2ad2ee7ecb5c-dirty #7 [ 479.528799] Hardware name: FVP Base (DT) [ 479.528899] pstate: 00400009 (nzcv daif +PAN -UAO) [ 479.528941] pc : walk_pgd.isra.1+0x20/0x1d0 [ 479.529011] lr : ptdump_walk_pgd+0x30/0x50 [ 479.529105] sp : ffff00000bf4bc20 [ 479.529185] x29: ffff00000bf4bc20 x28: 0000ffff9d22e000 [ 479.529271] x27: 0000000000020000 x26: ffff80007b4c63c0 [ 479.529358] x25: 00000000014000c0 x24: ffff80007c098900 [ 479.529445] x23: ffff00000bf4beb8 x22: 0000000000000000 [ 479.529532] x21: ffff00000bf4bd70 x20: 0000000000000001 [ 479.529618] x19: ffff00000bf4bcb0 x18: 0000000000000000 [ 479.529760] x17: 000000000041a1c8 x16: ffff0000082139d8 [ 479.529800] x15: 0000ffff9d3c6030 x14: 0000ffff9d2527f4 [ 479.529924] x13: 00000000000003f3 x12: 0000000000000038 [ 479.530000] x11: 0000000000000003 x10: 0101010101010101 [ 479.530099] x9 : 0000000017e94050 x8 : 000000000000003f [ 479.530226] x7 : 0000000000000000 x6 : 0000000000000000 [ 479.530313] x5 : 0000000000000001 x4 : 0000000000000000 [ 479.530416] x3 : ffff000009069fd8 x2 : 0000000000000000 [ 479.530500] x1 : 0000000000000000 x0 : 0000000000000000 [ 479.530599] Process cat (pid: 2457, stack limit = 0x000000005d1b0e6f) [ 479.530660] Call trace: [ 479.530746] walk_pgd.isra.1+0x20/0x1d0 [ 479.530833] ptdump_walk_pgd+0x30/0x50 [ 479.530907] ptdump_show+0x10/0x20 [ 479.530920] seq_read+0xc8/0x470 [ 479.531023] full_proxy_read+0x60/0x90 [ 479.531100] __vfs_read+0x18/0x100 [ 479.531180] vfs_read+0x88/0x160 [ 479.531267] SyS_read+0x48/0xb0 [ 479.531299] el0_svc_naked+0x20/0x24 [ 479.531400] Code: 91400420 f90033a0 a90707a2 f9403fa0 (f9400000) [ 479.531499] ---[ end trace bfe8e28d8acb2b67 ]--- Segmentation fault Let's avoid this problem by only registering the tables after their successful creation, which is also less confusing when EFI runtime services are not in use. Reported-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180308080020.22828-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-08firmware: tegra: adjust tested variableJulia Lawall
Check the variable that was most recently initialized. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x, y, f, g, e, m; statement S1,S2,S3,S4; @@ x = f(...); if (\(<+...x...+>\&e\)) S1 else S2 ( x = g(...); | m = g(...,&x,...); | y = g(...); *if (e) S3 else S4 ) // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-03-08firmware: tegra: Simplify channel managementMikko Perttunen
The Tegra194 BPMP only implements 5 channels (4 to BPMP, 1 to CCPLEX), and they are not placed contiguously in memory. The current channel management in the BPMP driver does not support this. Simplify and refactor the channel management such that only one atomic transmit channel and one receive channel are supported, and channels are not required to be placed contiguously in memory. The same configuration also works on T186 so we end up with less code. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-03-07firmware: meson-sm: rework meson_sm_init to use module_platform_driver_probeSudeep Holla
Commit 3aa0582fdb82 ("of: platform: populate /firmware/ node from of_platform_default_populate_init()") takes care of populating all the devices under the /firmware/ node in of_platform_default_populate_init() This patch reworks meson_sm_init to use module_platform_driver_probe as the platform device is populated. Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: linux-amlogic@lists.infradead.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2018-03-07Merge tag 'scmi-updates-4.17' of ↵Arnd Bergmann
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers Pull "ARM SCMI support for v4.17" from Sudeep Holla: ARM System Control and Management Interface(SCMI)[1] is more flexible and easily extensible than any of the existing interfaces. Few existing as well as future ARM platforms provide micro-controllers to abstract various power and other system management tasks which have similar interfaces, both in terms of the functions that are provided by them, and in terms of how requests are communicated to them. There are quite a few protocols like ARM SCPI, TI SCI, QCOM RPM, Nvidia Tegra BPMP, and so on already. This specification is to standardize and avoid any further fragmentation in the design of such interface by various vendors. The current SCMI driver implementation is very basic and initial support. It lacks support for notifications, asynchronous/delayed response, perf/power statistics region and sensor register region. Mailbox is the only form of transport supported currently in the driver. SCMI supports interrupt based mailbox communication, where, on completion of the processing of a message, the caller receives an interrupt as well as polling for completion. SCMI is designed to minimize the dependency on the mailbox/transport hardware. So in terms of SCMI, each channel in the mailbox includes memory area, doorbell and completion interrupt. However the doorbell and completion interrupt is highly mailbox dependent which was bit of controversial as part of SCMI/mailbox discussions. Arnd and me discussed about the few aspects of SCMI and the mailbox framework: 1. Use of mailbox framework for doorbell type mailbox controller: - Such hardware may not require any data to be sent to signal the remote about the presence of a message. The channel will have in-built information on how to trigger the signal to the remote. There are few mailbox controller drivers which are purely doorbell based. e.g.QCOM IPC, STM, Tegra, ACPI PCC,..etc 2. Supporting other mailbox controller: - SCMI just needs a mechanism to signal the remote firmware. Such controller may need fixed message to be sent to trigger a doorbell. In such case we may need to get that data from DT and pass the same to the controller. It's not covered in the current DT binding, but can be extended as optional property in future. However handling notifications may be interesting on such mailbox, but again there is no way to interpret what the data field(remote message) means, it could be a bit mask or a number or don't-care. Arnd mentioned that he doesn't like the way the mailbox binding deals with doorbell-type hardware, but we do have quite a few precedent drivers already and changing the binding to add a data field would not make it any better, but could cause other problems. So he is happy with the status quo of SCMI implementation. [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0056a/index.html * tag 'scmi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: cpufreq: scmi: add support for fast frequency switching cpufreq: add support for CPU DVFS based on SCMI message protocol hwmon: add support for sensors exported via ARM SCMI hwmon: (core) Add hwmon_max to hwmon_sensor_types enumeration clk: add support for clocks provided by SCMI firmware: arm_scmi: add device power domain support using genpd firmware: arm_scmi: add per-protocol channels support using idr objects firmware: arm_scmi: refactor in preparation to support per-protocol channels firmware: arm_scmi: add option for polling based performance domain operations firmware: arm_scmi: add support for polling based SCMI transfers firmware: arm_scmi: probe and initialise all the supported protocols firmware: arm_scmi: add initial support for sensor protocol firmware: arm_scmi: add initial support for power protocol firmware: arm_scmi: add initial support for clock protocol firmware: arm_scmi: add initial support for performance protocol firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices firmware: arm_scmi: add common infrastructure and support for base protocol firmware: arm_scmi: add basic driver infrastructure for SCMI dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol dt-bindings: mailbox: add support for mailbox client shared memory
2018-02-28firmware: arm_scmi: add device power domain support using genpdSudeep Holla
This patch hooks up the support for device power domain provided by SCMI using the Linux generic power domain infrastructure. Cc: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add per-protocol channels support using idr objectsSudeep Holla
In order to maintain the channel information per protocol, we need some sort of list or hashtable to hold all this information. IDR provides sparse array mapping of small integer ID numbers onto arbitrary pointers. In this case the arbitrary pointers can be pointers to the channel information. This patch adds support for per-protocol channels using those idr objects. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: refactor in preparation to support per-protocol channelsSudeep Holla
In order to support per-protocol channels if available, we need to factor out all the mailbox channel information(Tx/Rx payload and channel handle) out of the main SCMI instance information structure. This patch refactors the existing channel information into a separate chan_info structure. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add option for polling based performance domain operationsSudeep Holla
In order to implement fast CPU DVFS switching, we need to perform all DVFS operations atomically. Since SCMI transfer already provide option to choose between pooling vs interrupt driven(default), we can opt for polling based transfers for set,get performance domain operations. This patch adds option to choose between polling vs interrupt driven SCMI transfers for set,get performance level operations. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add support for polling based SCMI transfersSudeep Holla
It would be useful to have options to perform some SCMI transfers atomically by polling for the completion flag instead of interrupt driven. The SCMI specification has option to disable the interrupt and poll for the completion flag in the shared memory. This patch adds support for polling based SCMI transfers using that option. This might be used for uninterrupted/atomic DVFS operations from the scheduler context. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: probe and initialise all the supported protocolsSudeep Holla
Now that we have basic support for all the protocols in the specification, let's probe them individually and initialise them. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add initial support for sensor protocolSudeep Holla
The sensor protocol provides functions to manage platform sensors, and provides the commands to describe the protocol version and the various attribute flags. It also provides commands to discover various sensors implemented and managed by the platform, read any sensor synchronously or asynchronously as allowed by the platform, program sensor attributes and/or configurations, if applicable. This patch adds support for most of the above features. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add initial support for power protocolSudeep Holla
The power protocol is intended for management of power states of various power domains. The power domain management protocol provides commands to describe the protocol version, discover the implementation specific attributes, set and get the power state of a domain. This patch adds support for the above mention features of the protocol. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> -- drivers/firmware/arm_scmi/Makefile | 2 +- drivers/firmware/arm_scmi/power.c | 242 +++++++++++++++++++++++++++++++++++++ include/linux/scmi_protocol.h | 28 +++++ 3 files changed, 271 insertions(+), 1 deletion(-) create mode 100644 drivers/firmware/arm_scmi/power.c
2018-02-28firmware: arm_scmi: add initial support for clock protocolSudeep Holla
The clock protocol is intended for management of clocks. It is used to enable or disable clocks, and to set and get the clock rates. This protocol provides commands to describe the protocol version, discover various implementation specific attributes, describe a clock, enable and disable a clock and get/set the rate of the clock synchronously or asynchronously. This patch adds initial support for the clock protocol. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add initial support for performance protocolSudeep Holla
The performance protocol is intended for the performance management of group(s) of device(s) that run in the same performance domain. It includes even the CPUs. A performance domain is defined by a set of devices that always have to run at the same performance level. For example, a set of CPUs that share a voltage domain, and have a common frequency control, is said to be in the same performance domain. The commands in this protocol provide functionality to describe the protocol version, describe various attribute flags, set and get the performance level of a domain. It also supports discovery of the list of performance levels supported by a performance domain, and the properties of each performance level. This patch adds basic support for the performance protocol. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add scmi protocol bus to enumerate protocol devicesSudeep Holla
The SCMI specification encompasses various protocols. However, not every protocol has to be present on a given platform/implementation as not every protocol is relevant for it. Furthermore, the platform chooses which protocols it exposes to a given agent. The only protocol that must be implemented is the base protocol. The base protocol is used by an agent to discover which protocols are available to it. In order to enumerate the discovered implemented protocols, this patch adds support for a separate scmi protocol bus. It also adds mechanism to register support for different protocols. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add common infrastructure and support for base protocolSudeep Holla
The base protocol describes the properties of the implementation and provide generic error management. The base protocol provides commands to describe protocol version, discover implementation specific attributes and vendor/sub-vendor identification, list of protocols implemented and the various agents are in the system including OSPM and the platform. It also supports registering for notifications of platform errors. This protocol is mandatory. This patch adds support for the same along with some basic infrastructure to add support for other protocols. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28firmware: arm_scmi: add basic driver infrastructure for SCMISudeep Holla
The SCMI is intended to allow OSPM to manage various functions that are provided by the hardware platform it is running on, including power and performance functions. SCMI provides two levels of abstraction, protocols and transports. Protocols define individual groups of system control and management messages. A protocol specification describes the messages that it supports. Transports describe the method by which protocol messages are communicated between agents and the platform. This patch adds basic infrastructure to manage the message allocation, initialisation, packing/unpacking and shared memory management. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: improve info message for pre-1.0 firmwareHeiner Kallweit
On legacy pre-1.0 firmware versions so far the following message is printed which may cause some confusion: SCP Protocol 0.0 Firmware 0.0.0 version Therefore replace the message with the following if firmware doesn't provide usable version information: SCP Protocol legacy pre-1.0 firmware Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: use FIELD_GET/_PREP to simplify macro definitionsHeiner Kallweit
Macro definitions can be simplified by making use of the FIELD_GET/_PREP bitfield macros. Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: remove struct sensor_capabilitiesHeiner Kallweit
One more single-element struct was left, remove it. Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: fix incorrect __iomem accesses using correct accessorsHeiner Kallweit
At several positions in the code sparse complains about incorrect access to __iomem annotated memory. Fix this and make sparse happy. Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> [Sudeep Holla: changed the patch title to describe the change] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: remove all single element structuresSudeep Holla
Both clk_get_value and sensor_value structures contains a single element and hence needs no packing making the whole structure defination unnecessary. This patch gets rid of both those unnecessary structures. Tested-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: drop unnecessary type cast to scpi_shared_memSudeep Holla
This patch drops the only present type cast of the SCPI payload pointer to scpi_shared_mem inorder to align with other occurrences, IOW for consistency. Tested-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: improve struct sensor_valueHeiner Kallweit
lo_val and hi_val together in this order are a little endian 64 bit value. Therefore we can simplify struct sensor_value and the code by defining it as a __le64 value and by using le64_to_cpu. Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: improve handling of protocol and firmware version subfieldsHeiner Kallweit
By using FIELD_GET and proper masks we can avoid quite some shifting and masking macro magic and make the code better readable. Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: improve struct dvfs_info to make code better readableHeiner Kallweit
Making the header subfields members of struct dvfs_info allows to make the code better readable and avoids some macro magic. In addition remove a useless statement using info->latency. Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: make scpi_probe completely device-managedHeiner Kallweit
Replace two remaining functions in probe with their devm versions. Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: make freeing mbox channels device-managedHeiner Kallweit
Make freeing the mbox channels device-managed, thus further simplifying scpi_remove and and one further step to get rid of scpi_remove. Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-23firmware: arm_scpi: remove two unneeded devm_kfree's in scpi_removeHeiner Kallweit
Both memory areas are free'd anyway when the device is destroyed, so we don't have to do it manually. Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-08Merge tag 'arm64-upstream' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull more arm64 updates from Catalin Marinas: "As I mentioned in the last pull request, there's a second batch of security updates for arm64 with mitigations for Spectre/v1 and an improved one for Spectre/v2 (via a newly defined firmware interface API). Spectre v1 mitigation: - back-end version of array_index_mask_nospec() - masking of the syscall number to restrict speculation through the syscall table - masking of __user pointers prior to deference in uaccess routines Spectre v2 mitigation update: - using the new firmware SMC calling convention specification update - removing the current PSCI GET_VERSION firmware call mitigation as vendors are deploying new SMCCC-capable firmware - additional branch predictor hardening for synchronous exceptions and interrupts while in user mode Meltdown v3 mitigation update: - Cavium Thunder X is unaffected but a hardware erratum gets in the way. The kernel now starts with the page tables mapped as global and switches to non-global if kpti needs to be enabled. Other: - Theoretical trylock bug fixed" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (38 commits) arm64: Kill PSCI_GET_VERSION as a variant-2 workaround arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support arm/arm64: smccc: Implement SMCCC v1.1 inline primitive arm/arm64: smccc: Make function identifiers an unsigned quantity firmware/psci: Expose SMCCC version through psci_ops firmware/psci: Expose PSCI conduit arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support arm/arm64: KVM: Turn kvm_psci_version into a static inline arm/arm64: KVM: Advertise SMCCC v1.1 arm/arm64: KVM: Implement PSCI 1.0 support arm/arm64: KVM: Add smccc accessors to PSCI code arm/arm64: KVM: Add PSCI_VERSION helper arm/arm64: KVM: Consolidate the PSCI include files arm64: KVM: Increment PC after handling an SMC trap arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls arm64: entry: Apply BP hardening for suspicious interrupts from EL0 arm64: entry: Apply BP hardening for high-priority synchronous exceptions arm64: futex: Mask __user pointers prior to dereference ...
generated by cgit (git 2.34.1) at 2025-09-13 01:04:20 +0000