- 22 Jan, 2019 40 commits
-
-
Logan Gunthorpe authored
Add support for io{read|write}64() functions in parisc architecture. These are pretty straightforward copies of similar functions which make use of readq and writeq. Also, indicate that the lo_hi and hi_lo variants of these functions are not provided by this architecture. Signed-off-by:Logan Gunthorpe <logang@deltatee.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by:
Helge Deller <deller@gmx.de> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Logan Gunthorpe authored
Fix an asymmetry in the io{read|write}XXbe functions in that the big-endian variants make use of the raw io accessors while the little-endian variants use the regular accessors. Some architectures implement barriers to order against both spinlocks and DMA accesses and for these case, the big-endian variant of the API would not be protected. Thus, change the mmio_XXXXbe macros to use the appropriate swab() function wrapping the regular accessor. This is similar to what was done for PIO. When this code was originally written, barriers in the IO accessors were not common and the accessors simply wrapped the raw functions in a conversion to CPU endianness. Since then, barriers have been added in some architectures and are now missing in the big endian variant of the API. This also manages to silence a few sparse warnings that check for using the correct endian types which the original code did not annotate correctly. Signed-off-by: -
Georgi Djakov authored
When consumers report their bandwidth needs with icc_set_bw(), it's possible that the requested amount of bandwidth is not available or just the new configuration fails to apply on some path. In this case revert to the previous configuration and propagate the error back to the consumers to let them know that bandwidth is not available, hardware is busy or whatever error is returned by the interconnect platform driver. Signed-off-by:
Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by:
-
Georgi Djakov authored
Add myself as the maintainer of the interconnect API. Signed-off-by:
-
David Dai authored
Add RSC (Resource State Coordinator) provider dictating network-on-chip interconnect bus performance found on SDM845-based platforms. Signed-off-by:
David Dai <daidavid1@codeaurora.org> Signed-off-by:
-
David Dai authored
Introduce Qualcomm SDM845 specific provider driver using the interconnect framework. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Georgi Djakov authored
Add a functionality to provide information about the current constraints per each node and provider. Reviewed-by:
Evan Green <evgreen@chromium.org> Signed-off-by:
-
Georgi Djakov authored
Currently we support only platform data for specifying the interconnect endpoints. As now the endpoints are hard-coded into the consumer driver this may lead to complications when a single driver is used by multiple SoCs, which may have different interconnect topology. To avoid cluttering the consumer drivers, introduce a translation function to help us get the board specific interconnect data from device-tree. Reviewed-by:
-
Georgi Djakov authored
This binding is intended to represent the relations between interconnect controllers (providers) and consumer device nodes. It will allow creating links between consumers and interconnect paths (exposed by interconnect providers). Reviewed-by:
-
Georgi Djakov authored
This patch introduces a new API to get requirements and configure the interconnect buses across the entire chipset to fit with the current demand. The API is using a consumer/provider-based model, where the providers are the interconnect buses and the consumers could be various drivers. The consumers request interconnect resources (path) between endpoints and set the desired constraints on this data flow path. The providers receive requests from consumers and aggregate these requests for all master-slave pairs on that path. Then the providers configure each node along the path to support a bandwidth that satisfies all bandwidth requests that cross through that node. The topology could be complicated and multi-tiered and is SoC specific. Reviewed-by:
-
Alexander Kapshuk authored
The regular expression that matches the version number of a utility being queried is used as a constant expression in the current implementation. Assigning the RE in question to a variable gives it a meaningful name that clearly expresses the intended use of the expression without having to think about the details of implementation. Signed-off-by:
Alexander Kapshuk <alexander.kapshuk@gmail.com> Signed-off-by:
-
Gustavo A. R. Silva authored
IndexCard is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/char/applicom.c:418 ac_write() warn: potential spectre issue 'apbs' [r] drivers/char/applicom.c:728 ac_ioctl() warn: potential spectre issue 'apbs' [r] (local cap) Fix this by sanitizing IndexCard before using it to index apbs. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Buland Singh authored
Commit '3d035f58 ("drivers/char/hpet.c: allow user controlled mmap for user processes")' introduced a new kernel command line parameter hpet_mmap, that is required to expose the memory map of the HPET registers to user-space. Unfortunately the kernel command line parameter 'hpet_mmap' is broken and never takes effect due to missing '=' character in the __setup() code of hpet_mmap_enable. Before this patch: dmesg output with the kernel command line parameter hpet_mmap=1 [ 0.204152] HPET mmap disabled dmesg output with the kernel command line parameter hpet_mmap=0 [ 0.204192] HPET mmap disabled After this patch: dmesg output with the kernel command line parameter hpet_mmap=1 [ 0.203945] HPET mmap enabled dmesg output with the kernel command line parameter hpet_mmap=0 [ 0.204652] HPET mmap disabled Fixes: 3d035f58 ("drivers/char/hpet.c: allow user controlled mmap for user processes") Signed-off-by:
Buland Singh <bsingh@redhat.com> Signed-off-by:
-
Srinivas Kandagatla authored
Add missing spin lock intialization this also fixes the spinlock bad magic warning. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Srinivas Kandagatla authored
use slim_device_update_status() instead of directly calling the device_status() callback. Move slim_device_update_status() before probe to avoid forward declaration too. Signed-off-by:
-
Srinivas Kandagatla authored
Calling device_status callback under a lock would prevent drivers to do any slimbus trasactions which would invoke this lock like get_laddr(). Remove this unnecessary lock! Signed-off-by:
-
Srinivas Kandagatla authored
match full slim device id instead of just product and manufacture code, this will allow drivers to be much more specific to that device. Signed-off-by:
-
Naveen Kumar Parna authored
There is no advantage to keep 'struct file_operations.open & .close' API's. So removed the unnecessary code efi_rtc_open & efi_rtc_close. Signed-off-by:
Naveen Kumar Parna <parna.naveenkumar@gmail.com> Signed-off-by:
-
Chengguang Xu authored
It is not necessary to check idev->info several times under mutex lock, so just remove redundant check. Signed-off-by:
Chengguang Xu <cgxu519@gmx.com> Signed-off-by:
-
Chengguang Xu authored
Should jump to lable err_infoopen when idev->info is NULL in uio_open(). Signed-off-by:
-
Roman Kiryanov authored
prefer 'help' over '---help---' for new help texts Signed-off-by:
Roman Kiryanov <rkir@google.com> Signed-off-by:
-
Vincent Whitchurch authored
This is needed, for example, for VIRTIO_F_IOMMU_PLATFORM. Signed-off-by:
Vincent Whitchurch <vincent.whitchurch@axis.com> Signed-off-by:
-
Vincent Whitchurch authored
Fallback gracefully if no DMA channel is provided instead of dereferencing NULL pointers. Signed-off-by:
-
Vincent Whitchurch authored
Include <linux/io-64-nonatomic-lo-hi.h> so that readq/writeq are replaced by two readl/writel on systems that do not support them. The values read/written are pointers which will be 32-bit on 32-bit systems so the non-atomicity should not matter. Signed-off-by:
-
Vincent Whitchurch authored
Fixes these kind of errors on 32-bit: drivers/misc/mic/vop/vop_vringh.c:590:3: error: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type 'size_t {aka unsigned int}' [-Werror=format=] Signed-off-by: -
Finn Thain authored
Adopt nvram module to reduce code duplication. This means CONFIG_NVRAM becomes available to PPC64 builds. Previously it was only available to PPC32 builds because it depended on CONFIG_GENERIC_NVRAM. The IOC_NVRAM_GET_OFFSET ioctl as implemented on PPC64 validates the offset returned by pmac_get_partition(). Do the same in the nvram module. Note that the old PPC32 generic_nvram module lacked this test. So when CONFIG_PPC32 && CONFIG_PPC_PMAC, the IOC_NVRAM_GET_OFFSET ioctl would have returned 0 (always). But when CONFIG_PPC64 && CONFIG_PPC_PMAC, the IOC_NVRAM_GET_OFFSET ioctl would have returned -1 (which is -EPERM) when the requested partition was not found. With this patch, the result is now -EINVAL on both PPC32 and PPC64 when the requested PowerMac NVRAM partition is not found. This is a userspace- visible change, in the non-existent partition case, which would be in an error path for an IOC_NVRAM_GET_OFFSET ioctl syscall. Tested-by:
Stan Johnson <userm57@yahoo.com> Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
-
Finn Thain authored
Signed-off-by:
-
Finn Thain authored
Switch PPC32 kernels from the generic_nvram module to the nvram module. Also fix a theoretical bug where CHRP omits the chrp_nvram_init() call when CONFIG_NVRAM_MODULE=m. Tested-by:
-
Finn Thain authored
This patch addresses inconsistencies in Mac framebuffer drivers and their use of Kconfig symbols relating to NVRAM, so PPC64 can use CONFIG_NVRAM. The defined(CONFIG_NVRAM) condition is replaced with the weaker IS_REACHABLE(CONFIG_NVRAM) condition, like atari_scsi. Macintosh framebuffer drivers use default settings for color mode and video mode that are found in NVRAM. On PCI Macs, MacOS stores display settings in the Name Registry (NR) partition in NVRAM*. On NuBus Macs, there is no NR partition and MacOS stores display mode settings in PRAM**. Early-model Macs are the ones most likely to benefit from these settings, since they are more likely to have a fixed-frequency monitor connected to the built-in framebuffer device. Moreover, a single NV_CMODE value and a single NV_VMODE value provide for only one display. The NV_CMODE and NV_VMODE constants are apparently offsets into the NR partition for Old World machines. This also suggests that these defaults are not useful on later models. The NR partition seems to be optional on New World machines. CONFIG_NVRAM cannot be enabled on PPC64 at present. It is safe to say that NVRAM support in PowerMac fbdev drivers is only applicable to CONFIG_PPC32 so make this condition explicit. This means matroxfb driver won't crash on PPC64 when CONFIG_NVRAM becomes available there. For imsttfb, add the missing CONFIG_NVRAM test to prevent a build failure, since PPC64 does not implement nvram_read_byte(). Also add a missing machine_is(powermac) check. Change the inconsistent dependency on CONFIG_PPC and the matching #ifdef tests to CONFIG_PPC_PMAC. For valkyriefb, to improve clarity and consistency with the other PowerMac fbdev drivers, test for CONFIG_PPC_PMAC instead of !CONFIG_MAC. Remove a bogus comment regarding PRAM. * See GetPreferredConfiguration and SavePreferredConfiguration in "Designing PCI Cards and Drivers for Power Macintosh Computers". ** See SetDefaultMode and GetDefaultMode in "Designing Cards and Drivers for the Macintosh Family". Signed-off-by:
-
Finn Thain authored
Add the powerpc-specific ioctls to the nvram module. This allows the nvram module to replace the generic_nvram module. Tested-by:
-
Finn Thain authored
Add the nvram_size() function to those PowerPC platforms that don't already have one: CHRP and PowerMac. This means that the ppc_md.nvram_size() function can be called by nvram_get_size(). Since we are addressing CHRP inconsistencies here, rename chrp_nvram_read and chrp_nvram_write, which break the naming convention used across powerpc platforms for NVRAM accessor functions. Tested-by:
-
Finn Thain authored
Signed-off-by:
-
Finn Thain authored
A multi-platform kernel binary has to decide at run-time how to dispatch the arch_nvram_ops calls. Add a platform-independent arch_nvram_ops struct for this, to replace the atari-specific one. Enable CONFIG_HAVE_ARCH_NVRAM_OPS for Macs. Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Tested-by:
-
Finn Thain authored
Certain Cuda transfers have to be ended by the driver. According to Apple's open source Cuda driver, as found in mkLinux and XNU, this applies to any "open ended request such as PRAM read". This fixes an infinite polling loop in cuda_pram_read_byte(). Tested-by:
-
Finn Thain authored
PMU-based m68k Macs pre-date PowerMac-style NVRAM. Use the appropriate PMU commands. Also implement the missing XPRAM accessors for VIA-based Macs. Acked-by:
-
Finn Thain authored
This is intended to improve code style and not affect code behaviour. Acked-by:
-
Finn Thain authored
Adopt the existing *_read_byte and *_write_byte naming convention. Rename via_pram_readbyte and via_pram_writebyte to avoid confusion. Adjust calling conventions of mac_pram_* functions to match the struct nvram_ops methods. Acked-by:
-
Finn Thain authored
Atari RTC NVRAM uses a checksum so implement the remaining arch_nvram_ops methods for the set_checksum and initialize ioctls. Enable CONFIG_HAVE_ARCH_NVRAM_OPS. Acked-by:
-
Finn Thain authored
Refactor the RTC "CMOS" NVRAM functions so that they can be used as arch_nvram_ops methods. Checksumming logic is moved from the misc device operations to the nvram read/write operations. This makes the misc device implementation more generic. This preserves the locking mechanism such that "read if checksum valid" and "write and update checksum" remain atomic operations. Some platforms implement byte-range read/write methods which are similar to file_operations struct methods. Other platforms provide only byte-at-a-time methods. The former are more efficient but may be unavailable so fall back on the latter methods when necessary. Tested-by:
-
Finn Thain authored
The drivers/char/nvram.c module has previously supported only RTC "CMOS" NVRAM, for which it provides appropriate checksum ioctls. Make these ioctls optional so the module can be re-used with other kinds of NVRAM. The ops struct methods that implement the ioctls now return error codes so that a multi-platform kernel binary can do the right thing when running on hardware without a suitable NVRAM. Signed-off-by:
-
