summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2019-02-22Merge tag 'kvm-s390-next-5.1-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-next KVM: s390: Features for 5.1 - Clarify KVM related kernel messages - Interrupt cleanup - Introduction of the Guest Information Block (GIB) - Preparation for processor subfunctions in cpu model
2019-02-22IB/mlx4: Increase the timeout for CM cacheHåkon Bugge
Using CX-3 virtual functions, either from a bare-metal machine or pass-through from a VM, MAD packets are proxied through the PF driver. Since the VF drivers have separate name spaces for MAD Transaction Ids (TIDs), the PF driver has to re-map the TIDs and keep the book keeping in a cache. Following the RDMA Connection Manager (CM) protocol, it is clear when an entry has to evicted form the cache. But life is not perfect, remote peers may die or be rebooted. Hence, it's a timeout to wipe out a cache entry, when the PF driver assumes the remote peer has gone. During workloads where a high number of QPs are destroyed concurrently, excessive amount of CM DREQ retries has been observed The problem can be demonstrated in a bare-metal environment, where two nodes have instantiated 8 VFs each. This using dual ported HCAs, so we have 16 vPorts per physical server. 64 processes are associated with each vPort and creates and destroys one QP for each of the remote 64 processes. That is, 1024 QPs per vPort, all in all 16K QPs. The QPs are created/destroyed using the CM. When tearing down these 16K QPs, excessive CM DREQ retries (and duplicates) are observed. With some cat/paste/awk wizardry on the infiniband_cm sysfs, we observe as sum of the 16 vPorts on one of the nodes: cm_rx_duplicates: dreq 2102 cm_rx_msgs: drep 1989 dreq 6195 rep 3968 req 4224 rtu 4224 cm_tx_msgs: drep 4093 dreq 27568 rep 4224 req 3968 rtu 3968 cm_tx_retries: dreq 23469 Note that the active/passive side is equally distributed between the two nodes. Enabling pr_debug in cm.c gives tons of: [171778.814239] <mlx4_ib> mlx4_ib_multiplex_cm_handler: id{slave: 1,sl_cm_id: 0xd393089f} is NULL! By increasing the CM_CLEANUP_CACHE_TIMEOUT from 5 to 30 seconds, the tear-down phase of the application is reduced from approximately 90 to 50 seconds. Retries/duplicates are also significantly reduced: cm_rx_duplicates: dreq 2460 [] cm_tx_retries: dreq 3010 req 47 Increasing the timeout further didn't help, as these duplicates and retries stems from a too short CMA timeout, which was 20 (~4 seconds) on the systems. By increasing the CMA timeout to 22 (~17 seconds), the numbers fell down to about 10 for both of them. Adjustment of the CMA timeout is not part of this commit. Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com> Acked-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-02-22x86: pcengines apuv2 gpio/leds/keys platform driverEnrico Weigelt, metux IT consult
Driver for PCengines APUv2 board's front LEDs and Button, which are attached to AMD PCH GPIOs. Due to lack of dedicated ACPI entry, detecting the board via DMI. Cc: linux-gpio@vger.kernel.org Cc: linus.walleij@linaro.org Cc: bgolaszewski@baylibre.com Cc: dvhart@infradead.org Cc: platform-driver-x86@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-22gpio: AMD G-Series PCH gpio driverEnrico Weigelt, metux IT consult
GPIO platform driver for the AMD G-series PCH (eg. on GX-412TC) This driver doesn't registers itself automatically, as it needs to be provided with platform specific configuration, provided by some board driver setup code. Didn't implement oftree probing yet, as it's rarely found on x86. Cc: linux-gpio@vger.kernel.org Cc: linus.walleij@linaro.org Cc: bgolaszewski@baylibre.com Cc: dvhart@infradead.org Cc: platform-driver-x86@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-22spi: sifive: Remove redundant dev_err call in sifive_spi_probe()Wei Yongjun
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-02-22spi: sifive: Remove spi_master_put in sifive_spi_remove()Wei Yongjun
The call to spi_master_put() in sifive_spi_remove() is redundant since the master is registered using devm_spi_register_master() and no reference hold by using spi_master_get() in sifive_spi_remove(). This is detected by Coccinelle semantic patch. Fixes: 484a9a68d669 ("spi: sifive: Add driver for the SiFive SPI controller") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-02-22regulator: da9063: Use struct_size() in devm_kzalloc()Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = alloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = alloc(struct_size(instance, entry, count), GFP_KERNEL) Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-02-22regulator: mt6311: Use linear instead of linear range for mt6311_buck_opsAxel Lin
Current code already set .min_uV and .uV_step fields and it actually can use regulator_list_voltage_linear. So remove buck_volt_range and use regulator_list_voltage_linear instead. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-02-22regulator: max77650: Fix set_current_limit implementationAxel Lin
Current code always return error, fix it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-02-22regulator: tps65218: Add support for LS2Christian Hohnstaedt
Re-use the "tps65218_pmic_*_current_limit()" functions of LS3 and calculate the different required bit-shift by counting the trailing 0s in "struct regulator_desc.csel_mask" Signed-off-by: Christian Hohnstaedt <Christian.Hohnstaedt@wago.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-02-22ipmi_si: Remove hacks for adding a dummy platform devicesCorey Minyard
All the IPMI address sources now supply a real device. This cheap hack is no longer necessary. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2019-02-22ipmi_si: Consolidate scanning the platform busCorey Minyard
The same basic code was in two places. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2019-02-22ipmi_si: Remove hotmod devices on removal and exitCorey Minyard
When a hotmod-added device is removed or when the module is removed, remove the platform devices that was created for it. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2019-02-22ipmi_si: Remove hardcode IPMI devices by scanning the platform busCorey Minyard
Instead of keeping track of each one, just scan the platform bus for hardcode devices and remove them. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2019-02-22ipmi_si: Switch hotmod to use a platform deviceCorey Minyard
Don't force the main code to create one for it. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2019-02-22ipmi: Consolidate the adding of platform devicesCorey Minyard
It was being done in two different places now that hard-coded devices use platform devices, and it's about to be three with hotmod switching to platform devices. So put the code in one place. This required some rework on some interfaces to make the type space clean. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2019-02-22ipmi_si: Rename addr_type to addr_space to match what it doesCorey Minyard
Make the naming consistent, and make the values an enum. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2019-02-22ipmi_si: Convert some types into unsignedCorey Minyard
Things dealing with registers and addresses are all unsigned, make them so. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2019-02-22ipmi_si: Fix crash when using hard-coded deviceCorey Minyard
When excuting a command like: modprobe ipmi_si ports=0xffc0e3 type=bt The system would get an oops. The trouble here is that ipmi_si_hardcode_find_bmc() is called before ipmi_si_platform_init(), but initialization of the hard-coded device creates an IPMI platform device, which won't be initialized yet. The real trouble is that hard-coded devices aren't created with any device, and the fixup is done later. So do it right, create the hard-coded devices as normal platform devices. This required adding some new resource types to the IPMI platform code for passing information required by the hard-coded device and adding some code to remove the hard-coded platform devices on module removal. To enforce the "hard-coded devices passed by the user take priority over firmware devices" rule, some special code was added to check and see if a hard-coded device already exists. Reported-by: Yang Yingliang <yangyingliang@huawei.com> Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Corey Minyard <cminyard@mvista.com> Tested-by: Yang Yingliang <yangyingliang@huawei.com>
2019-02-22Merge remote-tracking branch 'net-next/master' into mac80211-nextJohannes Berg
Merge net-next to resolve a conflict and to get the mac80211 rhashtable fixes so further patches can be applied on top. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-22mac80211: update HE IEs to D3.3Liad Kaufman
Update element names and new fields according to D3.3 of the HE spec. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-22mac80211_hwsim: propagate genlmsg_reply return codeLi RongQing
genlmsg_reply can fail, so propagate its return code Signed-off-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-22drm/i915/guc: Flush the residual log capture irq on disablingChris Wilson
As we disable the log capture events, flush any residual interrupt before we flush and disable the worker. v2: Mika pointed out that it wasn't the worker re-queueing itself, but a rogue irq. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109716 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221163833.21393-1-chris@chris-wilson.co.uk
2019-02-22drm/imx: only send commit done event when all state has been appliedLucas Stach
Currently there is a small race window where we could manage to arm the vblank event from atomic flush, but programming the hardware was too close to the frame end, so the hardware will only apply the current state on the next vblank. In this case we will send out the commit done event too early causing userspace to reuse framebuffes that are still in use. Instead of using the event arming mechnism, just remember the pending event and send it from the vblank IRQ handler, once we are sure that all state has been applied successfully. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> [p.zabel@pengutronix.de: inverted logic: done -> pending, added back spinlock in atomic_flush, commit message typo fix] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22drm/imx: allow building under COMPILE_TESTPhilipp Zabel
Allow to compile-test imx-drm on other platforms. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-22drm/imx: imx-tve: depend on COMMON_CLKPhilipp Zabel
Since the TVE provides a clock to the DI, the driver can only be compiled if the common clock framework is enabled. With the COMMON_CLK dependency in place, it will be possible to allow building the other parts of imx-drm under COMPILE_TEST on architectures that do not select the common clock framework. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-22drm/imx: ipuv3-plane: add zpos propertyPhilipp Zabel
Add a zpos property to planes. Call drm_atomic_helper_check() instead of calling drm_atomic_helper_check_modeset() and drm_atomic_check_planes() manually. This effectively adds a call to drm_atomic_normalize_zpos() before checking planes. Reorder atomic update to allow changing plane zpos without modeset. Note that the initial zpos is set in ipu_plane_state_reset(). The initial value set in ipu_plane_init() is just for show. The zpos parameter of drm_plane_create_zpos_property() is ignored because the newly created plane do not have state yet. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Marius Vlad <marius.vlad@collabora.com>
2019-02-22drm/imx: ipuv3-plane: add function to query atomic update statusLucas Stach
This function allows upper layer to check if a requested atomic update to the plane has been applied or is still pending. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> [p.zabel@pengutronix.de: inverted logic: done -> pending] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22gpu: ipu-v3: prg: add function to get channel configure statusLucas Stach
This allows channels using the PRG to check if a requested configuration update has been applied or is still pending. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> [p.zabel@pengutronix.de: inverted logic: done -> pending] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22gpu: ipu-v3: pre: add double buffer status readbackLucas Stach
This allows the upper layers to check if a double buffer update has been applied by the PRE or is still pending. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> [p.zabel@pengutronix.de: inverted logic: done -> pending] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22PCI: pci-bridge-emul: Extend pci_bridge_emul_init() with flagsThomas Petazzoni
Depending on the capabilities of the PCI controller/platform, the PCI-to-PCI bridge emulation behavior might need to be different. For example, on platforms that use the pci-mvebu code, we currently don't support prefetchable memory BARs, so the corresponding fields in the PCI-to-PCI bridge configuration space should be read-only. To implement this, extend pci_bridge_emul_init() to take a "flags" argument, with currently one flag supported: PCI_BRIDGE_EMUL_NO_PREFETCHABLE_BAR that will make the prefetchable memory base and limit registers read-only. The pci-mvebu and pci-aardvark drivers are updated accordingly. Fixes: 1f08673eef123 ("PCI: mvebu: Convert to PCI emulated bridge config space") Reported-by: Luís Mendes <luis.p.mendes@gmail.com> Reported-by: Leigh Brown <leigh@solinno.co.uk> Tested-by: Leigh Brown <leigh@solinno.co.uk> Tested-by: Luis Mendes <luis.p.mendes@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Cc: Luís Mendes <luis.p.mendes@gmail.com> Cc: Leigh Brown <leigh@solinno.co.uk>
2019-02-22PCI: pci-bridge-emul: Create per-bridge copy of register behaviorThomas Petazzoni
The behavior of the different registers of the PCI-to-PCI bridge is currently encoded in two global arrays, shared by all instances of PCI-to-PCI bridge emulation. However, we will need to tweak the behavior on a per-bridge basis, to accommodate for different capabilities of the platforms where this code is used. In preparation for this, create a per-bridge copy of the register behavior arrays, so that they can later be tweaked on a per-bridge basis. Fixes: 1f08673eef123 ("PCI: mvebu: Convert to PCI emulated bridge config space") Reported-by: Luís Mendes <luis.p.mendes@gmail.com> Reported-by: Leigh Brown <leigh@solinno.co.uk> Tested-by: Leigh Brown <leigh@solinno.co.uk> Tested-by: Luis Mendes <luis.p.mendes@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Cc: Luís Mendes <luis.p.mendes@gmail.com> Cc: Leigh Brown <leigh@solinno.co.uk>
2019-02-22irqchip/imx-irqsteer: Add multi output interrupts supportAisheng Dong
One irqsteer channel can support up to 8 output interrupts. Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-02-22irqchip/imx-irqsteer: Change to use reg_num instead of irq_groupAisheng Dong
One group can manage 64 interrupts by using two registers (e.g. STATUS/SET). However, the integrated irqsteer may support only 32 interrupts which needs only one register in a group. But the current driver assume there's a mininum of two registers in a group which result in a wrong register map for 32 interrupts per channel irqsteer. Let's use the reg_num caculated by interrupts per channel instead of irq_group to cover this case. Cc: Rob Herring <robh+dt@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-02-22Merge branch 'pm-cpufreq-fixes'Rafael J. Wysocki
* pm-cpufreq-fixes: cpufreq: scmi: Fix use-after-free in scmi_cpufreq_exit()
2019-02-22drivers: depend on HAS_IOMEM for devm_platform_ioremap_resource()Bartosz Golaszewski
We only build devm_ioremap_resource() if HAS_IOMEM is selected, so this dependency must cascade down to devm_platform_ioremap_resource(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-22usb: core: add option of only authorizing internal devicesDmitry Torokhov
On Chrome OS we want to use USBguard to potentially limit access to USB devices based on policy. We however to do not want to wait for userspace to come up before initializing fixed USB devices to not regress our boot times. This patch adds option to instruct the kernel to only authorize devices connected to the internal ports. Previously we could either authorize all or none (or, by default, we'd only authorize wired devices). The behavior is controlled via usbcore.authorized_default command line option. Signed-off-by: Dmitry Torokhov <dtor@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-22s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystemPierre Morel
Libudev relies on having a subsystem link for non-root devices. To avoid libudev (and potentially other userspace tools) choking on the matrix device let us introduce a matrix bus and with it the matrix bus subsytem. Also make the matrix device reside within the matrix bus. Doing this we remove the forced link from the matrix device to the vfio_ap driver and the device_type we do not need anymore. Since the associated matrix driver is not the vfio_ap driver any more, we have to change the search for the devices on the vfio_ap driver in the function vfio_ap_verify_queue_reserved. Fixes: 1fde573413b5 ("s390: vfio-ap: base implementation of VFIO AP device driver") Cc: stable@vger.kernel.org Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22clk: x86: Move clk-lpss.h to platform_data/x86Andy Shevchenko
clk-lpss.h is solely x86 related header. Move it to correct folder. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-22clk: fractional-divider: check parent rate only if flag is setKatsuhiro Suzuki
Custom approximation of fractional-divider may not need parent clock rate checking. For example Rockchip SoCs work fine using grand parent clock rate even if target rate is greater than parent. This patch checks parent clock rate only if CLK_SET_RATE_PARENT flag is set. For detailed example, clock tree of Rockchip I2S audio hardware. - Clock rate of CPLL is 1.2GHz, GPLL is 491.52MHz. - i2s1_div is integer divider can divide N (N is 1~128). Input clock is CPLL or GPLL. Initial divider value is N = 1. Ex) PLL = CPLL, N = 10, i2s1_div output rate is CPLL / 10 = 1.2GHz / 10 = 120MHz - i2s1_frac is fractional divider can divide input to x/y, x and y are 16bit integer. CPLL --> | selector | ---> i2s1_div -+--> | selector | --> I2S1 MCLK GPLL --> | | ,--------------' | | `--> i2s1_frac ---> | | Clock mux system try to choose suitable one from i2s1_div and i2s1_frac for master clock (MCLK) of I2S1. Bad scenario as follows: - Try to set MCLK to 8.192MHz (32kHz audio replay) Candidate setting is - i2s1_div: GPLL / 60 = 8.192MHz i2s1_div candidate is exactly same as target clock rate, so mux choose this clock source. i2s1_div output rate is changed 491.52MHz -> 8.192MHz - After that try to set to 11.2896MHz (44.1kHz audio replay) Candidate settings are - i2s1_div : CPLL / 107 = 11.214945MHz - i2s1_frac: i2s1_div = 8.192MHz This is because clk_fd_round_rate() thinks target rate (11.2896MHz) is higher than parent rate (i2s1_div = 8.192MHz) and returns parent clock rate. Above is current upstreamed behavior. Clock mux system choose i2s1_div, but this clock rate is not acceptable for I2S driver, so users cannot replay audio. Expected behavior is: - Try to set master clock to 11.2896MHz (44.1kHz audio replay) Candidate settings are - i2s1_div : CPLL / 107 = 11.214945MHz - i2s1_frac: i2s1_div * 147/6400 = 11.2896MHz Change i2s1_div to GPLL / 1 = 491.52MHz at same time. If apply this commit, clk_fd_round_rate() calls custom approximate function of Rockchip even if target rate is higher than parent. Custom function changes both grand parent (i2s1_div) and parent (i2s_frac) settings at same time. Clock mux system can choose i2s1_frac and audio works fine. Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Reviewed-by: Heiko Stuebner <heiko@sntech.de> [sboyd@kernel.org: Make function into a macro instead] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-22clk: qcom: Make common clk_hw registrationsJeffrey Hugo
Several clock controller drivers define a list of clk_hw devices, and then register those devices in probe() before using common code to process the rest of initialization. Extend the common code to accept a list of clk_hw devices to process, thus eliminating many duplicate implementations. Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> Suggested-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Tested-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-22clk: actions: Add clock driver for S500 SoCManivannan Sadhasivam
Add common clock driver for Actions Semi S500 SoC. Signed-off-by: Edgar Bernardi Righi <edgar.righi@lsitec.org.br> [Mani: cleaned up the driver] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-21clk: actions: Add configurable PLL delayManivannan Sadhasivam
S500 SoC requires configurable delay for different PLLs. Hence, add a separate macro for declaring a PLL with configurable delay and also modify the existing OWL_PLL_NO_PARENT macro to use default delay so that no need to modify the existing S700/S900 drivers. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-22habanalabs: use GFP_ATOMIC under spin lockWei Yongjun
A spin lock is taken here so we should use GFP_ATOMIC. Fixes: 0feaf86d4e69 ("habanalabs: add virtual memory and MMU modules") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-22Merge branch 'drm-next-5.1' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-next Fixes for 5.1: amdgpu: - Fix missing fw declaration after dropping old CI DPM code - Fix debugfs access to registers beyond the MMIO bar size - Fix context priority handling - Add missing license on some new files - Various cleanups and bug fixes radeon: - Fix missing break in CS parser for evergreen - Various cleanups and bug fixes sched: - Fix entities with 0 run queues Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221214134.3308-1-alexander.deucher@amd.com
2019-02-21rocker: Add missing break for PRE_BRIDGE_FLAGSFlorian Fainelli
A missing break keyword should have been added after adding support for PRE_BRIDGE_FLAGS. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 93700458ff63 ("rocker: Check Handle PORT_PRE_BRIDGE_FLAGS") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22crypto: ccp - Update driver messages to remove some confusionLendacky, Thomas
The current content of some of the driver messages and the way that they are issued results in some confusion, especially in the area of the PSP as it relates to SEV support. If SEV is not supported, a message is issued that says "psp initialization failed." This makes it seem like there was a problem, when in fact, the PSP support is just disabled if SEV is not supported. Update the driver to check SEV support a bit earlier and issue a debug- level message if SEV is not supported, followed by a debug-level message that the PSP is disabled. This way you will only see PSP messages if SEV is supported or if debug information is desired. Also, remove the overall "enabled" and "disabled" messages for the driver and rely on the CCP and PSP support to issue component-specific messages. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-02-22crypto: rockchip - update new iv to device in multiple operationsZhang Zhijie
For chain mode in cipher(eg. AES-CBC/DES-CBC), the iv is continuously updated in the operation. The new iv value should be written to device register by software. Reported-by: Eric Biggers <ebiggers@google.com> Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288") Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by: Zhang Zhijie <zhangzj@rock-chips.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-02-22crypto: rockchip - fix scatterlist nents errorZhang Zhijie
In some cases, the nents of src scatterlist is different from dst scatterlist. So two variables are used to handle the nents of src&dst scatterlist. Reported-by: Eric Biggers <ebiggers@google.com> Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288") Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by: Zhang Zhijie <zhangzj@rock-chips.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-02-22crypto: ccree - fix missing break in switch statementGustavo A. R. Silva
Add missing break statement in order to prevent the code from falling through to case S_DIN_to_DES. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>