| Age | Commit message (Collapse) | Author |
|---|
|
Add device-tree for ASUS Transformer Pad TF300TG, which is a NVIDIA
Tegra30-based 2-in-1 detachable, originally running Android. It's a
variant of the TF300T that has a 3G modem.
Link: https://wiki.postmarketos.org/wiki/ASUS_Transformer_Pad_(asus-tf300t)
Co-developed-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Ion Agorria <ion@agorria.com>
Co-developed-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Signed-off-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
[treding@nvidia.com: cosmetic fixups]
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add device-tree for ASUS Transformer Pad TF300T, which is a NVIDIA
Tegra30-based 2-in-1 detachable, originally running Android.
Link: https://wiki.postmarketos.org/wiki/ASUS_Transformer_Pad_(asus-tf300t)
Tested-by: Ihor Didenko <tailormoon@rambler.ru>
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com>
Co-developed-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Ion Agorria <ion@agorria.com>
Co-developed-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Signed-off-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
[treding@nvidia.com: cosmetic fixups]
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add device-tree for ASUS Transformer Prime TF201, which is a NVIDIA
Tegra30-based 2-in-1 detachable, orignally running Android.
Link: https://wiki.postmarketos.org/wiki/ASUS_Transformer_Prime_(asus-tf201)
Co-developed-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Ion Agorria <ion@agorria.com>
Co-developed-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Signed-off-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
[treding@nvidia.com: cosmetic fixups]
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
tablets
All Tegra30 ASUS tablets have a similar design pattern in terms of
hardware integration of LVDS display panels, like exactly the same GPIOs
are used for power and reset, etc. Add a common device-tree for LVDS
display panels of Tegra30 ASUS tablets to avoid replicating the
boilerplate panel description.
[digetx@gmail.com: factored out common part into separate patch and wrote commit message]
Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add common DTSI for Tegra30 ASUS Transformers. It will be used by multiple
device-trees of ASUS devices. The common part initially was born out of
the ASUS TF300T tablet's device-tree that was created by Michał Mirosław.
It was heavily reworked and improved by Svyatoslav Ryhel, Maxim Schwalm,
Ion Agorria et al.
[digetx@gmail.com: factored out common part into separate patch and wrote commit message]
Co-developed-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Ion Agorria <ion@agorria.com>
Co-developed-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Signed-off-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Co-developed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
[treding@nvidia.com: cosmetic fixups]
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add device-tree for Tegra20-based ASUS Transformer EeePad TF101.
Link: https://wiki.postmarketos.org/wiki/ASUS_Eee_Pad_Transformer_(asus-tf101)
Co-developed-by: David Heidelberg <david@ixit.cz>
Signed-off-by: David Heidelberg <david@ixit.cz>
Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Co-developed-by: Antoni Aloy Torrens <aaloytorrens@gmail.com>
Signed-off-by: Antoni Aloy Torrens <aaloytorrens@gmail.com>
Signed-off-by: Nikola Milosavljevic <mnidza@outlook.com>
Co-developed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
[treding@nvidia.com: cosmetic fixups]
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Move the default state pinmux definition into the pinmux node. There's
no need for the indirection via the phandle.
Note that the phandle indirection is kept for the EMC operating
performance point tables because they reference nodes that are defined
in an external file.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Use the correct "reset-gpios" property for the I2C mux reset GPIO
reference instead of the deprecated "reset-gpio" property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The SLINK controller found on Tegra30 is not compatible with its
predecessor found on Tegra20. Drop the fallback compatible string.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The Ouya board specifies the #reset-cells property for the GPIO
controller. Since the GPIO controller doesn't provide reset controls
this is not needed, so they can be dropped.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The clock-frequency property was never used and is deprecated now.
Remove it from Nexus 7 device-tree.
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The +V1.2_VDD_CORE regulator on Apalis and Colibri boards uses the
unsupported ti,vsel{0,1}-state-low properties. It turns out that these
are in fact the default and can be overridden by ti,vsel{0,1}-state-high
properties if needed. Drop them since they are not needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The correct vendor prefix for Invensense is "invensense," rather than
"invn,".
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The Medcom Wide and PAZ00 boards don't specify the power supply for the
backlight, which means that the Linux driver will provide a dummy one.
Wire up an explicit dummy to also make the DT schema validation succeed.
Unfortunately I don't have access to the schematics for the Medcom Wide,
so I don't know if a more accurate description is possible.
The AC100 (PAZ00) schematics from here:
https://www.s-manuals.com/pdf/motherboard/compal/compal_la-6352p_r1.0a_schematics.pdf
aren't entirely clear which one of the supplies powers backlight, but
the panel supply is probably close enough.
Based on work by David Heidelberg <david@ixit.cz>.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The PHY reset GPIO references belong in the USB PHY nodes, where they
already exist. There is no need to keep them in the USB controller's
device tree node as well.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The device tree node for the built-in ASIX Ethernet device on Colibri
boards needs a compatible string in order to pass DT schema validation.
Add the USB VID,PID compatible string as required by the DT schema for
USB devices.
Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add binding for the jackpotlte board (Samsung Galaxy A8 (2018)).
Signed-off-by: David Virag <virag.david003@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20211206153124.427102-4-virag.david003@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
|
A new warning in clang points out two instances where boolean
expressions are being used with a bitwise OR instead of logical OR:
drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
reg = tegra_fuse_read_spare(i) |
^~~~~~~~~~~~~~~~~~~~~~~~~~
||
drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: note: cast one or both operands to int to silence this warning
drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
reg = tegra_fuse_read_spare(i) |
^~~~~~~~~~~~~~~~~~~~~~~~~~
||
drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: note: cast one or both operands to int to silence this warning
2 warnings generated.
The motivation for the warning is that logical operations short circuit
while bitwise operations do not.
In this instance, tegra_fuse_read_spare() is not semantically returning
a boolean, it is returning a bit value. Use u32 for its return type so
that it can be used with either bitwise or boolean operators without any
warnings.
Fixes: 25cd5a391478 ("ARM: tegra: Add speedo-based process identification")
Link: https://github.com/ClangBuiltLinux/linux/issues/1488
Suggested-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Enable display-related drivers used by various Tegra-based tablets.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Enable charger, touchpad and EC drivers found on Acer Tegra124 (Nyan)
Chromebooks, display bridge found on ASUS TF700T and audio codecs
found on ASUS tablets.
Suggested-by: Thomas Graichen <thomas.graichen@gmail.com> # Nyan options
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The function btrfs_scan_one_device() calls blkdev_get_by_path() and
blkdev_put() to get and release its target block device. However, when
btrfs_sb_log_location_bdev() fails, blkdev_put() is not called and the
block device is left without clean up. This triggered failure of fstests
generic/085. Fix the failure path of btrfs_sb_log_location_bdev() to
call blkdev_put().
Fixes: 12659251ca5df ("btrfs: implement log-structured superblock for ZONED mode")
CC: stable@vger.kernel.org # 5.15+
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
|
|
When creating a subvolume, at ioctl.c:create_subvol(), if we fail to
insert the root item for the new subvolume into the root tree, we can
trigger the following warning:
[78961.741046] WARNING: CPU: 0 PID: 4079814 at fs/btrfs/extent-tree.c:3357 btrfs_free_tree_block+0x2af/0x310 [btrfs]
[78961.743344] Modules linked in:
[78961.749440] dm_snapshot dm_thin_pool (...)
[78961.773648] CPU: 0 PID: 4079814 Comm: fsstress Not tainted 5.16.0-rc4-btrfs-next-108 #1
[78961.775198] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[78961.777266] RIP: 0010:btrfs_free_tree_block+0x2af/0x310 [btrfs]
[78961.778398] Code: 17 00 48 85 (...)
[78961.781067] RSP: 0018:ffffaa4001657b28 EFLAGS: 00010202
[78961.781877] RAX: 0000000000000213 RBX: ffff897f8a796910 RCX: 0000000000000000
[78961.782780] RDX: 0000000000000000 RSI: 0000000011004000 RDI: 00000000ffffffff
[78961.783764] RBP: ffff8981f490e800 R08: 0000000000000001 R09: 0000000000000000
[78961.784740] R10: 0000000000000000 R11: 0000000000000001 R12: ffff897fc963fcc8
[78961.785665] R13: 0000000000000001 R14: ffff898063548000 R15: ffff898063548000
[78961.786620] FS: 00007f31283c6b80(0000) GS:ffff8982ace00000(0000) knlGS:0000000000000000
[78961.787717] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[78961.788598] CR2: 00007f31285c3000 CR3: 000000023fcc8003 CR4: 0000000000370ef0
[78961.789568] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[78961.790585] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[78961.791684] Call Trace:
[78961.792082] <TASK>
[78961.792359] create_subvol+0x5d1/0x9a0 [btrfs]
[78961.793054] btrfs_mksubvol+0x447/0x4c0 [btrfs]
[78961.794009] ? preempt_count_add+0x49/0xa0
[78961.794705] __btrfs_ioctl_snap_create+0x123/0x190 [btrfs]
[78961.795712] ? _copy_from_user+0x66/0xa0
[78961.796382] btrfs_ioctl_snap_create_v2+0xbb/0x140 [btrfs]
[78961.797392] btrfs_ioctl+0xd1e/0x35c0 [btrfs]
[78961.798172] ? __slab_free+0x10a/0x360
[78961.798820] ? rcu_read_lock_sched_held+0x12/0x60
[78961.799664] ? lock_release+0x223/0x4a0
[78961.800321] ? lock_acquired+0x19f/0x420
[78961.800992] ? rcu_read_lock_sched_held+0x12/0x60
[78961.801796] ? trace_hardirqs_on+0x1b/0xe0
[78961.802495] ? _raw_spin_unlock_irqrestore+0x3e/0x60
[78961.803358] ? kmem_cache_free+0x321/0x3c0
[78961.804071] ? __x64_sys_ioctl+0x83/0xb0
[78961.804711] __x64_sys_ioctl+0x83/0xb0
[78961.805348] do_syscall_64+0x3b/0xc0
[78961.805969] entry_SYSCALL_64_after_hwframe+0x44/0xae
[78961.806830] RIP: 0033:0x7f31284bc957
[78961.807517] Code: 3c 1c 48 f7 d8 (...)
This is because we are calling btrfs_free_tree_block() on an extent
buffer that is dirty. Fix that by cleaning the extent buffer, with
btrfs_clean_tree_block(), before freeing it.
This was triggered by test case generic/475 from fstests.
Fixes: 67addf29004c5b ("btrfs: fix metadata extent leak after failure to create subvolume")
CC: stable@vger.kernel.org # 4.4+
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
|
|
When creating a subvolume, at ioctl.c:create_subvol(), if we fail to
insert the new root's root item into the root tree, we are freeing the
metadata extent we reserved for the new root to prevent a metadata
extent leak, as we don't abort the transaction at that point (since
there is nothing at that point that is irreversible).
However we allocated the metadata extent for the new root which we are
creating for the new subvolume, so its delayed reference refers to the
ID of this new root. But when we free the metadata extent we pass the
root of the subvolume where the new subvolume is located to
btrfs_free_tree_block() - this is incorrect because this will generate
a delayed reference that refers to the ID of the parent subvolume's root,
and not to ID of the new root.
This results in a failure when running delayed references that leads to
a transaction abort and a trace like the following:
[3868.738042] RIP: 0010:__btrfs_free_extent+0x709/0x950 [btrfs]
[3868.739857] Code: 68 0f 85 e6 fb ff (...)
[3868.742963] RSP: 0018:ffffb0e9045cf910 EFLAGS: 00010246
[3868.743908] RAX: 00000000fffffffe RBX: 00000000fffffffe RCX: 0000000000000002
[3868.745312] RDX: 00000000fffffffe RSI: 0000000000000002 RDI: ffff90b0cd793b88
[3868.746643] RBP: 000000000e5d8000 R08: 0000000000000000 R09: ffff90b0cd793b88
[3868.747979] R10: 0000000000000002 R11: 00014ded97944d68 R12: 0000000000000000
[3868.749373] R13: ffff90b09afe4a28 R14: 0000000000000000 R15: ffff90b0cd793b88
[3868.750725] FS: 00007f281c4a8b80(0000) GS:ffff90b3ada00000(0000) knlGS:0000000000000000
[3868.752275] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[3868.753515] CR2: 00007f281c6a5000 CR3: 0000000108a42006 CR4: 0000000000370ee0
[3868.754869] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[3868.756228] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[3868.757803] Call Trace:
[3868.758281] <TASK>
[3868.758655] ? btrfs_merge_delayed_refs+0x178/0x1c0 [btrfs]
[3868.759827] __btrfs_run_delayed_refs+0x2b1/0x1250 [btrfs]
[3868.761047] btrfs_run_delayed_refs+0x86/0x210 [btrfs]
[3868.762069] ? lock_acquired+0x19f/0x420
[3868.762829] btrfs_commit_transaction+0x69/0xb20 [btrfs]
[3868.763860] ? _raw_spin_unlock+0x29/0x40
[3868.764614] ? btrfs_block_rsv_release+0x1c2/0x1e0 [btrfs]
[3868.765870] create_subvol+0x1d8/0x9a0 [btrfs]
[3868.766766] btrfs_mksubvol+0x447/0x4c0 [btrfs]
[3868.767669] ? preempt_count_add+0x49/0xa0
[3868.768444] __btrfs_ioctl_snap_create+0x123/0x190 [btrfs]
[3868.769639] ? _copy_from_user+0x66/0xa0
[3868.770391] btrfs_ioctl_snap_create_v2+0xbb/0x140 [btrfs]
[3868.771495] btrfs_ioctl+0xd1e/0x35c0 [btrfs]
[3868.772364] ? __slab_free+0x10a/0x360
[3868.773198] ? rcu_read_lock_sched_held+0x12/0x60
[3868.774121] ? lock_release+0x223/0x4a0
[3868.774863] ? lock_acquired+0x19f/0x420
[3868.775634] ? rcu_read_lock_sched_held+0x12/0x60
[3868.776530] ? trace_hardirqs_on+0x1b/0xe0
[3868.777373] ? _raw_spin_unlock_irqrestore+0x3e/0x60
[3868.778280] ? kmem_cache_free+0x321/0x3c0
[3868.779011] ? __x64_sys_ioctl+0x83/0xb0
[3868.779718] __x64_sys_ioctl+0x83/0xb0
[3868.780387] do_syscall_64+0x3b/0xc0
[3868.781059] entry_SYSCALL_64_after_hwframe+0x44/0xae
[3868.781953] RIP: 0033:0x7f281c59e957
[3868.782585] Code: 3c 1c 48 f7 d8 4c (...)
[3868.785867] RSP: 002b:00007ffe1f83e2b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
[3868.787198] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281c59e957
[3868.788450] RDX: 00007ffe1f83e2c0 RSI: 0000000050009418 RDI: 0000000000000003
[3868.789748] RBP: 00007ffe1f83f300 R08: 0000000000000000 R09: 00007ffe1f83fe36
[3868.791214] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000003
[3868.792468] R13: 0000000000000003 R14: 00007ffe1f83e2c0 R15: 00000000000003cc
[3868.793765] </TASK>
[3868.794037] irq event stamp: 0
[3868.794548] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[3868.795670] hardirqs last disabled at (0): [<ffffffff98294214>] copy_process+0x934/0x2040
[3868.797086] softirqs last enabled at (0): [<ffffffff98294214>] copy_process+0x934/0x2040
[3868.798309] softirqs last disabled at (0): [<0000000000000000>] 0x0
[3868.799284] ---[ end trace be24c7002fe27747 ]---
[3868.799928] BTRFS info (device dm-0): leaf 241188864 gen 1268 total ptrs 214 free space 469 owner 2
[3868.801133] BTRFS info (device dm-0): refs 2 lock_owner 225627 current 225627
[3868.802056] item 0 key (237436928 169 0) itemoff 16250 itemsize 33
[3868.802863] extent refs 1 gen 1265 flags 2
[3868.803447] ref#0: tree block backref root 1610
(...)
[3869.064354] item 114 key (241008640 169 0) itemoff 12488 itemsize 33
[3869.065421] extent refs 1 gen 1268 flags 2
[3869.066115] ref#0: tree block backref root 1689
(...)
[3869.403834] BTRFS error (device dm-0): unable to find ref byte nr 241008640 parent 0 root 1622 owner 0 offset 0
[3869.405641] BTRFS: error (device dm-0) in __btrfs_free_extent:3076: errno=-2 No such entry
[3869.407138] BTRFS: error (device dm-0) in btrfs_run_delayed_refs:2159: errno=-2 No such entry
Fix this by passing the new subvolume's root ID to btrfs_free_tree_block().
This requires changing the root argument of btrfs_free_tree_block() from
struct btrfs_root * to a u64, since at this point during the subvolume
creation we have not yet created the struct btrfs_root for the new
subvolume, and btrfs_free_tree_block() only needs a root ID and nothing
else from a struct btrfs_root.
This was triggered by test case generic/475 from fstests.
Fixes: 67addf29004c5b ("btrfs: fix metadata extent leak after failure to create subvolume")
CC: stable@vger.kernel.org # 4.4+
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
|
|
Filipe reported a hang when we have errors on btrfs. This turned out to
be a side-effect of my fix c2e39305299f01 ("btrfs: clear extent buffer
uptodate when we fail to write it") which made it so we clear
EXTENT_BUFFER_UPTODATE on an eb when we fail to write it out.
Below is a paste of Filipe's analysis he got from using drgn to debug
the hang
"""
btree readahead code calls read_extent_buffer_pages(), sets ->io_pages to
a value while writeback of all pages has not yet completed:
--> writeback for the first 3 pages finishes, we clear
EXTENT_BUFFER_UPTODATE from eb on the first page when we get an
error.
--> at this point eb->io_pages is 1 and we cleared Uptodate bit from the
first 3 pages
--> read_extent_buffer_pages() does not see EXTENT_BUFFER_UPTODATE() so
it continues, it's able to lock the pages since we obviously don't
hold the pages locked during writeback
--> read_extent_buffer_pages() then computes 'num_reads' as 3, and sets
eb->io_pages to 3, since only the first page does not have Uptodate
bit set at this point
--> writeback for the remaining page completes, we ended decrementing
eb->io_pages by 1, resulting in eb->io_pages == 2, and therefore
never calling end_extent_buffer_writeback(), so
EXTENT_BUFFER_WRITEBACK remains in the eb's flags
--> of course, when the read bio completes, it doesn't and shouldn't
call end_extent_buffer_writeback()
--> we should clear EXTENT_BUFFER_UPTODATE only after all pages of
the eb finished writeback? or maybe make the read pages code
wait for writeback of all pages of the eb to complete before
checking which pages need to be read, touch ->io_pages, submit
read bio, etc
writeback bit never cleared means we can hang when aborting a
transaction, at:
btrfs_cleanup_one_transaction()
btrfs_destroy_marked_extents()
wait_on_extent_buffer_writeback()
"""
This is a problem because our writes are not synchronized with reads in
any way. We clear the UPTODATE flag and then we can easily come in and
try to read the EB while we're still waiting on other bio's to
complete.
We have two options here, we could lock all the pages, and then check to
see if eb->io_pages != 0 to know if we've already got an outstanding
write on the eb.
Or we can simply check to see if we have WRITE_ERR set on this extent
buffer. We set this bit _before_ we clear UPTODATE, so if the read gets
triggered because we aren't UPTODATE because of a write error we're
guaranteed to have WRITE_ERR set, and in this case we can simply return
-EIO. This will fix the reported hang.
Reported-by: Filipe Manana <fdmanana@suse.com>
Fixes: c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it")
CC: stable@vger.kernel.org # 5.4+
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
|
|
into arm/drivers
Apple SoC PMGR driver updates for 5.17
* Adds an auto-PM feature that is necessary for a single device
* Disables module builds, which were broken anyway
* tag 'asahi-soc-pmgr-5.17-v2' of https://github.com/AsahiLinux/linux:
soc: apple: apple-pmgr-pwrstate: Do not build as a module
soc: apple: apple-pmgr-pwrstate: Add auto-PM min level support
Link: https://lore.kernel.org/r/660f6f7f-0857-b54c-c415-79bcb93f0e02@marcan.st
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
arm/dt
Apple SoC DT updates for 5.17, round 2:
- Various cleanups (removing useless props, sorting nodes, renaming
things)
- Add PMGR min-state binding & props (see PMGR pull for driver change)
- Initial compatibles for t600x machines (M1 Pro/Max). This covers the
bindings that just need compatible bumps & minor tweaks, no driver
changes.
- Add watchdog node (driver not merged yet, hopefully will be; binding
went in the previous pull)
- Add missing power-domains property to the mailbox binding
* tag 'asahi-soc-dt-5.17-v2' of https://github.com/AsahiLinux/linux:
dt-bindings: mailbox: apple,mailbox: Add power-domains property
arm64: dts: apple: t8103: Sort nodes by address
arm64: dts: apple: t8103: Rename clk24 to clkref
arm64: dts: apple: t8103: Add watchdog node
dt-bindings: pinctrl: apple,pinctrl: Add apple,t6000-pinctrl compatible
dt-bindings: pci: apple,pcie: Add t6000 support
dt-bindings: i2c: apple,i2c: Add apple,t6000-i2c compatible
dt-bindings: arm: apple: Add t6000/t6001 MacBook Pro 14/16" compatibles
arm64: dts: apple: t8103: Add apple,min-state to DCP PMGR nodes
dt-bindings: power: apple,pmgr-pwrstate: Add apple,min-state prop
arm64: dts: apple: t8103: Remove PCIe max-link-speed properties
Link: https://lore.kernel.org/r/a24faafd-f2ae-c3a7-5327-b27da7d9e34b@marcan.st
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into arm/dt
STM32 DT for v5.17, round 1
Highlights:
----------
-MCU:
- fix ili9341 for dtbs_check warnings on stm32f429 disco.
- MPU:
- ST boards:
- tune HS USB phys on stm32mp15 EV1 and DKx boards.
- add pull-up on USART3/UART7 RX pins on STM32MP15 DKx boards.
- use correct pinctrl setting for STUSB1600 on STM32MP15 DK boards.
- ENGICAM:
- enable LVDS pannel on i.Core STM32MP1 EDIMM2.2.
- add "i.Core STM32MP1 C.TOUCH 2.0 10.1" OF" support:
EDIMM compliant general purpose carrier board with ETH 10/100,
WIFI/BT, CAN, ...
* tag 'stm32-dt-for-v5.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32:
ARM: dts: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0 10.1" OF
dt-bindings: arm: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0 10.1" OF
ARM: dts: stm32: Enable LVDS panel on i.Core STM32MP1 EDIMM2.2
ARM: dts: stm32: fix stusb1600 pinctrl used on stm32mp157c-dk
ARM: dts: stm32: tune the HS USB PHYs on stm32mp157c-ev1
ARM: dts: stm32: tune the HS USB PHYs on stm32mp15xx-dkx
ARM: dts: stm32: clean uart4_idle_pins_a node for stm32mp15
ARM: dts: stm32: add pull-up to USART3 and UART7 RX pins on STM32MP15 DKx boards
ARM: dts: stm32: fix dtbs_check warning on ili9341 dts binding on stm32f429 disco
Link: https://lore.kernel.org/r/dfe942db-5af7-bb82-22b6-3bd866c9017d@foss.st.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
wireless-drivers fixes for v5.16
Second set of fixes for v5.16, hopefully also the last one. I changed
my email in MAINTAINERS, one crash fix in iwlwifi and some build
problems fixed.
iwlwifi
* fix crash caused by a warning
* fix LED linking problem
brcmsmac
* rework LED dependencies for being consistent with other drivers
mt76
* mt7921: fix build regression
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The memory reservation in arch/x86/platform/efi/efi.c depends on at
least two command line parameters. Put it back later in the boot process
and move efi_memblock_x86_reserve_range() out of early_memory_reserve().
An attempt to fix this was done in
8d48bf8206f7 ("x86/boot: Pull up cmdline preparation and early param parsing")
but that caused other troubles so it got reverted.
The bug this is addressing is:
Dan reports that Anjaneya Chagam can no longer use the efi=nosoftreserve
kernel command line parameter to suppress "soft reservation" behavior.
This is due to the fact that the following call-chain happens at boot:
early_reserve_memory
|-> efi_memblock_x86_reserve_range
|-> efi_fake_memmap_early
which does
if (!efi_soft_reserve_enabled())
return;
and that would have set EFI_MEM_NO_SOFT_RESERVE after having parsed
"nosoftreserve".
However, parse_early_param() gets called *after* it, leading to the boot
cmdline not being taken into account.
See also https://lore.kernel.org/r/e8dd8993c38702ee6dd73b3c11f158617e665607.camel@intel.com
[ bp: Turn into a proper patch. ]
Signed-off-by: Mike Rapoport <rppt@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20211213112757.2612-4-bp@alien8.de
|
|
This doesn't make any sense as a module since it is a critical device,
and it turns out of_phandle_iterator_args was not exported so the module
version doesn't build anyway.
Fixes: 6df9d38f9146 ("soc: apple: Add driver for Apple PMGR power state controls")
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Hector Martin <marcan@marcan.st>
|
|
This will bind to the PMGR pwrstate nodes that control power/clock
gating to SoC blocks. The mailbox driver doesn't do runtime-pm yet, so
initially this will just keep the domain on permanently.
Reviewed-by: Sven Peter <sven@svenpeter.dev>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
|
|
We decided to keep SoC nodes sorted by address for sanity; fix a couple
that slipped into the wrong place.
Reviewed-by: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Hector Martin <marcan@marcan.st>
|
|
We now know that this frequency comes from the external reference
oscillator and is used for various SoC blocks, and isn't just a random
24MHz clock, so let's call it something more appropriate.
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Hector Martin <marcan@marcan.st>
|
|
The __dma_inv_area() and __dma_clean_area() aliases make cache.S harder
to navigate, but don't gain us anything in practice.
For clarity, let's remove them along with their redundant comments. The
only users are __dma_map_area() and __dma_unmap_area(), which need to be
position independent, and can call __pi_dcache_inval_poc() and
__pi_dcache_clean_poc() directly.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20211206124715.4101571-4-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
hwight16() is much faster. While we are at it, no need to include
"perm =" part into data_race() macro, for perm is a local variable
that cannot be accessed by other threads.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
|
|
If tomoyo is used in a testing/fuzzing environment in learning mode,
for lots of domains the quota will be exceeded and stay exceeded
for prolonged periods of time. In such cases it's pointless (and slow)
to walk the whole acl list again and again just to rediscover that
the quota is exceeded. We already have the TOMOYO_DIF_QUOTA_WARNED flag
that notes the overflow condition. Check it early to avoid the slowdown.
[penguin-kernel]
This patch causes a user visible change that the learning mode will not be
automatically resumed after the quota is increased. To resume the learning
mode, administrator will need to explicitly clear TOMOYO_DIF_QUOTA_WARNED
flag after increasing the quota. But I think that this change is generally
preferable, for administrator likely wants to optimize the acl list for
that domain before increasing the quota, or that domain likely hits the
quota again. Therefore, don't try to care to clear TOMOYO_DIF_QUOTA_WARNED
flag automatically when the quota for that domain changed.
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2021-12-14
This series contains updates to ice driver only.
Karol corrects division that was causing incorrect calculations and
adds a check to ensure stale timestamps are not being used.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This reverts commit 8d48bf8206f77aa8687f0e241e901e5197e52423.
It turned out to be a bad idea as it broke supplying mem= cmdline
parameters due to parse_memopt() requiring preparatory work like setting
up the e820 table in e820__memory_setup() in order to be able to exclude
the range specified by mem=.
Pulling that up would've broken Xen PV again, see threads at
https://lkml.kernel.org/r/20210920120421.29276-1-jgross@suse.com
due to xen_memory_setup() needing the first reservations in
early_reserve_memory() - kernel and initrd - to have happened already.
This could be fixed again by having Xen do those reservations itself...
Long story short, revert this and do a simpler fix in a later patch.
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20211213112757.2612-3-bp@alien8.de
|
|
If pm_runtime_resume_and_get() fails then it returns w/o the RPM usage
counter being incremented. In this case call pm_runtime_put() in
remove() will result in a usage counter imbalance. Therefore check the
return code of pm_runtime_resume_and_get() and bail out in case of error.
Fixes: bee08559701f ("reset: renesas: Add RZ/G2L usbphy control driver")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/ec24e13f-0530-b091-7a08-864577b9b3be@gmail.com
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
This reverts commit c0f2077baa4113f38f008b8e912b9fb3ff8d43df.
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20211213112757.2612-2-bp@alien8.de
|
|
There is a HP ProBook which using ALC236 codec and need the
ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to make mute LED and
micmute LED work.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211214164156.49711-1-jeremy.szu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
|
|
Now that HSI2C binding [1] is converted to dt-schema format, it reveals
incorrect HSI2C clocks order in USI binding example:
.../exynos-usi.example.dt.yaml:
i2c@13820000: clock-names:0: 'hsi2c' was expected
From schema: .../i2c-exynos5.yaml
.../exynos-usi.example.dt.yaml:
i2c@13820000: clock-names:1: 'hsi2c_pclk' was expected
From schema: .../i2c-exynos5.yaml
Change HSI2C clock order in USI binding example to satisfy HSI2C binding
requirements and fix above warnings.
[1] Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20211214170924.27998-1-semen.protsenko@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
|
Fix up unprivileged test case results for 'Dest pointer in r0' verifier tests
given they now need to reject R0 containing a pointer value, and add a couple
of new related ones with 32bit cmpxchg as well.
root@foo:~/bpf/tools/testing/selftests/bpf# ./test_verifier
#0/u invalid and of negative number OK
#0/p invalid and of negative number OK
[...]
#1268/p XDP pkt read, pkt_meta' <= pkt_data, bad access 1 OK
#1269/p XDP pkt read, pkt_meta' <= pkt_data, bad access 2 OK
#1270/p XDP pkt read, pkt_data <= pkt_meta', good access OK
#1271/p XDP pkt read, pkt_data <= pkt_meta', bad access 1 OK
#1272/p XDP pkt read, pkt_data <= pkt_meta', bad access 2 OK
Summary: 1900 PASSED, 0 SKIPPED, 0 FAILED
Acked-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
The implementation of BPF_CMPXCHG on a high level has the following parameters:
.-[old-val] .-[new-val]
BPF_R0 = cmpxchg{32,64}(DST_REG + insn->off, BPF_R0, SRC_REG)
`-[mem-loc] `-[old-val]
Given a BPF insn can only have two registers (dst, src), the R0 is fixed and
used as an auxilliary register for input (old value) as well as output (returning
old value from memory location). While the verifier performs a number of safety
checks, it misses to reject unprivileged programs where R0 contains a pointer as
old value.
Through brute-forcing it takes about ~16sec on my machine to leak a kernel pointer
with BPF_CMPXCHG. The PoC is basically probing for kernel addresses by storing the
guessed address into the map slot as a scalar, and using the map value pointer as
R0 while SRC_REG has a canary value to detect a matching address.
Fix it by checking R0 for pointers, and reject if that's the case for unprivileged
programs.
Fixes: 5ffa25502b5a ("bpf: Add instructions for atomic_[cmp]xchg")
Reported-by: Ryota Shiga (Flatt Security)
Acked-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Test whether unprivileged would be able to leak the spilled pointer either
by exporting the returned value from the atomic{32,64} operation or by reading
and exporting the value from the stack after the atomic operation took place.
Note that for unprivileged, the below atomic cmpxchg test case named "Dest
pointer in r0 - succeed" is failing. The reason is that in the dst memory
location (r10 -8) there is the spilled register r10:
0: R1=ctx(id=0,off=0,imm=0) R10=fp0
0: (bf) r0 = r10
1: R0_w=fp0 R1=ctx(id=0,off=0,imm=0) R10=fp0
1: (7b) *(u64 *)(r10 -8) = r0
2: R0_w=fp0 R1=ctx(id=0,off=0,imm=0) R10=fp0 fp-8_w=fp
2: (b7) r1 = 0
3: R0_w=fp0 R1_w=invP0 R10=fp0 fp-8_w=fp
3: (db) r0 = atomic64_cmpxchg((u64 *)(r10 -8), r0, r1)
4: R0_w=fp0 R1_w=invP0 R10=fp0 fp-8_w=mmmmmmmm
4: (79) r1 = *(u64 *)(r0 -8)
5: R0_w=fp0 R1_w=invP(id=0) R10=fp0 fp-8_w=mmmmmmmm
5: (b7) r0 = 0
6: R0_w=invP0 R1_w=invP(id=0) R10=fp0 fp-8_w=mmmmmmmm
6: (95) exit
However, allowing this case for unprivileged is a bit useless given an
update with a new pointer will fail anyway:
0: R1=ctx(id=0,off=0,imm=0) R10=fp0
0: (bf) r0 = r10
1: R0_w=fp0 R1=ctx(id=0,off=0,imm=0) R10=fp0
1: (7b) *(u64 *)(r10 -8) = r0
2: R0_w=fp0 R1=ctx(id=0,off=0,imm=0) R10=fp0 fp-8_w=fp
2: (db) r0 = atomic64_cmpxchg((u64 *)(r10 -8), r0, r10)
R10 leaks addr into mem
Acked-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
The change in commit 37086bfdc737 ("bpf: Propagate stack bounds to registers
in atomics w/ BPF_FETCH") around check_mem_access() handling is buggy since
this would allow for unprivileged users to leak kernel pointers. For example,
an atomic fetch/and with -1 on a stack destination which holds a spilled
pointer will migrate the spilled register type into a scalar, which can then
be exported out of the program (since scalar != pointer) by dumping it into
a map value.
The original implementation of XADD was preventing this situation by using
a double call to check_mem_access() one with BPF_READ and a subsequent one
with BPF_WRITE, in both cases passing -1 as a placeholder value instead of
register as per XADD semantics since it didn't contain a value fetch. The
BPF_READ also included a check in check_stack_read_fixed_off() which rejects
the program if the stack slot is of __is_pointer_value() if dst_regno < 0.
The latter is to distinguish whether we're dealing with a regular stack spill/
fill or some arithmetical operation which is disallowed on non-scalars, see
also 6e7e63cbb023 ("bpf: Forbid XADD on spilled pointers for unprivileged
users") for more context on check_mem_access() and its handling of placeholder
value -1.
One minimally intrusive option to fix the leak is for the BPF_FETCH case to
initially check the BPF_READ case via check_mem_access() with -1 as register,
followed by the actual load case with non-negative load_reg to propagate
stack bounds to registers.
Fixes: 37086bfdc737 ("bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH")
Reported-by: <n4ke4mry@gmail.com>
Acked-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Commit 0259d4498ba4 ("bcache: move calc_cached_dev_sectors to proper
place on backing device detach") tries to fix calc_cached_dev_sectors
when bcache device detaches, but now we have:
cached_dev_detach_finish
...
bcache_device_detach(&dc->disk);
...
closure_put(&d->c->caching);
d->c = NULL; [*explicitly set dc->disk.c to NULL*]
list_move(&dc->list, &uncached_devices);
calc_cached_dev_sectors(dc->disk.c); [*passing a NULL pointer*]
...
Upper codeflows shows how bug happens, this patch fix the problem by
caching dc->disk.c beforehand, and cache_set won't be freed under us
because c->caching closure at least holds a reference count and closure
callback __cache_set_unregister only being called by bch_cache_set_stop
which using closure_queue(&c->caching), that means c->caching closure
callback for destroying cache_set won't be trigger by previous
closure_put(&d->c->caching).
So at this stage(while cached_dev_detach_finish is calling) it's safe to
access cache_set dc->disk.c.
Fixes: 0259d4498ba4 ("bcache: move calc_cached_dev_sectors to proper place on backing device detach")
Signed-off-by: Lin Feng <linf@wangsu.com>
Signed-off-by: Coly Li <colyli@suse.de>
Link: https://lore.kernel.org/r/20211112053629.3437-2-colyli@suse.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
This is a minimal devicetree for Microsoft Surface Duo 2 with SM8350
Chipset
Signed-off-by: Katherine Perez <kaperez@linux.microsoft.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211209183246.842880-2-kaperez@linux.microsoft.com
|
|
The msm-id and board-id can be used to select the correct dtb when
multiple are provided to the bootloader.
Multiple DTBs can be provided on sdm845 devices using boot image header
v1 by appending them all to the kernel image before creating the boot
image. The bootloader then selects them like this:
Best match DTB tags 321/00000008/0x00000000/20001/20014/20115/20018/0/(offset)0x79998E27/(size)0x000173CD
Using pmic info 0x20014/0x20115/0x20018/0x0 for device 0x20014/0x20115/0x20018/0x0
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211209225938.2427342-1-caleb.connolly@linaro.org
|
