Remove a pointless layer of indentation after a return statement.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The bi_max_vecs and bi_vcnt fields are defined as unsigned short, so
don't allow passing larger values in.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
All bios with up to 4 bvecs use the inline bvecs in the bio itself, so
don't bother to define bvec_slabs entries for them. Also decruftify
the bvec_slabs definition and initialization while we're at it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Avoid the pointless goto by trying the slab allocation first and falling
through to the mempool.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Clean up bvec_alloc a little by factoring out a helper for the gfp_t
manipulations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
struct biovec_slab is only used inside of bio.c, so move it there.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
bvec_alloc always uses biovec_slabs, and thus always needs to use the
same number of inline vecs. Share a single definition for the data
and integrity bvecs.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
For SQPOLL rings tctx_inflight() always returns zero, so it might skip
doing full cancelation. It's fine because we jam all sqpoll submissions
in any case and do go through files cancel for them, but not nice.
Do the intended full cancellation, by mimicking __io_uring_task_cancel()
waiting but impersonating SQPOLL task.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
- only at91_dt_defconfig and sama5_defconfig modified
- update to match current options, unneeded options removed
- missing drivers added, some are on-SoC peripherals, some are helpers
- modify legacy ATAGS or DT options to match common usage
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEEAbEK3+sX+gUxe5RcpMrf1MU8doFAmAhJisACgkQcpMrf1MU
8dp4cw//f0ANwK27iYa3HSyDeJGE4GGzNkXUlOvB2Qe2OJruxSdsDbWTB8xmm32g
P6gK/KLb2q3mruYVUCTvPuZjl/V6TMO4ygbuAxmLCUKbyBXb95mFH/c6mVYt6jXF
rheqc7sEe1uCfCOEx+o7By27rsl8zlY3JomGTB/5b91PqI3svUCESKRXvddOnVK9
VXnHeMqW93aFxwbUT26DnUoABjlyv2fJvQRNiMIaQOUxKLDDet9OMgWEcVkKqG5b
Pk2jKmKMu5w0on6wnIP3PUgu1CkKyb55RkYwq1zz1w3rq3L7QnC9zjwL9R9Dg8Tk
KsK8Ppt0MtCumJQEa62V/GW0LN5p7NadIc9fFuS3GUPY/1xgIsAh2LSU+HuiMY0i
9GB5eo2X4uAxuICG628YYOyvF88RvujY/mXSPQP3rhDme2GHjxqDD94TuGBE0ViW
trUYL163QIihwjmNqIQgK2zf7ZnX1v/6/T3sHBxfG/WLawEVxpT+DVe+/M0rqrfM
5lAIShZQKYqWYCn3ZgDFr15IzJ8d8ICsfmQ/b9yIZK5GmcUQ7NVtmd/e2M+sn7dK
tabMnrJEMfgIHXGP5lqrZaIqmefscXToRVfUi6DHWAmtbTdD5kwFVBJb/69W6u/l
4d7PHrlCsOr5NTQo6P2k07P9tgdc0ct2NQO8N7FVKVzMWKj4yzE=
=GYHk
-----END PGP SIGNATURE-----
Merge tag 'at91-defconfig-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/defconfig
AT91 defconfig for 5.12, part 2:
- only at91_dt_defconfig and sama5_defconfig modified
- update to match current options, unneeded options removed
- missing drivers added, some are on-SoC peripherals, some are helpers
- modify legacy ATAGS or DT options to match common usage
* tag 'at91-defconfig-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: configs: sama5_defconfig: add QSPI driver
ARM: configs: at91_dt_defconfig: add ov7740 module
ARM: configs: at91_dt_defconfig: add useful helper options
ARM: configs: at91: DT/ATAG defconfig modifications
ARM: configs: sama5_defconfig: update and remove unneeded options
ARM: configs: at91: enable drivers for sam9x60
Link: https://lore.kernel.org/r/20210208115753.54730-1-nicolas.ferre@microchip.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add a new ASoc Machine driver for Intel Baytrail platforms with a
Wolfson Microelectronics WM5102 codec.
This is based on a past contributions [1] from Paulo Sergio Travaglia
<pstglia@gmail.com> based on the Levono kernel [2] combined with
insights in things like the speaker GPIO from the android-x86 android
port for the Lenovo Yoga Tablet 2 1051F/L [3].
[1] https://patchwork.kernel.org/project/alsa-devel/patch/593313f5.3636c80a.50e05.47e9@mx.google.com/
[2] https://github.com/lenovo-yt2-dev/android_kernel_lenovo_baytrail/blob/cm-12.1/sound/soc/intel/board/byt_bl_wm5102.c
[3] https://github.com/Kitsune2222/Android_Yoga_Tablet_2-1051F_Kernel
The original machine driver from the Android ports was a crude modified
copy of bytcr_rt5640.c adjusted to work with the WM5102 codec.
This version has been extensively reworked to:
1. Remove all rt5640 related quirk handling. to the best of my knowledge
this setup is only used on the Lenovo Yoga Tablet 2 series (8, 10 and 13
inch models) which all use the same setup. So there is no need to deal
with all the variations with which we need to deal on rt5640 boards.
2. Rework clock handling, properly turn off the FLL and the platform-clock
when they are no longer necessary and don't reconfigure the FLL
unnecessarily when it is already running. This fixes a number of:
"Timed out waiting for lock" warnings being logged.
3. Add the GPIO controlled Speaker-VDD regulator as a DAPM_SUPPLY
This only adds the machine driver and ACPI hooks, the BYT-CR detection
quirk which these devices need will be added in a separate patch.
BugLink: https://github.com/thesofproject/linux/issues/2485
Co-authored-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210120214957.140232-6-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some Bay Trail systems:
1. Use a non CR version of the Bay Trail SoC
2. Contain at least 6 interrupt resources so that the
platform_get_resource(pdev, IORESOURCE_IRQ, 5) check to workaround
non CR systems which list their IPC IRQ at index 0 despite being
non CR does not work
3. Despite 1. and 2. still have their IPC IRQ at index 0 rather then 5
Add a DMI quirk table to check for the few known models with this issue,
so that the right IPC IRQ index is used on these systems.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210120214957.140232-5-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the ingenic,jz4760b-codec and ingenic,jz4760-codec compatible
strings.
In the process, convert the previous compatible strings to use an enum
instead.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210123140958.12895-1-paul@crapouillou.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the internal codec found in the JZ4760 SoC from Ingenic.
Signed-off-by: Christophe Branchereau <cbranchereau@gmail.com>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210123140958.12895-3-paul@crapouillou.net
Signed-off-by: Mark Brown <broonie@kernel.org>
No need to show the options to build Ingenic-specific drivers on all
MIPS kernel configurations if Ingenic SoCs support is not enabled.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210123140958.12895-2-paul@crapouillou.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Some controllers only have one HW CS, if support multiple devices, other devices need
to use SW CS.
This patch adds the support of both HW and SW CS via cs_gpio.
leilk.liu (3):
spi: add power control when set_cs_timing
spi: support CS timing for HW & SW mode
spi: mediatek: add set_cs_timing support
drivers/spi/spi-mt65xx.c | 72 +++++++++++++++++++++++++++++++---------
drivers/spi/spi.c | 32 +++++++++++++++---
2 files changed, 83 insertions(+), 21 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
The below patch series are to support Audio over HDMI.
The modification in this patch series shall allow I2S driver
to playback standard PCM format and IEC958 encoded format to
the ADV7511 HDMI chip.
ALSA IEC958 plugin will be used to compose the IEC958 format.
Existing hdmi-codec driver only support standard pcm format.
Support of IEC958 encoded format passdown from ALSA IEC958 plugin
is needed so that the IEC958 encoded data can be streamed to the
HDMI chip.
Sia Jee Heng (4):
ASoC: codec: hdmi-codec: Support IEC958 encoded PCM format
drm: bridge: adv7511: Support I2S IEC958 encoded PCM format
dt-bindings: sound: Intel, Keembay-i2s: Add hdmi-i2s compatible string
ASoC: Intel: KMB: Support IEC958 encoded PCM format
.../bindings/sound/intel,keembay-i2s.yaml | 1 +
drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 +
.../gpu/drm/bridge/adv7511/adv7511_audio.c | 6 ++
include/sound/hdmi-codec.h | 5 ++
sound/soc/codecs/hdmi-codec.c | 4 +-
sound/soc/intel/keembay/kmb_platform.c | 73 ++++++++++++++++++-
sound/soc/intel/keembay/kmb_platform.h | 1 +
7 files changed, 89 insertions(+), 2 deletions(-)
base-commit: 2557c711b87cd42bb22be9ca6ff3fce038624f30
--
2.18.0
There are a few places doing the same loop iterating all PCM
substreams belonging to the PCM object. Introduce a local helper
macro, for_each_pcm_substream(), to simplify the code.
Link: https://lore.kernel.org/r/20210206203656.15959-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The PCM stop operation sets the stop_operating flag for indicating the
sync_stop post-process. This flag is, however, set unconditionally
even if the PCM trigger weren't issued. This may lead to
inconsistency in the driver side.
Correct the code to set stop_operating flag only after the trigger
STOP is actually called.
Fixes: 1e850beea2 ("ALSA: pcm: Add the support for sync-stop operation")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210206203656.15959-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The current PCM code calls the sync_stop at the resume action due to
the analogy to the PCM prepare call pattern. But, it makes little
sense, as the sync should have been done rather at the suspend time,
not at the resume time.
This patch corrects the sync_stop call at suspend/resume to assure the
sync before finishing the suspend.
Fixes: 1e850beea2 ("ALSA: pcm: Add the support for sync-stop operation")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210206203656.15959-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The PCM core should perform the sync for the pending stop operations
at disconnection. Otherwise it may lead to unexpected access.
Currently the old user of sync_stop, USB-audio driver, has its own
sync, so this isn't needed, but it's better to guarantee the sync in
the PCM core level.
This patch adds the missing sync_stop call at PCM disconnection
callback. It also assures the IRQ sync if it's specified in the
card. snd_pcm_sync_stop() is slightly modified to be called also for
any PCM substream object now.
Fixes: 1e850beea2 ("ALSA: pcm: Add the support for sync-stop operation")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210206203656.15959-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the later patch, we're going to issue the PCM sync_stop calls at
disconnection. But currently the USB-audio driver can't handle it
because it has a check of shutdown flag for stopping the URBs. This
is basically superfluous (the stopping URBs are safe at disconnection
state), so let's drop the check.
Fixes: dc5eafe778 ("ALSA: usb-audio: Support PCM sync_stop")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210206203052.15606-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The endpoint management has bit flags to indicate the current state,
and we're dealing two things: the running bit and the stopping bit.
There is a thin window in transition from the running to the stopping
in stop_urbs(), and as long as the bit flags are used, it's difficult
to plug.
This patch modifies the state management code to use the atomic int
and follow the explicit three states, STOPPED, RUNNING and STOPPING.
The state change is done via atomic_cmpxhg() for avoiding possible
races, and check the state change more strictly. The unexpected state
change is now handled as an error.
Fixes: d0f09d1e4a ("ALSA: usb-audio: Refactoring endpoint URB deactivation")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210206203052.15606-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When we stop an endpoint in release_urbs(), it ignores the
inconsistent endpoint state and tries to release the resources.
This shouldn't happen in theory, but it's still safer to abort the
release and let the caller proper error handling.
Also, stop_and_unlink_urbs() called from release_urbs() does two step
works, and it's more straightforward to split this to two functions
again, so that the call from the PCM trigger won't take the path with
sleeping.
This patch modifies the EP management code to adapt two points above.
Fixes: d0f09d1e4a ("ALSA: usb-audio: Refactoring endpoint URB deactivation")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210206203052.15606-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fireface UCX, UFX, and FF802 are categorized for latter protocol of the
series. Current support for FF802 (and UFX) includes failure to parse
sync status register and results in EIO.
Further investigation figures out that the content of register differs
depending on models. This commit adds tables specific to FF802 and UFX
to fix it.
Fixes: 062bb452b0 ("ALSA: fireface: add support for RME FireFace 802")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210207154736.229551-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The i915 display power is requested both by controller (for init
and link reset) as well as by codec driver (for codec control).
There's an additional constraint that on some platforms frequent changes
to display power state may cause visible flicker. To avoid this, the SOF
hda controller requests display power whenever it is active and only
releases it when runtime suspended.
This patch utilizes the new hdac_bus link_power op to plug
into HDA link state changes. By monitoring link state changes,
we can keep the controller side display power wakeref until
the codec driver has completed its work, and only release
the wakeref when codec driver is suspended.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210205184630.1938761-4-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Opt-in to use snd_hdac_ext_bus_link_power() to manage HDA link
power up/down events.
This allows to reduce power consumption in cases where some HDA codecs
are suspended, but other child devices (HDA or non-HDA codecs) remain
active and controller itself remains in active state.
By using snd_hdac_ext_bus_link_power(), the individual HDA links can be
powered off and if all HDA codecs are powered down, the command DMA can
also be shut down.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210205184630.1938761-3-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The extended HDA bus (hdac_ext) provides interfaces for more
fine-grained control of individual links than what plain HDA
provides for. Links can be powered off when they are not used and if
all links are released, controller can shut down the command DMA.
These interfaces are currently not used by common HDA codec drivers.
When a HDA codec is runtime suspended, it calls snd_hdac_codec_link_down(),
but there is no link to the HDA extended bus, and on controller side
the links are shut down only when all codecs are suspended.
This patch adds link_power() to hdac_bus ops. Controllers using the HDA
extended core, can use this to plug in snd_hdac_ext_bus_link_power() to
implement more fine-grained control of link power.
No change is needed for plain HDA controllers nor to existing HDA
codec drivers.
Co-developed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210205184630.1938761-2-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Compiling with the clang integrated assembler warns about
a recently added instruction:
<instantiation>:14:13: error: unknown token in expression
ldr tmp1, =#0x00020010UL
arch/arm/mach-at91/pm_suspend.S:542:2: note: while in macro instantiation
at91_plla_enable
Remove the extra '#' character that is not used for the 'ldr'
instruction when doing an indirect load of a constant.
Fixes: 4fd36e4583 ("ARM: at91: pm: add plla disable/enable support for sam9x60")
Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20210204160129.2249394-1-arnd@kernel.org'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
These functions always return '0' and no callers use the return value.
So make it a void function.
This eliminates the following coccicheck warning:
./fs/jfs/jfs_txnmgr.c:1365:5-7: Unneeded variable: "rc". Return "0" on
line 1414
./fs/jfs/jfs_txnmgr.c:1422:5-7: Unneeded variable: "rc". Return "0" on
line 1527
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Remove spaces preceding closing brace of one of the nested if statement
blocks inside the rtl92e_leisure_ps_leave function, and replace with a
tab, to align it properly with the start of the block. Fixes a
checkpatch warning.
Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
Link: https://lore.kernel.org/r/20210207194944.113613-1-phil@philpotter.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This removes the braces from the if statement that checks the
wps_ie_len and ieee->wps_ie values in rtllib_association_req of
rtllib_softmac.c as this block contains only one statement.
Fixes a checkpatch warning.
Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
Link: https://lore.kernel.org/r/20210207225703.114229-1-phil@philpotter.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the firmware rejects a frame (because station become asleep or
disconnected), the frame is re-queued in mac80211. However, the
re-queued frame was 8 bytes longer than the original one (the size of
the ICV for the encryption). So, when mac80211 try to send this frame
again, it is a little bigger than expected.
If the frame is re-queued secveral time it end with a skb_over_panic
because the skb buffer is not large enough.
Note it only happens when device acts as an AP and encryption is
enabled.
This patch more or less reverts the commit 049fde1304 ("staging: wfx:
drop useless field from struct wfx_tx_priv").
Fixes: 049fde1304 ("staging: wfx: drop useless field from struct wfx_tx_priv")
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20210208135254.399964-1-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes warnings of 'checkpatch.pl'. According to
Linux coding guidelines, code should be aligned properly to
match with open parenthesis and lines should not end with
open parenthesis.
Signed-off-by: Mahak Gupta <gmahak1@gmail.com>
Link: https://lore.kernel.org/r/20210208025904.25928-1-gmahak1@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Constify two static structs which are never modified, to allow the
compiler to put them in read-only memory.
The only usage of controller_attribute_group is to put its address in an
array of pointers to const struct attribute_group, and the only usage of
can_power_ops is to assign its address to the 'ops' field in the
regulator_desc struct, which is a pointer to const struct regulator_ops.
Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20210207202501.9494-1-rikard.falkeborn@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There's a short window during boot where although the kernel is
running little endian, any exceptions will cause the CPU to switch
back to big endian. This situation persists until we call
configure_exceptions(), which calls either the hypervisor or OPAL to
configure the CPU so that exceptions will be taken in little
endian (via HID0[HILE]).
We don't intend to take exceptions during early boot, but one way we
sometimes do is via a WARN/BUG etc. Those all boil down to a trap
instruction, which will cause a program check exception.
The first instruction of the program check handler is an mtsprg, which
when executed in the wrong endian is an lhzu with a ~3GB displacement
from r3. The content of r3 is random, so that becomes a load from some
random location, and depending on the system (installed RAM etc.) can
easily lead to a checkstop, or an infinitely recursive page fault.
That prevents whatever the WARN/BUG was complaining about being
printed to the console, and the user just sees a dead system.
We can fix it by having a trampoline at the beginning of the program
check handler that detects we are in the wrong endian, and flips us
back to the correct endian.
We can't flip MSR[LE] using mtmsr (alas), so we have to use rfid. That
requires backing up SRR0/1 as well as a GPR. To do that we use
SPRG0/2/3 (SPRG1 is already used for the paca). SPRG3 is user
readable, but this trampoline is only active very early in boot, and
SPRG3 will be reinitialised in vdso_getcpu_init() before userspace
starts.
With this trampoline in place we can survive a WARN early in boot and
print a stack trace, which is eventually printed to the console once
the console is up, eg:
[83565.758545] kexec_core: Starting new kernel
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] static_key_enable_cpuslocked(): static key '0xc000000000ea6160' used before call to jump_label_init()
[ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-gcc-8.2.0-dirty #618
[ 0.000000] NIP: c0000000002fd46c LR: c0000000002fd468 CTR: c000000000170660
[ 0.000000] REGS: c000000001227940 TRAP: 0700 Not tainted (5.10.0-gcc-8.2.0-dirty)
[ 0.000000] MSR: 9000000002823003 <SF,HV,VEC,VSX,FP,ME,RI,LE> CR: 24882422 XER: 20040000
[ 0.000000] CFAR: 0000000000000730 IRQMASK: 1
[ 0.000000] GPR00: c0000000002fd468 c000000001227bd0 c000000001228300 0000000000000065
[ 0.000000] GPR04: 0000000000000001 0000000000000065 c0000000010cf970 000000000000000d
[ 0.000000] GPR08: 0000000000000000 0000000000000000 0000000000000000 c00000000122763f
[ 0.000000] GPR12: 0000000000002000 c000000000f8a980 0000000000000000 0000000000000000
[ 0.000000] GPR16: 0000000000000000 0000000000000000 c000000000f88c8e c000000000f88c9a
[ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.000000] GPR24: 0000000000000000 c000000000dea3a8 0000000000000000 c000000000f35114
[ 0.000000] GPR28: 0000002800000000 c000000000f88c9a c000000000f88c8e c000000000ea6160
[ 0.000000] NIP [c0000000002fd46c] static_key_enable_cpuslocked+0xfc/0x120
[ 0.000000] LR [c0000000002fd468] static_key_enable_cpuslocked+0xf8/0x120
[ 0.000000] Call Trace:
[ 0.000000] [c000000001227bd0] [c0000000002fd468] static_key_enable_cpuslocked+0xf8/0x120 (unreliable)
[ 0.000000] [c000000001227c40] [c0000000002fd4c0] static_key_enable+0x30/0x50
[ 0.000000] [c000000001227c70] [c000000000f6629c] early_page_poison_param+0x58/0x9c
[ 0.000000] [c000000001227cb0] [c000000000f351b8] do_early_param+0xa4/0x10c
[ 0.000000] [c000000001227d30] [c00000000011e020] parse_args+0x270/0x5e0
[ 0.000000] [c000000001227e20] [c000000000f35864] parse_early_options+0x48/0x5c
[ 0.000000] [c000000001227e40] [c000000000f358d0] parse_early_param+0x58/0x84
[ 0.000000] [c000000001227e70] [c000000000f3a368] early_init_devtree+0xc4/0x490
[ 0.000000] [c000000001227f10] [c000000000f3bca0] early_setup+0xc8/0x1c8
[ 0.000000] [c000000001227f90] [000000000000c320] 0xc320
[ 0.000000] Instruction dump:
[ 0.000000] 4bfffddd 7c2004ac 39200001 913f0000 4bffffb8 7c651b78 3c82ffac 3c62ffc0
[ 0.000000] 38841b00 3863f310 4bdf03a5 60000000 <0fe00000> 4bffff38 60000000 60000000
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x40/0x80 with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] dt-cpu-ftrs: setup for ISA 3000
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210202130207.1303975-2-mpe@ellerman.id.au
If we try to stack trace very early during boot, either due to a
WARN/BUG or manual dump_stack(), we will oops in
valid_emergency_stack() when we try to dereference the paca_ptrs
array.
The fix is simple, we just return false if paca_ptrs isn't allocated
yet. The stack pointer definitely isn't part of any emergency stack
because we haven't allocated any yet.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210202130207.1303975-1-mpe@ellerman.id.au
The idle entry/exit code saves/restores GPRs in the stack "red zone"
(Protected Zone according to PowerPC64 ELF ABI v2). However, the offset
used for the first GPR is incorrect and overwrites the back chain - the
Protected Zone actually starts below the current SP. In practice this is
probably not an issue, but it's still incorrect so fix it.
Also expand the comments to explain why using the stack "red zone"
instead of creating a new stackframe is appropriate here.
Signed-off-by: Christopher M. Riedl <cmr@codefail.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210206072342.5067-1-cmr@codefail.de
Function names should tell what the function does, not how.
mfsrin() and mtsrin() are read/writing segment registers.
They are called that way because they are using mfsrin and mtsrin
instructions, but it doesn't matter for the caller.
In preparation of following patch, change their name to mfsr() and mtsr()
in order to make it obvious they manipulate segment registers without
messing up with how they do it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/f92d99f4349391b77766745900231aa880a0efb5.1612612022.git.christophe.leroy@csgroup.eu
barrier_nospec() in uaccess helpers is there to protect against
speculative accesses around access_ok().
When using user_access_begin() sequences together with
unsafe_get_user() like macros, barrier_nospec() is called for
every single read although we know the access_ok() is done
onece.
Since all user accesses must be granted by a call to either
allow_read_from_user() or allow_read_write_user() which will
always happen after the access_ok() check, move the barrier_nospec()
there.
Reported-by: Christopher M. Riedl <cmr@codefail.de>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/c72f014730823b413528e90ab6c4d3bcb79f8497.1612692067.git.christophe.leroy@csgroup.eu
Commit 8813ff4960 ("powerpc/sstep: Check instruction validity
against ISA version before emulation") introduced a proper way to skip
unknown instructions. This makes sure that the same is used for the
darn instruction when the range selection bits have a reserved value.
Fixes: a23987ef26 ("powerpc: sstep: Add support for darn instruction")
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210204080744.135785-2-sandipan@linux.ibm.com
The Power ISA says that the fixed-point load and update instructions
must neither use R0 for the base address (RA) nor have the
destination (RT) and the base address (RA) as the same register.
Similarly, for fixed-point stores and floating-point loads and stores,
the instruction is invalid when R0 is used as the base address (RA).
This is applicable to the following instructions.
* Load Byte and Zero with Update (lbzu)
* Load Byte and Zero with Update Indexed (lbzux)
* Load Halfword and Zero with Update (lhzu)
* Load Halfword and Zero with Update Indexed (lhzux)
* Load Halfword Algebraic with Update (lhau)
* Load Halfword Algebraic with Update Indexed (lhaux)
* Load Word and Zero with Update (lwzu)
* Load Word and Zero with Update Indexed (lwzux)
* Load Word Algebraic with Update Indexed (lwaux)
* Load Doubleword with Update (ldu)
* Load Doubleword with Update Indexed (ldux)
* Load Floating Single with Update (lfsu)
* Load Floating Single with Update Indexed (lfsux)
* Load Floating Double with Update (lfdu)
* Load Floating Double with Update Indexed (lfdux)
* Store Byte with Update (stbu)
* Store Byte with Update Indexed (stbux)
* Store Halfword with Update (sthu)
* Store Halfword with Update Indexed (sthux)
* Store Word with Update (stwu)
* Store Word with Update Indexed (stwux)
* Store Doubleword with Update (stdu)
* Store Doubleword with Update Indexed (stdux)
* Store Floating Single with Update (stfsu)
* Store Floating Single with Update Indexed (stfsux)
* Store Floating Double with Update (stfdu)
* Store Floating Double with Update Indexed (stfdux)
E.g. the following behaviour is observed for an invalid load and
update instruction having RA = RT.
While a userspace program having an instruction word like 0xe9ce0001,
i.e. ldu r14, 0(r14), runs without getting receiving a SIGILL on a
Power system (observed on P8 and P9), the outcome of executing that
instruction word varies and its behaviour can be considered to be
undefined.
Attaching an uprobe at that instruction's address results in emulation
which currently performs the load as well as writes the effective
address back to the base register. This might not match the outcome
from hardware.
To remove any inconsistencies, this adds additional checks for the
aforementioned instructions to make sure that the emulation
infrastructure treats them as unknown. The kernel can then fallback to
executing such instructions on hardware.
Fixes: 0016a4cf55 ("powerpc: Emulate most Book I instructions in emulate_step()")
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210204080744.135785-1-sandipan@linux.ibm.com
For unimplemented instructions or unimplemented SPRs, the 8xx triggers
a "Software Emulation Exception" (0x1000). That interrupt doesn't set
reason bits in SRR1 as the "Program Check Exception" does.
Go through emulation_assist_interrupt() to set REASON_ILLEGAL.
Fixes: fbbcc3bb13 ("powerpc/8xx: Remove SoftwareEmulation()")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/ad782af87a222efc79cfb06079b0fd23d4224eaf.1612515180.git.christophe.leroy@csgroup.eu
While sampling for marked events, currently we record the sample only
if the SIAR valid bit of Sampled Instruction Event Register (SIER) is
set. SIAR_VALID bit is used for fetching the instruction address from
Sampled Instruction Address Register(SIAR). But there are some
usecases, where the user is interested only in the PMU stats at each
counter overflow and the exact IP of the overflow event is not
required. Dropping SIAR invalid samples will fail to record some of
the counter overflows in such cases.
Example of such usecase is dumping the PMU stats (event counts) after
some regular amount of instructions/events from the userspace (ex: via
ptrace). Here counter overflow is indicated to userspace via signal
handler, and captured by monitoring and enabling I/O signaling on the
event file descriptor. In these cases, we expect to get
sample/overflow indication after each specified sample_period.
Perf event attribute will not have PERF_SAMPLE_IP set in the
sample_type if exact IP of the overflow event is not requested. So
while profiling if SAMPLE_IP is not set, just record the counter
overflow irrespective of SIAR_VALID check.
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
[mpe: Reflow comment and if formatting]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1612516492-1428-1-git-send-email-atrajeev@linux.vnet.ibm.com
dlpar_configure_connector() has two problems in its handling of
ibm,configure-connector's return status:
1. When the status is -2 (busy, call again), we call
ibm,configure-connector again immediately without checking whether
to schedule, which can result in monopolizing the CPU.
2. Extended delay status (9900..9905) goes completely unhandled,
causing the configuration to unnecessarily terminate.
Fix both of these issues by using rtas_busy_delay().
Fixes: ab519a011c ("powerpc/pseries: Kernel DLPAR Infrastructure")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210107025900.410369-1-nathanl@linux.ibm.com
Similarly to the x86 commit b13b1d2d86 ("x86/mm: In the PTE swapout
page reclaim case clear the accessed bit instead of flushing the TLB"),
implement ptep_clear_flush_young that does not actually flush the TLB
in the case the referenced bit is cleared.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201217134731.488135-8-npiggin@gmail.com
serialize_against_pte_lookup() performs IPIs to all CPUs in mm_cpumask.
Take this opportunity to try trim the CPU out of mm_cpumask. This can
reduce the cost of future serialize_against_pte_lookup() and/or the
cost of future TLB flushes.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201217134731.488135-7-npiggin@gmail.com
