Add a ov2680_fill_format() helper function and use this everywhere were
a v4l2_mbus_framefmt struct needs to be filled in so that the driver always
fills it consistently.
This is a preparation patch for fixing ov2680_set_fmt()
which == V4L2_SUBDEV_FORMAT_TRY calls not properly filling in
the passed in v4l2_mbus_framefmt struct.
Note that for ov2680_init_cfg() this now simply always fills
the try_fmt struct of the passed in sd_state. This is correct because
ov2680_init_cfg() is never called with a NULL sd_state so the old
sd_state check is not necessary.
Fixes: 3ee47cad3e ("media: ov2680: Add Omnivision OV2680 sensor driver")
Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
On ov2680_set_fmt() calls with format->which == V4L2_SUBDEV_FORMAT_TRY,
ov2680_set_fmt() does not talk to the sensor.
So in this case there is no need to lock the sensor->lock mutex or
to check that the sensor is streaming.
Fixes: 3ee47cad3e ("media: ov2680: Add Omnivision OV2680 sensor driver")
Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
VIDEO_V4L2_SUBDEV_API is now automatically selected in Kconfig
for all sensor drivers. Remove the ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
checks.
This is a preparation patch for fixing ov2680_set_fmt()
which == V4L2_SUBDEV_FORMAT_TRY calls not properly filling in
the passed in v4l2_mbus_framefmt struct.
Fixes: 3ee47cad3e ("media: ov2680: Add Omnivision OV2680 sensor driver")
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
ov2680_vflip_disable() / ov2680_hflip_disable() pass BIT(0) instead of
0 as value to ov2680_mod_reg().
While fixing this also:
1. Stop having separate enable/disable functions for hflip / vflip
2. Move the is_streaming check, which is unique to hflip / vflip
into the ov2680_set_?flip() functions.
for a nice code cleanup.
Fixes: 3ee47cad3e ("media: ov2680: Add Omnivision OV2680 sensor driver")
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The index into ov2680_hv_flip_bayer_order[] should be 0-3, but
ov2680_bayer_order() was using 0 + BIT(2) + (BIT(2) << 1) as
max index, while the intention was to use: 0 + 1 + 2 as max index.
Fix the index calculation in ov2680_bayer_order(), while at it
also just use the ctrl values rather then reading them back using
a slow i2c-read transaction.
This also allows making the function void, since there now are
no more i2c-reads to error check.
Note the check for the ctrls being NULL is there to allow
adding an ov2680_fill_format() helper later, which will call
ov2680_set_bayer_order() during probe() before the ctrls are created.
[Sakari Ailus: Change all users of ov2680_set_bayer_order() here]
Fixes: 3ee47cad3e ("media: ov2680: Add Omnivision OV2680 sensor driver")
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Quoting the OV2680 datasheet:
"3.2 exposure and gain control
In the OV2680, the exposure time and gain are set manually from an external
controller. The OV2680 supports manual gain and exposure control only for
normal applications, no auto mode."
And indeed testing with the atomisp_ov2680 fork of ov2680.c has shown that
auto-exposure and auto-gain do not work.
Note that the code setting the auto-exposure flag was broken, callers
of ov2680_exposure_set() were directly passing !!ctrls->auto_exp->val as
"bool auto_exp" value, but ctrls->auto_exp is a menu control with:
enum v4l2_exposure_auto_type {
V4L2_EXPOSURE_AUTO = 0,
V4L2_EXPOSURE_MANUAL = 1,
...
So instead of passing !!ctrls->auto_exp->val they should have been passing
ctrls->auto_exp->val == V4L2_EXPOSURE_AUTO, iow the passed value was
inverted of what it should have been.
Also remove ov2680_g_volatile_ctrl() since without auto support the gain
and exposure controls are not volatile.
This also fixes the control values not being properly applied in
ov2680_mode_set(). The 800x600 mode register-list also sets gain,
exposure and vflip overriding the last set ctrl values.
ov2680_mode_set() does call ov2680_gain_set() and ov2680_exposure_set()
but did this before writing the mode register-list, so these values
would still be overridden by the mode register-list.
Add a v4l2_ctrl_handler_setup() call after writing the mode register-list
to restore all ctrl values. Also remove the ctrls->gain->is_new check from
ov2680_gain_set() so that the gain always gets restored properly.
Last since ov2680_mode_set() now calls v4l2_ctrl_handler_setup(), remove
the v4l2_ctrl_handler_setup() call after ov2680_mode_restore() since
ov2680_mode_restore() calls ov2680_mode_set().
Fixes: 3ee47cad3e ("media: ov2680: Add Omnivision OV2680 sensor driver")
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Add mention that successful VIDIOC_SUBDEV_G_ROUTING call will update
'num_routes' and remove mention about non-existing streams, which is
incorrect.
Fixes: ea73eda508 ("media: Documentation: Add GS_ROUTING documentation")
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The initial state of RESETB input signal of OV5640 should be
asserted, i.e. the sensor should be in reset. This is not the
case, make it so.
Since the subsequent assertion of RESETB signal is no longer
necessary and the timing of the power sequencing could be
slightly adjusted, add annotations to the delays which match
OV5640 datasheet rev. 2.03, both:
figure 2-3 power up timing with internal DVDD
figure 2-4 power up timing with external DVDD source
The 5..10ms delay between PWDN assertion and RESETB assertion
is not even documented in the power sequencing diagram, and
with this reset fix, it is no longer even necessary.
Fixes: 19a81c1426 ("[media] add Omnivision OV5640 sensor driver")
Reported-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Tested-by: Jai Luthra <j-luthra@ti.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
There is no possible for platform_get_irq() to return 0,
and the return value of platform_get_irq() is more sensible
to show the error reason.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.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@kernel.org>
It is not possible for platform_get_irq() or platform_get_irq_byname()
to return 0. Use the return value from platform_get_irq()
or platform_get_irq_byname().
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
It is not possible for platform_get_irq() to return 0. Use the
return value from platform_get_irq().
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Set OV5640_REG_IO_MIPI_CTRL00 bit 2 to 1 instead of 0, since 1 means
MIPI CSI2 interface, while 0 means CPI parallel interface.
In the ov5640_set_power_mipi() the interface should obviously be set
to MIPI CSI2 since this functions is used to power up the sensor when
operated in MIPI CSI2 mode. The sensor should not be in CPI mode in
that case.
This fixes a corner case where capturing the first frame on i.MX8MN
with CSI/ISI resulted in corrupted frame.
Fixes: aa4bb8b883 ("media: ov5640: Re-work MIPI startup sequence")
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> # [Test on imx6q]
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Jai Luthra <j-luthra@ti.com> # [Test on bplay, sk-am62]
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Previously on ACPI platforms, sensors that are intended to be connected
to an IPU device for use with the ipu3-cio2 driver lacking the necessary
connection information in firmware. IPU bridge driver is to connect
sensors to IPU device via software nodes.
Currently IVSC located between IPU device and sensors is available in
existing commercial platforms from multiple OEMs. But the connection
information between them in firmware is also not enough to build V4L2
connection graph. This patch parses the connection properties from the
SSDB buffer in DSDT and build the connection using software nodes.
IVSC driver is based on MEI framework (previously known as HECI), it
has two MEI clients, MEI CSI and MEI ACE. Both clients are used to
communicate messages with IVSC firmware. Linux abstracts MEI client
as a device, whose bus type is MEI. And the device is addressed by a
GUID/UUID which is part of the device name of MEI client. After figured
out MEI CSI via the UUID composed device name, this patch setup the
connection between MEI CSI and IPU, and the connection between MEI CSI
and sensor via software nodes.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
ACE is a submodule of IVSC which controls camera sensor's
ownership, belonging to host or IVSC. When IVSC owns camera
sensor, it is for algorithm computing. When host wants to
control camera sensor, ACE module needs to be informed of
ownership with defined interface.
The interface is via MEI. There is a separate MEI UUID, which
this driver uses to enumerate.
To switch ownership of camera sensor between IVSC and host,
the caller specifies the defined ownership information which
will be sent to firmware by sending MEI command.
Device link(device_link_add) is used to set the right camera
sensor ownership before accessing the sensor via I2C. With
DL_FLAG_PM_RUNTIME and DL_FLAG_RPM_ACTIVE, the supplier device
will be PM runtime resumed before the consumer(camera sensor).
So use runtime PM callbacks to transfer the ownership between
host and IVSC.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
CSI is a submodule of IVSC which can route camera sensor data
to the outbound MIPI CSI-2 interface.
The interface communicating with firmware is via MEI. There is
a separate MEI UUID, which this driver uses to enumerate.
To route camera sensor data to host, the information of link
frequency and number of data lanes is sent to firmware by
sending MEI command when starting stream.
CSI also provides a privacy mode. When privacy mode is turned
on, camera sensor can't be used. This means that both IVSC and
host Image Processing Unit(IPU) can't get image data. And when
this mode is turned on, user is notified via v4l2 control
callback.
Link: https://lore.kernel.org/linux-media/20230803115550.1601965-2-sakari.ailus@linux.intel.com
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
A couple of architectures build the __weak versions of
pci_create_resource_files() and pci_remove_resource_files() but don't
have prototypes for these, which causes warnings:
drivers/pci/pci-sysfs.c:1253:12: error: no previous prototype for 'pci_create_resource_files' [-Werror=missing-prototypes]
1253 | int __weak pci_create_resource_files(struct pci_dev *dev) { return 0; }
drivers/pci/pci-sysfs.c:1254:13: error: no previous prototype for 'pci_remove_resource_files' [-Werror=missing-prototypes]
1254 | void __weak pci_remove_resource_files(struct pci_dev *dev) { return; }
Move the prototypes from alpha architecture into the global header to avoid
these warnings for all of them.
Link: https://lore.kernel.org/r/20230810141947.1236730-5-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
When we have a struct pci_dev *, use pci_dev_id() instead of manually
composing the ID from dev->bus->number and dev->devfn.
[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20230811111057.31900-1-zhengzengkai@huawei.com
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Summary
=======
This introduces FSCONFIG_CMD_CREATE_EXCL which will allows userspace to
implement something like mount -t ext4 --exclusive /dev/sda /B which
fails if a superblock for the requested filesystem does already exist:
Before this patch
-----------------
$ sudo ./move-mount -f xfs -o source=/dev/sda4 /A
Requesting filesystem type xfs
Mount options requested: source=/dev/sda4
Attaching mount at /A
Moving single attached mount
Setting key(source) with val(/dev/sda4)
$ sudo ./move-mount -f xfs -o source=/dev/sda4 /B
Requesting filesystem type xfs
Mount options requested: source=/dev/sda4
Attaching mount at /B
Moving single attached mount
Setting key(source) with val(/dev/sda4)
After this patch with --exclusive as a switch for FSCONFIG_CMD_CREATE_EXCL
--------------------------------------------------------------------------
$ sudo ./move-mount -f xfs --exclusive -o source=/dev/sda4 /A
Requesting filesystem type xfs
Request exclusive superblock creation
Mount options requested: source=/dev/sda4
Attaching mount at /A
Moving single attached mount
Setting key(source) with val(/dev/sda4)
$ sudo ./move-mount -f xfs --exclusive -o source=/dev/sda4 /B
Requesting filesystem type xfs
Request exclusive superblock creation
Mount options requested: source=/dev/sda4
Attaching mount at /B
Moving single attached mount
Setting key(source) with val(/dev/sda4)
Device or resource busy | move-mount.c: 300: do_fsconfig: i xfs: reusing existing filesystem not allowed
Details
=======
As mentioned on the list (cf. [1]-[3]) mount requests like
mount -t ext4 /dev/sda /A are ambigous for userspace. Either a new
superblock has been created and mounted or an existing superblock has
been reused and a bind-mount has been created.
This becomes clear in the following example where two processes create
the same mount for the same block device:
P1 P2
fd_fs = fsopen("ext4"); fd_fs = fsopen("ext4");
fsconfig(fd_fs, FSCONFIG_SET_STRING, "source", "/dev/sda"); fsconfig(fd_fs, FSCONFIG_SET_STRING, "source", "/dev/sda");
fsconfig(fd_fs, FSCONFIG_SET_STRING, "dax", "always"); fsconfig(fd_fs, FSCONFIG_SET_STRING, "resuid", "1000");
// wins and creates superblock
fsconfig(fd_fs, FSCONFIG_CMD_CREATE, ...)
// finds compatible superblock of P1
// spins until P1 sets SB_BORN and grabs a reference
fsconfig(fd_fs, FSCONFIG_CMD_CREATE, ...)
fd_mnt1 = fsmount(fd_fs); fd_mnt2 = fsmount(fd_fs);
move_mount(fd_mnt1, "/A") move_mount(fd_mnt2, "/B")
Not just does P2 get a bind-mount but the mount options that P2
requestes are silently ignored. The VFS itself doesn't, can't and
shouldn't enforce filesystem specific mount option compatibility. It
only enforces incompatibility for read-only <-> read-write transitions:
mount -t ext4 /dev/sda /A
mount -t ext4 -o ro /dev/sda /B
The read-only request will fail with EBUSY as the VFS can't just
silently transition a superblock from read-write to read-only or vica
versa without risking security issues.
To userspace this silent superblock reuse can become a security issue in
because there is currently no straightforward way for userspace to know
that they did indeed manage to create a new superblock and didn't just
reuse an existing one.
This adds a new FSCONFIG_CMD_CREATE_EXCL command to fsconfig() that
returns EBUSY if an existing superblock would be reused. Userspace that
needs to be sure that it did create a new superblock with the requested
mount options can request superblock creation using this command. If the
command succeeds they can be sure that they did create a new superblock
with the requested mount options.
This requires the new mount api. With the old mount api it would be
necessary to plumb this through every legacy filesystem's
file_system_type->mount() method. If they want this feature they are
most welcome to switch to the new mount api.
Following is an analysis of the effect of FSCONFIG_CMD_CREATE_EXCL on
each high-level superblock creation helper:
(1) get_tree_nodev()
Always allocate new superblock. Hence, FSCONFIG_CMD_CREATE and
FSCONFIG_CMD_CREATE_EXCL are equivalent.
The binderfs or overlayfs filesystems are examples.
(4) get_tree_keyed()
Finds an existing superblock based on sb->s_fs_info. Hence,
FSCONFIG_CMD_CREATE would reuse an existing superblock whereas
FSCONFIG_CMD_CREATE_EXCL would reject it with EBUSY.
The mqueue or nfsd filesystems are examples.
(2) get_tree_bdev()
This effectively works like get_tree_keyed().
The ext4 or xfs filesystems are examples.
(3) get_tree_single()
Only one superblock of this filesystem type can ever exist.
Hence, FSCONFIG_CMD_CREATE would reuse an existing superblock
whereas FSCONFIG_CMD_CREATE_EXCL would reject it with EBUSY.
The securityfs or configfs filesystems are examples.
Note that some single-instance filesystems never destroy the
superblock once it has been created during the first mount. For
example, if securityfs has been mounted at least onces then the
created superblock will never be destroyed again as long as there is
still an LSM making use it. Consequently, even if securityfs is
unmounted and the superblock seemingly destroyed it really isn't
which means that FSCONFIG_CMD_CREATE_EXCL will continue rejecting
reusing an existing superblock.
This is acceptable thugh since special purpose filesystems such as
this shouldn't have a need to use FSCONFIG_CMD_CREATE_EXCL anyway
and if they do it's probably to make sure that mount options aren't
ignored.
Following is an analysis of the effect of FSCONFIG_CMD_CREATE_EXCL on
filesystems that make use of the low-level sget_fc() helper directly.
They're all effectively variants on get_tree_keyed(), get_tree_bdev(),
or get_tree_nodev():
(5) mtd_get_sb()
Similar logic to get_tree_keyed().
(6) afs_get_tree()
Similar logic to get_tree_keyed().
(7) ceph_get_tree()
Similar logic to get_tree_keyed().
Already explicitly allows forcing the allocation of a new superblock
via CEPH_OPT_NOSHARE. This turns it into get_tree_nodev().
(8) fuse_get_tree_submount()
Similar logic to get_tree_nodev().
(9) fuse_get_tree()
Forces reuse of existing FUSE superblock.
Forces reuse of existing superblock if passed in file refers to an
existing FUSE connection.
If FSCONFIG_CMD_CREATE_EXCL is specified together with an fd
referring to an existing FUSE connections this would cause the
superblock reusal to fail. If reusing is the intent then
FSCONFIG_CMD_CREATE_EXCL shouldn't be specified.
(10) fuse_get_tree()
-> get_tree_nodev()
Same logic as in get_tree_nodev().
(11) fuse_get_tree()
-> get_tree_bdev()
Same logic as in get_tree_bdev().
(12) virtio_fs_get_tree()
Same logic as get_tree_keyed().
(13) gfs2_meta_get_tree()
Forces reuse of existing gfs2 superblock.
Mounting gfs2meta enforces that a gf2s superblock must already
exist. If not, it will error out. Consequently, mounting gfs2meta
with FSCONFIG_CMD_CREATE_EXCL would always fail. If reusing is the
intent then FSCONFIG_CMD_CREATE_EXCL shouldn't be specified.
(14) kernfs_get_tree()
Similar logic to get_tree_keyed().
(15) nfs_get_tree_common()
Similar logic to get_tree_keyed().
Already explicitly allows forcing the allocation of a new superblock
via NFS_MOUNT_UNSHARED. This effectively turns it into
get_tree_nodev().
Link: [1] https://lore.kernel.org/linux-block/20230704-fasching-wertarbeit-7c6ffb01c83d@brauner
Link: [2] https://lore.kernel.org/linux-block/20230705-pumpwerk-vielversprechend-a4b1fd947b65@brauner
Link: [3] https://lore.kernel.org/linux-fsdevel/20230725-einnahmen-warnschilder-17779aec0a97@brauner
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
Message-Id: <20230802-vfs-super-exclusive-v2-4-95dc4e41b870@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Split the steps to reconfigure a superblock into a tiny helper instead
of open-coding it in the switch.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
Message-Id: <20230802-vfs-super-exclusive-v2-3-95dc4e41b870@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Split the steps to create a superblock into a tiny helper. This will
make the next patch easier to follow.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
Message-Id: <20230802-vfs-super-exclusive-v2-2-95dc4e41b870@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
The get_tree_single_reconf() helper isn't used anywhere. Remove it.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
Message-Id: <20230802-vfs-super-exclusive-v2-1-95dc4e41b870@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Running the bench_rename test script, the following error occurs:
# ./benchs/run_bench_rename.sh
base : 0.819 ± 0.012M/s
kprobe : 0.538 ± 0.009M/s
kretprobe : 0.503 ± 0.004M/s
rawtp : 0.779 ± 0.020M/s
fentry : 0.726 ± 0.007M/s
fexit : 0.691 ± 0.007M/s
benchmark 'rename-fmodret' not found
The bench_rename_fmodret has been removed in commit b000def2e0
("selftests: Remove fmod_ret from test_overhead"), thus remove it
from the runners in the test script.
Fixes: b000def2e0 ("selftests: Remove fmod_ret from test_overhead")
Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20230814030727.3010390-1-zouyipeng@huawei.com
1. Tegra:
- Extend support for Tegra234 SoC Memory Controllers with DRM and GPU
clients.
- Tegra186: Skip MRQ DVFS where it is not supported and do not fail
probe.
2. Wide cleanup of DT includes.
3. Devicetree bindings:
- Reference common peripheral (client) properties in Ingenic NEMC and
TI GPMC.
- Convert Davicom DM9000 to DT schema.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmTaFZAQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD18seEACbP3gOtRxG8hRnZ6mZvV+6bfEaQAKLuVN2
cuQ/cuyHYzCtCxoo3dJyobTJOR5LFXNlNb5ch5+QrzPXFj9YeJxuXKn+eYrLssDu
pkzMkAskDm1Xi181pylsmTh878u7G2jmvuq87l5yc+U3YxryIkhTejW/zl995JtP
pS28viuP6ywa0RyAquoc9mWQQQc++tR/Z958jBAkiECsb0Q7KOsXP0+XqHYxRCQ8
ea/tLzbs1sdDNE0PBRB9zZ9yS3DAVZkBmdWpNexNWFJAdkOLeUqTe2qMTOorPxkA
YzYyl9nTbNMcAh3Uj6J9eONNqiSZuBAqmSVG2S7G2HP1xMReElnLu5BNaWplr2me
xr39F0RPPtV6pSj30D80uyB+Gbuo3KFCXbs2rTPPlGWZeKBEVbaOrvcQnb9XSSGZ
W3DwwTKi/Fgus5cTRtHvYY78596734XZzd4QtA9b3fIF59qUZwoxreSPbpAVwyjX
P1Nhpc0T/65S63VIJYiiv1L+9efu9IhGON6eNmUAr416/otzkYNEtXG+kMY70k6e
9vuWdc9/J3eQqHuVtHYmX162aqIImIEJOYu+M5p8hIgaNBan8GkwIiyRsPIXH0h1
tFn4nicO0TU0B3G2TdKRJcZsNLcdzEZ0pzYQrYnrgsIPCIcOOj2y/qgKuy2m5oev
sfWxLOmm9g==
=2YX2
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmTaVh8ACgkQYKtH/8kJ
UicVMw//WLPFEadd/RKZfQQWJ2/I0LVwG/lasQd9ZXiHMKWuUvfmFsO/cdiwMWZf
S+5g0vR/zRtvaEmLM+ICLzIxwuHG9IdmiIB+K2aVF3s2vttycG6KS2Hak4ryaYXK
Yzo7W6GFGeK+Yn763tj/5GVWdHqzqLzs7vBoZbjoIZDX3sVouTmBENUh+Trmwv/j
Vm/7Jz5napGwqICFkcPFh2BKQ9BxlO7oL8nx/qKmjCWRnccgQJEjKLaIcYNQKUYN
gUHX8bUjRPu2/KJq/Z0unMi57vSra0hVA+G7izmGznSOllIEfa3p+AbBVQ4Zpj1P
d3Npvfub2iDTI/liHUEmjRRCGOS/mL9BrWs+YymlMmr40Hgqf0VjsJiABLkZuemB
RbIBMwuLJsEo5VLLMk+DSHV20tm800zSoF7aX1CER2pzNTGiJ+fIMqp6igbasE3k
bpHElXh3AnrqUsKnazJGsZI1zw6Sk/9JhCh+oECZo48Mfa7YXhj0kJF+R1NtQn0/
yPEElcaKLuo1fJgQi4aLdvUKu2fPmfOj9w7Ivbxt6FmsOfzzlhSasSoMSROFtApa
5LpS8DiNUyFVEqvMYrBqb9oI2bI02XBt8nqPl5tnu2JkZ5zjDmYp1oBiIMOJg6r1
22edeNdbnaaCDxxcQtgaB3reYxurmhRe/gPOlFupHdH9dt5a51I=
=19if
-----END PGP SIGNATURE-----
Merge tag 'memory-controller-drv-6.6' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers
Memory controller drivers for v6.6
1. Tegra:
- Extend support for Tegra234 SoC Memory Controllers with DRM and GPU
clients.
- Tegra186: Skip MRQ DVFS where it is not supported and do not fail
probe.
2. Wide cleanup of DT includes.
3. Devicetree bindings:
- Reference common peripheral (client) properties in Ingenic NEMC and
TI GPMC.
- Convert Davicom DM9000 to DT schema.
* tag 'memory-controller-drv-6.6' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
memory: tegra: add MC client for Tegra234 GPU
dt-bindings: net: davicom,dm9000: convert to DT schema
dt-bindings: memory-controllers: reference TI GPMC peripheral properties
dt-bindings: memory-controllers: ingenic,nemc: reference peripheral properties
memory: Explicitly include correct DT includes
memory: tegra: Prefer octal over symbolic permissions
memory: tegra: add check if MRQ_EMC_DVFS_LATENCY is supported
memory: tegra: Add clients used by DRM in Tegra234
memory: tegra: sort tegra234_mc_clients table as per register offsets
memory: tegra: make icc_set_bw return zero if BWMGR not supported
memory: tegra: Add dummy implementation on Tegra194
Link: https://lore.kernel.org/r/20230814120052.27485-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
iproc_i2c_rd_reg() and iproc_i2c_wr_reg() are called from both
interrupt context (e.g. bcm_iproc_i2c_isr) and process context
(e.g. bcm_iproc_i2c_suspend). Therefore, interrupts should be
disabled to avoid potential deadlock. To prevent this scenario,
use spin_lock_irqsave().
Fixes: 9a10387280 ("i2c: iproc: add NIC I2C support")
Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
Acked-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Updates:
- Consolidation of files and drop pm_domain.c and keystone.h
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE+KKGk1TrgjIXoxo03bWEnRc2JJ0FAmTaSXkACgkQ3bWEnRc2
JJ3xwQ//aXbS2nrgWMUgK8JkcoPKSnRYL8DVp9ng3gsJb3VrVxKsYjqCvKVfeJ37
ppRIR/5SFMu/vT1fWWVS28sQOoEb211avY6bd2x0Hoj58uTQ5lch40R63j6e6vT1
cWrJose27KYJELY9tGnDYlKp+eh+0RhBJUCmwdLkPwFlldXqlpzFFLzD1baXHaYL
R2wZJl1EQuc/o3r2G2kQIX6PlV/F3+/8RGrVqpbXWbe9pFRiZZeKiuHnaXxd45AS
+mbdxYYUQCnylfxg1q34qjB5AQ33Vl/LZLhsh2lblBqZITo11hiv2+XIsxMhBJQ1
lJO7fNe6wWrZ8HJUzu9NtTpy1omQCFBHWG/iN3vyYzbIgfqDqyz8lSGpze/UOoX6
AwvDPhPrHB/LyNOC/tHt68dGaqSTtfv75JgyLJf48fxngOBjPO8kqYDCtFpJvAUC
M/hhkJlm7MCVK8y0gtQhwSyjC957DzSvxKHsYKXfMdR68JU+uD7MI7kx2stWxY22
/WjWqAQIGoRpb9vDC2ylgGVPuGtfSJBwIRg+0biceB3AiMnbGCxFBxC68UGQ4dW2
2+8AHmeyr35QMH5U+uZxhZtwULzVSQKhH62IPEg5eK7XZOQzkcne59qae2zwiL1h
qSuO29xqr9lknY3cUG8Cvfs5dQ7wVauAjrmQGobzDzgPbMLxPL0=
=QSA2
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmTaU1QACgkQYKtH/8kJ
UicCRQ//Q+1UQlzbh0cYP2Rrn6KOoCbyhepYE52/MVOhSR+UiRJjjuTI7niOgzsK
2X0ZS0LYM1aaVju1RVsi4wk5MpjSXf9R0WhfH7MnPGCalx5NvuvXS46pu6mvUE6U
oc8MKJZl8BPSvW63BT72UhA4d2MMoEZgeIUVc8x6ZsWkO+0crkNuy6qypAJWUctA
2br5137l4JmuwxSPTsZ3Dz1q3xbHvdX4oL13OlokMpLMwTEw0IPEnCFjRscs8qa+
YiK5V7I00CvVOZZf2R4VahJkFpehgQS8oKXghhQKcg34sKvFj/YKmAg8sZPSyQfI
ETEHFmsnCMJhIW094OrdaY29TfE6E+6hPyBW5QNiOq2pLlD3kn1o6adnSG1gAc4A
frSsPbQ4jxZWSKkpkUWl9e47pHsp/2sN9+5Ga/YLtcorbX8xzs4hZmSLSrMA8Spm
H7MfPZZ7aJH8K4aYcoiHNpki+aUolIRqxTjssu86lrRnHs16qcFtjNHH5OnMYxu9
8w20/rW9ahqrpkf9kvwhvB1OOW3b1JATGGCejoL4DoZ4W2CISqo6rJjIxCDUcMSN
uykFDFvQV3o53ybAJkpQk7+JjOBkmKG3NVlk0vWevGoPyBiT/rmH/ziwLmpG3Bah
qklejmjPUzkcDAn8TwWCj2Zq5mudOXlscevVeVC7PvUjyWts4lI=
=kFIn
-----END PGP SIGNATURE-----
Merge tag 'ti-keystone-soc-for-v6.6' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/arm
TI keystone SoC updates for v6.6
Updates:
- Consolidation of files and drop pm_domain.c and keystone.h
* tag 'ti-keystone-soc-for-v6.6' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux:
ARM: keystone: Merge PM function into main support file
ARM: keystone: Merge memory.h into the only file that uses it
ARM: keystone: Drop unused includes
Link: https://lore.kernel.org/r/20230814160702.6l2fcujbx33eogap@junction
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230720172751.2918776-1-robh@kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230814114051.25840-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Since commit 03c835f498 ("i2c: Switch .probe() to not take an id
parameter") .probe() is the recommended callback to implement (again).
Reflect this in the documentation and don't mention .probe_new() any
more.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Kamal Dasu <kamal.dasu@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Acked-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
There is no way where topts.repeat can be set to 1 when tc_test fails.
Fix the typo where the break statement slipped by one line.
Fixes: fb66223a24 ("selftests/bpf: add test for accessing ctx from syscall program type")
Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/bpf/20230814031434.3077944-1-zouyipeng@huawei.com
This code was only used in the past for the sysfs interface. But since
this was replace with netlink, it was never executed. The function pointer
was only checked to figure out whether the limit 255 (B.A.T.M.A.N. IV) or
2**32-1 (B.A.T.M.A.N. V) should be used as limit.
So instead of keeping the function pointer, just store the limits directly
in struct batadv_algo_gw_ops.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
The batadv_netlink_notify_*() functions are not used by any other source
file. Just keep them local to netlink.c to get informed by the compiler
when they are not used anymore.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
This function is no longer used since the sysfs support was removed from
batman-adv.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
- A series from NXP i.MX developers (Peng Fan, etc.) to update imx-scu
and imx-scu-irq firmware drivers.
- Add dedicated lockdep class for nested genpd locks to fix a lockdep
warning in imx93-blk-ctrl driver.
- A change from Rob to explicitly include correct DT headers for i.MX
SoC drivers.
- Use devm_platform_ioremap_resource() in imx-weim bus driver.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmTYNCAUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM7x+wgAsB65MMhY74a8pjuO0q1nJierjc46
of2ayxR8I1jXQK/3IUijBZpg+8bnQkhXiVK1uyzvLmUc28iw1y6B2dWec/hXRld8
mc516IWjGa0Re+dOeliKPFNWzj6TZRi3TmqKIfg5XIb0poBtxBiXm7tvjm1oYRQl
ijkCqauOXJmK3yMMTQqxknGQG+B8wQDTPnbssk0A46ShD4RrYXmC3wjTEb27WoGk
nw18XT5XpS+LomctRcqza3Bcdry6YPmI0hOt9Oy9db2sBtXbz+bf9tLGKztvfxGz
44R0+Rz/XncJHwRXGgUNR71ps0+WP55qKsqoTw/zHhkS2BPl8gMxhBtQbQ==
=T2Uo
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmTaT8sACgkQYKtH/8kJ
UieFHQ//YrvUhNJjVtQeUcZ4s43MKKJsq7HNnki02ZRlIOdcG+vM7JzWe6PsRDbK
8jeV1tM3ZE67VBeIZU1+ELshebiU01VQY4ZobmGOPMajDFXZmu1Znzr8O6RASrmd
u+aFhpTGleg4SQQ2avdaQIQ4gpw19ciellxCTx37Y/hae06nANXzFFTlnPO4qseW
rzJzgh2h3Z1Gv/LdqtlfMAeI2aEQy/+hfKmZs4f20/Rs8wwH7lzrNLSUideY6cqt
RM1nX3F97b+glRJ4siqRoUISVSW6naWkb5qZ+VZXN4e7xrczuV/1Sp2dqINWXxKp
dR3WpOfb2V9sIGQOiAb8XSFBkxvDVG6ze6l2RkXA0szqpVBRMOTGshykMqt2I2tN
8Eeek9+XXZHZxNR6omFX4cvTjRW7hvhB0W35UdoZr1qteC8jV/H1DBYV3v8ri1d8
z17Y0JGBFrtQFBF/jq1yK0WND4RIb2aHYxrojDQ3/mtqsMailIuogwGpMQyhsCll
nX2NeKpaKe3MwEtKPOSTkUD5k8TLBfDOn/fcoLRQ6Ys6fsBAcplJ+6Sp3Hv/mgWQ
W9eWaeBAh0BllI66twAxeTKdy/1IsGpsLyNVDJliAExW3Z1ISPUMw6pI4M+H/QZY
W+joqcvJYAAiOfIvRqQWvyt40I/2JYx6otsJKN4JB9Qlh3QRvxg=
=2iHc
-----END PGP SIGNATURE-----
Merge tag 'imx-drivers-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/drivers
i.MX drivers update for 6.6:
- A series from NXP i.MX developers (Peng Fan, etc.) to update imx-scu
and imx-scu-irq firmware drivers.
- Add dedicated lockdep class for nested genpd locks to fix a lockdep
warning in imx93-blk-ctrl driver.
- A change from Rob to explicitly include correct DT headers for i.MX
SoC drivers.
- Use devm_platform_ioremap_resource() in imx-weim bus driver.
* tag 'imx-drivers-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
firmware: imx: scu-irq: support identifying SCU wakeup source from sysfs
firmware: imx: scu-irq: enlarge the IMX_SC_IRQ_NUM_GROUP
firmware: imx: scu-irq: add imx_scu_irq_get_status
firmware: imx: scu-irq: fix RCU complaint after M4 partition reset
firmware: imx: scu: use EOPNOTSUPP
firmware: imx: scu: use soc name for soc_id
firmware: imx: scu: increase RPC timeout
firmware: imx: scu: change init level to subsys_initcall_sync
soc: imx: Explicitly include correct DT includes
bus: imx-weim: use devm_platform_ioremap_resource
soc: imx: imx93-blk-ctrl: Add dedicated lockdep class for nested genpd locks
Link: https://lore.kernel.org/r/20230813133354.847010-1-shawnguo@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
