This was used to track if the item had logged fields being flushed
to disk. We log everything in the inode these days, so this logic is
no longer needed. Remove it.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
In tracking down a problem in this patchset, I discovered we are
reclaiming dirty stale inodes. This wasn't discovered until inodes
were always attached to the cluster buffer and then the rcu callback
that freed inodes was assert failing because the inode still had an
active pointer to the cluster buffer after it had been reclaimed.
Debugging the issue indicated that this was a pre-existing issue
resulting from the way the inodes are handled in xfs_inactive_ifree.
When we free a cluster buffer from xfs_ifree_cluster, all the inodes
in cache are marked XFS_ISTALE. Those that are clean have nothing
else done to them and so eventually get cleaned up by background
reclaim. i.e. it is assumed we'll never dirty/relog an inode marked
XFS_ISTALE.
On journal commit dirty stale inodes as are handled by both
buffer and inode log items to run though xfs_istale_done() and
removed from the AIL (buffer log item commit) or the log item will
simply unpin it because the buffer log item will clean it. What happens
to any specific inode is entirely dependent on which log item wins
the commit race, but the result is the same - stale inodes are
clean, not attached to the cluster buffer, and not in the AIL. Hence
inode reclaim can just free these inodes without further care.
However, if the stale inode is relogged, it gets dirtied again and
relogged into the CIL. Most of the time this isn't an issue, because
relogging simply changes the inode's location in the current
checkpoint. Problems arise, however, when the CIL checkpoints
between two transactions in the xfs_inactive_ifree() deferops
processing. This results in the XFS_ISTALE inode being redirtied
and inserted into the CIL without any of the other stale cluster
buffer infrastructure being in place.
Hence on journal commit, it simply gets unpinned, so it remains
dirty in memory. Everything in inode writeback avoids XFS_ISTALE
inodes so it can't be written back, and it is not tracked in the AIL
so there's not even a trigger to attempt to clean the inode. Hence
the inode just sits dirty in memory until inode reclaim comes along,
sees that it is XFS_ISTALE, and goes to reclaim it. This reclaiming
of a dirty inode caused use after free, list corruptions and other
nasty issues later in this patchset.
Hence this patch addresses a violation of the "never log XFS_ISTALE
inodes" caused by the deferops processing rolling a transaction
and relogging a stale inode in xfs_inactive_free. It also adds a
bunch of asserts to catch this problem in debug kernels so that
we don't reintroduce this problem in future.
Reproducer for this issue was generic/558 on a v4 filesystem.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Remove current_pid(), current_test_flags() and
current_clear_flags_nested(), because they are useless.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
The page faultround path ->map_pages is implemented in XFS via
filemap_map_pages(). This function checks that pages found in page
cache lookups have not raced with truncate based invalidation by
checking page->mapping is correct and page->index is within EOF.
However, we've known for a long time that this is not sufficient to
protect against races with invalidations done by operations that do
not change EOF. e.g. hole punching and other fallocate() based
direct extent manipulations. The way we protect against these
races is we wrap the page fault operations in a XFS_MMAPLOCK_SHARED
lock so they serialise against fallocate and truncate before calling
into the filemap function that processes the fault.
Do the same for XFS's ->map_pages implementation to close this
potential data corruption issue.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Move the double-inode locking helpers to xfs_inode.c since they're not
specific to reflink.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Refactor the two functions that we use to lock and unlock two inodes to
block userspace from initiating IO against a file, whether via system
calls or mmap activity.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Fix the return value of xfs_reflink_remap_prep so that its return value
conventions match the rest of xfs.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
If the source and destination map are identical, we can skip the remap
step to save some time.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
When logging quota block count updates during a reflink operation, we
only log the /delta/ of the block count changes to the dquot. Since we
now know ahead of time the extent type of both dmap and smap (and that
they have the same length), we know that we only need to reserve quota
blocks for dmap's blockcount if we're mapping it into a hole.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Now that we've reworked xfs_reflink_remap_extent to remap only one
extent per transaction, we actually know if the extent being removed is
an allocated mapping. This means that we now know ahead of time if
we're going to be touching the data fork.
Since we only need blocks for a bmbt split if we're going to update the
data fork, we only need to get quota reservation if we know we're going
to touch the data fork.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
The existing reflink remapping loop has some structural problems that
need addressing:
The biggest problem is that we create one transaction for each extent in
the source file without accounting for the number of mappings there are
for the same range in the destination file. In other words, we don't
know the number of remap operations that will be necessary and we
therefore cannot guess the block reservation required. On highly
fragmented filesystems (e.g. ones with active dedupe) we guess wrong,
run out of block reservation, and fail.
The second problem is that we don't actually use the bmap intents to
their full potential -- instead of calling bunmapi directly and having
to deal with its backwards operation, we could call the deferred ops
xfs_bmap_unmap_extent and xfs_refcount_decrease_extent instead. This
makes the frontend loop much simpler.
Solve all of these problems by refactoring the remapping loops so that
we only perform one remapping operation per transaction, and each
operation only tries to remap a single extent from source to dest.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reported-by: Edwin Török <edwin@etorok.net>
Tested-by: Edwin Török <edwin@etorok.net>
The name of this predicate is a little misleading -- it decides if the
extent mapping is allocated and written. Change the name to be more
direct, as we're going to add a new predicate in the next patch.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Quota reservations are supposed to account for the blocks that might be
allocated due to a bmap btree split. Reflink doesn't do this, so fix
this to make the quota accounting more accurate before we start
rearranging things.
Fixes: 862bb360ef ("xfs: reflink extents from one file to another")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
The data fork scrubber calls filemap_write_and_wait to flush dirty pages
and delalloc reservations out to disk prior to checking the data fork's
extent mappings. Unfortunately, this means that scrub can consume the
EIO/ENOSPC errors that would otherwise have stayed around in the address
space until (we hope) the writer application calls fsync to persist data
and collect errors. The end result is that programs that wrote to a
file might never see the error code and proceed as if nothing were
wrong.
xfs_scrub is not in a position to notify file writers about the
writeback failure, and it's only here to check metadata, not file
contents. Therefore, if writeback fails, we should stuff the error code
back into the address space so that an fsync by the writer application
can pick that up.
Fixes: 99d9d8d05d ("xfs: scrub inode block mappings")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
The rmapbt extent swap algorithm remaps individual extents between
the source inode and the target to trigger reverse mapping metadata
updates. If either inode straddles a format or other bmap allocation
boundary, the individual unmap and map cycles can trigger repeated
bmap block allocations and frees as the extent count bounces back
and forth across the boundary. While net block usage is bound across
the swap operation, this behavior can prematurely exhaust the
transaction block reservation because it continuously drains as the
transaction rolls. Each allocation accounts against the reservation
and each free returns to global free space on transaction roll.
The previous workaround to this problem attempted to detect this
boundary condition and provide surplus block reservation to
acommodate it. This is insufficient because more remaps can occur
than implied by the extent counts; if start offset boundaries are
not aligned between the two inodes, for example.
To address this problem more generically and dynamically, add a
transaction accounting mode that returns freed blocks to the
transaction reservation instead of the superblock counters on
transaction roll and use it when the rmapbt based algorithm is
active. This allows the chain of remap transactions to preserve the
block reservation based own its own frees and prevent premature
exhaustion regardless of the remap pattern. Note that this is only
safe for superblocks with lazy sb accounting, but the latter is
required for v5 supers and the rmap feature depends on v5.
Fixes: b3fed43482 ("xfs: account format bouncing into rmapbt swapext tx reservation")
Root-caused-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Michael Guralnik says:
====================
This series handles IPoIB child interface creation with setting
interface's HW address.
In current implementation, lladdr requested by user is ignored and
overwritten. Child interface gets the same GID as the parent interface and
a QP number which is assigned by the underlying drivers.
In this series we fix this behavior so that user's requested address is
assigned to the newly created interface.
As specific QP number request is not supported for all vendors, QP number
requested by user will still be overwritten when this is not supported.
Behavior of creation of child interfaces through the sysfs mechanism or
without specifying a requested address, stays the same.
====================
Based on the mlx5-next branch at
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
due to dependencies.
* branch 'mlx5_ipoib_qpn':
RDMA/ipoib: Handle user-supplied address when creating child
net/mlx5: Enable QP number request when creating IPoIB underlay QP
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
The initial CI results did not include a TGL system which includes a
panel that is having issues with patch. Revert while we triage.
This reverts commit 680c45c767.
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200702230957.30536-1-matthew.s.atwood@intel.com
init_on_alloc and init_on_free options work.
- Fix vfio-ccw build error due to missing include.
- Prevent callchain data collection with hardware sampling, since the
callchains simply do not exist.
- Prevent multiple registrations of the same zPCI function.
- Update defconfigs.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEECMNfWEw3SLnmiLkZIg7DeRspbsIFAl8DQcMACgkQIg7DeRsp
bsKvuRAArbyG3KYcBCJ4GnNNXlXgji2MZyiHHvXgy2CwzttNVJpZUN1UHeSb6zC6
PDp3K+bJwgH0UHSGi3cMEtPLD0ccEApXeYJ0f/dHrZ6e0YvnKR1KHy2o/givYBN0
hvXpoSYlVZb8wtYV4Npr66NoT4Gp2RHC8ZJtouJVQ/9dIpIddI7ZmsEs4hUELgVz
1VAknDL+FNfOrD39+psCEWyju8+W08IfVMtyGmRn5RfvLESqB7GgJtmLybng+BdJ
3RTneFKDGogFpdgcVVDyND99+xh0zxDlXkzjVnS/lAHe9+M9X4/OAiQwctX4b5jA
Ev0ZPX5CYcHKC9PAgW+C3/kCsP+V739ZeUwVnhPkJfsB2BkItIw3c0BXPiF/QCFq
son5qWy4XOyWCxWAqKTrQku7W5+UDBvOmFaN3JxgIYZeM17BJsyaB6ORkVb5Jtt+
OaFIY31apLaljt3gGBFsUgQPjrqxTsn2uHtN4JBxDss6H0zQWdJC2m+cIlZKp9s4
Ix8QikqS08mJ9cL8RzF2lrjCdmg4cklWRKDI9EgrLAsx+fn5mWGcP7EQV3gtArm4
3xxgGHSUUXUm//Uaqs6xI0mSOt29valljHSbdRAJfK9oaAnPDvL1RNvdBgAi73ES
PMdnG2Tp/zYJbHjFs2bOBW3RnWpM9LrYYgTgl34D3d2J+c74z/I=
=79cE
-----END PGP SIGNATURE-----
Merge tag 's390-5.8-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Heiko Carstens:
- Initialize jump labels before early command line parsing in order to
make init_on_alloc and init_on_free options work
- Fix vfio-ccw build error due to missing include
- Prevent callchain data collection with hardware sampling, since the
callchains simply do not exist
- Prevent multiple registrations of the same zPCI function
- Update defconfigs
* tag 's390-5.8-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
vfio-ccw: Fix a build error due to missing include of linux/slab.h
s390: update defconfigs
s390/cpum_sf: prohibit callchain data collection
s390/setup: init jump labels before command line parsing
s390/maccess: add no DAT mode to kernel_write
s390/pci: fix enabling a reserved PCI function
- Disable preemption on context-switching PMU EL0 state happening
on system register trap
- Don't clobber X0 when tearing down KVM via a soft reset (kexec)
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAl8DAcQPHG1hekBrZXJu
ZWwub3JnAAoJECPQ0LrRPXpD7qgP/3xVVCyO32eqfe+Vh+0cHun3yfMKYPHdhrT4
rXPoJbUFNXu/pvMuPd1plh5DJM/sdZtrC96tgswDmF00Yk9ObdLDafgSFCrscfMU
GrgSEGplTve1RArzATSC64nfFzJqkJlLNywJeD1bFmh4qC5rbm7w8jStf4H6MEp3
sBXedqQO+WswDLQAPnMCXw5t4uNU4urA757fKWJAgJv2Xwx0NKG+3PFbvx9I4dcK
M0q+266ufDbq3xv6bhvFqo4kOnZQKH2fwIENRZVHi+5iU7Em2EX6NpzmbxxGCAfD
d3jGCcrJ8f959j/d23k0lZXU0V30h3gvifGHUwEz/hqnbi1+EOt9pGqnqMWgmwPf
QdoVtL9CdUeyAlfROLMBp0gxXwlUgN5dodCE9BlTzctUCQFRTsZPgAktEDlKcUWh
rFz4LyoZ82OiC+db+wOHRTL+q7b0gs/KUgLbkeu26WGvDuLU4kEtol1ScmrfSm7O
VzKxHzaxLsm6LP/OcS+9r9qHU2RRHhJnuwSNmsueGnKSFV2AECrsgoKGO5Tl2kKU
rWnpJY/lqlChGsu4nfPeRQIcQtVL3H6BM7hz7d+EM4/Yx70EzmaTOB8K2C15o6BI
tDuLWzzAaaY4YqFEVgvaieRuI+2qZWCh8jSu5sPuC6StfpqDD/G4221Q6vn3ioor
g8hUv78j
=/VkN
-----END PGP SIGNATURE-----
Merge tag 'kvmarm-fixes-5.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master
KVM/arm fixes for 5.8, take #3
- Disable preemption on context-switching PMU EL0 state happening
on system register trap
- Don't clobber X0 when tearing down KVM via a soft reset (kexec)
Use the address supplied by user when creating a child interface.
Previously, the address requested by the user was ignored and overridden
with parent's GID and the random QP number assigned to the child.
Link: https://lore.kernel.org/r/20200623110105.1225750-3-leon@kernel.org
Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Reviewed-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
The kernel test robot reports two functions that should be marked
static:
>> drivers/usb/gadget/udc/lpc32xx_udc.c:1928:6: warning: no previous prototype for 'udc_send_in_zlp' [-Wmissing-prototypes]
1928 | void udc_send_in_zlp(struct lpc32xx_udc *udc, struct lpc32xx_ep *ep)
>> drivers/usb/gadget/udc/lpc32xx_udc.c:1942:6: warning: no previous prototype for 'udc_handle_eps' [-Wmissing-prototypes]
1942 | void udc_handle_eps(struct lpc32xx_udc *udc, struct lpc32xx_ep *ep)
This showed up after my commit 792e559e94 ("udc: lpc32xx: fix 64-bit
compiler warning") made it possible to build the driver on x86-64.
Fix the warning as suggested.
Reported-by: kernel test robot <lkp@intel.com>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Increase support for the Renesas RZ/G1H SoC on the iWave RainboW
Qseven board (G21D), and its camera expansion board,
- IPMMU support for R-Car M3-W+,
- Support for Rev.3.0/4.0 of the HopeRun HiHope RZ/G2M and RZ/G2N
boards,
- Minor fixes and improvements.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCXv8cBwAKCRCKwlD9ZEnx
cAJ9AQCu1HWVrJj89lZPYFbKENJwXTDOBF3CEegYkewGteflDAD9F2pKp7bvfXrS
3X3nPaX+cI+tLOTA0+bSwRSjyX3INgo=
=OKk9
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm-dt-for-v5.9-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/dt
Renesas ARM DT updates for v5.9
- Increase support for the Renesas RZ/G1H SoC on the iWave RainboW
Qseven board (G21D), and its camera expansion board,
- IPMMU support for R-Car M3-W+,
- Support for Rev.3.0/4.0 of the HopeRun HiHope RZ/G2M and RZ/G2N
boards,
- Minor fixes and improvements.
* tag 'renesas-arm-dt-for-v5.9-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (36 commits)
ARM: dts: r8a7778: Enable IRLM setup via DT
arm64: dts: renesas: Add HiHope RZ/G2N Rev2.0/3.0/4.0 board with idk-1110wr display
arm64: dts: renesas: Add HiHope RZ/G2N Rev.3.0/4.0 sub board support
arm64: dts: renesas: Add HiHope RZ/G2N Rev.3.0/4.0 main board support
arm64: dts: renesas: Add HiHope RZ/G2M Rev.3.0/4.0 board with idk-1110wr display
arm64: dts: renesas: hihope-rzg2-ex: Separate out lvds specific nodes into common file
arm64: dts: renesas: Add HiHope RZ/G2M Rev.3.0/4.0 sub board support
arm64: dts: renesas: Add HiHope RZ/G2M Rev.3.0/4.0 main board support
arm64: dts: renesas: Add HiHope RZ/G2M[N] Rev.3.0/4.0 specific into common file
arm64: dts: renesas: hihope-common: Separate out Rev.2.0 specific into hihope-rev2.dtsi file
arm64: dts: renesas: r8a774b1-hihope-rzg2n[-ex]: Rename HiHope RZ/G2N boards
arm64: dts: renesas: r8a774a1-hihope-rzg2m[-ex/-ex-idk-1110wr]: Rename HiHope RZ/G2M boards
arm64: dts: renesas: r8a77961: Add IPMMU nodes
ARM: dts: r8a7742: Add MSIOF[0123] support
ARM: dts: r8a7742-iwg21d-q7-dbcm-ca: Add device tree for camera DB
ARM: dts: r8a7742: Add CMT SoC specific support
ARM: dts: r8a7742: Add thermal device to DT
ARM: dts: r8a7742-iwg21d-q7: Sound DMA support via DVC on DTS
ARM: dts: r8a7742-iwg21d-q7: Enable SGTL5000 audio codec
ARM: dts: r8a7742: Add audio support
...
Link: https://lore.kernel.org/r/20200703120642.5128-3-geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A SPI transfer defines the _maximum_ speed of the SPI transfer. However the
driver doesn't take into account that the clock divider is always rounded down
(due to integer arithmetics). This results in a too high clock rate for the SPI
transfer.
E.g.: with a mclk_rate of 24 MHz and a SPI transfer speed of 10 MHz, the
original code calculates a reg of "0", which results in a effective divider of
"2" and a 12 MHz clock for the SPI transfer.
This patch fixes the issue by using DIV_ROUND_UP() instead of a plain
integer division.
While there simplify the divider calculation for the CDR1 case, use
order_base_2() instead of two ilog2() calculations.
Fixes: 3558fe900e ("spi: sunxi: Add Allwinner A31 SPI controller driver")
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20200706143443.9855-2-mkl@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
It's not nice to hold @uring_lock for too long io_iopoll_reap_events().
For instance, the lock is needed to publish requests to @poll_list, and
that locks out tasks doing that for no good reason. Loose it
occasionally.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Nobody adjusts *nr_events (number of completed requests) before calling
io_iopoll_getevents(), so the passed @min shouldn't be adjusted as well.
Othewise it can return less than initially asked @min without hitting
need_resched().
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
->iopoll() may have completed current request, but instead of reaping
it, io_do_iopoll() just continues with the next request in the list.
As a result it can leave just polled and completed request in the list
up until next syscall. Even outer loop in io_iopoll_getevents() doesn't
help the situation.
E.g. poll_list: req0 -> req1
If req0->iopoll() completed both requests, and @min<=1,
then @req0 will be left behind.
Check whether a req was completed after ->iopoll().
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
- Refresh shmobile_defconfig for v5.8-rc1
- Enable additional support for Renesas platforms to
shmobile_defconfig, multi_v7_defconfig, and the arm64 defconfig.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCXv8YvAAKCRCKwlD9ZEnx
cJXnAQDNsLH6WhuPlpjSOHutTm9UkE1a/x9CCuwCOgsAgtGG7gD8CKISt+ZvyK6H
qS5EHvICz6mfCyDa1QjQtyARIeq3iQQ=
=cyc4
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm-defconfig-for-v5.9-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/defconfig
Renesas ARM defconfig updates for v5.9
- Refresh shmobile_defconfig for v5.8-rc1
- Enable additional support for Renesas platforms to
shmobile_defconfig, multi_v7_defconfig, and the arm64 defconfig.
* tag 'renesas-arm-defconfig-for-v5.9-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
arm64: defconfig: Enable additional support for Renesas platforms
ARM: multi_v7_defconfig: Enable additional support for Renesas platforms
ARM: shmobile: defconfig: Enable RZ/A1H RTC support
ARM: shmobile: defconfig: Enable ADV7612 CEC support
ARM: shmobile: defconfig: Enable RZ/A1 CEU support
ARM: shmobile: defconfig: Enable RZ/A watchdog support
ARM: shmobile: defconfig: Enable CAT9554 support
ARM: shmobile: defconfig: Enable DA9063 ONKEY support
ARM: shmobile: defconfig: Refresh for v5.8-rc1
Link: https://lore.kernel.org/r/20200703120642.5128-2-geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add brackets to protect parameters of the recently added sg_table related
macros from side-effects.
Fixes: 709d6d73c7 ("scatterlist: add generic wrappers for iterating over sgtable objects")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
The max value of blkio.bfq.weight is 1000, rather than 10000.
And 'weights' have been remove from /sys/block/XXX/queue/iosched.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Acked-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
describes a generic pixel re-ordering which can be applicable to
multiple vendors.
Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be
used to describe this layout in a vendor-neutral way, and add a
comment about the expected usage of such "generic" modifiers.
Changes in v2:
- Move note about future cases to comment (Daniel)
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200626164800.11595-1-brian.starkey@arm.com
Export necessary APIs to support i.MX8 SCU SoCs pinctrl driver to be
built as module.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Link: https://lore.kernel.org/r/1592979844-18833-3-git-send-email-Anson.Huang@nxp.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Export necessary APIs to support i.MX8 SoCs pinctrl driver to be
built as module.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Link: https://lore.kernel.org/r/1592979844-18833-2-git-send-email-Anson.Huang@nxp.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- Add RPC (HyperFlash and Octal-SPI Flash) pin groups on R-Car V3H and
V3M.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCXv8eOQAKCRCKwlD9ZEnx
cMM1AP9PwW0xGLxy1S+/RiGhu6gl4QNPgwko7rdvrMxNYQXwowD+OsXCq2/CwSJk
BE7Fw1X5j/yWZ4mkLIPReVo4PSvfyA8=
=On87
-----END PGP SIGNATURE-----
Merge tag 'sh-pfc-for-v5.9-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel
pinctrl: sh-pfc: Updates for v5.9
- Add RPC (HyperFlash and Octal-SPI Flash) pin groups on R-Car V3H and
V3M.
We're missing a bunch of options related to the DRM driver options (panels,
HDMI, CEC) that seems useful. Let's add them in the defconfig.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20200705091904.42795-5-maxime@cerno.tech
Acked-by: Chen-Yu Tsai <wens@csie.org>
