summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-11-21KVM: x86: create mmu/ subdirectoryPaolo Bonzini
Preparatory work for shattering mmu.c into multiple files. Besides making it easier to follow, this will also make it possible to write unit tests for various parts. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-21KVM: nVMX: Remove unnecessary TLB flushes on L1<->L2 switches when L1 use ↵Liran Alon
apic-access-page According to Intel SDM section 28.3.3.3/28.3.3.4 Guidelines for Use of the INVVPID/INVEPT Instruction, the hypervisor needs to execute INVVPID/INVEPT X in case CPU executes VMEntry with VPID/EPTP X and either: "Virtualize APIC accesses" VM-execution control was changed from 0 to 1, OR the value of apic_access_page was changed. In the nested case, the burden falls on L1, unless L0 enables EPT in vmcs02 but L1 enables neither EPT nor VPID in vmcs12. For this reason prepare_vmcs02() and load_vmcs12_host_state() have special code to request a TLB flush in case L1 does not use EPT but it uses "virtualize APIC accesses". This special case however is not necessary. On a nested vmentry the physical TLB will already be flushed except if all the following apply: * L0 uses VPID * L1 uses VPID * L0 can guarantee TLB entries populated while running L1 are tagged differently than TLB entries populated while running L2. If the first condition is false, the processor will flush the TLB on vmentry to L2. If the second or third condition are false, prepare_vmcs02() will request KVM_REQ_TLB_FLUSH. However, even if both are true, no extra TLB flush is needed to handle the APIC access page: * if L1 doesn't use VPID, the second condition doesn't hold and the TLB will be flushed anyway. * if L1 uses VPID, it has to flush the TLB itself with INVVPID and section 28.3.3.3 doesn't apply to L0. * even INVEPT is not needed because, if L0 uses EPT, it uses different EPTP when running L2 than L1 (because guest_mode is part of mmu-role). In this case SDM section 28.3.3.4 doesn't apply. Similarly, examining nested_vmx_vmexit()->load_vmcs12_host_state(), one could note that L0 won't flush TLB only in cases where SDM sections 28.3.3.3 and 28.3.3.4 don't apply. In particular, if L0 uses different VPIDs for L1 and L2 (i.e. vmx->vpid != vmx->nested.vpid02), section 28.3.3.3 doesn't apply. Thus, remove this flush from prepare_vmcs02() and nested_vmx_vmexit(). Side-note: This patch can be viewed as removing parts of commit fb6c81984313 ("kvm: vmx: Flush TLB when the APIC-access address changes”) that is not relevant anymore since commit 1313cc2bd8f6 ("kvm: mmu: Add guest_mode to kvm_mmu_page_role”). i.e. The first commit assumes that if L0 use EPT and L1 doesn’t use EPT, then L0 will use same EPTP for both L0 and L1. Which indeed required L0 to execute INVEPT before entering L2 guest. This assumption is not true anymore since when guest_mode was added to mmu-role. Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-21KVM: x86: remove set but not used variable 'called'Mao Wenan
Fixes gcc '-Wunused-but-set-variable' warning: arch/x86/kvm/x86.c: In function kvm_make_scan_ioapic_request_mask: arch/x86/kvm/x86.c:7911:7: warning: variable called set but not used [-Wunused-but-set-variable] It is not used since commit 7ee30bc132c6 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs") Signed-off-by: Mao Wenan <maowenan@huawei.com> Fixes: 7ee30bc132c6 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs") Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-21KVM: nVMX: Do not mark vmcs02->apic_access_page as dirty when unpinningLiran Alon
vmcs->apic_access_page is simply a token that the hypervisor puts into the PFN of a 4KB EPTE (or PTE if using shadow-paging) that triggers APIC-access VMExit or APIC virtualization logic whenever a CPU running in VMX non-root mode read/write from/to this PFN. As every write either triggers an APIC-access VMExit or write is performed on vmcs->virtual_apic_page, the PFN pointed to by vmcs->apic_access_page should never actually be touched by CPU. Therefore, there is no need to mark vmcs02->apic_access_page as dirty after unpin it on L2->L1 emulated VMExit or when L1 exit VMX operation. Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-21Merge branch 'kvm-tsx-ctrl' into HEADPaolo Bonzini
Conflicts: arch/x86/kvm/vmx/vmx.c
2019-11-21Merge tag 'tag-ib-chrome-mfd-iio-input-5.5' into chrome-platform-5.5Enric Balletbo i Serra
IB between mfd, iio, input and chrome platform for cros-ec-sensorhub Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21gfs2: Don't write log headers after file system withdrawBob Peterson
Before this patch, when a node withdrew a gfs2 file system, it wrote a (clean) unmount log header. That's wrong. You don't want to write anything to the journal once you're withdrawn because that's acknowledging that the transaction is complete and the journal is in good shape, neither of which may be a valid assumption when the file system is withdrawn. This is especially true if the withdraw was caused due to io errors writing to the journal in the first place. The best course of action is to leave the journal "as is" until it may be safely replayed during journal recovery, regardless of whether it's done by this node or another. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2019-11-21gfs2: Remove duplicate call from gfs2_create_inodeAndreas Gruenbacher
In gfs2_create_inode, gfs2_set_inode_blocks is called twice for no good reason. Remove the unnecessary call. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2019-11-21Revert "Input: cros_ec_keyb: mask out extra flags in event_type"Gwendal Grignou
This reverts commit d096aa3eb6045a6a475a0239f3471c59eedf3d61. This patch is not needed anymore since we clear EC_MKBP_HAS_MORE_EVENTS flag before calling the notifiers in patch "9d9518f5b52a (platform: chrome: cros_ec: handle MKBP more events flag)" Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21Revert "Input: cros_ec_keyb - add back missing mask for event_type"Gwendal Grignou
This reverts commit 62c3801619e16b68a37ea899b76572145dfe41c9. This patch is not needed anymore since we clear EC_MKBP_HAS_MORE_EVENTS flag before calling the notifiers in patch "9d9518f5b52a (platform: chrome: cros_ec: handle MKBP more events flag)" Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21platform/chrome: cros_ec: handle MKBP more events flagEnrico Granata
The ChromeOS EC has support for signaling to the host that a single IRQ can serve multiple MKBP (Matrix KeyBoard Protocol) events. Doing this serves an optimization purpose, as it minimizes the number of round-trips into the interrupt handling machinery, and it proves beneficial to sensor timestamping as it keeps the desired synchronization of event times between the two processors. This patch adds kernel support for this EC feature, allowing the ec_irq to loop until all events have been served. Signed-off-by: Enrico Granata <egranata@chromium.org> Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21platform/chrome: cros_ec: Do not attempt to register a non-positive IRQ numberGwendal Grignou
Add a layer of sanity checking to cros_ec_register against attempting to register IRQ values that are not strictly greater than 0. Signed-off-by: Enrico Granata <egranata@chromium.org> Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21platform/chrome: cros-ec: Record event timestamp in the hard irqGwendal Grignou
To improve sensor timestamp precision, given EC and AP are in different time domains, the AP needs to try to record the exact moment an event was signalled to the AP by the EC as soon as possible after it happens. First thing in the hard irq is the best place for this. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@kernel.org> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21mfd / platform / iio: cros_ec: Register sensor through sensorhubGwendal Grignou
Remove the duplicated code in MFD, since MFD just registers cros-ec-sensorhub if at least one sensor is present. Change IIO cros-ec driver to get the pointer to the cros-ec-dev through cros-ec-sensorhub. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21iio / platform: cros_ec: Add cros-ec-sensorhub driverGwendal Grignou
Similar to HID sensor stack, the new driver sits between cros-ec-dev and the IIO device drivers: The EC based IIO device topology would be: iio:device1 -> ...0/0000:00:1f.0/PNP0C09:00/GOOG0004:00/cros-ec-dev.6.auto/ cros-ec-sensorhub.7.auto/ cros-ec-accel.15.auto/ iio:device1 It will be expanded to control EC sensor FIFO. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> [Fix "unknown type name 'uint32_t'" type errors] Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21mfd / platform: cros_ec: Add sensor_count and make check_features publicGwendal Grignou
Add a new function to return the number of MEMS sensors available in a ChromeOS Embedded Controller. It uses MOTIONSENSE_CMD_DUMP if available or a specific memory map ACPI registers to find out. Also, make check_features public as it can be useful for other drivers to know what the Embedded Controller supports. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21platform/chrome: cros_ec: Put docs with the codeGwendal Grignou
To avoid doc rot, put function documentations with code, not header. Use kernel-doc style comments for exported functions. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21MAINTAINERS: add nds32 maintainerGreentime Hu
Nick implements many features of nds32 such as perf, power management and unaligned access handler. Let's add him as a maintainer. Signed-off-by: Greentime Hu <green.hu@gmail.com>
2019-11-21habanalabs: add more protection of device during resetOded Gabbay
Prevent accesses to the device (register read/write) from debugfs entries during reset as that can cause the device to get stuck. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Tomer Tayar <ttayar@habana.ai>
2019-11-21habanalabs: flush EQ workers in hard resetOded Gabbay
During hard-reset, there can be multiple events received from the H/W. For each event, the driver opens a worker thread to handle it. For some of the events, the driver will read/write registers in the code that handles the event. In case of hard-reset, we must prevent reads/writes to the registers during the reset operation because the device might get stuck if that happens. Therefore, flush the EQ workers before resetting the device (in hard-reset only). Additional events won't arrive as we synced and disabled the interrupts. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Tomer Tayar <ttayar@habana.ai>
2019-11-21habanalabs: make the reset code more consistentOded Gabbay
In the hl_device_reset we ask about the hard_reset argument when we want to differentiate between soft and hard reset, except for three places where we use "from_hard_reset_thread". Replace one of those locations with the hard_reset argument as it is guaranteed that if we reached to that line in the code during hard_reset, it is from a kernel thread. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Tomer Tayar <ttayar@habana.ai>
2019-11-21habanalabs: expose reset counters via existing INFO IOCTLMoti Haimovski
Expose both soft and hard reset counts via INFO IOCTL. This will allow system management applications to easily check if the device has undergone reset. Signed-off-by: Moti Haimovski <mhaimovski@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: make code more conciseOded Gabbay
Instead of doing if inside if, just write them with && operator. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Omer Shpigelman <oshpigelman@habana.ai>
2019-11-21habanalabs: use defines for F/W filesOded Gabbay
Make the code more concise and maintainable by using defines for the F/W files. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Omer Shpigelman <oshpigelman@habana.ai>
2019-11-21habanalabs: remove prints on successful device initializationOded Gabbay
Successful device initialization is mentioned in kernel log with the message "Successfully added device to habanalabs driver". There is no point of spamming the log with additional messages about successful queue testing, which are implied by the above mentioned message. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Omer Shpigelman <oshpigelman@habana.ai>
2019-11-21habanalabs: remove unnecessary checksOmer Shpigelman
Now that the VA block free list is not updated on context close in order to optimize this flow, no need in the sanity checks of the list contents as these will fail for sure. In addition, remove the "context closing with VA in use" print during hard reset as this situation is a side effect of the failure that caused the hard reset. Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: invalidate MMU cache only onceOmer Shpigelman
Reduce context close time by performing MMU cache invalidation once at the end of the unmap loop rather in each iteration, in order to avoid hard reset with open contexts. Reset with open contexts can potentially lead to a kernel crash as the generic pool of the MMU hops is destroyed while it is not empty because some unmap operations are not done. The commit affect mainly when running on simulator. Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: skip VA block list update in reset flowOmer Shpigelman
Reduce context close time by skipping the VA block free list update in order to avoid hard reset with open contexts. Reset with open contexts can potentially lead to a kernel crash as the generic pool of the MMU hops is destroyed while it is not empty because some unmap operations are not done. The commit affect mainly when running on simulator. Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: optimize MMU unmapOmer Shpigelman
Reduce context close time by skipping hash table lookup if possible in order to avoid hard reset with open contexts. Reset with open contexts can potentially lead to a kernel crash as the generic pool of the MMU hops is destroyed while it is not empty because some unmap operations are not done. This commit affect mainly when running on simulator. Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: prevent read/write from/to the device during hard resetOmer Shpigelman
During hard reset we should not access the device except of necessary reset operations because the device might be stuck or unresponsive. Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: split MMU properties to PCI/DRAMOmer Shpigelman
Split the properties used for MMU mappings to DRAM and PCI (host) types. This is a prerequisite for future ASICs support. Note that in Goya ASIC, the PMMU and DMMU are the same (except of page sizes) as only one MMU mechanism is used for both of the mapping types. Hence this patch should not have any effect on current behavior. Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: re-factor MMU masks and documentationOmer Shpigelman
Some cosmetics around the MMU code to make it more self-explanatory. Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: type specific MMU cache invalidationOmer Shpigelman
Add the ability to invalidate the necessary MMU cache only. This ability is a prerequisite for future ASICs support. Note that in Goya ASIC, a single cache is used for both host/DRAM mappings and hence this patch should not have any effect on current behavior. Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: re-factor memory module codeOmer Shpigelman
Some of the functions in the memory module code were too long and/or contained multiple operations that are not always done together. Re-factor the code by dividing those functions to smaller functions which are more readable and maintainable. Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: export uapi defines to user-spaceOded Gabbay
The two defines that control the maximum size of a command buffer and the maximum number of JOBS per CS need to be exported to the user as they are part of the API towards user-space. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Omer Shpigelman <oshpigelman@habana.ai>
2019-11-21habanalabs: don't print error when queues are fullOded Gabbay
If the queues are full and we return -EAGAIN to the user, there is no need to print an error, as that case isn't an error and the user is expected to re-submit the work. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Omer Shpigelman <oshpigelman@habana.ai>
2019-11-21habanalabs: increase max jobs number to 512Oded Gabbay
In training, there is a need for a large amount of patching to the recipe. This results in many command buffers contains a lot of DMA packets. The number of command buffers per CS is larger than the current maximum of 64, which is an arbitrary number that is enough for inference, but it has no real affect on the code and/or resources of the host machine. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Omer Shpigelman <oshpigelman@habana.ai>
2019-11-21habanalabs: set ETR as non-securedOded Gabbay
ETR should always be non-secured as it is used by the users to record profiling/trace data. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Omer Shpigelman <oshpigelman@habana.ai>
2019-11-21habanalabs: use registers name defines for ETR blockOded Gabbay
We have a single ETR block in the SOC, so use explicit register name defines for initializing this block. This makes it more readable and maintainable. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Omer Shpigelman <oshpigelman@habana.ai>
2019-11-21habanalabs: read F/W versions before failureOded Gabbay
Move the read of the F/W boot versions before exiting on possible failures of the F/W boot. This will help debug boot failures as we will be able to know the F/W boot version. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Omer Shpigelman <oshpigelman@habana.ai>
2019-11-21habanalabs: expose card name in INFO IOCTLOded Gabbay
To enable userspace processes, e.g. management utilities, to display the card name to the user, add the card name property to the HW_IP structure that is copied to the user in the INFO IOCTL. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: remove set but not used variable 'qman_base_addr'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/misc/habanalabs/goya/goya.c: In function 'goya_init_mme_cmdq': drivers/misc/habanalabs/goya/goya.c:1536:6: warning: variable 'qman_base_addr' set but not used [-Wunused-but-set-variable] It is never used, so can be removed. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: add opcode to INFO IOCTL to return clock rateOded Gabbay
Add a new opcode to the INFO IOCTL to allow the user application to retrieve the ASIC's current and maximum clock rate. The rate is returned in MHz. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Tomer Tayar <ttayar@habana.ai>
2019-11-21habanalabs: set TPC Icache to 16 cache linesOded Gabbay
Reduce latency to memory during TPC kernel execution. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Reviewed-by: Tomer Tayar <ttayar@habana.ai>
2019-11-21habanalabs: Add a new H/W queue typeTomer Tayar
This patch adds a support for a new H/W queue type. This type of queue is for DMA and compute engines jobs, for which completion notification are sent by H/W. Command buffer for this queue can be created either through the CB IOCTL and using the retrieved CB handle, or by preparing a buffer on the host or device SRAM/DRAM, and using the device address to that buffer. The patch includes the handling of the 2 options, as well as the initialization of the H/W queue and its jobs scheduling. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: Mark queue as expecting CB handle or addressTomer Tayar
Jobs on some queues must be provided with a handle to a driver command buffer object, while for other queues, jobs must be provided with an address to a command buffer. Currently the distinction is done based on the queue type, which is less flexible if the same queue type behaves differently on different types of ASICs. This patch adds a new queue property for this target, which is configured per queue type per ASIC type. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: Fix typosTomer Tayar
s/paerser/parser/ s/requeusted/requested/ s/an JOB/a JOB/ Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: remove set but not used variable 'ctx'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/misc/habanalabs/device.c: In function hpriv_release: drivers/misc/habanalabs/device.c:45:17: warning: variable ctx set but not used [-Wunused-but-set-variable] It is never used since commit eb7caf84b029 ("habanalabs: maintain a list of file private data objects") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21habanalabs: handle F/W failure for sensor initializationOded Gabbay
In case the F/W fails to initialize the thermal sensors, print an appropriate error message to kernel log and fail the device initialization. Reviewed-by: Tomer Tayar <ttayar@habana.ai> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2019-11-21afs: xattr: use scnprintfMark Salyzyn
sprintf and snprintf are fragile in future maintenance, switch to using scnprintf to ensure no accidental Use After Free conditions are introduced. Signed-off-by: Mark Salyzyn <salyzyn@android.com> Cc: linux-kernel@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: David Howells <dhowells@redhat.com> Cc: linux-afs@lists.infradead.org Cc: Jan Kara <jack@suse.cz> Signed-off-by: David Howells <dhowells@redhat.com>