aboutsummaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
2018-03-20firmware: arm_scmi: prevent accessing rate_discrete uninitializedAnders Roxell1-2/+3
gcc-5.3 and earlier warns that rate_discrete maybe-uninitialized ../drivers/firmware/arm_scmi/clock.c:185:5: warning: 'rate_discrete' may be used uninitialized in this function [-Wmaybe-uninitialized] if (rate_discrete) ^ ../drivers/firmware/arm_scmi/clock.c:128:7: note: 'rate_discrete' was declared here bool rate_discrete; ^ This patch fixing the warning by initialising rate_discrete and also using goto label for the error path. Fixes: 5f6c6430e904 ("firmware: arm_scmi: add initial support for clock protocol") Suggested-by: Arnd Bergmann <[email protected]> Signed-off-by: Anders Roxell <[email protected]> [sudeep.holla: added one line description to the commit message] Signed-off-by: Sudeep Holla <[email protected]>
2018-03-20fw_cfg: write vmcoreinfo detailsMarc-André Lureau1-3/+142
If the "etc/vmcoreinfo" fw_cfg file is present and we are not running the kdump kernel, write the addr/size of the vmcoreinfo ELF note. The DMA operation is expected to run synchronously with today qemu, but the specification states that it may become async, so we run "control" field check in a loop for eventual changes. Signed-off-by: Marc-André Lureau <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-03-20fw_cfg: add DMA registerMarc-André Lureau1-12/+41
Add an optional <dma_off> kernel module (or command line) parameter using the following syntax: [qemu_fw_cfg.]ioport=<size>@<base>[:<ctrl_off>:<data_off>[:<dma_off>]] or [qemu_fw_cfg.]mmio=<size>@<base>[:<ctrl_off>:<data_off>[:<dma_off>]] and initializes the register address using given or default offset. Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Gabriel Somlo <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-03-20fw_cfg: add a public uapi headerMarc-André Lureau1-20/+2
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 <[email protected]> Signed-off-by: Marc-André Lureau <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-03-20fw_cfg: handle fw_cfg_read_blob() errorMarc-André Lureau1-10/+22
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 <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-03-20fw_cfg: remove inline from fw_cfg_read_blob()Marc-André Lureau1-2/+2
The function is not small and getting bigger. Let the compiler decide instead. No profiling done, hopefully unnecessary. Signed-off-by: Marc-André Lureau <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-03-20fw_cfg: fix sparse warnings around FW_CFG_FILE_DIR readMarc-André Lureau1-3/+4
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 <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-03-20fw_cfg: fix sparse warning reading FW_CFG_IDMarc-André Lureau1-2/+3
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 <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-03-20fw_cfg: fix sparse warnings with fw_cfg_fileMarc-André Lureau1-13/+15
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 <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-03-20fw_cfg: fix sparse warnings in fw_cfg_sel_endianness()Marc-André Lureau1-3/+6
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 <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2018-03-18Merge branch 'efi-urgent-for-linus' of ↵Linus Torvalds1-2/+2
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)1-1/+1
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 <[email protected]> Cc: [email protected] Signed-off-by: Darren Hart (VMware) <[email protected]>
2018-03-14firmware, DMI: Add function to look up a handle and return DIMM sizeTony Luck1-0/+31
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 <[email protected]> Signed-off-by: Tony Luck <[email protected]> Cc: Aristeu Rozanski <[email protected]> Cc: Dan Williams <[email protected]> Cc: Len Brown <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Qiuxu Zhuo <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Borislav Petkov <[email protected]>
2018-03-13efi/libstub/tpm: Initialize pointer variables to zero for mixed modeArd Biesheuvel1-2/+2
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 <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-12efi: Use string literals for efi_char16_t variable initializersArd Biesheuvel3-15/+6
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 <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Lukas Wunner <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-12efi/esrt: Fix handling of early ESRT table mappingArd Biesheuvel1-13/+4
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 <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Peter Jones <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-12efi: Use efi_mm in x86 as well as ARMSai Praneeth2-9/+9
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 <[email protected]> [ardb: don't #include the world to get a declaration of struct mm_struct] Signed-off-by: Sai Praneeth Prakhya <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Reviewed-by: Matt Fleming <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Lee, Chun-Yi <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Michael S. Tsirkin <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Ravi Shankar <[email protected]> Cc: Ricardo Neri <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tony Luck <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-09FIRMWARE: bcm47xx_nvram: Replace mac address parsingAndy Shevchenko2-15/+4
Replace sscanf() with mac_pton(). Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Hauke Mehrtens <[email protected]> Cc: David S. Miller <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/17982/ Signed-off-by: James Hogan <[email protected]>
2018-03-09efi/apple-properties: Use memremap() instead of ioremap()Andy Shevchenko1-5/+6
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 <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-09efi: Reorder pr_notice() with add_device_randomness() callArd Biesheuvel1-1/+1
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 <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-09efi/arm*: Stop printing addresses of virtual mappingsArd Biesheuvel1-4/+1
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 <[email protected]> Acked-by: Leif Lindholm <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-09efi/apple-properties: Remove redundant attribute initialization from ↵Andy Shevchenko1-8/+1
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 <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-09efi/arm*: Only register page tables when they existMark Rutland1-0/+3
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 <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-08firmware: tegra: adjust tested variableJulia Lawall1-1/+1
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 <[email protected]> Reviewed-by: Mikko Perttunen <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2018-03-08firmware: tegra: Simplify channel managementMikko Perttunen1-78/+64
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 <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2018-03-07firmware: meson-sm: rework meson_sm_init to use module_platform_driver_probeSudeep Holla1-13/+12
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 <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: [email protected] Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Kevin Hilman <[email protected]>
2018-03-07Merge tag 'scmi-updates-4.17' of ↵Arnd Bergmann12-0/+2954
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 Holla3-0/+143
This patch hooks up the support for device power domain provided by SCMI using the Linux generic power domain infrastructure. Cc: Kevin Hilman <[email protected]> Reviewed-by: Ulf Hansson <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: add per-protocol channels support using idr objectsSudeep Holla1-12/+42
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: refactor in preparation to support per-protocol channelsSudeep Holla1-34/+56
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: add option for polling based performance domain operationsSudeep Holla1-8/+11
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: add support for polling based SCMI transfersSudeep Holla1-8/+47
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: probe and initialise all the supported protocolsSudeep Holla1-1/+50
Now that we have basic support for all the protocols in the specification, let's probe them individually and initialise them. Cc: Arnd Bergmann <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: add initial support for sensor protocolSudeep Holla2-1/+292
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: add initial support for power protocolSudeep Holla2-1/+222
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> -- 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 Holla2-1/+343
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: add initial support for performance protocolSudeep Holla3-1/+480
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: add scmi protocol bus to enumerate protocol devicesSudeep Holla3-1/+224
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: add common infrastructure and support for base protocolSudeep Holla4-1/+345
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-28firmware: arm_scmi: add basic driver infrastructure for SCMISudeep Holla5-0/+768
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 <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-23firmware: arm_scpi: improve info message for pre-1.0 firmwareHeiner Kallweit1-6/+15
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 <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-23firmware: arm_scpi: use FIELD_GET/_PREP to simplify macro definitionsHeiner Kallweit1-23/+15
Macro definitions can be simplified by making use of the FIELD_GET/_PREP bitfield macros. Tested-by: Kevin Hilman <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-23firmware: arm_scpi: remove struct sensor_capabilitiesHeiner Kallweit1-8/+4
One more single-element struct was left, remove it. Tested-by: Kevin Hilman <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-23firmware: arm_scpi: fix incorrect __iomem accesses using correct accessorsHeiner Kallweit1-8/+9
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 <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> [Sudeep Holla: changed the patch title to describe the change] Signed-off-by: Sudeep Holla <[email protected]>
2018-02-23firmware: arm_scpi: remove all single element structuresSudeep Holla1-15/+7
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 <[email protected]> Reviewed-by: Heiner Kallweit <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-23firmware: arm_scpi: drop unnecessary type cast to scpi_shared_memSudeep Holla1-1/+1
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 <[email protected]> Reviewed-by: Heiner Kallweit <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-23firmware: arm_scpi: improve struct sensor_valueHeiner Kallweit1-7/+5
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 <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-23firmware: arm_scpi: improve handling of protocol and firmware version subfieldsHeiner Kallweit1-24/+19
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 <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-23firmware: arm_scpi: improve struct dvfs_info to make code better readableHeiner Kallweit1-8/+5
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 <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2018-02-23firmware: arm_scpi: make scpi_probe completely device-managedHeiner Kallweit1-8/+2
Replace two remaining functions in probe with their devm versions. Tested-by: Kevin Hilman <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.