As part of removing broken pm-support from s390 arch, remove
the pm callbacks from ccw-bus driver.The power-management functions
are unused since the 'commit 394216275c ("s390: remove broken
hibernate / power management support")'.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The power-management functions are unused since the
'commit 394216275c ("s390: remove broken hibernate / power
management support")'. Remove the unused pm callbacks from
css-bus driver.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The power-management functions are unused since the
'commit 394216275c ("s390: remove broken hibernate / power
management support")'. Remove these unused pm callbacks from
io-subchannel drivers.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
As part of removing the broken pm-support from s390 arch, remove
the pm-calls from chsc subchannel driver. The power-management
functions are unused since the 'commit 394216275c ("s390: remove
broken hibernate / power management support")'.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The Power-management related functions are unused since
'commit 394216275c ("s390: remove broken hibernate / power management
support")'. Remove them from the unit-record device driver.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The power-management related functions are unused since
'commit 394216275c ("s390: remove broken hibernate / power
management support")'. Remove them from tape drivers.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The power-management functions are unused since the
'commit 394216275c ("s390: remove broken hibernate / power management
support")'. Remove the unsued pm functions from the console drivers.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The power-management related functions are unused since the
'commit 394216275c ("s390: remove broken hibernate / power management
support")'. Remove them from dasd drivers.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
As part of removing the power management support from
s390 arch, remove PM callbacks from the scsi/zfcp driver.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
With commit 58c644ba51 ("sched/idle: Fix arch_cpu_idle() vs
tracing") common code calls arch_cpu_idle() with a lockdep state that
tells irqs are on.
This doesn't work very well for s390: psw_idle() will enable interrupts
to wait for an interrupt. As soon as an interrupt occurs the interrupt
handler will verify if the old context was psw_idle(). If that is the
case the interrupt enablement bits in the old program status word will
be cleared.
A subsequent test in both the external as well as the io interrupt
handler checks if in the old context interrupts were enabled. Due to
the above patching of the old program status word it is assumed the
old context had interrupts disabled, and therefore a call to
TRACE_IRQS_OFF (aka trace_hardirqs_off_caller) is skipped. Which in
turn makes lockdep incorrectly "think" that interrupts are enabled
within the interrupt handler.
Fix this by unconditionally calling TRACE_IRQS_OFF when entering
interrupt handlers. Also call unconditionally TRACE_IRQS_ON when
leaving interrupts handlers.
This leaves the special psw_idle() case, which now returns with
interrupts disabled, but has an "irqs on" lockdep state. So callers of
psw_idle() must adjust the state on their own, if required. This is
currently only __udelay_disabled().
Fixes: 58c644ba51 ("sched/idle: Fix arch_cpu_idle() vs tracing")
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The directed MSIs are delivered to CPUs whose address is
written to the MSI message address. The current code assumes
that a CPU logical number (as it is seen by the kernel)
is also the CPU address.
The above assumption is not correct, as the CPU address
is rather the value returned by STAP instruction. That
value does not necessarily match the kernel logical CPU
number.
Fixes: e979ce7bce ("s390/pci: provide support for CPU directed interrupts")
Cc: <stable@vger.kernel.org> # v5.2+
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
of_dma_get_max_cpu_address() is not defined if !CONFIG_OF_ADDRESS, so
return early in of_unittest_dma_get_max_cpu_address().
Fixes: 07d13a1d61 ("of: unittest: Add test for of_dma_get_max_cpu_address()")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
__bio_for_each_bvec(), __bio_for_each_segment() and bio_copy_data_iter()
fall under conditions of bvec_iter_advance_single(), which is a faster
and slimmer version of bvec_iter_advance(). Add
bio_advance_iter_single() and convert them.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Because of how for_each_bvec() works it never advances across multiple
entries at a time, so bvec_iter_advance() is an overkill. Add
specialised bvec_iter_advance_single() that is faster. It also handles
zero-len bvecs, so can kill bvec_iter_skip_zero_bvec().
text data bss dec hex filename
before:
23977 805 0 24782 60ce lib/iov_iter.o
before, bvec_iter_advance() w/o WARN_ONCE()
22886 600 0 23486 5bbe ./lib/iov_iter.o
after:
21862 600 0 22462 57be lib/iov_iter.o
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
During cci_isr() errors read from register fields belonging to
i2c master1 are currently assigned to the status field belonging to
i2c master0. This patch corrects this error, and always assigns
master1 errors to the status field of master1.
Fixes: e517526195 ("i2c: Add Qualcomm CCI I2C driver")
Reported-by: Loic Poulain <loic.poulain@linaro.org>
Suggested-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Good riddance! Remove the macros and their remaining references in
comments.
The following functions should be used instead, depending on the use
case:
- intel_uncore_read(), intel_uncore_write(), intel_uncore_posting_read()
- intel_de_read(), intel_de_write(), intel_de_posting_read()
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130111601.2817-10-jani.nikula@intel.com
The series supports new machines with rt1015p and rt5682. Reuses most of
the code in mt8192-mt6359-rt1015-rt5682.c.
The first 3 patches refactor the existing mt8192-mt6359-rt1015-rt5682.c.
For easier to support newly added components later.
The 4th patch fixes a typo in DT bindings document.
The 5th patch proposes a new compatible string "mt8192_mt6359_rt1015p_rt5682"
for machines with rt1015p and rt5682.
The 6th patch reuses the existing machine driver to support machines with
rt1015p and rt5682.
Tzung-Bi Shih (6):
ASoC: mediatek: mt8192: rename common symbols
ASoC: mediatek: mt8192: extract rt1015_rt5682 specific DAI link
ASoC: mediatek: mt8192: move rt1015_rt5682 specific data
ASoC: dt-bindings: mt8192-mt6359: fix typo in the example
ASoC: dt-bindings: mt8192-mt6359: add new compatible for using rt1015p
ASoC: mediatek: mt8192: support rt1015p_rt5682
.../sound/mt8192-mt6359-rt1015-rt5682.yaml | 6 +-
sound/soc/mediatek/Kconfig | 1 +
.../mt8192/mt8192-mt6359-rt1015-rt5682.c | 171 +++++++++++++-----
3 files changed, 129 insertions(+), 49 deletions(-)
--
2.29.2.454.gaff20da3a2-goog
SND_SOC_ADAU1372_I2C and SND_SOC_ADAU1372_SPI prpoerly select the REGMAP
config they need but forget to depend on the underlying bus.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201130215626.2400999-1-alexandre.belloni@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The "decimator" variable is in the 0-7 range and it's unsigned so there
is no need to check for negative values.
Fixes: 908e6b1df2 ("ASoC: codecs: lpass-va-macro: Add support to VA Macro")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/X8c5gjZO7YN/CFsq@mwanda
Signed-off-by: Mark Brown <broonie@kernel.org>
To comply with the intended usage of the V4L2 selection target when
used to retrieve a sensor image properties, adjust the rectangles
returned by the imx219 driver.
The top/left crop coordinates of the TGT_CROP rectangle were set to
(0, 0) instead of (8, 8) which is the offset from the larger physical
pixel array rectangle. This was also a mismatch with the default values
crop rectangle value, so this is corrected. Found with v4l2-compliance.
While at it, add V4L2_SEL_TGT_CROP_BOUNDS support: CROP_DEFAULT and
CROP_BOUNDS have the same size as the non-active pixels are not readable
using the selection API. Found with v4l2-compliance.
[reword commit message, use macros for pixel offsets]
Fixes: e6d4ef7d58 ("media: i2c: imx219: Implement get_selection")
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Now that we have a graph schema, rework the media related schemas to
use it. Mostly this is adding a reference to graph.yaml and dropping
duplicate parts from schemas.
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Jacopo Mondi <jacopo@jmondi.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-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>
The MAX9271 GPIO1 line that controls the sensor reset is by default
enabled after a serializer chip reset.
As rdacm20 does not go through an explicit serializer reset, make sure
GPIO1 is enabled to make the camera module driver more robust.
Fixes: 34009bffc1 ("media: i2c: Add RDACM20 driver")
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fix GPIO enable/disable operations which wrongly read the 0x0f register
to obtain the current mask of the enabled lines instead of using
the correct 0x0e register.
Also fix access to bit 0 of the register which is marked as reserved.
Fixes: 34009bffc1 ("media: i2c: Add RDACM20 driver")
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are no users left of this helper and as it implements an
undesirable and too simple behaviour that should instead be implemented
directly by drivers remove it to prevent future uses of it.
Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Rework the CSI-2 firmware parsing code to not use the soon to be
removed v4l2_async_notifier_parse_fwnode_endpoints_by_port() helper. The
change only aims to prepare for the removing of the old helper and there
are no functional change.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In preparation of removing the usage of the old helper
v4l2_async_notifier_parse_fwnode_endpoints_by_port() use the
v4l2_async_subdev instead of fwnode_handle to match subdevices.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Rework the parallel firmware parsing code to not use the soon to be
removed v4l2_async_notifier_parse_fwnode_endpoints_by_port() helper. The
change only aims to prepare for the removing of the old helper and there
are no functional change.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In preparation of removing the usage of the old helper
v4l2_async_notifier_parse_fwnode_endpoints_by_port() do not dynamically
allocate the whole structure containing the parameters for the parallel
interface, instead only allocate the v4l2_async_subdev structure. There
is no functional change.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently pointer nvm is being dereferenced before it is being null
checked. Fix this by moving the assignments of pointers client and
ov2740 so that are after the null check hence avoiding any potential
null pointer dereferences on pointer nvm.
Fixes: 5e6fd339b6 ("media: ov2740: allow OTP data access during streaming")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There's no need to defer allocation of pages for the receive buffer.
- This upcall is quite infrequent
- gssp_alloc_receive_pages() can allocate the pages with GFP_KERNEL,
unlike the transport
- gssp_alloc_receive_pages() knows exactly how many pages are needed
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Reviewed-by: Olga Kornievskaia <aglo@umich.edu>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
The lock in ov9734 is used to protect the streaming state and
serialize the stream on and off callbacks, it should be hold before
checking the streaming state in ov9734_set_stream().
Reported-by: Tomasz Figa <tfiga@chromium.org>
Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The subdev's video device node was only assigned after registering the
device node in the system. While it is unlikely that a driver needed to
use this field in handling system calls to its file handle, there remains
a slim chance the devnode field remains NULL while the driver expects to
find a video node there.
Assign the devnode field before registering the device, and assign it back
to NULL if the registration failed.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
in_interrupt() covers hard and soft interrupt servicing and bottom half
disabled contexts, which is semantically undefined and useless.
The comment for __ccdc_lsc_configure() "Context: in_interrupt()" is
therefore as useful as "Context: unknown'. Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
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>
The DT bindings documented "reset-gpios" property but the driver never
made use of it. Instead it used a GPIO called "xshutdown", with apprently
wrong polarity.
Fix this by requesting "reset" GPIO with the right polarity first, and if
that fails, then request "xshutdown" GPIO with the old polarity. This way
it works for new users as expected while if someone, somewhere, depended
on "xshutdown" GPIO, that continues to work as well.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The bus-type property is required for C-PHY support. Add it, including
values for CCP2 and CSI-2 D-PHY.
Also require the bus-type property. Effectively all new sensors are MIPI
D-PHY or C-PHY that cannot be told apart without the bus-type property.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Amend the existing SMIA bindings by adding MIPI CCS support, with separate
compatible strings for CCS 1.0 and CCS 1.1. Rename the old bindings
accordingly as CCS is the current standard.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Generally reset signal is active low on camera sensors. The example had it
high. Make it low, and use GPIO_ACTIVE_LOW in gpio.h for that.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Convert nokia,smia DT bindings to YAML.
Also add explicit license to bindings.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
nokia,nvm-size property was removed from the bindings but it was left in
the example. Remove it from the example, too.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
vana-supply is optional in the spec, therefore make it optional in
bindings, too.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The link-frequencies property belongs to the endpoint, not to the node
representing the device.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This removes a warning at driver probe time telling that one or two
entities have no function set. The function used for both the binner and
scaler is the scaler.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The driver doesn't do anything tangible with profiles. Remove the notion,
and use the capabilities directly.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
