i40iw_mmap manipulates the vma->vm_pgoff to differentiate a push page mmap
vs a doorbell mmap, and uses it to compute the pfn in remap_pfn_range
without any validation. This is vulnerable to an mmap exploit as described
in: https://lore.kernel.org/r/20201119093523.7588-1-zhudi21@huawei.com
The push feature is disabled in the driver currently and therefore no push
mmaps are issued from user-space. The feature does not work as expected in
the x722 product.
Remove the push module parameter and all VMA attribute manipulations for
this feature in i40iw_mmap. Update i40iw_mmap to only allow DB user
mmapings at offset = 0. Check vm_pgoff for zero and if the mmaps are bound
to a single page.
Cc: <stable@kernel.org>
Fixes: d374984179 ("i40iw: add files for iwarp interface")
Link: https://lore.kernel.org/r/20201125005616.1800-2-shiraz.saleem@intel.com
Reported-by: Di Zhu <zhudi21@huawei.com>
Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
We can simplify the error path in probe() and drop remove() entirely if
we provide a devm action for freeing the device ID.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We can simplify the code in gpio-exar by using regmap. This allows us to
drop the mutex (regmap provides its own locking) and we can also reuse
regmap's bit operations instead of implementing our own update function.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Provide and use helpers for calculating the register address and bit
offset instead of hand coding it in every function.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
It's more elegant to use a helper local variable to store the address
of the underlying struct device than to dereference pdev everywhere. It
also has the benefit of avoiding unnecessary line breaks.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We don't need to specify any ranges when allocating IDs so we can switch
to ida_alloc() and ida_free() instead of the ida_simple_ counterparts.
ida_simple_get(ida, 0, 0, gfp) is equivalent to
ida_alloc_range(ida, 0, UINT_MAX, gfp) which is equivalent to
ida_alloc(ida, gfp). Note: IDR will never actually allocate an ID
larger than INT_MAX.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
This driver uses IDA APIs but doesn't include the relevant header. This
fixes it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
It's customary to have a newline between the copyright header and the
includes. Add one to gpio-exar.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
So far, the thermocouple-type property described in here is only
used in a single driver. Whilst I would like it to be more generally
used that hasn't happened yet and I don't see a reason to maintain
this small file in the hope that it happens.
I pushed for this generic binding in the first place. Hopefully
we can bring it back at somepoint.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Link: https://lore.kernel.org/r/20201031184854.745828-47-jic23@kernel.org
This is a large but fairly simple binding.
It may well be possible to constrain some of the properties more than
currently done, but that would involve diving into datasheets for the
supported parts. Hence for this initial conversion just use the
information that was in the txt file.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Link: https://lore.kernel.org/r/20201031184854.745828-46-jic23@kernel.org
This binding document covers a very large number of different sensors.
As such the existing documentation is less specific than it could
be (such as which devices have 2 interrupt pin options).
That can be improved later.
Denis, are you happy to be listed as maintainer for this one?
If not feel free to suggestion someone else.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Link: https://lore.kernel.org/r/20201031184854.745828-45-jic23@kernel.org
Very simple direct conversion of existing txt file.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/20201031184854.745828-44-jic23@kernel.org
Simple binding so mostly straight forward to convert.
Original binding was unclear on how many interrupts there are.
The device has two such lines, whilst I believe the driver currently
only uses one at a time. The binding should allow both to be specified.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Martin Kepplinger <martin.kepplinger@theobroma-systems.com>
Link: https://lore.kernel.org/r/20201031184854.745828-43-jic23@kernel.org
Very simple binding hence a straight forward conversion.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Dmitry Osipenko <digetx@gmail.com>
Cc: Robert Yang <decatf@gmail.com>
Link: https://lore.kernel.org/r/20201031184854.745828-42-jic23@kernel.org
One question in here is whether we want to constrain the number of
interrupts. Some parts definitely only have 1 such pin, and others
2 pins but I can not find information on the bma254.
Oleksandr's email address is bouncing so I've listed myself as
maintainer for this binding until someone else steps up.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-41-jic23@kernel.org
This is a more complex binding. Whilst conversion is straight forward
I am unsure if the full nature of required properties has been captured.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Link: https://lore.kernel.org/r/20201031184854.745828-39-jic23@kernel.org
Simple binding so straight forward format conversion.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Link: https://lore.kernel.org/r/20201031184854.745828-38-jic23@kernel.org
Straight forward conversion. Not heard from Ivan in a while so if the
email bounces, I'll change the maintainer to myself for this binding unless
anyone else comes forwards.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-37-jic23@kernel.org
Renamed to match a listed compatible rather than relying on wildcards
with all their usual problems.
Dropped the reference supply as a requirement as at least one dtsi doesn't
include it and the example never did.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201031184854.745828-36-jic23@kernel.org
Simple conversion of the binding doc for this subnode of the palmas
PMIC.
Given age of driver and lack interaction with original authors,
I've guessed at Tony for a maintainer on this one. Tony, if you
are happy with that great, otherwise I can default back to myself.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20201031184854.745828-35-jic23@kernel.org
The current driver and indeed binding are named after a part that they
do not list in the compatible. Hence renamed the binding to reflect
one that does.
>From the driver it looks like there is a lot more backwards compatibility
than the binding currently reflects. We could consider expressing that
more explicitly in the yaml for the compatible property. I have
added one explicit pair that was present in the upstream dtsi files.
I added Matthias alongside Zhiyong Tao because I don't think
Zhiyong Tao has reviewed recent patches. Please let me know if this
isn't the right thing to do.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Zhiyong Tao <zhiyong.tao@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Link: https://lore.kernel.org/r/20201031184854.745828-34-jic23@kernel.org
A few questions came up in this one.
1) Why does the txt file document io-channel-ranges as a required property.
That property is for iio-channel consumers, and this is a provider.
I have dropped it.
2) The example had an @180a6000 for the ADC but given it uses syscon for
all access, it doesn't have its own reg etc. I've dropped that from
the binding example.
Note this example was lifted directly from bcm-cygnus.dtsi so both
issues are present there as well.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
Link: https://lore.kernel.org/r/20201031184854.745828-33-jic23@kernel.org
DMA device nodes should follow regex pattern of "^dma-controller(@.*)?$".
This is a preparatory patch to use YAML doc format for ADMA.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
For some reason this was never hooked up. Do it now so that over-current
interrupts can be logged.
Reported-by: Nicolas Chauvet <kwizart@gmail.com>
Suggested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
According to dmesg, thermal-zones for mem and cpu are missing hot
temperatures properties.
throttrip: pll: missing hot temperature
...
throttrip: mem: missing hot temperature
...
Adding them will clear the messages.
Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
On Jetson TX1 the following message can be seen:
tegra_soctherm 700e2000.thermal-sensor: throttle-cfg: heavy: no throt prop or invalid prop
This patch will fix the invalid prop issue according to the binding.
Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
According to dmesg, thermal-zones for mem and cpu are missing hot
temperatures properties.
throttrip: pll: missing hot temperature
...
throttrip: mem: missing hot temperature
...
Adding them will clear the messages.
Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Fix the device-tree entry that represents I/O High Voltage property
by replacing 'nvidia,io-high-voltage' with 'nvidia,io-hv' as the former
entry is deprecated.
Fixes: dbb72e2c30 ("arm64: tegra: Add configuration for PCIe C5 sideband signals")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
GIC400 has full support for virtualization, and yet the tegra186
DT doesn't expose the GICH/GICV regions (despite exposing the
maintenance interrupt that only makes sense for virtualization).
Add the missing regions, based on the hunch that the HW doesn't
use the CPU build-in interfaces, but instead the external ones
provided by the GIC. KVM's virtual GIC now works with this change.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the description of CPU PMUs for both the Denver and A57 clusters,
which enables the perf subsystem.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When the device-tree board file was added for the Tegra234 VDK simulator
it incorrectly used the names 'cbb' and 'sdhci' instead of 'bus' and
'mmc', respectively. The names 'bus' and 'mmc' are required by the
device-tree json-schema validation tools. Therefore, fix this by
renaming these nodes accordingly.
Fixes: 639448912b ("arm64: tegra: Initial Tegra234 VDK support")
Reported-by: Ashish Singhal <ashishsingha@nvidia.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The AON HSP node's "reg" property size 0xa0000 will overlap with other
resources. This patch fixes that wrong value with correct size 0x90000.
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Fixes: a38570c22e ("arm64: tegra: Add nodes for TCU on Tegra194")
Signed-off-by: Thierry Reding <treding@nvidia.com>
USB host mode is broken on the OTG port of Jetson TX1 platform because
the USB_VBUS_EN0 regulator (regulator@11) is being overwritten by the
vdd-cam-1v2 regulator. This commit rearranges USB_VBUS_EN0 to be
regulator@14.
Fixes: 257c8047be ("arm64: tegra: jetson-tx1: Add camera supplies")
Cc: stable@vger.kernel.org
Signed-off-by: JC Kuo <jckuo@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Jetson Xavier NX board routes UARTA to the 40-pin header and UARTC
to a 12-pin debug header. The UARTs can be used by either the Tegra
Combined UART (TCU) driver or the Tegra 8250 driver. By default, the
TCU will use UARTC on Jetson Xavier NX. Currently, device-tree for
Xavier NX enables the TCU and the Tegra 8250 node for UARTC. Fix this
by disabling the Tegra 8250 node for UARTC and enabling the Tegra 8250
node for UARTA.
Fixes: 3f9efbbe57 ("arm64: tegra: Add support for Jetson Xavier NX")
Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commit ff4c371d2b ("arm64: defconfig: Build ADMA and ACONNECT driver")
enable the Tegra ADMA and ACONNECT drivers and this is causing resume
from system suspend to fail on Jetson TX2. Resume is failing because the
ACONNECT driver is being resumed before the BPMP driver, and the ACONNECT
driver is attempting to power on a power-domain that is provided by the
BPMP. While a proper fix for the resume sequencing problem is identified,
disable the ACONNECT for Jetson TX2 temporarily to avoid breaking system
suspend.
Please note that ACONNECT driver is used by the Audio Processing Engine
(APE) on Tegra, but because there is no mainline support for APE on
Jetson TX2 currently, disabling the ACONNECT does not disable any useful
feature at the moment.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The SDM630/660 SoCs (and variants) have another clock source
for the PHY, which must be set to a rate that's equal or
greater than the CSI PHY timer clock: failing to do this
will produce PHY overflows when trying to get a stream from
a very high bandwidth camera sensor and outputting no frame
or a partial one.
Since I haven't found any usecase in which the csiX_phy
clock needs to be higher than the csiXphy_timer, let's just
set the same rate on both, which seems to work just perfect.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The CSIPHY on SDM630/660 needs a slightly longer T_HS_CLK_MISS
configuration on lanes CFG4.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add support for the Qualcomm SDM630/636/660 and SDA variants' camera
subsystem. These SoCs are equipped with:
- 3x CSI PHY 3-Phase v1.0 (downstream csiphy-v3.5)
- 4x CSID v5.0
- 2x ISPIF v3.0
- 2x VFE 4.8
As a note, this camera subsystem is very similar to the one that
is found in the MSM8998/APQ8098 SoCs.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add bindings for qcom,sdm660-camss in order to support the camera
subsystem on SDM630/660 and SDA variants.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add the support for VFE 4.8 in the camss-vfe-4-7 driver, as this one
really is a minor revision, requiring the very same management and
basically having the same register layout as VFE 4.7, but needing
a different QoS and DS configuration, using a different register to
enable the wm and habing the same UB size for both instances (instead
of a different size between instance 0 and 1).
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In preparation to add support for VFE 4.8, rename these functions
by adding the vfe version that they are referred to (for example,
vfe_get_ub_size -> vfe47_get_ub_size), as these are the only ones
that will be different for the VFE version 4.8.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Resetting the ISPIF VFE0 context is wrong if we are using the VFE1
for dual-camera or simply because a secondary camera is connected
to it: in this case the reset will always happen on the VFE0 ctx
of the ISPIF, which is .. useless.
Fix this usecase by adding the ISPIF_RST_CMD_1 address and choose
where to do the (or what to) reset based on the VFE line id.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The enum rc_proto value RC_PROTO_MAX has no documentation, this is causing
a warning while building the documentation.
Fixes: 72e637fec5 ("media: rc: validate that "rc_proto" is reasonable")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This allows the timeout to be set with the LIRC_SET_REC_TIMEOUT ioctl.
The timeout was hardcoded at just over 20ms, but returned 120ms when
queried with the LIRC_GET_REC_TIMEOUT ioctl.
This also ensures the idle threshold is set correctly with a base clock
other than 8Mhz.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
If a user holds a button down on a remote, then no ir idle interrupt will
be generated until the user releases the button, depending on how quickly
the remote repeats. No IR is processed until that point, which means that
holding down a button may not do anything.
This also resolves an issue on a Cubieboard 1 where the IR receiver is
picking up ambient infrared as IR and spews out endless
"rc rc0: IR event FIFO is full!" messages unless you choose to live in
the dark.
Cc: stable@vger.kernel.org
Tested-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The flag V4L2_SUBDEV_FL_HAS_EVENTS is required if the subdev can
generate events. It can create events from the ctrl handler, therefore
this is required.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
