Axel Rasmussen [Fri, 10 Jun 2022 17:38:12 +0000 (10:38 -0700)]
mm: userfaultfd: fix UFFDIO_CONTINUE on fallocated shmem pages
When fallocate() is used on a shmem file, the pages we allocate can end up
with !PageUptodate.
Since UFFDIO_CONTINUE tries to find the existing page the user wants to
map with SGP_READ, we would fail to find such a page, since
shmem_getpage_gfp returns with a "NULL" pagep for SGP_READ if it discovers
!PageUptodate. As a result, UFFDIO_CONTINUE returns -EFAULT, as it would
do if the page wasn't found in the page cache at all.
This isn't the intended behavior. UFFDIO_CONTINUE is just trying to find
if a page exists, and doesn't care whether it still needs to be cleared or
not. So, instead of SGP_READ, pass in SGP_NOALLOC. This is the same,
except for one critical difference: in the !PageUptodate case, SGP_NOALLOC
will clear the page and then return it. With this change, UFFDIO_CONTINUE
works properly (succeeds) on a shmem file which has been fallocated, but
otherwise not modified.
Link: https://lkml.kernel.org/r/20220610173812.1768919-1-axelrasmussen@google.com Fixes: 153132571f02 ("userfaultfd/shmem: support UFFDIO_CONTINUE for shmem") Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> Acked-by: Peter Xu <peterx@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
coccinelle: Extend address test from ifaddr semantic patch to test expressions
The test of an expression's address does not necessarily represent the
whole condition, it may only be a part of it. Also, an expression's
address is likely to be non-zero in every test expression, not only in
if statements.
This change aims at detecting an address test in more complex conditions
and not only in if statements.
Signed-off-by: Jérémy Lefaure <jeremy.lefaure@netatmo.com> Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
lockref: remove unused 'lockref_get_or_lock()' function
Looking at the conditional lock acquire functions in the kernel due to
the new sparse support (see commit 4a557a5d1a61 "sparse: introduce
conditional lock acquire function attribute"), it became obvious that
the lockref code has a couple of them, but they don't match the usual
naming convention for the other ones, and their return value logic is
also reversed.
In the other very similar places, the naming pattern is '*_and_lock()'
(eg 'atomic_put_and_lock()' and 'refcount_dec_and_lock()'), and the
function returns true when the lock is taken.
The lockref code is superficially very similar to the refcount code,
only with the special "atomic wrt the embedded lock" semantics. But
instead of the '*_and_lock()' naming it uses '*_or_lock()'.
And instead of returning true in case it took the lock, it returns true
if it *didn't* take the lock.
Now, arguably the reflock code is quite logical: it really is a "either
decrement _or_ lock" kind of situation - and the return value is about
whether the operation succeeded without any special care needed.
So despite the similarities, the differences do make some sense, and
maybe it's not worth trying to unify the different conditional locking
primitives in this area.
But while looking at this all, it did become obvious that the
'lockref_get_or_lock()' function hasn't actually had any users for
almost a decade.
The only user it ever had was the shortlived 'd_rcu_to_refcount()'
function, and it got removed and replaced with 'lockref_get_not_dead()'
back in 2013 in commits 0d98439ea3c6 ("vfs: use lockred 'dead' flag to
mark unrecoverably dead dentries") and e5c832d55588 ("vfs: fix dentry
RCU to refcounting possibly sleeping dput()")
In fact, that single use was removed less than a week after the whole
function was introduced in commit b3abd80250c1 ("lockref: add
'lockref_get_or_lock() helper") so this function has been around for a
decade, but only had a user for six days.
Let's just put this mis-designed and unused function out of its misery.
We can think about the naming and semantic oddities of the remaining
'lockref_put_or_lock()' later, but at least that function has users.
And while the naming is different and the return value doesn't match,
that function matches the whole '{atomic,refcount}_dec_and_test()'
pattern much better (ie the magic happens when the count goes down to
zero, not when it is incremented from zero).
Merge tag 'qcom-arm64-fixes-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm ARM64 DT fixes for v5.19
This removes duplicate includes in the sc7180-trogdor files, which
accidentally ended up disabling nodes intended to be enabled.
It corrects identifiers for CPU6/7 on MSM8994. On SM8450 the UFS node's
interconnects property is updated to match the #interconnect-cells,
avoiding sync_state issues and the GIC ITS is defined, to correct the
references from the PCIe nodes. On SDM845 the display subsystem's AHB
clock is corrected and on msm8992 devices, the supplies for lvs 1 and 2
are correctly specified.
Lastly, a welcome addition of Konrad as reviewer for the Qualcomm SoC.
* tag 'qcom-arm64-fixes-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo
MAINTAINERS: Add myself as a reviewer for Qualcomm ARM/64 support
arm64: dts: qcom: sdm845: use dispcc AHB clock for mdss node
arm64: dts: qcom: sm8450 add ITS device tree node
arm64: dts: qcom: msm8994: Fix CPU6/7 reg values
arm64: dts: qcom: sm8450: fix interconnects property of UFS node
arm64: dts: qcom: Remove duplicate sc7180-trogdor include on lazor/homestar
Add binding for the Emerging Display Technology ETML0700Y5DHA panel.
It is a 7" WSVGA (1024x600) TFT LCD panel with:
- LVDS data interface,
- backlight and
- capacitive touch.
Anton Bambura [Sun, 29 May 2022 18:05:46 +0000 (21:05 +0300)]
dt-bindings: sharp,lq101r1sx01: Add compatible for LQ101R1SX03
LQ101R1SX03 is compatible with LQ101R1SX01 from software perspective,
document it. The LQ101R1SX03 is a newer revision of LQ101R1SX01, it has
minor differences in hardware pins in comparison to the older version.
The newer version of the panel can be found on Android tablets, like
ASUS TF701T.
Linus Torvalds [Thu, 30 Jun 2022 16:34:10 +0000 (09:34 -0700)]
sparse: introduce conditional lock acquire function attribute
The kernel tends to try to avoid conditional locking semantics because
it makes it harder to think about and statically check locking rules,
but we do have a few fundamental locking primitives that take locks
conditionally - most obviously the 'trylock' functions.
That has always been a problem for 'sparse' checking for locking
imbalance, and we've had a special '__cond_lock()' macro that we've used
to let sparse know how the locking works:
so that you can then use this to tell sparse that (for example) the
spinlock trylock macro ends up acquiring the lock when it succeeds, but
not when it fails:
and then sparse can follow along the locking rules when you have code like
if (!spin_trylock(&dentry->d_lock))
return LRU_SKIP;
.. sparse sees that the lock is held here..
spin_unlock(&dentry->d_lock);
and sparse ends up happy about the lock contexts.
However, this '__cond_lock()' use does result in very ugly header files,
and requires you to basically wrap the real function with that macro
that uses '__cond_lock'. Which has made PeterZ NAK things that try to
fix sparse warnings over the years [1].
To solve this, there is now a very experimental patch to sparse that
basically does the exact same thing as '__cond_lock()' did, but using a
function attribute instead. That seems to make PeterZ happy [2].
Note that this does not replace existing use of '__cond_lock()', but
only exposes the new proposed attribute and uses it for the previously
unannotated 'refcount_dec_and_lock()' family of functions.
For existing sparse installations, this will make no difference (a
negative output context was ignored), but if you have the experimental
sparse patch it will make sparse now understand code that uses those
functions, the same way '__cond_lock()' makes sparse understand the very
similar 'atomic_dec_and_lock()' uses that have the old '__cond_lock()'
annotations.
Note that in some cases this will silence existing context imbalance
warnings. But in other cases it may end up exposing new sparse warnings
for code that sparse just didn't see the locking for at all before.
This is a trial, in other words. I'd expect that if it ends up being
successful, and new sparse releases end up having this new attribute,
we'll migrate the old-style '__cond_lock()' users to use the new-style
'__cond_acquires' function attribute.
The actual experimental sparse patch was posted in [3].
Merge tag 'xfs-5.19-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull xfs fixes from Darrick Wong:
"This fixes some stalling problems and corrects the last of the
problems (I hope) observed during testing of the new atomic xattr
update feature.
- Fix statfs blocking on background inode gc workers
- Fix some broken inode lock assertion code
- Fix xattr leaf buffer leaks when cancelling a deferred xattr update
operation
- Clean up xattr recovery to make it easier to understand.
- Fix xattr leaf block verifiers tripping over empty blocks.
- Fix a bug where an rt extent crossing EOF was treated as "posteof"
blocks and cleaned unnecessarily.
- Fix a UAF when log shutdown races with unmount"
* tag 'xfs-5.19-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: prevent a UAF when log IO errors race with unmount
xfs: dont treat rt extents beyond EOF as eofblocks to be cleared
xfs: don't hold xattr leaf buffers across transaction rolls
xfs: empty xattr leaf header blocks are not corruption
xfs: clean up the end of xfs_attri_item_recover
xfs: always free xattri_leaf_bp when cancelling a deferred op
xfs: use invalidate_lock to check the state of mmap_lock
xfs: factor out the common lock flags assert
xfs: introduce xfs_inodegc_push()
xfs: bound maximum wait time for inodegc work
The compatible “mediatek,mt8192-disp-rdma” is being used for reading
the data into DMA for back-end panel driver in mt8192 but there is
no difference between mt8183 and mt8192 in rdma driver.
Remove compatible “mediatek,mt8192-disp-rdma” from the driver and
should use “mediatek,mt8183-disp-rdma” as fallback in 8192 DTS
according to the mediatek,rdma.yaml.
The following patchset contains Netfilter fixes for net:
1) Insufficient validation of element datatype and length in
nft_setelem_parse_data(). At least commit 7d7402642eaf updates
maximum element data area up to 64 bytes when only 16 bytes
where supported at the time. Support for larger element size
came later in fdb9c405e35b though. Picking this older commit
as Fixes: tag to be safe than sorry.
2) Memleak in pipapo destroy path, reproducible when transaction
in aborted. This is already triggering in the existing netfilter
test infrastructure since more recent new tests are covering this
path.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sun, 3 Jul 2022 11:02:20 +0000 (12:02 +0100)]
Merge tag 'mlx5-updates-2022-06-29' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
mlx5-updates-2022-06-29
Chris Mi Says:
==============
Remove dependency between sriov and eswitch mode
Currently, there are three eswitch modes, none, legacy and
switchdev. None is the default mode. And when disabling sriov,
current eswitch mode will be changed to none. This patchset
removes eswitch mode none and also removes dependency between
sriov and eswitch mode. With this patchset, there are two
behavior changes:
Original behavior
-----------------
- When driver is loaded without sriov enabled, none is the default
mode. But actually eswitch mode should be either legacy or
switchdev, so devlink will return unsupported when showing
eswitch mode.
- When disabling sriov in either legacy or switchdev mode, eswitch
mode will be changed to none.
New behavior
------------
- When driver is loaded, legacy will be the default mode.
- When disabling sriov in either legacy or switchdev mode, eswitch
mode will not be changed.
Jianbo Liu Says:
================
Add support offloading police action
This patchset supports offloading police action by flow meter ASO
object in hardware.
The first part is to add interfaces to create and destroy flow meter
ASO object, and modify meter parameters by ACCESS_ASO WQE. As multiple
objects are created at a time, and two meters are in one object,
bitmaps are used manage these meters in one creation.
Then the police action can be mapped to a meter by the action index.
After mlx5e tc action refactoring was merged and post_act table was
added, a simple tc flow with one police action is broken down into two
rules in hardware. One rule with the original match in the original
table, which performs a metadata rewrite and do metering, then jumps
to post_meter table. The second rule is placed in the post_act table
with all the actions left.
The rules in post_meter table match on the meter outcome. If the
outcome is GREEN, we merely jump back to the post_act table for
further processing. Otherwise, the outcome is RED, and we drop the
packet.
The last part is to support flow meter ASO object in sw steering.
Signed-off-by: David S. Miller <davem@davemloft.net>
Dario Binacchi says:
====================
This series originated as a result of CAN communication tests for an
application using the USBtin adapter (https://www.fischl.de/usbtin/).
The tests showed some errors but for the driver everything was ok.
Also, being the first time I used the slcan driver, I was amazed that
it was not possible to configure the bitrate via the ip tool.
For these two reasons, I started looking at the driver code and realized
that it didn't use the CAN network device driver interface.
Starting from these assumptions, I tried to:
- Use the CAN network device driver interface.
- Set the bitrate via the ip tool.
- Send the open/close command to the adapter from the driver.
- Add ethtool support to reset the adapter errors.
- Extend the protocol to forward the adapter CAN communication
errors and the CAN state changes to the netdev upper layers.
Except for the protocol extension patches (i. e. forward the adapter CAN
communication errors and the CAN state changes to the netdev upper
layers), the whole series has been tested under QEMU with Linux 4.19.208
using the USBtin adapter.
Testing the extension protocol patches requires updating the adapter
firmware. Before modifying the firmware I think it makes sense to know if
these extensions can be considered useful.
Before applying the series I used these commands:
slcan_attach -f -s6 -o /dev/ttyACM0
slcand ttyACM0 can0
ip link set can0 up
After applying the series I am using these commands:
slcan_attach /dev/ttyACM0
slcand ttyACM0 can0
ip link set dev can0 down
ip link set can0 type can bitrate 500000
ethtool --set-priv-flags can0 err-rst-on-open on
ip link set dev can0 up
Now there is a clearer separation between serial line and CAN,
but above all, it is possible to use the ip and ethtool commands
as it happens for any CAN device driver. The changes are backward
compatible, you can continue to use the slcand and slcan_attach
command options.
Changes in v5:
- Update the commit message.
- Restore the use of rtnl_lock() and rtnl_unlock().
Changes in v4:
- Move the patch in front of the patch "[v3,04/13] can: slcan: use CAN network device driver API".
- Add the CAN_BITRATE_UNSET (0) and CAN_BITRATE_UNKNOWN (-1U) macros.
- Simplify the bitrate check to dump it.
- Update the commit description.
- Update the commit description.
- Use the CAN_BITRATE_UNKNOWN macro.
- Use kfree_skb() instead of can_put_echo_skb() in the slc_xmit().
- Remove the `if (slcan_devs)' check in the slc_dealloc().
- Replace `sl->tty == NULL' with `!sl->tty'.
- Use CAN_BITRATE_UNSET (0) and CAN_BITRATE_UNKNOWN (-1U) macros.
- Don't reset the bitrate in ndo_stop() if it has been configured.
- Squashed to the patch [v3,09/13] can: slcan: send the close command to the adapter.
- Use the CAN_BITRATE_UNKNOWN macro.
- Add description of slc_bump_err() function.
- Remove check for the 'e' character at the beggining of the function.
It was already checked by the caller function.
- Protect decoding against the case the len value is longer than the
received data.
- Some small changes to make the decoding more readable.
- Increment all the error counters at the end of the function.
- Add description of slc_bump_state() function.
- Remove check for the 's' character at the beggining of the function.
It was already checked by the caller function.
- Protect decoding against the case the frame len is longer than the
received data (add SLC_STATE_FRAME_LEN macro).
- Set cf to NULL in case of alloc_can_err_skb() failure.
- Some small changes to make the decoding more readable.
- Use the character 'b' instead of 'f' for bus-off state.
Changes in v3:
- Increment the error counter in case of decoding failure.
- Replace (-1) with (-1U) in the commit description.
- Update the commit description.
- Remove the slc_do_set_bittiming().
- Set the bitrate in the ndo_open().
- Replace -1UL with -1U in setting a fake value for the bitrate.
- Drop the patch "can: slcan: simplify the device de-allocation".
- Add the patch "can: netlink: dump bitrate 0 if can_priv::bittiming.bitrate is -1U".
Changes in v2:
- Put the data into the allocated skb directly instead of first
filling the "cf" on the stack and then doing a memcpy().
- Move CAN_SLCAN Kconfig option inside CAN_DEV scope.
- Improve the commit message.
- Use the CAN framework support for setting fixed bit rates.
- Improve the commit message.
- Protect decoding against the case the len value is longer than the
received data.
- Continue error handling even if no skb can be allocated.
- Continue error handling even if no skb can be allocated.
====================
Dario Binacchi [Tue, 28 Jun 2022 16:31:31 +0000 (18:31 +0200)]
can: slcan: set bitrate by CAN device driver API
It allows to set the bitrate via ip tool, as it happens for the other
CAN device drivers. It still remains possible to set the bitrate via
slcand or slcan_attach utilities. In case the ip tool is used, the
driver will send the serial command to the adapter.
Dario Binacchi [Tue, 28 Jun 2022 16:31:30 +0000 (18:31 +0200)]
can: slcan: allow to send commands to the adapter
This is a preparation patch for the upcoming support to change the
bitrate via ip tool, reset the adapter error states via the ethtool API
and, more generally, send commands to the adapter.
Since the close command (i. e. "C\r") will be sent in the ndo_stop()
where netif_running() returns false, a new flag bit (i. e. SLF_XCMD) for
serial transmission has to be added.
Dario Binacchi [Tue, 28 Jun 2022 16:31:29 +0000 (18:31 +0200)]
can: slcan: use CAN network device driver API
As suggested by commit [1], now the driver uses the functions and the
data structures provided by the CAN network device driver interface.
Currently the driver doesn't implement a way to set bitrate for SLCAN
based devices via ip tool, so you'll have to do this by slcand or
slcan_attach invocation through the -sX parameter:
where -s6 in will set adapter's bitrate to 500 Kbit/s and -s8 to
1Mbit/s.
See the table below for further CAN bitrates:
- s0 -> 10 Kbit/s
- s1 -> 20 Kbit/s
- s2 -> 50 Kbit/s
- s3 -> 100 Kbit/s
- s4 -> 125 Kbit/s
- s5 -> 250 Kbit/s
- s6 -> 500 Kbit/s
- s7 -> 800 Kbit/s
- s8 -> 1000 Kbit/s
In doing so, the struct can_priv::bittiming.bitrate of the driver is not
set and since the open_candev() checks that the bitrate has been set, it
must be a non-zero value, the bitrate is set to a fake value (-1U)
before it is called.
Using the rtnl_lock()/rtnl_unlock() functions has become a bit more
tricky as the register_candev() function indirectly calls rtnl_lock()
via register_netdev(). To avoid a deadlock it is therefore necessary to
call rtnl_unlock() before calling register_candev(). The same goes for
the unregister_candev() function.
[1] commit 39549eef3587f ("can: CAN Network device driver and Netlink interface")
Dario Binacchi [Tue, 28 Jun 2022 16:31:28 +0000 (18:31 +0200)]
can: netlink: dump bitrate 0 if can_priv::bittiming.bitrate is -1U
Upcoming changes on slcan driver will require you to specify a bitrate
of value -1 to prevent the open_candev() from failing but at the same
time highlighting that it is a fake value. In this case the command
`ip --details -s -s link show' would print 4294967295 as the bitrate
value. The patch change this value in 0.
Bhupesh Sharma [Sat, 14 May 2022 21:54:19 +0000 (03:24 +0530)]
ARM: dts: qcom: Fix sdhci node names - use 'mmc@'
Since the Qualcomm sdhci-msm device-tree binding has been converted
to yaml format, 'make dtbs_check' reports issues with
inconsistent 'sdhci@' convention used for specifying the
sdhci nodes. The generic mmc bindings expect 'mmc@' format
instead.
Stephen Boyd [Mon, 27 Jun 2022 21:28:02 +0000 (14:28 -0700)]
arm64: dts: qcom: sc7180-trogdor: Split out keyboard node and describe detachables
Trogdor devices that have a detachable keyboard still have a
non-detachable keyboard input device present because we include the
cros-ec-keyboard.dtsi snippet in the top-level sc7180-trogdor.dtsi file
that every variant board includes. We do this because the
keyboard-controller node also provides some buttons like the power
button and volume buttons. Unfortunately, this means we register a
keyboard input device that doesn't do anything on boards with a
detachable keyboard.
Change the node's compatible on detachables to the newly introduced
"google,cros-ec-keyb-switches" compatible to indicate that there are
only switches and no keyboard to register. Similarly, move the keyboard
include that defines the keyboard-controller node out of
sc7180-trogdor.dtsi to boards that actually have a keyboard so that the
matrix properties are not defined on boards with the switches
compatible. Future boards can either use the include approach or the
node definition approach to describe a keyboard with possible switches
or just some switches.
Cc: Benson Leung <bleung@chromium.org> Cc: Guenter Roeck <groeck@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Hsin-Yi Wang <hsinyi@chromium.org> Cc: "Joseph S. Barrera III" <joebar@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220627212802.3593012-1-swboyd@chromium.org
Dmitry Baryshkov [Fri, 17 Jun 2022 10:36:52 +0000 (13:36 +0300)]
arm64: dts: qcom: msm8996: add second DSI interface
Add device nodes for the DSI1, second DSI interface found on
MSM8996/APQ8096 platforms. For example on db820c it is routed to the
secondary HS expansion connector.
This is an SMMU for the adreno gpu, and adding this compatible lets
the driver use per-fd page tables, which are required for security
between GPU clients.
Signed-off-by: Emma Anholt <emma@anholt.net> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
[bjorn: Move arm,smmu-500 last, per Dmitry's request] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220614230136.3726047-2-emma@anholt.net
arm64: dts: qcom: msm8996: drop phy-names from HDMI device node
The HDMI driver doesn't use the phy-names to identify the PHY. Different
Qualcomm platforms have used different names for the PHY. So, we are
deprecating phy-names propertty of the HDMI device and dropping them
from existing DTs.
arm64: dts: qcom: sdm845: add dedicated IMEM and syscon compatibles
Add proper compatibles to the IMEM device node:
1. syscon to allow accessing memory from other devices,
2. dedicated compatible as required for syscon and simple-mfd nodes.
arm64: dts: qcom: sdm630: add dedicated IMEM and syscon compatibles
Add proper compatibles to the IMEM device node:
1. syscon to allow accessing memory from other devices,
2. dedicated compatible as required for syscon and simple-mfd nodes.
arm64: dts: qcom: sc7180: add dedicated IMEM and syscon compatibles
Add proper compatibles to the IMEM device node:
1. syscon to allow accessing memory from other devices,
2. dedicated compatible as required for syscon and simple-mfd nodes.
arm64: dts: qcom: qcs404: add dedicated IMEM and syscon compatibles
Add proper compatibles to the IMEM device node:
1. syscon to allow accessing memory from other devices,
2. dedicated compatible as required for syscon and simple-mfd nodes.
arm64: dts: qcom: use generic sram as name for imem and ocmem nodes
According to Devicetree specification, the device nodes should be
generic, reflecting the function of the device. The typical name for
memory regions is "sram".
clk-virt and mc-virt interconnect nodes were named interconnect@0 and
interconnect@1. That is incorrect as we don't have unit addresses 0/1
for these node.
This causes warning:
arch/arm64/boot/dts/qcom/sm8450.dtsi:255.27-259.4:
Warning (unit_address_vs_reg): /interconnect@0:
node has a unit name, but no reg or ranges property
arch/arm64/boot/dts/qcom/sm8450.dtsi:261.26-265.4:
Warning (unit_address_vs_reg): /interconnect@1:
node has a unit name, but no reg or ranges property
arch/arm64/boot/dts/qcom/sm8450.dtsi:255.27-259.4:
Warning (unique_unit_address_if_enabled): /interconnect@0:
duplicate unit-address (also used in node /soc@0)
Rename the nodes to interconnect-0 and interconnect-1 to fix the
warning.
Current QUP peripheral labels like spi_0 and i2c_0 dont really tell what is
the exact QUP HW being used as there are actually 6 identical QUP HW blocks
for UART, SPI and I2C.
For example current i2c_0 label actually points to the QUP2 I2C HW.
This style of labeling does not follow what the rest of Qualcomm SoC-s use,
for example IPQ8074 which has the identical QUP blocks.
It also makes it really hard to add the missing QUP DT nodes as there are
multiple missing.
So utilize the same style as other Qualcomm SoC-s are using and update the
CP01 DTS as its the current sole user of them.
Luca Weiss [Fri, 3 Jun 2022 09:47:10 +0000 (11:47 +0200)]
arm64: dts: qcom: sm8250: use constants for audio clocks
The use of these constants was removed during merging, probably because
the patches adding those defines and the dts patches were merged through
different trees.
Re-add them to make it clear which clocks are getting used.
Sireesh Kodali [Thu, 26 May 2022 14:17:40 +0000 (19:47 +0530)]
arm64: dts: qcom: msm8916: Fix typo in pronto remoteproc node
The smem-state properties for the pronto node were incorrectly labelled,
reading `qcom,state*` rather than `qcom,smem-state*`. Fix that, allowing
the stop state to be used.
Fixes: 88106096cbf8 ("ARM: dts: msm8916: Add and enable wcnss node") Signed-off-by: Sireesh Kodali <sireeshkodali1@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220526141740.15834-3-sireeshkodali1@gmail.com
Specifying interrupts and interrupts-extended is not correct. Keep only
the extended ones, routed towards IPCC mailbox to fix warnings like:
sm8450-qrd.dtb: glink-edge: More than one condition true in oneOf schema:
{'$filename': 'Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml',
Specifying interrupts and interrupts-extended is not correct. Keep only
the extended ones, routed towards IPCC mailbox to fix warnings like:
sm8350-sony-xperia-sagami-pdx214.dtb: glink-edge: More than one condition true in oneOf schema:
{'$filename': 'Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml',
As Bjorn noted in [1], since the qmp phy driver doesn't
use the 'vdda-max-microamp' & 'vdda-pll-max-microamp' properties
currently, let's remove them from the dts files as well.
Otherwise, it leads to the following '$ make dtbs_check'
warning(s):
sm8350-microsoft-surface-duo2.dt.yaml: phy@1d87000:
'vdda-max-microamp', 'vdda-pll-max-microamp' do not match any of
the regexes: '^phy@[0-9a-f]+$', 'pinctrl-[0-9]+
If later on the driver support is added, we can add these properties
back to the dts files.
Bhupesh Sharma [Sat, 14 May 2022 21:54:23 +0000 (03:24 +0530)]
arm64: dts: qcom: Fix 'reg-names' for sdhci nodes
Since the Qualcomm sdhci-msm device-tree binding has been converted
to yaml format, 'make dtbs_check' reports a number of issues with
ordering of 'reg-names' as various possible combinations
are possible for different qcom SoC dts files.
Fix the same by updating the offending 'dts' files.
Bhupesh Sharma [Sat, 14 May 2022 21:54:22 +0000 (03:24 +0530)]
arm64: dts: qcom: Fix ordering of 'clocks' & 'clock-names' for sdhci nodes
Since the Qualcomm sdhci-msm device-tree binding has been converted
to yaml format, 'make dtbs_check' reports a number of issues with
ordering of 'clocks' & 'clock-names' for sdhci nodes:
arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dtb: sdhci@7824900:
clock-names:0: 'iface' was expected
arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dtb: sdhci@7824900:
clock-names:1: 'core' was expected
arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dtb: sdhci@7824900:
clock-names:2: 'xo' was expected
Fix the same by updating the offending 'dts' files.
Bhupesh Sharma [Sat, 14 May 2022 21:54:20 +0000 (03:24 +0530)]
arm64: dts: qcom: sdm630: Fix 'interconnect-names' for sdhci nodes
Since the Qualcomm sdhci-msm device-tree binding has been converted
to yaml format, 'make dtbs_check' reports issues with
inconsistent 'interconnect-names' used for sdhci nodes.
Bhupesh Sharma [Sat, 14 May 2022 21:54:19 +0000 (03:24 +0530)]
arm64: dts: qcom: Fix sdhci node names - use 'mmc@'
Since the Qualcomm sdhci-msm device-tree binding has been converted
to yaml format, 'make dtbs_check' reports issues with
inconsistent 'sdhci@' convention used for specifying the
sdhci nodes. The generic mmc bindings expect 'mmc@' format
instead.
Fix the same.
Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Rob Herring <robh@kernel.org> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
[bjorn: Moved non-arm64 changes to separate commit] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220514215424.1007718-2-bhupesh.sharma@linaro.org
Marijn Suijten [Wed, 11 May 2022 19:07:18 +0000 (21:07 +0200)]
arm64: dts: qcom: sdm630-nile: Add RGB status LED on the PM660L LPG
The entire Sony Nile and Ganges lineup utilize the first three channels
(the triled channels) of the LPG block for an RGB (battery) status and
notification indicator.
Marijn Suijten [Wed, 11 May 2022 19:07:17 +0000 (21:07 +0200)]
arm64: dts: qcom: pm660l: Add LPG node
The Light Pulse Generator describes a hardware block responsible for
displaying colors and patterns on an RGB LED (usually used for [battery]
status and notifications), and drive PWM signals for general-purpose
(ie. backlight) LEDs. The availability and usage of the individual
channels differ per board and is hence left for individual platform DTs
to configure.
Andrey Konovalov [Sat, 11 Jun 2022 19:57:13 +0000 (22:57 +0300)]
arm64: dts: qcom: qcs404: fix default pinctrl settings for blsp1_spi1
The current settings refer to "blsp_spi1" function which isn't defined.
For this reason an attempt to enable blsp1_spi1 interface results in
the probe failure below:
[ 3.492900] qcs404-pinctrl 1000000.pinctrl: invalid function blsp_spi1 in map table
[ 3.502460] qcs404-pinctrl 1000000.pinctrl: invalid function blsp_spi1 in map table
[ 3.517725] qcs404-pinctrl 1000000.pinctrl: invalid function blsp_spi1 in map table
[ 3.532998] qcs404-pinctrl 1000000.pinctrl: invalid function blsp_spi1 in map table
[ 3.548277] spi_qup: probe of 78b6000.spi failed with error -22
Fix this by making the functions used in qcs404.dtsi to match the contents
of drivers/pinctrl/qcom/pinctrl-qcs404.c.
Fix whitespace coding style: use single space instead of tabs or
multiple spaces around '=' sign in property assignment. No functional
changes (same DTB).
The NVMEM bindings expect that 'bits' property holds offset and size of
region within a byte, so it applies a constraint of <0, 7> for the
offset. Using 25 as HSTX trim offset is within 4-byte QFPROM word, but
outside of the byte:
sdm630-sony-xperia-nile-discovery.dtb: qfprom@780000: hstx-trim@240:bits:0:0: 25 is greater than the maximum of 7
sdm630-sony-xperia-nile-discovery.dtb: qfprom@780000: gpu-speed-bin@41a0:bits:0:0: 21 is greater than the maximum of 7
The AOSS QMP bindings expect all compatibles to be followed by fallback
"qcom,aoss-qmp" because all of these are actually compatible with each
other. This fixes dtbs_check warnings like:
sm8250-hdk.dtb: power-controller@c300000: compatible: ['qcom,sm8250-aoss-qmp'] is too short
Wormdingler is a trogdor-based board, shipping to customers as the
Lenovo IdeaPad Chromebook Duet 3. These dts files are copies from
the downstream Chrome OS 5.4 kernel, but with the camera
(sc7180-trogdor-mipi-camera.dtsi) #include removed.
Gwendal Grignou [Thu, 23 Jun 2022 22:31:19 +0000 (15:31 -0700)]
arm64: dts: qcom: sc7280: Rename sar sensor labels
To ease matching configuration of sysfs attributes for particular
sensor, match label reported by iio 'label' attribute with the location
label generated by ChromeOS config tool.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220623223119.1858863-1-gwendal@chromium.org
Add an initial devicetree for the Lenovo Thinkpad X13s with support for
USB, backlight, keyboard, touchpad, touchscreen (to be verified), PMICs
and remoteprocs.
Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220622132617.24604-1-johan+linaro@kernel.org
projects / people / ms / linux.git / log
