| Age | Commit message (Collapse) | Author |
|---|
|
Building BPF samples is failing with the below error:
samples/bpf/map_perf_test_user.c: In function ‘main’:
samples/bpf/map_perf_test_user.c:134:9: error: variable ‘r’ has
initializer but incomplete type
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
^
samples/bpf/map_perf_test_user.c:134:21: error: ‘RLIM_INFINITY’
undeclared (first use in this function)
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
^
samples/bpf/map_perf_test_user.c:134:21: note: each undeclared
identifier is reported only once for each function it appears in
samples/bpf/map_perf_test_user.c:134:9: warning: excess elements in
struct initializer [enabled by default]
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
^
samples/bpf/map_perf_test_user.c:134:9: warning: (near initialization
for ‘r’) [enabled by default]
samples/bpf/map_perf_test_user.c:134:9: warning: excess elements in
struct initializer [enabled by default]
samples/bpf/map_perf_test_user.c:134:9: warning: (near initialization
for ‘r’) [enabled by default]
samples/bpf/map_perf_test_user.c:134:16: error: storage size of ‘r’
isn’t known
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
^
samples/bpf/map_perf_test_user.c:139:2: warning: implicit declaration of
function ‘setrlimit’ [-Wimplicit-function-declaration]
setrlimit(RLIMIT_MEMLOCK, &r);
^
samples/bpf/map_perf_test_user.c:139:12: error: ‘RLIMIT_MEMLOCK’
undeclared (first use in this function)
setrlimit(RLIMIT_MEMLOCK, &r);
^
samples/bpf/map_perf_test_user.c:134:16: warning: unused variable ‘r’
[-Wunused-variable]
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
^
make[2]: *** [samples/bpf/map_perf_test_user.o] Error 1
Fix this by including the necessary header file.
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David S. Miller <davem@davemloft.net>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
br_sysfs_addbr"
This reverts commit c862cc9b70526a71d07e7bd86d9b61d1c792cead.
Patch lacks a real-name Signed-off-by.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
Pull rdma fixes from Doug Ledford:
"I'm back from PTO. These issues cropped up while I was gone and are
simple fixes. I'll have more after I've caught up, but I wanted to
get these in quick.
Two minor fixes for 4.6-rc2:
- Fix mlx5 build error when on demand paging is not enabled
- Fix possible uninit variable in new i40iw driver"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
i40iw: avoid potential uninitialized variable use
IB/mlx5: fix VFs callback function prototypes
|
|
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
gcc finds that the i40iw_make_cm_node() function in the recently added
i40iw driver uses an uninitilized variable as an index into an array
if CONFIG_IPV6 is disabled and the driver uses IPv6 mode:
drivers/infiniband/hw/i40iw/i40iw_cm.c: In function 'i40iw_make_cm_node':
drivers/infiniband/hw/i40iw/i40iw_cm.c:2206:52: error: 'arpindex' may be used uninitialized in this function [-Werror=maybe-uninitialized]
ether_addr_copy(cm_node->rem_mac, iwdev->arp_table[arpindex].mac_addr);
As far as I can tell, this code path can not be used because the ipv4
variable is always set with CONFIG_IPV6 is disabled, but it's better
to be sure and prevent the undefined behavior, as well as shut up
that warning in a proper way.
This adds an 'else' clause for the case we get the warning about,
causing the function to return an error in a controlled way.
To avoid adding extra mess with combined io()/#ifdef clauses,
I'm also converting the existing #ifdef into a more readable
if(IS_ENABLED()) check.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: f27b4746f378 ("i40iw: add connection management code")
Acked-by: Mustafa Ismail <Mustafa.ismail@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
|
The previous patch that added a couple of callback functions put
the declarations inside of an #ifdef CONFIG_INFINIBAND_ON_DEMAND_PAGING,
which causes the build to fail if that option is disabled:
drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_add':
drivers/infiniband/hw/mlx5/main.c:2358:31: error: 'mlx5_ib_get_vf_config' undeclared (first use in this function)
This moves the four declarations below the #ifdef section so they
are always available.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: eff901d30e6c ("IB/mlx5: Implement callbacks for manipulating VFs")
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
|
The Keystone 2 supports DT-boot only, as result dma_mask will be
always configured properly from DT -
of_platform_device_create_pdata()->of_dma_configure(). More over,
dwc3-keystone.c can be built as module and in this case it's unsafe to
assign local variable as dma_mask.
Hence, remove dma_mask configuration code.
Cc: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
Since commit 7ace8fc8219e ("usb: gadget: udc: core: Fix argument of
dma_map_single for IOMMU") it is not necessary to configure DMA for
usb_gadget device manually, because all DMA operation are performed
using parent/controller device.
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
BXT-M is a Intel Broxton SoC based platform with unique PCI ID.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
This fixes:
net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be used uninitialized in this function
target_metric is only consumed when reply = true so no bug exists here,
but not all versions of gcc realize it. Initialize to 0 to remove the
warning.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
R can select between two parents. We deal with it like this: During
initialization, check if EXTALR is populated. If so, use it for R. If
not, use R_Internal. clk_mux doesn't help here because we don't want to
switch parents depending on the clock rate. The clock rate (and source)
should stay constant for the watchdog, so I think a setup like this
during initialization makes sense.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Gen3 has two clocks (OSC and R) which look like a DIV6 clock but their
divider value is read-only and depends on MD pins at bootup. Add support
for such clocks by reading the value and adding a fixed clock.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Just a single fix to prevent GM20B systems hanging at boot.
* 'linux-4.6' of git://github.com/skeggsb/linux:
drm/nouveau/tegra: acquire and enable reference clock if needed
|
|
GM20B requires an extra clock compared to GK20A. Add that information
into the platform data and acquire and enable this clock if necessary.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
arm hdlcd fix.
* 'for-upstream/hdlcd' of git://linux-arm.org/linux-ld:
drm: ARM HDLCD - fix an error code
drm: ARM HDLCD - get rid of devm_clk_put()
|
|
git://git.pengutronix.de/git/pza/linux into drm-fixes
imx-drm: stricter plane parameter checking, dw_hdmi-imx and dmfc fixes
- Check whether plane parameters comply with IPU IDMAC limitations and
fix planar YUV 4:2:0 U/V offsets and stride
- Cleanup encoder in dw_hdmi-imx bind error path and
remove a superfluous platform_set_drvdata in dw_hdmi-imx
- DMFC setup fixes: lock the ipu_dmfc_init_channel function against
concurrent use, rename it to ipu_dmfc_config_wait4eot, and call
it after the FIFO size has been determined.
* tag 'imx-drm-next-2016-04-01' of git://git.pengutronix.de/git/pza/linux:
drm/imx: Don't set a gamma table size
drm/imx: ipuv3-plane: Configure DMFC wait4eot bit after slots are determined
gpu: ipu-v3: ipu-dmfc: Rename ipu_dmfc_init_channel to ipu_dmfc_config_wait4eot
gpu: ipu-v3: ipu-dmfc: Make function ipu_dmfc_init_channel() return void
gpu: ipu-v3: ipu-dmfc: Protect function ipu_dmfc_init_channel() with mutex
drm/imx: dw_hdmi: Don't call platform_set_drvdata()
drm/imx: dw_hdmi: Call drm_encoder_cleanup() in error path
drm/imx: ipuv3-plane: fix planar YUV 4:2:0 support
drm/imx: ipuv3-plane: Add more thorough checks for plane parameter limitations
gpu: ipu-cpmem: modify ipu_cpmem_set_yuv_planar_full for better control
|
|
When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set
before ip6_tnl_create2 is called. When register_netdevice is called, there
is no linkinfo attribute in the NEWLINK message because of that.
Setting rtnl_link_ops before calling register_netdevice fixes that.
Fixes: 0b112457229d ("ip6tnl: add support of link creation via rtnl")
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This reverts commit 543e3a8da5a4c453e992d5351ef405d5e32f27d7.
Direct callers of __netpoll_setup() depend on it to set np->dev,
so we can't simply move that assignment up to netpoll_stup().
Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates 2016-04-05
This series contains updates to i40e and e1000.
Jesse fixes an issue where code was added by a previous commit but the
flag to enable it was never set.
Alex fixes the e1000 driver from grossly overestimated the descriptors
needed to transmit a frame.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pull KVM fixes from Paolo Bonzini:
"Miscellaneous bugfixes.
The ARM and s390 fixes are for new regressions from the merge window,
others are usual stable material"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
compiler-gcc: disable -ftracer for __noclone functions
kvm: x86: make lapic hrtimer pinned
s390/mm/kvm: fix mis-merge in gmap handling
kvm: set page dirty only if page has been writable
KVM: x86: reduce default value of halt_poll_ns parameter
KVM: Hyper-V: do not do hypercall userspace exits if SynIC is disabled
KVM: x86: Inject pending interrupt even if pending nmi exist
arm64: KVM: Register CPU notifiers when the kernel runs at HYP
arm64: kvm: 4.6-rc1: Fix VTCR_EL2 VS setting
|
|
The 82544 has code that adds one additional descriptor per data buffer.
However we weren't taking that into account when determining the descriptors
needed for the next transmit at the end of the xmit_frame path.
This change takes that into account by doubling the number of descriptors
needed for the 82544 so that we can avoid a potential issue where we could
hang the Tx ring by loading frames with xmit_more enabled and then stopping
the ring without writing the tail.
In addition it adds a few more descriptors to account for some additional
workarounds that have been added over time.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
The current code path is capable of grossly overestimating the number of
descriptors needed to transmit a new frame. This specifically occurs if
the skb contains a number of 4K pages. The issue is that the logic for
determining the descriptors needed is ((S) >> (X)) + 1. When X is 12 it
means that we were indicating that we required 2 descriptors for each 4K
page when we only needed one.
This change corrects this by instead adding (1 << (X)) - 1 to the S value
instead of adding 1 after the fact. This way we get an accurate descriptor
needed count as we are essentially doing a DIV_ROUNDUP().
Reported-by: Ivan Suzdal <isuzdal@mirantis.com>
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
There was an error introduced with commit 3fced535079a ("i40e: X722 is
on the IOSF bus and does not report the PCI bus info"), where code was
added but the enabling flag is never set.
CC: Anjali Singhai Jain <anjali.singhai@intel.com>
CC: Stefan Assman <sassman@redhat.com>
Fixes: 3fced535079a ("i40e: X722 is on the IOSF bus ...")
Reported-by: Steve Best <sbest@redhat.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A couple of driver specific fixes here that came in since the merge
window plus one core fix for locking in cases where a client driver
grabs a lock on the whole bus for an extended series of operations
that was introduced by the changes to support accelerated flash
operations"
* tag 'spi-fix-v4.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: rockchip: fix probe deferral handling
spi: omap2-mcspi: fix dma transfer for vmalloced buffer
spi: fix possible deadlock between internal bus locks and bus_lock_flag
spi: imx: Fix possible NULL pointer deref
spi: imx: only do necessary changes to ECSPIx_CONFIGREG
spi: rockchip: Spelling s/divsor/divisor/
|
|
As of 5a60e87603c4c533492c515b7f62578189b03c9c, RBD object request
allocations are made via rbd_obj_request_create() with GFP_NOIO.
However, subsequent OSD request allocations in rbd_osd_req_create*()
use GFP_ATOMIC.
With heavy page cache usage (e.g. OSDs running on same host as krbd
client), rbd_osd_req_create() order-1 GFP_ATOMIC allocations have been
observed to fail, where direct reclaim would have allowed GFP_NOIO
allocations to succeed.
Cc: stable@vger.kernel.org # 3.18+
Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Suggested-by: Neil Brown <neilb@suse.com>
Signed-off-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
|
|
Use list_* helpers in sctp_list_dequeue, more readable.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
There is no point on delaying the packet if we can't fit a single byte
of data on it anymore. So lets just reduce the threshold by the amount
that a data chunk with 4 bytes (rounding) would use.
v2: based on the right tree
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here is a set of pin control fixes for the v4.6 series.
A bit bigger than what I hoped for, but all fixes are confined to
drivers, a few of them also targeted to stable.
Summary:
- On Super-H PFC (Renesas) controllers: only use dummies on legacy
systems. This fixes a serious ethernet regression on a Renesas
board.
- Pistachio: Fix errors in the pin table.
- Allwinner SunXi: fix the external interrupts to work.
- Intel: fix so the high level interrupts start working, and fix a
spurious interrupt issue.
- Qualcomm ipq4019: fix the number of GPIOs provided (bump to 100),
correct register offsets and handle GPIO mode properly.
- Revert the revert on the revert so that Xway has a .to_irq()
callback again.
- Minor fixes to errorpaths and debug info.
- A MAINTAINERS update"
* tag 'pinctrl-v4.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
Revert "Revert "pinctrl: lantiq: Implement gpio_chip.to_irq""
pinctrl: qcom: ipq4019: fix register offsets
pinctrl: qcom: ipq4019: fix the function enum for gpio mode
pinctrl: qcom: ipq4019: set ngpios to correct value
pinctrl: nomadik: fix pull debug print inversion
MAINTAINERS: pinctrl: samsung: Add two new maintainers
pinctrl: intel: implement gpio_irq_enable
pinctrl: intel: make the high level interrupt working
pinctrl: freescale: imx: fix bogus check of of_iomap() return value
pinctrl: sunxi: Fix A33 external interrupts not working
pinctrl: pistachio: fix mfio84-89 function description and pinmux.
pinctrl: sh-pfc: only use dummy states for non-DT platforms
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
"Some bug fixes on au0828 and snd-usb-audio:
- the au0828+snd-usb-audio MC patch broke several things and produced
some race conditions. Better to revert the patches, and re-work on
them for a next version
- fix a regression at tuner disable links logic
- properly handle dev_state as a bitmask"
* tag 'media/v4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] Revert "[media] media: au0828 change to use Managed Media Controller API"
[media] Revert "[media] sound/usb: Use Media Controller API to share media resources"
[media] au0828: Fix dev_state handling
[media] au0828: fix au0828_v4l2_close() dev_state race condition
[media] media: au0828 fix to clear enable/disable/change source handlers
[media] v4l2-mc: cleanup a warning
[media] au0828: disable tuner links and cache tuner/decoder
|
|
Add the PMC driver compatible strings for Tegra132 and Tegra210.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Currently, the function tegra_powergate_set() simply sets the desired
powergate state but does not wait for the state to change. In most cases
we should wait for the state to change before proceeding. Currently,
there is a case for Tegra114 and Tegra124 devices where we do not wait
when starting the secondary CPU as this is not necessary. However, this
is only done at boot time and so waiting here will only have a small
impact on boot time. Therefore, update tegra_powergate_set() to wait
when setting the powergate.
By adding this feature, we can also eliminate the polling loop from
tegra30_boot_secondary().
A function has been added for checking the status of the powergate and
so update the tegra_powergate_is_powered() to use this macro as well.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
For Tegra124 and Tegra210, the GPU partition cannot be toggled on and
off via the APBDEV_PMC_PWRGATE_TOGGLE_0 register. For these devices, the
partition is simply powered up and down via an external regulator.
For these devices, there is a separate register for controlling the
signal clamping of the partition and this is described in the PMC SoC
data by the "has_gpu_clamp" variable. Use this variable to determine if
the GPU partition can be controlled via the APBDEV_PMC_PWRGATE_TOGGLE_0
register and ensure that no one can incorrectly try to toggle the GPU
partition via the APBDEV_PMC_PWRGATE_TOGGLE_0 register.
Furthermore, we cannot use the APBDEV_PMC_PWRGATE_STATUS_0 register to
determine if the GPU partition is powered for Tegra124 and Tegra210.
However, if the GPU partition is powered, then the signal clamp for the
GPU partition should be removed and so use bit 0 of the
APBDEV_PMC_GPU_RG_CNTRL_0 register to determine if the clamp has been
removed (bit[0] = 0) and the GPU partition is powered.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The function tegra_powergate_is_powered() verifies that the partition
being queried is valid and so there is no need to check this before
calling tegra_powergate_is_powered() in powergate_show(). So remove this
extra check.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The Tegra power partitions are referenced by numerical IDs which are the
same values programmed into the PMC registers for controlling the
partition. For a given device, the valid partition IDs may not be
contiguous and so simply checking that an ID is not greater than the
maximum ID supported may not mean it is valid. Fix this by checking if
the powergate is defined in the list of powergates for the Tegra SoC.
Add a helper function for checking valid powergates and use where we
need to verify if the powergate ID is valid or not.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
In tegra_powergate_set() the state of the powergates is read and OR'ed
with the bit for the powergate of interest. This unsigned 32-bit value
is then compared with a boolean value to test if the powergate is
already in the desired state. When turning on a powergate, apart from
the powergate that is represented by bit 0, this test will always
return false and so we may attempt to turn on the powergate when it is
already on.
After OR'ing the bit for the powergate, check if the result is not equal
to zero before comparing with the boolean value. Add a helper function
to return the current state of a powergate and use this in both
tegra_powergate_set() and tegra_powergate_is_powered() where we check
the powergate status.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The Tegra powergate and rail IDs are always positive values and so change
the type to be unsigned and remove the tests to see if the ID is less
than zero. Update the Tegra DC powergate type to be an unsigned as well.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The PMC base address pointer is initialised during early boot so that
early platform code may used the PMC public functions. During the probe
of the PMC driver the base address pointer is mapped again and the initial
mapping is freed. This exposes a window where a device accessing the PMC
registers via one of the public functions, could race with the updating
of the pointer and lead to a invalid access. Furthermore, the only
protection between multiple devices attempting to access the PMC registers
is when setting the powergate state to on or off. None of the other public
functions that access the PMC registers are protected.
Use the existing mutex to protect paths that may race with regard to
accessing the PMC registers.
Note that functions tegra_io_rail_prepare()/poll() either return a
negative value on failure or zero on success. Therefore, it is not
necessary to check if the return value is less than zero and so only
test that the return value is not zero to test for failure. This
simplifies the error handling with the mutex locking in place.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
During early initialisation, the PMC registers are mapped and the PMC SoC
data is populated in the PMC data structure. This allows other drivers
access the PMC register space, via the public Tegra PMC APIs, prior to
probing the PMC device.
When the PMC device is probed, the PMC registers are mapped again and if
successful the initial mapping is freed. If the probing of the PMC device
fails after the registers are remapped, then the registers will be
unmapped and hence the pointer to the PMC registers will be invalid. This
could lead to a potential crash, because once the PMC SoC data pointer is
populated, the driver assumes that the PMC register mapping is also valid
and a user calling any of the public Tegra PMC APIs could trigger an
exception because these APIs don't check that the mapping is still valid.
Fix this by updating the mapping and freeing the original mapping only if
probing the PMC device is successful.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Tegra124 does not have an L2 power partition and the L2 cache is part of
the cluster 0 non-CPU (CONC) partition. Remove the L2 as a valid
partition for Tegra124. The TRM also shows that there is no L2 partition
for Tegra124.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The power partitions L2, HEG, CELP and C1NC do not exist on Tegra210 but
were incorrectly documented in the TRM. These will be removed from the
TRM and so also remove their definitions.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The debugfs entry for the PMC device will not be removed if the probe of
the device fails to register the restart handler. This leaves behind the
dangling debugfs entry with no driver backing it. Remove the entry to
avoid this.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Sparse reports the following warning for tegra_pmc_init_tsense_reset():
drivers/soc/tegra/pmc.c:741:6: warning: symbol 'tegra_pmc_init_tsense_reset' was not declared. Should it be static?
This function is only used internally by the PMC driver and so fix this
by making it static.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Some members of the tegra_pmc structure are missing from the kernel-doc
comment for this structure. Add the missing members.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
With the change to stashing just the IOVA-page-aligned remainder of the
CPU-page offset rather than the whole thing, the failure path in
__invalidate_sg() also needs tweaking to account for that in the case of
differing page sizes where the two offsets may not be equivalent.
Similarly in __finalise_sg(), lest the architecture-specific wrappers
later get the wrong address for cache maintenance on sync or unmap.
Fixes: 164afb1d85b8 ("iommu/dma: Use correct offset in map_sg")
Reported-by: Magnus Damm <damm+renesas@opensource.se>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Cc: stable@ver.kernel.org # v4.4+
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
-ftracer can duplicate asm blocks causing compilation to fail in
noclone functions. For example, KVM declares a global variable
in an asm like
asm("2: ... \n
.pushsection data \n
.global vmx_return \n
vmx_return: .long 2b");
and -ftracer causes a double declaration.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: stable@vger.kernel.org
Cc: kvm@vger.kernel.org
Reported-by: Linda Walsh <lkml@tlinx.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
When a vCPU runs on a nohz_full core, the hrtimer used by
the lapic emulation code can be migrated to another core.
When this happens, it's possible to observe milisecond
latency when delivering timer IRQs to KVM guests.
The huge latency is mainly due to the fact that
apic_timer_fn() expects to run during a kvm exit. It
sets KVM_REQ_PENDING_TIMER and let it be handled on kvm
entry. However, if the timer fires on a different core,
we have to wait until the next kvm exit for the guest
to see KVM_REQ_PENDING_TIMER set.
This problem became visible after commit 9642d18ee. This
commit changed the timer migration code to always attempt
to migrate timers away from nohz_full cores. While it's
discussable if this is correct/desirable (I don't think
it is), it's clear that the lapic emulation code has
a requirement on firing the hrtimer in the same core
where it was started. This is achieved by making the
hrtimer pinned.
Lastly, note that KVM has code to migrate timers when a
vCPU is scheduled to run in different core. However, this
forced migration may fail. When this happens, we can have
the same problem. If we want 100% correctness, we'll have
to modify apic_timer_fn() to cause a kvm exit when it runs
on a different core than the vCPU. Not sure if this is
possible.
Here's a reproducer for the issue being fixed:
1. Set all cores but core0 to be nohz_full cores
2. Start a guest with a single vCPU
3. Trace apic_timer_fn() and kvm_inject_apic_timer_irqs()
You'll see that apic_timer_fn() will run in core0 while
kvm_inject_apic_timer_irqs() runs in a different core. If
you get both on core0, try running a program that takes 100%
of the CPU and pin it to core0 to force the vCPU out.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
commit 1e133ab296f3 ("s390/mm: split arch/s390/mm/pgtable.c") dropped
some changes from commit a3a92c31bf0b ("KVM: s390: fix mismatch
between user and in-kernel guest limit") - this breaks KVM for some
memory sizes (kvm-s390: failed to commit memory region) like
exactly 2GB.
Cc: Dominik Dingel <dingel@linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
