| Age | Commit message (Collapse) | Author |
|---|
|
Convert the driver to using the new generic GPIO chip interfaces from
linux/gpio/generic.h.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-12-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
Convert the driver to using the new generic GPIO chip interfaces from
linux/gpio/generic.h.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-11-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
Convert the driver to using the new generic GPIO chip interfaces from
linux/gpio/generic.h.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-10-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
Convert the driver to using the new generic GPIO chip interfaces from
linux/gpio/generic.h.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-9-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
Convert the driver to using the new generic GPIO chip interfaces from
linux/gpio/generic.h.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-8-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
Convert the driver to using the new generic GPIO chip interfaces from
linux/gpio/generic.h.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-7-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
Use dev_err_probe() where applicable.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-6-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
Avoid pulling in linux/of.h by using the generic device properties.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-5-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
There's no corresponding call to platform_get_drvdata() or
dev_get_drvdata(). Remove the call to platform_set_drvdata() from
.probe().
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-4-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
There's no reason for this driver to touch the gpio-mmio internals, we
have a dedicated flag passed to bgpio_init() indicating to the module
that the DIR register is unreadable.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-3-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
GPD devices originally used BMI160 sensors with the "BMI0160" PNP ID.
When they switched to BMI260 sensors in newer hardware, they reused
the existing Windows driver which accepts both "BMI0160" and "BMI0260"
IDs. Consequently, they kept "BMI0160" in DSDT tables for new BMI260
devices, causing driver mismatches in Linux.
1. GPD updated BIOS v0.40+[1] for newer devices to report "BMI0260" for
BMI260 sensors to avoid loading the bmi160 driver on Linux. While this
isn't Bosch's VID;
2. Bosch's official Windows driver uses "BMI0260" as a compatible ID
3. We're seeing real devices shipping with "BMI0260" in DSDT
The DSDT excerpt of GPD G1619-04 with BIOS v0.40:
Scope (_SB.I2CC)
{
Device (BMA2)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "BMI0260") // _HID: Hardware ID
Name (_CID, "BMI0260") // _CID: Compatible ID
Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0069, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2CC",
0x00, ResourceConsumer, , Exclusive,
)
})
Return (RBUF) /* \_SB_.I2CC.BMA2._CRS.RBUF */
}
# omit some noise
}
}
Link: http://download.softwincn.com/WIN%20Max%202024/Max2-7840-BIOS-V0.41.zip #1
Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Acked-by: Alex Lanzano <lanzano.alex@gmail.com>
Link: https://patch.msgid.link/20250821-bmi270-gpd-acpi-v4-1-5279b471d749@uniontech.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
There are two problems with the chip configuration in this driver:
- First, is that writing 12 bytes (ARRAY_SIZE(regs)) would anyhow
lead to a config overflow due to HW auto increment implementation
in the chip.
- Second, the i2c_smbus_write_block_data write ends up in writing
unexpected value to the channel_dis register, this is because
the smbus size that is 0x03 in this case gets written to the
register. The PAC1931/2/3/4 data sheet does not really specify
that block write is indeed supported.
This problem is probably not visible on PAC1934 version where all
channels are used as the chip is properly configured by luck,
but in our case whenusing PAC1931 this leads to nonfunctional device.
Fixes: 0fb528c8255b (iio: adc: adding support for PAC193x)
Suggested-by: Rene Straub <mailto:rene.straub@belden.com>
Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@belden.com>
Reviewed-by: Marius Cristea <marius.cristea@microchip.com>
Link: https://patch.msgid.link/20250811130904.2481790-1-aleksandar.gerasimovski@belden.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl into gpio/for-next
Convert GPIO drivers under drivers/pinctrl/ to using the new generic GPIO
chip API.
|
|
Replace calls of devm_kzalloc() with devm_kcalloc() in scmi_alloc_iiodev()
and scmi_iio_set_sampling_freq_avail() for safer memory allocation with
built-in overflow protection.
Similarly, use array_size() instead of explicit multiplication for
'sensor->sensor_info->intervals.count * 2'.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250819125017.635182-1-rongqianfeng@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
dt-bindings documentation for this driver claims to support
thermocouple-type, but the driver does not actually make use of
the property.
Implement usage of the property to configure the chip for the
selected thermocouple-type.
Signed-off-by: Ben Collins <bcollins@watter.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250822-upstream-changes-v8-5-40bb1739e3e2@watter.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The current driver works with mcp9601, but emits a warning because it
does not recognize the chip id.
MCP9601 is a superset of MCP9600. The drivers works without changes
on this chipset.
However, the 9601 chip supports open/closed-circuit detection if wired
properly, so we'll need to be able to differentiate between them.
Moved "struct mcp9600_data" up in the file since a later patch will
need it and chip_info before the declarations.
Signed-off-by: Ben Collins <bcollins@watter.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250822-upstream-changes-v8-4-40bb1739e3e2@watter.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Make tabs consistent for register definitions and also fix width
to byte size.
Signed-off-by: Ben Collins <bcollins@watter.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Andy Shevchenko <abdy@kernel.org>
Reviewed-by: David Lechner <dlechner@baylibrc.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20250822-upstream-changes-v8-3-40bb1739e3e2@watter.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Introduce virt/ directory to collect virtchnl files.
We are going to implement a few sizable extensions soon, each of them
increasing virt/ size, so it looks sensible to introduce a new dir.
Suggested-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Acked-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-8-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-7-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-6-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-5-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Gustavo Silva <gustavograzs@gmail.com> # for ens160
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-4-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # meson_saradc
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-3-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-2-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Remove the call to `dev_set_drvdata()` and the associated comment
since private data is never read.
Signed-off-by: Salah Triki <salah.triki@gmail.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/aKSRpTuwA0P-ZaUS@pc
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Commit 65e8202f0322 ("iio: Remove error prints for
devm_add_action_or_reset()") accidentally introduced a bug where we
returned "ret" but the error code was stored in "error" if
devm_add_action_or_reset() failed. Using two variables to store error
codes is unnecessary and confusing. Delete the "error" variable and use
"ret" everywhere instead.
Fixes: 65e8202f0322 ("iio: Remove error prints for devm_add_action_or_reset()")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/aKSSHTdJf5QoYiRx@stanley.mountain
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Avoid triggering a dereference of an error pointer on cleanup in
xe_vm_free_scratch() by clearing any scratch_pt error pointer.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Fixes: 06951c2ee72d ("drm/xe: Use NULL PTEs as scratch PTEs")
Cc: Brian Welty <brian.welty@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250821143045.106005-4-thomas.hellstrom@linux.intel.com
|
|
This member is set when exporting using prime. However
the xe_gem_prime_export() alone doesn't set it, since it's done
later in the prime export flow.
For the test, set it manually and remove the hack that set it
temporarily when it was really needed.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250821143045.106005-3-thomas.hellstrom@linux.intel.com
|
|
The pinning has the odd side-effect that unlocking *any* resv
during validation triggers an "unlocking pinned lock" warning.
Cc: Matthew Brost <matthew.brost@intel.com>
Fixes: 9d5558649f68 ("drm/xe: Rework eviction rejection of bound external bos")
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250821143045.106005-2-thomas.hellstrom@linux.intel.com
|
|
We need the char/misc/iio fixes in here as well to build on.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
We need the driver core and rust fixes in here as well to build on top
of.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
We need the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Currently we are ignoriong drm_dp_dpcd_read return values when reading PSR
and Panel Replay capability DPCD register. Rework intel_psr_dpcd a bit to
take care of checking the return value.
v2: use drm_dp_dpcd_read_data
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250821045918.17757-1-jouni.hogander@intel.com
|
|
Marking ufence as signalled after copy_to_user() is too late.
Worker thread which signals ufence by memory write might be raced
with another userspace vm-bind call. In map/unmap scenario unmap
may still see ufence is not signalled causing -EBUSY. Change the
order of marking / write to user-fence fixes this issue.
Fixes: 977e5b82e090 ("drm/xe: Expose user fence from xe_sync_entry")
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5536
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250820083903.2109891-2-zbigniew.kempczynski@intel.com
|
|
We need override certain link rates in favour of the next available
higher link rate. The Link rates that need to be overridden are
indicated by a mask in VBT. To make sure these modes are skipped we
don't add them in them in the sink rates array.
--v2
-Update the link rates after we have a final set of link rates [Ankit]
-Break this patch up [Ankit]
-Optimize the assingment during loop [Ankit]
--v3
-Add protection against broken VBTs [Jani]
--v4
-Fix build errors
-Create a seprate function to check if edp data override is selected
and using the correct vbt
--v5
-Use correct number to check the num of edp rates [Ankit]
--v6
-No seprate function check if vbt is broken in the reject rate function
[Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250821042653.269227-4-suraj.kandpal@intel.com
|
|
Add a function that helps identify if the rate provided needs to
be overridden. For this we need a function that compares the rate
provided and bitmask of rates provided in VBT.
--v2
-Rename functions [Jani]
-Return the mask instead of parsing it in function [Jani]
-Move the declaration in header [Jani]
--v3
-Change function name to depict what the function does [Ankit]
--v4
-Lets not use hweight [Ankit]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250821042653.269227-3-suraj.kandpal@intel.com
|
|
Add edp_data_rate_override field VBT which gives us a mask
of rates which needs to be skipped in favour of
subsequent higher rate.
--v2
-Rename vbt field [Jani]
-Fix comment to 263+ [Jani]
-Use BIT_U32 [Jani]
-Fix the bits assignment in vbt [Jani]
--v3
-Add a mask which represents all link rates [Ankit]
Bspec: 20124
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250821042653.269227-2-suraj.kandpal@intel.com
|
|
In the current design, the `pm8008_regulator_get_voltage_sel()` callback
can return a negative value if the raw voltage value is read as 0 uV from
the PMIC HW register. This can cause the probe to fail when the
`machine_constraints_voltage()` check is called during the regulator
registration flow.
Fix this by using the helper `regulator_map_voltage_linear_range()` to
convert the raw value to a voltage selector inside the mentioned get
voltage selector function. This ensures that the value returned is always
within the defined range.
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Message-ID: <20250823-pm8008-negitive-selector-v1-1-52b026a4b5e8@quicinc.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
- hisi: update maintainership
- fix several issues in rtl9300 xfer:
- check message length boundaries
- correct multi-byte value composition on write
- increase polling timeout
- fix block transfer protocol
* tag 'i2c-for-6.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: rtl9300: Add missing count byte for SMBus Block Ops
i2c: rtl9300: Increase timeout for transfer polling
i2c: rtl9300: Fix multi-byte I2C write
i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xfer
MAINTAINERS: i2c: Update i2c_hisi entry
|
|
In gicv5_irs_of_init_affinity() a WARN_ON() is triggered if:
1) a phandle in the "cpus" property does not correspond to a valid OF
node
2 a CPU logical id does not exist for a given OF cpu_node
#1 is a firmware bug and should be reported as such but does not warrant a
WARN_ON() backtrace.
#2 is not necessarily an error condition (eg a kernel can be booted with
nr_cpus=X limiting the number of cores artificially) and therefore there
is no reason to clutter the kernel log with WARN_ON() output when the
condition is hit.
Rework the IRS affinity parsing code to remove undue WARN_ON()s thus
making it less noisy.
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20250814094138.1611017-1-lpieralisi@kernel.org
|
|
The eiointc interrupt controller supports 256 interrupt vectors at most,
and the interrupt handler gets the interrupt status from the base register
group EIOINTC_REG_ISR at the interrupt specific offset.
It needs to read the register group EIOINTC_REG_ISR four times to get all
256 interrupt vectors status.
Eiointc registers including EIOINTC_REG_ISR are software emulated for
VMs, so there will be VM-exits when accessing eiointc registers.
Introduce a method to make the eiointc interrupt controller route
to different CPU interrupt pins for every 64 interrupt vectors.
The interrupt handler can then reduce the read to one specific
EIOINTC_REG_ISR register instead of all four, which reduces VM exits.
[ tglx: Massage change log ]
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20250804081946.1456573-3-maobibo@loongson.cn
|
|
Interrupt controller eiointc routes interrupts to CPU interface IP0 - IP7.
It is currently hard-coded that eiointc routes interrupts to the CPU
starting from IP1, but it should base that decision on the parent
interrupt, which is provided by ACPI or DTS.
Retrieve the parent's hardware interrupt number and store it in the
descriptor of the eointc instance, so that the routing function can utilize
it for the correct route settings.
[ tglx: Massaged change log ]
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20250804081946.1456573-2-maobibo@loongson.cn
|
|
plic_set_affinity() always calls plic_irq_enable(), which clears up the
priority setting even the interrupt is only masked. This unmasks the
interrupt unexpectly.
Replace the plic_irq_enable/disable() with plic_irq_toggle() to avoid
changing the priority setting.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Nam Cao <namcao@linutronix.de> # VisionFive 2
Tested-by: Chen Wang <unicorn_wang@outlook.com> # Pioneerbox
Reviewed-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
Link: https://lore.kernel.org/all/20250811002633.55275-1-inochiama@gmail.com
Link: https://lore.kernel.org/lkml/20250722224513.22125-1-inochiama@gmail.com/
|
|
L2 IST table entries are allocated with the kmalloc interface and their
physical addresses are programmed in the GIC (either IST base address
register or L1 IST table entries) but their virtual addresses are not
stored in any kernel data structure because they are not needed at runtime
- the L2 IST table entries are managed through system instructions but
never dereferenced directly by the driver.
This triggers kmemleak false positive reports:
unreferenced object 0xffff00080039a000 (size 4096):
comm "swapper/0", pid 0, jiffies 4294892296
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 0):
kmemleak_alloc+0x34/0x40
__kmalloc_noprof+0x320/0x464
gicv5_irs_iste_alloc+0x1a4/0x484
gicv5_irq_lpi_domain_alloc+0xe4/0x194
irq_domain_alloc_irqs_parent+0x78/0xd8
gicv5_irq_ipi_domain_alloc+0x180/0x238
irq_domain_alloc_irqs_locked+0x238/0x7d4
__irq_domain_alloc_irqs+0x88/0x114
gicv5_of_init+0x284/0x37c
of_irq_init+0x3b8/0xb18
irqchip_init+0x18/0x40
init_IRQ+0x104/0x164
start_kernel+0x1a4/0x3d4
__primary_switched+0x8c/0x94
Instruct kmemleak to ignore L2 IST table memory allocation virtual
addresses to prevent these false positive reports.
Reported-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/all/20250811135001.1333684-1-lpieralisi@kernel.org
Closes: https://lore.kernel.org/lkml/cc611dda-d1e4-4793-9bb2-0eaa47277584@huawei.com/
|
|
Replace the open coded for_each_cpu(cpu, cpu_present_mask) loop with the
more readable and equivalent for_each_present_cpu(cpu) macro.
Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20250811064701.2906-1-wangfushuai@baidu.com
|
|
ioremap() never returns error pointers, it returns NULL on error. Fix the
check to match.
Fixes: 3c3d7dbab2c7 ("irqchip/mvebu-gicp: Clear pending interrupts on init")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/aKRGcgMeaXm2TMIC@stanley.mountain
|
|
There is no need to register a manual `devm` action for
`pm_runtime_disable()` when `devm_pm_runtime_enable()` exists. It does
the same thing (but also calls `pm_runtime_dont_use_autosuspend()`,
which should be fine here).
Moreover, when `devm_add_action_or_reset()` fails, it is due to a failed
memory allocation and will thus return `-ENOMEM`. `dev_err_probe()`
doesn't do anything when error is `-ENOMEM`. Therefore, the call to
`dev_err_probe()` is useless. Note that `devm_pm_runtime_enable()` has a
tail call to `devm_add_action_or_reset()` and thus returns that value.
Therefore, replace `dev_err_probe()` with the returning value.
Signed-off-by: Waqar Hameed <waqar.hameed@axis.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/pnda54bjmij.a.out@axis.com
Signed-off-by: William Breathitt Gray <wbg@kernel.org>
|
|
Hardware Requirement:
BIT[3] of this register must be set if need to select i2s_bclk as
SSPA parent clock, to solve this, introduces a new SSPAx_I2S_BCLK
clock as the virtual gate clock.
Fixes: 1b72c59db0add ("clk: spacemit: Add clock support for SpacemiT K1 SoC")
Suggested-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Haylen Chu <heylenay@4d2.org>
Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Link: https://lore.kernel.org/r/20250811-k1-clk-i2s-v5-2-ebadd06e1e91@linux.spacemit.com
Signed-off-by: Yixun Lan <dlan@gentoo.org>
|
|
Add support for the Qualcomm SM8750 SoC to the protection
domain mapper. SM8750 shares the same protection domain
configuration as SM8550, so reuse the existing SM8550 domain data.
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250821160618.1037157-2-quic_pkumpatl@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
