Add SOF support for ACP7.0 version based platform.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://patch.msgid.link/20240823053739.465187-3-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add acpi machine id for ACP7.0 version based platform and configure
driver data to enable SOF sound card support on newer boards.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://patch.msgid.link/20240823053739.465187-2-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Many routes are just static, not modifiable at runtime. Show the route name
for all the other routes as an edge label in the generated graph.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20240823-dapm-graph-v1-3-989a47308c4c@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Read the bias_level debugfs files (ignored so far) and visualize the On/Off
state of each component using different graphic attributes in the generated
graph.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20240823-dapm-graph-v1-2-989a47308c4c@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Widgets not belonging to any component are currently represented inside a
cluster labeled "ROOT". This is not a correct representation of the actual
structure, as these widgets are not necessarily related to each other as
the ones inside actual components are.
Improve the graphical representation by not adding a cluster around these
widgets. Now a dot cluster represents a card component faithfully. This
will be particularly important with the upcoming improvements which will
visualize the component bias_level.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20240823-dapm-graph-v1-1-989a47308c4c@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are 2G and 4G RAM versions of the Lenovo Yoga Tab 3 X90F and it
turns out that the 2G version has a DMI product name of
"CHERRYVIEW D1 PLATFORM" where as the 4G version has
"CHERRYVIEW C0 PLATFORM". The sys-vendor + product-version check are
unique enough that the product-name check is not necessary.
Drop the product-name check so that the existing DMI match for the 4G
RAM version also matches the 2G RAM version.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://patch.msgid.link/20240823074305.16873-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 13f58267cd ("ASoC: soc.h: don't create dummy Component
via COMP_DUMMY()") dummy codecs declared like this:
SND_SOC_DAILINK_DEF(dummy,
DAILINK_COMP_ARRAY(COMP_DUMMY()));
expand to:
static struct snd_soc_dai_link_component dummy[] = {
};
Which means that dummy is a zero sized array and thus dais[i].codecs should
not be dereferenced *at all* since it points to the address of the next
variable stored in the data section as the "dummy" variable has an address
but no size, so even dereferencing dais[0] is already an out of bounds
array reference.
Which means that the if (dais[i].codecs->name) check added in
commit 7d99a70b65 ("ASoC: Intel: Boards: Fix NULL pointer deref
in BYT/CHT boards") relies on that the part of the next variable which
the name member maps to just happens to be NULL.
Which apparently so far it usually is, except when it isn't
and then it results in crashes like this one:
[ 28.795659] BUG: unable to handle page fault for address: 0000000000030011
...
[ 28.795780] Call Trace:
[ 28.795787] <TASK>
...
[ 28.795862] ? strcmp+0x18/0x40
[ 28.795872] 0xffffffffc150c605
[ 28.795887] platform_probe+0x40/0xa0
...
[ 28.795979] ? __pfx_init_module+0x10/0x10 [snd_soc_sst_bytcr_wm5102]
Really fix things this time around by checking dais.num_codecs != 0.
Fixes: 7d99a70b65 ("ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://patch.msgid.link/20240823074217.14653-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge the pmdomain fixes for v6.11-rc[n] into the next branch, to allow them
to get tested together with the new changes that are targeted for v6.12.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It has turned out that having _set_required_opps() to recursively call
dev_pm_opp_set_opp() to set the required OPPs, doesn't really work as well
as we expected.
More precisely, at each recursive call to dev_pm_opp_set_opp() we are
changing an OPP for a required_dev that belongs to a required-OPP table.
The problem with this, is that we may have several devices sharing the same
required-OPP table, which leads to an incorrect behaviour in regards to
aggregating the per device votes.
To fix the problem for a required-OPP table belonging to a PM domain, which
is the only existing usecase for now, let's simply replace the call to
dev_pm_opp_set_opp() in _set_required_opps() by a call to _set_opp_level().
Moving forward we may potentially need to add support for other types of
required-OPP tables. In this case, the aggregation needs to be thought of.
Fixes: e37440e7e2 ("OPP: Call dev_pm_opp_set_opp() for required OPPs")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/20240822224547.385095-2-ulf.hansson@linaro.org
RK3128 has a setting in GRF which selects whether the vpu attached iommu
uses the AXI clock of the decoder (vdpu) or the encoder (vepu). The
default is vepu but some part of the vendor firmware sets it to vdpu.
In order to be independent on whether any of those vendor firmware blobs is
used to boot the SoC reset "vpu main clock" setting to it's default value.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Link: https://lore.kernel.org/r/20240523185633.71355-3-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add IO voltage domains support for the RK3308 SoC.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240521211029.1236094-11-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
- request the wlan-enable GPIO "as-is" to fix an issue with the wifi
module being already powered up before linux boots
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmbIWRwACgkQEacuoBRx
13JxNRAAjjBfb870YqOzyq9ipsr3UdUybBU7cGfqNgo2+On6ovZ256e3iqWUV1Zf
wS7QGUXh38OGkzj1K3/jGb08S8XyizrL/UWxJfLqYiXrbqAPldA7BrElFDUpjAeN
+tR6JjfgPNZWPPwo9W6I1axgreD2AZyDRb9FQi7x40UzgcnqQiOglzZ6U75HanjP
G9Jm36UbS7akok2/M6IQmDUSWDB8TBFGBswun76qyevePLdtcjqfj06ut3FtMG79
3xZ1w9BxwauXe1upSzSwsINO+2FKq+RvgnJOVFs5H/1+4E/jXzQt8Oro4kuuEkGd
yzCyOCQ//ub9DjKVlNAuG2siLW7QGPSuEXYyRr0AX67dLOC+tCWhnTDKX6d3SCQO
XN6e6pfkicL6nMm2TqPQ72gqLGbFlW5nGLZZtlPcQVC1/ux01z+/cBPVx3/Hw0+K
u3L2JBNi3TQPQrwHd3eCqPx/vCs4f/nudbCKKiWYJDMJiunoTNLjLF5LhKmDAZxm
7Gl1Zq+0/bOz9xY3RiyMd9nFVJjbHchLf7uRaRTqsrVQZPeBfXkMAa7vCJ+ImcD5
w6mA6Ew7512S2+62yY19L9ZFidBeB+QELTghDA2t3bdhcoOK4HWRYWznSsJ6PrMK
KRG9ZHYB6OOwU7JtxwBlqLTSsjB2BQky1QZlj/0H4vB0fM1Lxts=
=d/4T
-----END PGP SIGNATURE-----
Merge tag 'pwrseq-fixes-for-v6.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull power sequencing fix from Bartosz Golaszewski:
- request the wlan-enable GPIO "as-is" to fix an issue with the wifi
module being already powered up before linux boots
* tag 'pwrseq-fixes-for-v6.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
power: sequencing: request the WLAN enable GPIO as-is
- imx: Remove duplicated clocks for scu power domain
- imx: Wait for SSAR to complete power-on for i.MX93 power domain
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmbIUTgXHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCksUw/+IRFASAh9XdENGY/hrjAdHR7E
PuclSeZMjDOjVui7zFTQzzQGmUAsO4PjsZMvAy+b+b+oLkd8aBoKdn9dnldhy/U7
0YtVQa/rbCefflHtzCD+3psrUrBPDPYbxUg2VMTI75ZGQBJnyrEUZe2ZCA0Qldi1
s3kPbjMxhNeV8hSeXrOo0ehk/xZjPemcfkJp+8HdSg4m6YJaAenjPUa84uDBTAu8
7HTZLFNwvkQS4VmSQO6oX3LDl39t6HhG1jn3CtDBF0z5AkjJmUB9vW8Zoy1eqw/1
p0Q0jZ6ppvSLqtj2iVL7pAYEUhJSFY3zYk/mv3O6nwRdqJHpbHgo3ArCnKDlYmtm
MFqHUjP8s2uoJQPlXjiamrc69E+4HOQkhahkVXK6/JzajH3ClNVvjcvitSgb9rdt
+FDhdgkXrlpKtNNzT1AyBN8IibHOrEle9aRQQZnB3vxF31m1QL9DMTJ17eEeTucT
uee0a0MjMcFmU27tKGcZM/iXD1CVJKHI2xWv0drF3KYqDKGSrOy7FdzdE9WLVWAC
s4ijzMGVDmqOtlQaj9OGifP2GPoxvFRj1kRV0mFgvQIGU9N5/MBgqLzOFEuDMy2K
1rml9d8zSqyk7tHBsCZKyXJwY0Xn+mgia92S+aGPTUvvAMeQR/Fftp6HAT246vuc
S5fcG3zomJ9IFym1knU=
=eOzk
-----END PGP SIGNATURE-----
Merge tag 'pmdomain-v6.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm
Pull pmdomain fixes from Ulf Hansson:
- imx: Remove duplicated clocks for scu power domain
- imx: Wait for SSAR to complete power-on for i.MX93 power domain
* tag 'pmdomain-v6.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm:
pmdomain: imx: wait SSAR when i.MX93 power domain on
pmdomain: imx: scu-pd: Remove duplicated clocks
As we discussed in the room at netdevconf earlier this week,
drop the requirement for special comment style for netdev.
For checkpatch, the general check accepts both right now, so
simply drop the special request there as well.
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Clean up and reorder them according to the bit index. There is no
functional change.
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20240816221650.62295-1-suravee.suthikulpanit@amd.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The iommu_report_device_fault function was updated to return void while
assuming that drivers only need to call iommu_report_device_fault() for
reporting an iopf. This implementation causes following problems:
1. The drivers rely on the core code to call it's page_reponse,
however, when a fault is received and no fault capable domain is
attached / iopf_param is NULL, the ops->page_response is NOT called
causing the device to stall in case the fault type was PAGE_REQ.
2. The arm_smmu_v3 driver relies on the returned value to log errors
returning void from iommu_report_device_fault causes these events to
be missed while logging.
Modify the iommu_report_device_fault function to return -EINVAL for
cases where no fault capable domain is attached or iopf_param was NULL
and calls back to the driver (ops->page_response) in case the fault type
was IOMMU_FAULT_PAGE_REQ. The returned value can be used by the drivers
to log the fault/event as needed.
Reported-by: Kunkun Jiang <jiangkunkun@huawei.com>
Closes: https://lore.kernel.org/all/6147caf0-b9a0-30ca-795e-a1aa502a5c51@huawei.com/
Fixes: 3dfa64aecb ("iommu: Make iommu_report_device_fault() return void")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20240816104906.1010626-1-praan@google.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Going forward, struct intel_display shall replace struct
drm_i915_private as the main display device data pointer type. Convert
intel_display_params.[ch] and intel_display_debugfs_params.[ch] to
struct intel_display.
Some stragglers are left behind where needed.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3e5cc1744eaf4708b08303e3e7e194035d7941cc.1724342644.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When building for xe, we get the context imbalance warning as the actual
locking/unlocking is not compiled:
../drivers/gpu/drm/i915/display/intel_vblank.c:306:13: warning: context imbalance in 'intel_vblank_section_enter' - wrong count at exit
../drivers/gpu/drm/i915/display/intel_vblank.c:314:13: warning: context imbalance in 'intel_vblank_section_exit' - wrong count at exit
Fix by adding separata stubs for xe without __acquires/__releases
annotation.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/111de5bee15f408de65b19ece4b68a7ac66b30cf.1724342644.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
- Don't drop references on LPIs that weren't visited by the
vgic-debug iterator
- Cure lock ordering issue when unregistering vgic redistributors
- Fix for misaligned stage-2 mappings when VMs are backed by hugetlb
pages
- Treat SGI registers as UNDEFINED if a VM hasn't been configured for
GICv3
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQSNXHjWXuzMZutrKNKivnWIJHzdFgUCZsb21xccb2xpdmVyLnVw
dG9uQGxpbnV4LmRldgAKCRCivnWIJHzdFkrnAP943OLc8UYPCQruiNuzDvzjF4Sf
zI1bdOczyL7QerD/GAD/cVa6I9RigjI+QQd9JeY7V8FUpo6B0KejGvB6DPXIfA8=
=7wBh
-----END PGP SIGNATURE-----
Merge tag 'kvmarm-fixes-6.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into for-next/fixes
KVM/arm64 fixes for 6.11, round #2
- Don't drop references on LPIs that weren't visited by the
vgic-debug iterator
- Cure lock ordering issue when unregistering vgic redistributors
- Fix for misaligned stage-2 mappings when VMs are backed by hugetlb
pages
- Treat SGI registers as UNDEFINED if a VM hasn't been configured for
GICv3
* tag 'kvmarm-fixes-6.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm:
KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
KVM: arm64: Ensure canonical IPA is hugepage-aligned when handling fault
KVM: arm64: vgic: Don't hold config_lock while unregistering redistributors
KVM: arm64: vgic-debug: Don't put unmarked LPIs
KVM: arm64: vgic: Hold config_lock while tearing down a CPU interface
KVM: selftests: arm64: Correct feature test for S1PIE in get-reg-list
KVM: arm64: Tidying up PAuth code in KVM
KVM: arm64: vgic-debug: Exit the iterator properly w/o LPI
KVM: arm64: Enforce dependency on an ARMv8.4-aware toolchain
docs: KVM: Fix register ID of SPSR_FIQ
KVM: arm64: vgic: fix unexpected unlock sparse warnings
KVM: arm64: fix kdoc warnings in W=1 builds
KVM: arm64: fix override-init warnings in W=1 builds
KVM: arm64: free kvm->arch.nested_mmus with kvfree()
With the new __counted_by annotation, the "num_leds" variable needs to
valid for accesses to the "leds" array. This requirement is not met in
gpio_leds_create(), since "num_leds" starts at "0", so "leds" index "0"
will not be considered valid (num_leds would need to be "1" to access
index "0").
Fix this by setting the allocation size after allocation, and then update
the final count based on how many were actually added to the array.
Fixes: 52cd75108a ("leds: gpio: Annotate struct gpio_leds_priv with __counted_by")
Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20240716212455.work.809-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
This adds support for CMU_TOP which generates clocks for all the
function blocks such as CORE, HSI0/1/2, PERIC0/1 and so on. For
CMU_TOP, PLL_SHARED0,1,2,3,4 and 5 will be the sources of this block
and they will generate bus clocks.
Signed-off-by: Sunyeal Hong <sunyeal.hong@samsung.com>
Link: https://lore.kernel.org/r/20240821232652.1077701-5-sunyeal.hong@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
pll531x PLL is used in Exynos Auto v920 SoC for shared pll.
pll531x: Integer/fractional PLL with mid frequency FVCO (800 to 3120 MHz)
PLL531x
FOUT = (MDIV x FIN)/(PDIV x 2^SDIV) for integer PLL
FOUT = (MDIV + F/2^32-F[31]) x FIN/(PDIV x 2^SDIV) for fractional PLL
Signed-off-by: Sunyeal Hong <sunyeal.hong@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Link: https://lore.kernel.org/r/20240821232652.1077701-4-sunyeal.hong@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
A relatively large collection of fixes here, all driver specific and
none of them particularly major, plus one MAINTAINERS update. There's
been a bunch of work on module autoloading from several people.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmbHv+8ACgkQJNaLcl1U
h9Czhgf/VTYu0+olW0SoNxGIzRSi89Sx7HFAug33EiTJ1JC5fvFxV1G94VMTPBkn
mXv+bb2WbPDSDwsehveBAxZLc1EnmqB5KZkAd/7DTuU1wVfF7PIWOAJZikc+blAJ
fYFUr+aD7dc+evcZCiUPwAPYFxuusQOQAL7Y48wrG7wOTlropJdkwugiJ4fQWIk7
6fuQ3vxwUjACTjP4u6EV+a/H+XMKLqy9D05PCMvupp+awY3HzPoan5/w5vcq7WcQ
xwzvTuz2Snn5ay83LPhyTIjGy40/O2n+LblnuqEzLD6KaPSNqGRzuCdqdACstjX+
xD/1B+wAkVG+oajXKQpu2tvEWL1iUg==
=xZ3o
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v6.11-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.11
A relatively large collection of fixes here, all driver specific and
none of them particularly major, plus one MAINTAINERS update. There's
been a bunch of work on module autoloading from several people.
Correct spelling in xfrm.h.
As reported by codespell.
Signed-off-by: Simon Horman <horms@kernel.org>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
One way to explain what `ListArc` does is that it controls exclusive
access to the prev/next pointer field in a refcounted object. The
feature of having a special reference to a refcounted object with
exclusive access to specific fields is useful for other things, so
provide a general utility for that.
This is used by Rust Binder to keep track of which processes have a
reference to a given node. This involves an object for each process/node
pair, that is referenced by both the process and the node. For some
fields in this object, only the process's reference needs to access
them (and it needs mutable access), so Binder uses a ListArc to give the
process's reference exclusive access.
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240814-linked-list-v5-10-f5f5e8075da0@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Support linked lists that can hold many different structs at once. This
is generally done using trait objects. The main challenge is figuring
what the struct is given only a pointer to the ListLinks.
We do this by storing a pointer to the struct next to the ListLinks
field. The container_of operation will then just read that pointer. When
the type is a trait object, that pointer will be a fat pointer whose
metadata is a vtable that tells you what kind of struct it is.
Heterogeneous lists are heavily used by Rust Binder. There are a lot of
so-called todo lists containing various events that need to be delivered
to userspace next time userspace calls into the driver. And there are
quite a few different todo item types: incoming transaction, changes to
refcounts, death notifications, and more.
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240814-linked-list-v5-9-f5f5e8075da0@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The cursor is very similar to the list iterator, but it has one
important feature that the iterator doesn't: it can be used to remove
items from the linked list.
This feature cannot be added to the iterator because the references you
get from the iterator are considered borrows of the original list,
rather than borrows of the iterator. This means that there's no way to
prevent code like this:
let item = iter.next();
iter.remove();
use(item);
If `iter` was a cursor instead of an iterator, then `item` will be
considered a borrow of `iter`. Since `remove` destroys `iter`, this
means that the borrow-checker will prevent uses of `item` after the call
to `remove`.
So there is a trade-off between supporting use in traditional for loops,
and supporting removal of elements as you iterate. Iterators and cursors
represents two different choices on that spectrum.
Rust Binder needs cursors for the list of death notifications that a
process is currently handling. When userspace tells Binder that it has
finished processing the death notification, Binder will iterate the list
to search for the relevant item and remove it.
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240814-linked-list-v5-8-f5f5e8075da0@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rust Binder has lists containing stuff such as all contexts or all
processes, and sometimes needs to iterate over them. This patch enables
Rust Binder to do that using a normal for loop.
The iterator returns the ArcBorrow type, so it is possible to grab a
refcount to values while iterating.
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240814-linked-list-v5-7-f5f5e8075da0@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add the actual linked list itself.
The linked list uses the following design: The List type itself just has
a single pointer to the first element of the list. And the actual list
items then form a cycle. So the last item is `first->prev`.
This is slightly different from the usual kernel linked list. Matching
that exactly would amount to giving List two pointers, and having it be
part of the cycle of items. This alternate design has the advantage that
the cycle is never completely empty, which can reduce the number of
branches in some cases. However, it also has the disadvantage that List
must be pinned, which this design is trying to avoid.
Having the list items form a cycle rather than having null pointers at
the beginning/end is convenient for several reasons. For one, it lets us
store only one pointer in List, and it simplifies the implementation of
several functions.
Unfortunately, the `remove` function that removes an arbitrary element
from the list has to be unsafe. This is needed because there is no way
to handle the case where you pass an element from the wrong list. For
example, if it is the first element of some other list, then that other
list's `first` pointer would not be updated. Similarly, it could be a
data race if you try to remove it from two different lists in parallel.
(There's no problem with passing `remove` an item that's not in any
list. Additionally, other removal methods such as `pop_front` need not
be unsafe, as they can't be used to remove items from another list.)
A future patch in this series will introduce support for cursors that
can be used to remove arbitrary items without unsafe code.
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240814-linked-list-v5-6-f5f5e8075da0@google.com
[ Fixed a few typos. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Adds a macro for safely implementing the ListItem trait. As part of the
implementation of the macro, we also provide a HasListLinks trait
similar to the workqueue's HasWorkItem trait.
The HasListLinks trait is only necessary if you are implementing
ListItem using the impl_list_item macro.
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240814-linked-list-v5-5-f5f5e8075da0@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Define the ListLinks struct, which wraps the prev/next pointers that
will be used to insert values into a List in a future patch. Also
define the ListItem trait, which is implemented by structs that have a
ListLinks field.
The ListItem trait provides four different methods that are all
essentially container_of or the reverse of container_of. Two of them are
used before inserting/after removing an item from the list, and the two
others are used when looking at a value without changing whether it is
in a list. This distinction is introduced because it is needed for the
patch that adds support for heterogeneous lists, which are implemented
by adding a third pointer field with a fat pointer to the full struct.
When inserting into the heterogeneous list, the pointer-to-self is
updated to have the right vtable, and the container_of operation is
implemented by just returning that pointer instead of using the real
container_of operation.
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240814-linked-list-v5-4-f5f5e8075da0@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add the ability to track whether a ListArc exists for a given value,
allowing for the creation of ListArcs without going through UniqueArc.
The `impl_list_arc_safe!` macro is extended with a `tracked_by` strategy
that defers the tracking of ListArcs to a field of the struct.
Additionally, the AtomicListArcTracker type is introduced, which can
track whether a ListArc exists using an atomic. By deferring the
tracking to a field of type AtomicListArcTracker, structs gain the
ability to create ListArcs without going through a UniqueArc.
Rust Binder uses this for some objects where we want to be able to
insert them into a linked list at any time. Using the
AtomicListArcTracker, we are able to check whether an item is already in
the list, and if not, we can create a `ListArc` and push it.
The macro has the ability to defer the tracking of ListArcs to a field,
using whatever strategy that field has. Since we don't add any
strategies other than AtomicListArcTracker, another similar option would
be to hard-code that the field should be an AtomicListArcTracker.
However, Rust Binder has a case where the AtomicListArcTracker is not
stored directly in the struct, but in a sub-struct. Furthermore, the
outer struct is generic:
struct Wrapper<T: ?Sized> {
links: ListLinks,
inner: T,
}
Here, the Wrapper struct implements ListArcSafe with `tracked_by inner`,
and then the various types used with `inner` also uses the macro to
implement ListArcSafe. Some of them use the untracked strategy, and some
of them use tracked_by with an AtomicListArcTracker. This way, Wrapper
just inherits whichever choice `inner` has made.
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240814-linked-list-v5-3-f5f5e8075da0@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The `ListArc` type can be thought of as a special reference to a
refcounted object that owns the permission to manipulate the
`next`/`prev` pointers stored in the refcounted object. By ensuring that
each object has only one `ListArc` reference, the owner of that
reference is assured exclusive access to the `next`/`prev` pointers.
When a `ListArc` is inserted into a `List`, the `List` takes ownership
of the `ListArc` reference.
There are various strategies for ensuring that a value has only one
`ListArc` reference. The simplest is to convert a `UniqueArc` into a
`ListArc`. However, the refcounted object could also keep track of
whether a `ListArc` exists using a boolean, which could allow for the
creation of new `ListArc` references from an `Arc` reference. Whatever
strategy is used, the relevant tracking is referred to as "the tracking
inside `T`", and the `ListArcSafe` trait (and its subtraits) are used to
update the tracking when a `ListArc` is created or destroyed.
Note that we allow the case where the tracking inside `T` thinks that a
`ListArc` exists, but actually, there isn't a `ListArc`. However, we do
not allow the opposite situation where a `ListArc` exists, but the
tracking thinks it doesn't. This is because the former can at most
result in us failing to create a `ListArc` when the operation could
succeed, whereas the latter can result in the creation of two `ListArc`
references. Only the latter situation can lead to memory safety issues.
This patch introduces the `impl_list_arc_safe!` macro that allows you to
implement `ListArcSafe` for types using the strategy where a `ListArc`
can only be created from a `UniqueArc`. Other strategies are introduced
in later patches.
This is part of the linked list that Rust Binder will use for many
different things. The strategy where a `ListArc` can only be created
from a `UniqueArc` is actually sufficient for most of the objects that
Rust Binder needs to insert into linked lists. Usually, these are todo
items that are created and then immediately inserted into a queue.
The const generic ID allows objects to have several prev/next pointer
pairs so that the same object can be inserted into several different
lists. You are able to have several `ListArc` references as long as they
correspond to different pointer pairs. The ID itself is purely a
compile-time concept and will not be present in the final binary. Both
the `List` and the `ListArc` will need to agree on the ID for them to
work together. Rust Binder uses this in a few places (e.g. death
recipients) where the same object can be inserted into both generic todo
lists and some other lists for tracking the status of the object.
The ID is a const generic rather than a type parameter because the
`pair_from_unique` method needs to be able to assert that the two ids
are different. There's no easy way to assert that when using types
instead of integers.
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240814-linked-list-v5-2-f5f5e8075da0@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add a macro to statically check if a field of a struct is marked with
`#[pin]` ie that it is structurally pinned. This can be used when
`unsafe` code needs to rely on fields being structurally pinned.
The macro has a special "inline" mode for the case where the type
depends on generic parameters from the surrounding scope.
Signed-off-by: Benno Lossin <benno.lossin@proton.me>
Co-developed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240814-linked-list-v5-1-f5f5e8075da0@google.com
[ Replaced `compile_fail` with `ignore` and a TODO note. Removed
`pub` from example to clean `unreachable_pub` lint. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Some configuration options such as the supported sanitizer list are
arrays. To support using Rust with sanitizers on x86, we must update the
target.json generator to support this case.
The Push trait is removed in favor of the From trait because the Push
trait doesn't work well in the nested case where you are not really
pushing values to a TargetSpec.
Signed-off-by: Matthew Maurer <mmaurer@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Tested-by: Gatlin Newhouse <gatlin.newhouse@gmail.com>
Link: https://lore.kernel.org/r/20240730-target-json-arrays-v1-1-2b376fd0ecf4@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
- Fix the max segment size and max number of segments supported by the
pata_macio driver to fix issues with BIO splitting leading to an
overflow of the adapter DMA table (from Michael).
- Related to the previous fix, change BUG_ON() calls for incorrect
command buffer segmentation into WARN_ON() and an error return (from
Michael).
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSRPv8tYSvhwAzJdzjdoc3SxdoYdgUCZsfZnQAKCRDdoc3SxdoY
dt+uAQDy8Y9KTaAtEy4nI7bLkeyLz/wI9mFLuxWkc2KgZ5SnDwEA4ub56/V1/fbb
Ae5Sm1KmUUU4E9AecqCD7Hg4wKNWoAc=
=HBRQ
-----END PGP SIGNATURE-----
Merge tag 'ata-6.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux
Pull ata fixes from Damien Le Moal:
- Fix the max segment size and max number of segments supported by the
pata_macio driver to fix issues with BIO splitting leading to an
overflow of the adapter DMA table (from Michael)
- Related to the previous fix, change BUG_ON() calls for incorrect
command buffer segmentation into WARN_ON() and an error return (from
Michael)
* tag 'ata-6.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
ata: pata_macio: Use WARN instead of BUG
ata: pata_macio: Fix DMA table overflow
Bart Van Assche <bvanassche@acm.org> says:
Hi Martin,
Multiple SCSI drivers use snprintf() to format a workqueue name before
invoking one of the create*_workqueue() macros. This patch series
simplifies such code by passing the format string and arguments to
alloc_workqueue(). Additionally, the structure members that are only
used as a temporary buffer for formatting workqueue names are
removed. Please consider this patch series for the next merge window.
Thanks,
Bart.
Link: https://lore.kernel.org/r/20240822195944.654691-1-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Let alloc_workqueue() format the workqueue name. Remove the
work_q_name[] member from struct Scsi_Host because it is no longer
used by any SCSI driver nor by the SCSI core.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20240822195944.654691-19-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Let alloc*_workqueue() format the workqueue name instead of calling
snprintf() explicitly.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20240822195944.654691-18-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Let alloc_ordered_workqueue() format the workqueue name instead of calling
snprintf() explicitly.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20240822195944.654691-17-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
