Using drm_device->dev_private is deprecated. Since we've switched to
devm_drm_dev_alloc(), struct drm_device is now embedded in struct
hdlcd_drm_private, hence we can use container_of() to get the struct
drm_device instance instead.
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221026153431.72033-3-dakr@redhat.com
Use drm managed resources to allocate driver structures and get rid of
the deprecated drm_dev_alloc() call and replace it with
devm_drm_dev_alloc().
This also serves as preparation to get rid of drm_device->dev_private
and to fix use-after-free issues on driver unload.
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221026153431.72033-2-dakr@redhat.com
Add support for HiSilicon GPIO controller in embedded platform, which
boot from devicetree.
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Acked-by: Jay Fang <f.fangjian@huawei.com>
Reviewed-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add the new compatible for HiSilicon gpio controller driver.
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add a comment to clarify how to handle best-effort backwards
compatibility for LANDLOCK_ACCESS_FS_REFER.
The "refer" access is special because these operations are always
forbidden in ABI 1, unlike most other operations, which are permitted
when using Landlock ABI levels where they are not supported yet.
Signed-off-by: Günther Noack <gnoack3000@gmail.com>
Link: https://lore.kernel.org/r/20221107181651.4555-1-gnoack3000@gmail.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
strtobool() is the same as kstrtobool().
However, the latter is more used within the kernel.
In order to remove strtobool() and slightly simplify kstrtox.h, switch to
the other function name.
While at it, include the corresponding header file (<linux/kstrtox.h>)
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/4311e9cb62687449f4175e2b062abcd77aada059.1667336095.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This patch adds support for Himax hx83112b touchscreen devices. As there
are no publicly available data sheets for these devices, the
implementation is based on the driver of the downstream Android kernel
used in the Fairphone 3. This patch is a complete rewrite, though, and
the code bears no resemblence to the original implementation.
The driver has been tested on the aforementioned phone.
Signed-off-by: Job Noorman <job@noorman.info>
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20221107105604.26541-3-job@noorman.info
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
On MTL there are no BCS engines on the media GT, so we can't always use
BCS0 in the test. There is no actual reason to use a BCS engine over an
engine of a different class, so switch to using any available engine.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102214310.2829310-1-daniele.ceraolospurio@intel.com
Pinebook has an RTL8723CS WiFi + BT chip. BT is connected to UART1
and uses PL5 as device wake GPIO and PL6 as host wake GPIO.
Enable it in the device tree.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Bastian Germann <bage@debian.org>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20221105153319.19345-2-bage@debian.org
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The X96 Mate TV box has two USB-A ports, VBUS is always on and connected
to the DC input.
Since USB port 0 is connected to an USB-A receptable, we configure it
as a host port. Using it as a peripheral is dangerous, because VBUS is
always on.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20221031111358.3387297-8-andre.przywara@arm.com
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The OrangePi Zero 2 has one USB-A host port, VBUS is provided by
a GPIO controlled regulator.
The USB-C port is meant to power the board, but is also connected to
the USB 0 port, which we configure as an MUSB peripheral.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20221031111358.3387297-7-andre.przywara@arm.com
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Add the nodes for the MUSB and the four USB host controllers to the SoC
.dtsi, along with the PHY node needed to bind all of them together.
EHCI/OHCI and MUSB are compatible to previous SoCs, but the PHY requires
some quirks (handled in the driver).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20221031111358.3387297-6-andre.przywara@arm.com
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The Allwinner H616 contains four fully OHCI/EHCI compatible USB host
controllers, so just add their compatible strings to the list of
generic OHCI/EHCI controllers.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221031111358.3387297-2-andre.przywara@arm.com
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
There is no userspace user for this CS yet, we only need it for internal
kernel ops (e.g. HuC, PXP), so don't expose it.
v2: even if it's not exposed, rename the engine so it is easier to
identify in the debug logs (Matt)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102171047.2787951-6-daniele.ceraolospurio@intel.com
The GSC CS re-uses the same interrupt bits that the GSC used in older
platforms. This means that we can now have an engine interrupt coming
out of OTHER_CLASS, so we need to handle that appropriately.
v2: clean up the if statement for the engine irq (Tvrtko)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102171047.2787951-4-daniele.ceraolospurio@intel.com
Starting on MTL, the GSC is no longer managed with direct MMIO access,
but we instead have a dedicated command streamer for it. As a first step
for adding support for this CS, add the required definitions.
Note that, although it is now a CS, the GSC retains its old
class:instance value (OTHER_CLASS instance 6)
Bspec: 65308, 45605
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102171047.2787951-2-daniele.ceraolospurio@intel.com
Fix an issue reported when performing a live migration when multipath is
configured with a short fast fail timeout of 5 seconds and also to have
no_path_retry set to fail. In this scenario, all paths would go into the
devloss state while the ibmvfc driver went through discovery to log back
in. On a loaded system, the discovery might take longer than 5 seconds,
which was resulting in all paths being marked failed, which then resulted
in a read only filesystem.
This patch changes the migration code in ibmvfc to avoid deleting rports at
all in this scenario, so we avoid losing all paths.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Link: https://lore.kernel.org/r/20221026181356.148517-1-brking@linux.vnet.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Like on the Acer Switch 10 SW5-012, the Acer Switch V 10 SW5-017's _LID
method messes with home- and power-button GPIO IRQ settings, causing an
IRQ storm.
Add a quirk entry for the Acer Switch V 10 to the dmi_use_low_level_irq[]
DMI quirk list, to use low-level IRQs on this model, fixing the IRQ storm.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20221106215320.67109-2-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
It seems that the Windows drivers for the ACPI0011 soc_button_array
device use low level triggered IRQs rather then using edge triggering.
Some ACPI tables depend on this, directly poking the GPIO controller's
registers to clear the trigger type when closing a laptop's/2-in-1's lid
and re-instating the trigger when opening the lid again.
Linux sets the edge/level on which to trigger to both low+high since
it is using edge type IRQs, the ACPI tables then ends up also setting
the bit for level IRQs and since both low and high level have been
selected by Linux we get an IRQ storm leading to soft lockups.
As a workaround for this the soc_button_array already contains
a DMI quirk table with device models known to have this issue.
Add a module parameter for this so that users can easily test if their
device is affected too and so that they can use the module parameter
as a workaround.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20221106215320.67109-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
syzbot is reporting uninitialized value at iforce_init_device() [1], for
commit 6ac0aec6b0 ("Input: iforce - allow callers supply data buffer
when fetching device IDs") is checking that valid length is shorter than
bytes to read. Since iforce_get_id_packet() stores valid length when
returning 0, the caller needs to check that valid length is longer than or
equals to bytes to read.
Reported-by: syzbot <syzbot+4dd880c1184280378821@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes: 6ac0aec6b0 ("Input: iforce - allow callers supply data buffer when fetching device IDs")
Link: https://lore.kernel.org/r/531fb432-7396-ad37-ecba-3e42e7f56d5c@I-love.SAKURA.ne.jp
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Highlights:
- ACPI: video: Fix regressions from 6.1 backlight refactor by making
acpi_video_backlight_use_native() always return true for now
- Misc. other bugfixes and HW id additions
The following is an automated git shortlog grouped by driver:
ACPI:
- video: Add backlight=native DMI quirk for Dell G15 5515
- video: Make acpi_video_backlight_use_native() always return true
- video: Improve Chromebook checks
hp_wmi:
- Fix rfkill causing soft blocked wifi
ideapad-laptop:
- Disable touchpad_switch
p2sb:
- Don't fail if unknown CPU is found
platform/x86/intel/hid:
- Add some ACPI device IDs
platform/x86/intel/pmt:
- Sapphire Rapids PMT errata fix
touchscreen_dmi:
- Add info for the RCA Cambio W101 v2 2-in-1
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEEuvA7XScYQRpenhd+kuxHeUQDJ9wFAmNo7hsUHGhkZWdvZWRl
QHJlZGhhdC5jb20ACgkQkuxHeUQDJ9y08wf/Q+GL05jx3uVprDmoQljc3DJnHCut
haa/ZHsqq6OY2RYeY4mX1iYOzlRD20nDEQ52/2IOXvx2FOEorDewByGHD7gOJ6Xr
IvI0JTmfPZ4yflW/N+z2ujXYpp/XlELzHEXFBA6t+62NOT0y4fu2mJx95twDgsa0
ohgTVtmSqIwhjJVt+pQ2UVdy2M+Yv07XabZswLTPt6JZJRhvu8UzPu+DkQd0qqKi
tvmFMkYVSkJnEKBT07Ii+QiUxXDKDzfwRPBFxSEm7m3GvkkPJp0ZqmrB9m8mK6oJ
f83FZ8X9vcTGaG5Gjm3X5xejs4B2qeBs9AzhsrAW/maKOADsbjJdJPz7JQ==
=aes0
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Hans de Goede:
"The most important fixes here are a set of fixes for the ACPI
backlight detection refactor which landed in 6.1.
These fix regressions reported on some laptop models by making
acpi_video_backlight_use_native() always return true for now, which in
essence undoes some of the changes.
I plan to take another shot at having only 1 /sys/class/backlight
class device per panel with 6.2, with modified detection heuristics to
avoid the (known) regressions.
Highlights:
- ACPI: video: Fix regressions from 6.1 backlight refactor by making
acpi_video_backlight_use_native() always return true for now
- Misc other bugfixes and HW id additions"
* tag 'platform-drivers-x86-v6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: p2sb: Don't fail if unknown CPU is found
platform/x86/intel/hid: Add some ACPI device IDs
platform/x86/intel/pmt: Sapphire Rapids PMT errata fix
platform/x86: hp_wmi: Fix rfkill causing soft blocked wifi
platform/x86: touchscreen_dmi: Add info for the RCA Cambio W101 v2 2-in-1
platform/x86: ideapad-laptop: Disable touchpad_switch
ACPI: video: Add backlight=native DMI quirk for Dell G15 5515
ACPI: video: Make acpi_video_backlight_use_native() always return true
ACPI: video: Improve Chromebook checks
If the starting position of our insert range happens to be in the hole
between the two ext4_extent_idx, because the lblk of the ext4_extent in
the previous ext4_extent_idx is always less than the start, which leads
to the "extent" variable access across the boundary, the following UAF is
triggered:
==================================================================
BUG: KASAN: use-after-free in ext4_ext_shift_extents+0x257/0x790
Read of size 4 at addr ffff88819807a008 by task fallocate/8010
CPU: 3 PID: 8010 Comm: fallocate Tainted: G E 5.10.0+ #492
Call Trace:
dump_stack+0x7d/0xa3
print_address_description.constprop.0+0x1e/0x220
kasan_report.cold+0x67/0x7f
ext4_ext_shift_extents+0x257/0x790
ext4_insert_range+0x5b6/0x700
ext4_fallocate+0x39e/0x3d0
vfs_fallocate+0x26f/0x470
ksys_fallocate+0x3a/0x70
__x64_sys_fallocate+0x4f/0x60
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
==================================================================
For right shifts, we can divide them into the following situations：
1. When the first ee_block of ext4_extent_idx is greater than or equal to
start, make right shifts directly from the first ee_block.
1) If it is greater than start, we need to continue searching in the
previous ext4_extent_idx.
2) If it is equal to start, we can exit the loop (iterator=NULL).
2. When the first ee_block of ext4_extent_idx is less than start, then
traverse from the last extent to find the first extent whose ee_block
is less than start.
1) If extent is still the last extent after traversal, it means that
the last ee_block of ext4_extent_idx is less than start, that is,
start is located in the hole between idx and (idx+1), so we can
exit the loop directly (break) without right shifts.
2) Otherwise, make right shifts at the corresponding position of the
found extent, and then exit the loop (iterator=NULL).
Fixes: 331573febb ("ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Link: https://lore.kernel.org/r/20220922120434.1294789-1-libaokun1@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Add compatible and constants for the power domains exposed by the RPMH
in the Qualcomm QDU1000 and QRU1000 platforms.
Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221026190549.4005703-3-quic_molvera@quicinc.com
The DeviceTree Specification v0.3 specifies that the cache node
'compatible' and 'cache-level' properties are 'required'. Cf.
s3.8 Multi-level and Shared Cache Nodes
The 'cache-unified' property should be present if one of the
properties for unified cache is present ('cache-size', ...).
Update the Device Trees accordingly.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20221107155825.1644604-4-pierre.gondois@arm.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Set the d0i3 with d0i3_offset for different platforms
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20221107164154.21925-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
MTL has different d0i3 offset compared to cavs platforms.
Use d0i3_offset to unify the setting.
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20221107164154.21925-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
MTL has a different offset of d0i3 compared to cavs platforms.
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20221107164154.21925-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The sc7280-herobrine-villager derivative doesn't have NVME enabled so
we shouldn't mark the PCIe nodes as "okay" since they're just for
boards that have NVME.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221025164915.1.I38e2545eda2b3bd3fef6b41c98f451e32851ae70@changeid
It turns out that only a few people have the fingerprint sensor hooked
up on their board. Leaving this enabled is slowing down boot for
everyone else because the driver slowly fails to probe while trying to
communicate with a sensor that isn't there. Remove the node to speed up
boot, developers with the board can manually enable it themselves.
Reported-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221025180703.1806234-1-swboyd@chromium.org
DT schema expects TLMM pin configuration nodes to be named with
'-state' suffix and their optional children with '-pins' suffix.
Order the "function" and "pins" property to match other DTS.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221018155450.39816-2-krzysztof.kozlowski@linaro.org
The GPIO55 is part of SPI10 pins, not its chip-select. Probably the
intention was to use one of dedicated chip-select GPIOs: 47 or 67.
GPIO47 is used for UART2, so choose GPIO67.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221018155450.39816-1-krzysztof.kozlowski@linaro.org
WLAN firmware uses SMP2P protocol in order to talk to the application
processor (AP) in certain cases like WoW (Wake on Wireless). WLAN
firmware runs on the WPSS Q6 processor (Wireless Processor SubSystem).
Therefore it is required to have sub nodes pertaining to the WPSS Q6
processor and the application processor in the SMP2P node.
Add WPSS Q6 (Wireless Processor SubSystem) node names to the pattern
property required for WPSS Q6 processor to communicate to the
application processor and vice versa over SMP2P protocol.
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221017125346.3691-2-quic_mpubbise@quicinc.com
The pl18x MMCI driver does not use the interrupt-names property,
the binding document has been updated to recommend this property
be unused, remove it.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221013221242.218808-2-marex@denx.de
On MDM9615 the PMICs are connected using SSBI devices, which do not have
any addressing scheme. Drop the unused unit ids from PMIC device nodes.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220930212052.894834-2-dmitry.baryshkov@linaro.org
The switch to using the gpiod API removed the last user of
lpc32xx_wp_disable() outside #ifdef CONFIG_PM, causing build failures if
CONFIG_PM=n:
drivers/mtd/nand/raw/lpc32xx_slc.c:318:13: error: ‘lpc32xx_wp_disable’ defined but not used [-Werror=unused-function]
318 | static void lpc32xx_wp_disable(struct lpc32xx_nand_host *host)
| ^~~~~~~~~~~~~~~~~~
Fix this by switching from #ifdef CONFIG_PM to pm_ptr(), increasing
compile-coverage as a side-effect.
Reported-by: noreply@ellerman.id.au
Fixes: 6b923db286 ("mtd: rawnand: lpc32xx_slc: switch to using gpiod API")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20221027131028.3838303-2-geert@linux-m68k.org
The switch to using the gpiod API removed the last user of
lpc32xx_wp_disable() outside #ifdef CONFIG_PM, causing build failures if
CONFIG_PM=n:
drivers/mtd/nand/raw/lpc32xx_mlc.c:380:13: error: ‘lpc32xx_wp_disable’ defined but not used [-Werror=unused-function]
380 | static void lpc32xx_wp_disable(struct lpc32xx_nand_host *host)
| ^~~~~~~~~~~~~~~~~~
Fix this by switching from #ifdef CONFIG_PM to pm_ptr(), increasing
compile-coverage as a side-effect.
Reported-by: noreply@ellerman.id.au
Fixes: 782e32a990 ("mtd: rawnand: lpc32xx_mlc: switch to using gpiod API")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20221027131028.3838303-1-geert@linux-m68k.org
The current ACPI PMU probing logic tries to associate PMUs with CPUs
when the CPU is first brought online, in order to handle late hotplug,
though PMUs are only registered during early boot, and so for late
hotplugged CPUs this can only associate the CPU with an existing PMU.
We tried to be clever and the have the arm_pmu_acpi_cpu_starting()
callback allocate a struct arm_pmu when no matching instance is found,
in order to avoid duplication of logic. However, as above this doesn't
do anything useful for late hotplugged CPUs, and this requires us to
allocate memory in an atomic context, which is especially problematic
for PREEMPT_RT, as reported by Valentin and Pierre.
This patch reworks the probing to detect PMUs for all online CPUs in the
arm_pmu_acpi_probe() function, which is more aligned with how DT probing
works. The arm_pmu_acpi_cpu_starting() callback only tries to associate
CPUs with an existing arm_pmu instance, avoiding the problem of
allocating in atomic context.
Note that as we didn't previously register PMUs for late-hotplugged
CPUs, this change doesn't result in a loss of existing functionality,
though we will now warn when we cannot associate a CPU with a PMU.
This change allows us to pull the hotplug callback registration into the
arm_pmu_acpi_probe() function, as we no longer need the callbacks to be
invoked shortly after probing the boot CPUs, and can register it without
invoking the calls.
For the moment the arm_pmu_acpi_init() initcall remains to register the
SPE PMU, though in future this should probably be moved elsewhere (e.g.
the arm64 ACPI init code), since this doesn't need to be tied to the
regular CPU PMU code.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Valentin Schneider <valentin.schneider@arm.com>
Link: https://lore.kernel.org/r/20210810134127.1394269-2-valentin.schneider@arm.com/
Reported-by: Pierre Gondois <pierre.gondois@arm.com>
Link: https://lore.kernel.org/linux-arm-kernel/20220912155105.1443303-1-pierre.gondois@arm.com/
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-and-tested-by: Pierre Gondois <pierre.gondois@arm.com>
Link: https://lore.kernel.org/r/20220930111844.1522365-4-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
A subsequent patch will rework the ACPI probing of PMUs, and we'll need
to match a CPU with a known cpuid in two separate paths.
Factor out the matching logic into a helper function so that it can be
reused.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-and-tested-by: Pierre Gondois <pierre.gondois@arm.com>
Link: https://lore.kernel.org/r/20220930111844.1522365-3-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
