| Age | Commit message (Collapse) | Author |
|
Add a 'bound lifetime to the associated Data, changing type Data to type
Data<'bound>.
This allows the driver's bus device private data to capture the device /
driver bound lifetime; device resources can be stored directly by
reference rather than requiring Devres.
The probe() and unbind() callbacks thus gain a 'bound lifetime parameter
on the methods themselves; avoiding a global lifetime on the trait impl.
Existing drivers set type Data<'bound> = Self, preserving the current
behavior.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-13-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
[Why]
With CONFIG_DRM_AMD_DC_KUNIT_TEST=m, allmodconfig only defines the
_MODULE variant. Four KUnit helper headers gate their declarations
with #ifdef CONFIG_DRM_AMD_DC_KUNIT_TEST, so the declarations vanish
while the matching .c files (driven by IS_ENABLED() via
STATIC_IFN_KUNIT) keep the functions non-static. The build breaks
with implicit declarations and -Werror=missing-prototypes.
amdgpu_dm_crc.h additionally uses symbols that its test file does not
pull in indirectly, amdgpu_dm_colorop_test.c has a copy-paste
duplicate function with the wrong expected bitmask, and the three
colorop TF bitmasks are not exported for modpost.
[How]
- Switch the crc/hdcp/color/psr KUnit guards to IS_ENABLED().
- Make amdgpu_dm_crc.h self-contained (dc_types.h + forward decl).
- Rename the duplicated shaper test back to its intended name and
fix its expected bitmask.
- Export amdgpu_dm_supported_{degam,shaper,blnd}_tfs via
EXPORT_IF_KUNIT().
Assisted-by: Copilot:claude-4-opus
Reviewed-by: Alex Hung <alex.hung@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ray Wu <ray.wu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Device<Core> references in probe callbacks are scoped to the callback,
not the full binding duration. Add a lifetime parameter to Core and
CoreInternal to accurately represent this in the type system.
Suggested-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-12-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Move the post_unbind_rust callback before devres_release_all() in
device_unbind_cleanup().
With drvdata() removed, the driver's bus device private data is only
accessible by the owning driver itself. It is hence safe to drop the
driver's bus device private data before devres actions are released.
This reordering is the key enabler for Higher-Ranked Lifetime Types
(HRT) in Rust device drivers -- it allows driver structs to hold direct
references to devres-managed resources, because the bus device private
data (and with it all such references) is guaranteed to be dropped while
the underlying devres resources are still alive.
Without this change, devres resources would be freed first, leaving the
driver's bus device private data with dangling references during its
destructor.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260525202921.124698-6-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add a type Data<'bound> associated type to all bus driver traits,
decoupling the driver's bus device private data type from the driver
struct itself.
In the context of adding a 'bound lifetime, making this an associated
type has the advantage that it allows us to avoid a driver trait global
lifetime and it avoids the need for ForLt for bus device private data;
both of which make the subsequent implementation by buses much simpler.
All existing drivers and doc examples set type Data = Self to preserve
the current behavior.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260525202921.124698-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
cpu_data().topo.apicid and kfd_fill_iolink_info_for_cpu() rely on
x86-specific structs not present on UML. The kfd_topology.c and
kfd_crat.c were guarded by CONFIG_X86_64 alone, causing build
failures when CONFIG_DRM_AMDGPU is selected on UML.
Update guards to '#if defined(CONFIG_X86_64) && !defined(CONFIG_UML)'
to ensure x86_64-only paths are excluded on UML builds.
Fixes: af3f2f5db265 ("drm/amdgpu: Remove UML build exclusion from Kconfig")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605140506.TI8zPIBG-lkp@intel.com/
Cc: Harry Wentland <harry.wentland@amd.com>
Assisted-by: Copilot:Claude-Sonnet-4.6
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
In nvmet_tcp_alloc_queue(), when a connection is closed during the
allocation process (e.g., nvmet_tcp_set_queue_sock() returns -ENOTCONN),
the error handling jumps to out_destroy_sq and then to out_ida_remove
without draining the page fragment cache.
Although nvmet_tcp_free_cmd() is called in some error paths to release
individual page fragments, the underlying page cache reference held by
queue->pf_cache is never released. The first allocation using pf_cache
is the call to nvmet_tcp_alloc_cmd() for queue->connect, which happens
after ida_alloc() returns successfully. This results in a page leak each
time a connection fails during allocation, which could lead to memory
exhaustion over time if connections are repeatedly opened and closed.
Fix this by calling page_frag_cache_drain() before freeing the queue
structure in the out_ida_remove label.
Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
The timeout variable in nvme_wait_freeze_timeout() is an unsigned type.
Checking if it is <= 0 triggers a compiler warning because an unsigned
variable can never be negative.
Fix this warning by changing the type to long.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/r/202605211257.STzj2Ujv-lkp@intel.com/
Fixes: 23b6d2cbf75f ("nvme: remove redundant timeout argument from nvme_wait_freeze_timeout")
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Wa_16023105232 programs the register IDLEDLY. The register is reset
whenever the engine is reset. Therefore it should be added to the GuC
save-restore register list for it to be restored after reset.
Fixes: 7c53ff050ba8 ("drm/xe: Apply Wa_16023105232")
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260522163531.1365540-2-balasubramani.vivekanandan@intel.com
Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
|
|
The ASUS DC301 USB-C dock containing a Realtek MST branch device
supports the DSC decompression functionality on each of the dock's
downstream connectors, even though there is no discoverable peer-to-peer
virtual device in the MST topology (which the DP Standard
requires/suggests to control the DSC functionality on a per-DFP basis).
Add the DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD quirk for this branch
device as well to enable the DSC decompression functionality on all DFP
connectors of the dock, similarly to how this is done for dock's
containing older Synaptics branch devices.
Cc: Lyude Paul <lyude@redhat.com>
Reported-and-tested-by: Shawn C Lee <shawn.c.lee@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260525125516.2794636-1-imre.deak@intel.com
|
|
Header files should use the C-style '/*' block comment for SPDX
license identifiers. Correct the style in pinctrl-mtk-mt8365.h
to satisfy checkpatch requirements.
Signed-off-by: Mayur Kumar <kmayur809@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Header files should use the C-style '/*' block comment for SPDX
license identifiers. Correct the style in pinctrl-owl.h
to satisfy checkpatch requirements.
Signed-off-by: Mayur Kumar <kmayur809@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Header files should use the C-style '/*' block comment for SPDX
license identifiers. Correct the style in pinctrl-bcm63xx.h
to satisfy checkpatch requirements.
Signed-off-by: Mayur Kumar <kmayur809@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Extend the tegra264_mc_clients table to cover the full set of memory
clients exposed by the SoC. The client name is used for MC fault
reporting. Clients managed by the BPMP bandwidth manager additionally
carry their bpmp_id and type.
Entries in tegra264_mc_clients[] are sorted to match the order of
the override and security register offsets used in previous SoCs.
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
Link: https://patch.msgid.link/20260518124306.2071481-4-sumitg@nvidia.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Some MC clients are present in tegra264_mc_clients[] only for
fault-log naming and have no .bpmp_id or .type assigned. Skip
forwarding bandwidth requests to BPMP for such clients in
tegra264_mc_icc_set().
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
Link: https://patch.msgid.link/20260518124306.2071481-2-sumitg@nvidia.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Unfortunately, this chip also comes with an incorrect BFPT table,
indicating the Control Register cannot be read back. This is wrong,
reading back the register works and has no (observed) side effect. The
datasheet clearly indicates supporting the 35h command and all bits from
the CR are marked readable. QE and CMP bits are inside, and can be
properly read back.
Add a fixup for this, otherwise it would defeat the use of the CMP
feature.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
|
|
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
|
|
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Unfortunately, this chip also comes with an incorrect BFPT table,
indicating the Control Register cannot be read back. This is wrong,
reading back the register works and has no (observed) side effect. The
datasheet clearly indicates supporting the 35h command and all bits from
the CR are marked readable. QE and CMP bits are inside, and can be
properly read back.
Add a fixup for this, otherwise it would defeat the use of the CMP
feature.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
|
|
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Unfortunately, this chip also comes with an incorrect BFPT table,
indicating the Control Register cannot be read back. This is wrong,
reading back the register works and has no (observed) side effect. The
datasheet clearly indicates supporting the 35h command and all bits from
the CR are marked readable. QE and CMP bits are inside, and can be
properly read back.
Add a fixup for this, otherwise it would defeat the use of the CMP
feature.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
|
|
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
|
|
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
|
|
The current locking implementation allows to select a power of two
number of blocks, which is going to be the protected amount, as well as
telling whether this is the data at the top (end of the device) or the
bottom (beginning of the device). This means at most we can cover half
of the device or the entire device, but nothing in between.
The complement feature allows a much finer grain of configuration, by
allowing to invert what is considered locked and unlocked.
Add support for this feature. The only known position for the CMP bit is
bit 6 of the configuration register.
The locking and unlocking logics are kept unchanged if the CMP bit is
unavailable. Otherwise, once the regular logic has been applied, we
check if we already found an optimal configuration. If not, we try with
the CMP bit set. If the coverage is closer to the request, we use it.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
|
|
The debounce bit sets a bypass on the debounce rather than enabling it,
as such the current polarity of the debounce is set incorrectly. Invert
the polarity to correct this.
Fixes: d5282a539297 ("pinctrl: cs42l43: Add support for the cs42l43")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Returning directly if the regmap_update_bits() fails causes a pm runtime
reference to be leaked, let things run to the end of the function
instead.
Fixes: e52c741907fb ("pinctrl: cirrus: cs42l43: use new GPIO line value setter callbacks")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Each GPIO bank has two 32-bit MFP registers: MFPL covering pins 0-7
at the bank base offset, and MFPH covering pins 8-15 at base offset+4.
ma35_pinctrl_parse_groups() computed the register address without
accounting for this split, so any pin with an index >= 8 within its
bank was written to the wrong register.
Also fix the pin descriptor table in pinctrl-ma35d1.c: switch from
sequential to 16-per-bank pin numbering, add missing PC8-PC11 pins
and their mux options, and remove the duplicate PN10-PN15 entries.
Fixes: f805e356313b ("pinctrl: nuvoton: Add ma35d1 pinctrl and GPIO driver")
Signed-off-by: Joey Lu <a0987203069@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add support for the three pin controllers (MAIN, UPHY and AON) found on
Tegra264.
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add support for the two pin controllers (MAIN and AON) found on Tegra238.
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Export tegra_pinctrl_probe() to allow SoC-specific Tegra pinctrl drivers
built as modules to use the common probe path.
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Drop the unnecessary initialization of device_id_scheme to false.
Signed-off-by: Jean-Ralph Aviles <jeanralph.aviles@gmail.com>
[ rjw: Subject and changelog edits ]
Link: https://patch.msgid.link/39d1c5567a2c0c6454a0c10a32d2dd853349d303.1778378939.git.jeanralph.aviles@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Currently in the function opt3001_get_processed(), there is a check
that directly returns -ETIMEDOUT if the conversion IRQ times out,
completely bypassing the err label, leaving ok_to_ignore_lock
permanently true, potentially breaking the device's falling threshold
interrupt detection.
Assign -ETIMEDOUT to the return variable and jump to the error label
to ensure ok_to_ignore_lock is properly reset.
Fixes: 26d90b559057 ("iio: light: opt3001: Fixed timeout error when 0 lux")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260525-opt3001-cleanup-v4-0-65b36a174f78%40gmail.com?part=1
Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
There is no need nor gain in splitting mutex or list initializations
between two init functions as all of this is just pure software state
and all this could be done at once.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20260526195452.20545-8-michal.wajdeczko@intel.com
|
|
We should separate software-only state initialization from anything
else that requires access to the device's hardware. Extract d3cold
capability detection into a new function. Add simple kernel-doc for
updated functions here.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20260526195452.20545-7-michal.wajdeczko@intel.com
|
|
We would like to initialize more of the xe_device struct also from
the kunit code, as it should be safe to use most of the generic drm
or xe components without doing any additional tweaks. Separate early
xe initialization code to a new function, so it can be reused.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20260526195452.20545-6-michal.wajdeczko@intel.com
|
|
The xe_info_init_early() is a place where we initialize those of
the xe->info fields that do not require any additional hardware
probes. Move the initialization of the devid/revid also there, but
to avoid breaking the kunit helper, which also calls this function,
keep their initialization separate in sub-function so we can easily
stub it when running the kunit test.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20260526195452.20545-5-michal.wajdeczko@intel.com
|
|
The xe_info_init_early() is a place where we initialize those of
the xe->info fields that do not require any additional hardware
probes. Move the initialization of the force_execlist flag there.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20260526195452.20545-4-michal.wajdeczko@intel.com
|
|
We never used or need anything from the struct pci_device_id there.
And while around, add simple kernel-doc for this function.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20260526195452.20545-3-michal.wajdeczko@intel.com
|
|
We don't need the partially initialized xe_device pointer to
find the sub-platform descriptor, as for the descriptor lookup
only the device ID is required and it can be obtained directly
from the pci_dev.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Link: https://patch.msgid.link/20260526195452.20545-2-michal.wajdeczko@intel.com
|
|
Include linux/bitfield.h for FIELD_GET().
Create new macros for bit manipulation in combination with manual bit
manipulation being replaced with FIELD_GET().
The current variable declaration and initializations are barely readable
and use comma separations across multiple lines. Refactor the
initializations so that mantissa and exp have separate declarations and
sign gets initialized later.
In addition (and due to the nature of the cleanup), fix a sign-extension
bug where, float32 would get bitwise anded with ~BIT(31)
(which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent.
Fixes: 64b3d8b1b0f5c ("iio: chemical: scd30: add core driver")
Reported-by: sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260524020309.18618-1-m32285159%40gmail.com
Signed-off-by: Maxwell Doose <m32285159@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
This driver was originally merged in 2002 for a board using
the Cirrus Logic CL/PS711x platform, but the actual board
file never made it upstream.
The SoC platform is still supported but uses devicetree
based probing, so if anyone ever wanted to upstream board
support, they would just use the regular physmap driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Rather than using platform data or DT properties, the configuration
for this mtd map driver used to be passed through the global
uclinux_ram_map structure, but the last instance was removed in
commit 4ba66a976072 ("arch: remove blackfin port") in 2018.
After commit 251f26c9e828 ("mtd: maps: Make uclinux_ram_map static"),
it became impossible to configure it at all, even with out-of-tree
platform code.
Clearly nobody is using it, so remove it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
There were four MTD maps drivers that were used with AMD Élan SoCs.
Since 486-class CPU support was removed in commit 8b793a92d862 ("x86/cpu:
Remove M486/M486SX/ELAN support"), it is no longer possible to actually
use these. Three of them have already been removed, so remove the
remaining driver entirely.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[Miquel Raynal: Only NETtel was still in the tree, adapt the patch and the commit log]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
When FF-A initialisation is driven from a platform device probe, systems
that do not implement FF-A can return -EOPNOTSUPP from the early transport
or version discovery paths. Driver core treats that as a matched probe
failure and prints:
| arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
That is noisy for a firmware interface that can be absent on otherwise
valid systems. Driver core already treats -ENODEV and -ENXIO as quiet
rejected matches, so translate only the early unsupported discovery cases
to -ENODEV. Keep later setup failures unchanged so real FF-A
initialisation problems are still reported as probe failures.
Reported-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://lore.kernel.org/all/20260523001148.GA1319283@ax162
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20260526103649.5684-1-sudeep.holla@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Replace all printk(KERN_WARNING ...) calls with pr_warn() to follow
the kernel's recommended logging style and resolve checkpatch warnings.
Also convert one bare printk() that was missing a log level.
No functional change.
Signed-off-by: Li Xinyu <xinyuili@126.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Initializing a pci_device_id using plain list expressions is hard to
understand for a human who isn't into the Linux PCI subsystem. So for
each initializer use one of the PCI_DEVICE macros for .vendor, .device,
.subvendor and .subdevice and named initializers for the remaining
assignments. This makes it easier to parse and also more robust against
chagnes to the struct definition.
Also drop useless zeros and commas.
The mentioned robustness is relevant for a planned change to struct
pci_device_id that replaces .driver_data by an anonymous union.
This change doesn't introduce changes to the compiled pci_device_id
array. Tested on x86 and arm64.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
During probe(), the devm_ioremap() is called with the parent device
instead of the current one. So when the module is unloaded, the register
area isn't released.
Target the pl35x device in the devm_ioremap() instead of its parent.
Cc: stable@vger.kernel.org
Fixes: 08d8c62164a3 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller")
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The qcom_nand_controller had a struct nand_controller *controller
pointer that was assigned to (struct nand_controller *)&nandc[1],
with the allocation oversized by sizeof(*controller) to make room.
get_qcom_nand_controller() then walked backwards from chip->controller
using sizeof()-based arithmetic to recover the enclosing nandc.
Embed the nand_controller directly into qcom_nand_controller and use
container_of() in get_qcom_nand_controller(). The header now needs
the full rawnand.h definition rather than a forward declaration.
Assisted-by: Claude:Opus-4.7
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Some chips do not support sequential cached reads past block
boundaries, like Winbond. In practice when using UBI, this should very
rarely happen, but let's make sure it never happens.
Cc: stable@vger.kernel.org
Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The mtd_info contains a struct device, which must be linked to its
parent. Without this, the initialization of the MTD fails with a NULL
pointer dereference.
Fixes: 47a72688fae7 ("mtd: flash mapping support for Dreamcast VMU.")
Cc: stable@vger.kernel.org
Signed-off-by: Florian Fuchs <fuchsfl@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|