[PATCH v2 0/4] tracefs/eventfs: Fix failed second run of test_ownership
The test_ownership test of the kselftests was failing again. That's because the original fix was incorrect and a fix to a race condition showed how the original fix was broken. Instead of using tracefs_inodes to find the eventfs_inode that needs to be reset on remount, use the "events" directory descriptor to descend into its files and directories to catch all changes. Changes since v1: https://lore.kernel.org/linux-trace-kernel/20240522124504.28982...@gandalf.local.home - Added other fixes underneath and rebased it on: https://lore.kernel.org/lkml/20240522164320.469785...@goodmis.org/ - The real fix is to not use the tracefs_inodes to find the eventfs_inodes that need to be cleared on remount. Instead, the events descriptor needs to be used to descend its directories and files to update their attributes - The d_iput callback logic was misplaced. It should be done in the drop_inode callback. git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git eventfs/urgent Head SHA1: 41b7db11bcac4638fa489c58d35e7d2146b665ab Steven Rostedt (Google) (4): eventfs: Keep the directories from having the same inode number as files tracefs: Update inode permissions on remount eventfs: Update all the eventfs_inodes from the events descriptor tracefs: Clear EVENT_INODE flag in tracefs_drop_inode() fs/tracefs/event_inode.c | 57 +--- fs/tracefs/inode.c | 48 2 files changed, 73 insertions(+), 32 deletions(-)
[PATCH v2 0/4] Fix user stack traces captured from uprobes
This patch set reports two issues with captured stack traces. First issue, fixed in patch #2, deals with fixing up uretprobe trampoline addresses in captured stack trace. This issue happens when there are pending return probes, for which kernel hijacks some of the return addresses on user stacks. The code is matching those special uretprobe trampoline addresses with the list of pending return probe instances and replaces them with actual return addresses. This is the same fixup logic that fprobe/kretprobe has for kernel stack traces. Second issue, which patch #3 is fixing with the help of heuristic, is having to do with capturing user stack traces in entry uprobes. At the very entrance to user function, frame pointer in rbp register is not yet setup, so actual caller return address is still pointed to by rsp. Patch is using a simple heuristic, looking for `push %rbp` instruction, to fetch this extra direct caller return address, before proceeding to unwind the stack using rbp. Patch #4 adds tests into BPF selftests, that validate that captured stack traces at various points is what we expect to get. This patch, while being BPF selftests, is isolated from any other BPF selftests changes and can go in through non-BPF tree without the risk of merge conflicts. Patches are based on latest linux-trace/probes/for-next. v1->v2: - fixed GCC aggressively inlining test_uretprobe_stack() function (BPF CI); - fixed comments (Peter). Andrii Nakryiko (4): uprobes: rename get_trampoline_vaddr() and make it global perf,uprobes: fix user stack traces in the presence of pending uretprobes perf,x86: avoid missing caller address in stack traces captured in uprobe selftests/bpf: add test validating uprobe/uretprobe stack traces arch/x86/events/core.c| 20 ++ include/linux/uprobes.h | 3 + kernel/events/callchain.c | 43 +++- kernel/events/uprobes.c | 17 +- .../bpf/prog_tests/uretprobe_stack.c | 186 ++ .../selftests/bpf/progs/uretprobe_stack.c | 96 + 6 files changed, 361 insertions(+), 4 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/uretprobe_stack.c create mode 100644 tools/testing/selftests/bpf/progs/uretprobe_stack.c -- 2.43.0
Re: [PATCH v2 0/4] vhost: Cleanup
On 4/30/24 04:50, Michael S. Tsirkin wrote: On Mon, Apr 29, 2024 at 08:13:56PM +1000, Gavin Shan wrote: This is suggested by Michael S. Tsirkin according to [1] and the goal is to apply smp_rmb() inside vhost_get_avail_idx() if needed. With it, the caller of the function needn't to worry about memory barriers. Since we're here, other cleanups are also applied. [1] https://lore.kernel.org/virtualization/20240327155750-mutt-send-email-...@kernel.org/ Patch 1 makes some sense, gave some comments. Rest I think we should just drop. Sure, v3 has been sent with PATCH[v2 2/3/4] dropped. Please take a look when you getting a chance. v3: https://lore.kernel.org/virtualization/20240429232748.642356-1-gs...@redhat.com/T/#u Thanks, Gavin
Re: [PATCH v2 0/4] vhost: Cleanup
On Mon, Apr 29, 2024 at 08:13:56PM +1000, Gavin Shan wrote:
> This is suggested by Michael S. Tsirkin according to [1] and the goal
> is to apply smp_rmb() inside vhost_get_avail_idx() if needed. With it,
> the caller of the function needn't to worry about memory barriers. Since
> we're here, other cleanups are also applied.
>
> [1]
> https://lore.kernel.org/virtualization/20240327155750-mutt-send-email-...@kernel.org/
Patch 1 makes some sense, gave some comments. Rest I think we should
just drop.
> PATCH[1] improves vhost_get_avail_idx() so that smp_rmb() is applied if
> needed. Besides, the sanity checks on the retrieved available
> queue index are also squeezed to vhost_get_avail_idx()
> PATCH[2] drops the local variable @last_avail_idx since it's equivalent
> to vq->last_avail_idx
> PATCH[3] improves vhost_get_avail_head(), similar to what we're doing
> for vhost_get_avail_idx(), so that the relevant sanity checks
> on the head are squeezed to vhost_get_avail_head()
> PATCH[4] Reformat vhost_{get, put}_user() by using tab instead of space
> as the terminator for each line
>
> Gavin Shan (3):
> vhost: Drop variable last_avail_idx in vhost_get_vq_desc()
> vhost: Improve vhost_get_avail_head()
> vhost: Reformat vhost_{get, put}_user()
>
> Michael S. Tsirkin (1):
> vhost: Improve vhost_get_avail_idx() with smp_rmb()
>
> drivers/vhost/vhost.c | 215 +++---
> 1 file changed, 97 insertions(+), 118 deletions(-)
>
> Changelog
> =
> v2:
> * Improve vhost_get_avail_idx() as Michael suggested in [1]
> as above (Michael)
> * Correct @head's type from 'unsigned int' to 'int'
> (l...@intel.com)
>
> --
> 2.44.0
[PATCH v2 0/4] vhost: Cleanup
This is suggested by Michael S. Tsirkin according to [1] and the goal
is to apply smp_rmb() inside vhost_get_avail_idx() if needed. With it,
the caller of the function needn't to worry about memory barriers. Since
we're here, other cleanups are also applied.
[1]
https://lore.kernel.org/virtualization/20240327155750-mutt-send-email-...@kernel.org/
PATCH[1] improves vhost_get_avail_idx() so that smp_rmb() is applied if
needed. Besides, the sanity checks on the retrieved available
queue index are also squeezed to vhost_get_avail_idx()
PATCH[2] drops the local variable @last_avail_idx since it's equivalent
to vq->last_avail_idx
PATCH[3] improves vhost_get_avail_head(), similar to what we're doing
for vhost_get_avail_idx(), so that the relevant sanity checks
on the head are squeezed to vhost_get_avail_head()
PATCH[4] Reformat vhost_{get, put}_user() by using tab instead of space
as the terminator for each line
Gavin Shan (3):
vhost: Drop variable last_avail_idx in vhost_get_vq_desc()
vhost: Improve vhost_get_avail_head()
vhost: Reformat vhost_{get, put}_user()
Michael S. Tsirkin (1):
vhost: Improve vhost_get_avail_idx() with smp_rmb()
drivers/vhost/vhost.c | 215 +++---
1 file changed, 97 insertions(+), 118 deletions(-)
Changelog
=
v2:
* Improve vhost_get_avail_idx() as Michael suggested in [1]
as above (Michael)
* Correct @head's type from 'unsigned int' to 'int'
(l...@intel.com)
--
2.44.0
[PATCH v2 0/4] Improve memory statistics for virtio balloon
Hi, v1 -> v2: - Add a new patch 'virtio_balloon: separate vm events into a function' to avoid any compiler warnings(unused stack variable on CONFIG_VM_EVENT_COUNTERS=n) - Suggested by David, use a loop 'for (zid = 0; zid < MAX_NR_ZONES; zid++)' to obtain all the stall events. RFC -> v1: - several text changes: oom-kill -> oom-kills, SCAN_ASYNC -> ASYN_SCAN. - move vm events codes into '#ifdef CONFIG_VM_EVENT_COUNTERS' RFC version: Link: https://lore.kernel.org/lkml/20240415084113.1203428-1-pizhen...@bytedance.com/T/#m1898963b3c27a989b1123db475135c3ca687ca84 zhenwei pi (4): virtio_balloon: separate vm events into a function virtio_balloon: introduce oom-kill invocations virtio_balloon: introduce memory allocation stall counter virtio_balloon: introduce memory scan/reclaim info drivers/virtio/virtio_balloon.c | 62 ++--- include/uapi/linux/virtio_balloon.h | 16 +++- 2 files changed, 61 insertions(+), 17 deletions(-) -- 2.34.1
[PATCH v2 0/4] MSM8976 MDSS/GPU/WCNSS support
This patch series provide support for display subsystem, gpu and also adds wireless connectivity subsystem support. Changes since v1 1. Addressed feedback 2. Dropped already applied dt-bindings patches 3. Dropped sdc patch as it was submitted as part of other series 4. Dropped dt-bindings patch for Adreno, also separate now Adam Skladowski (4): arm64: dts: qcom: msm8976: Add IOMMU nodes arm64: dts: qcom: msm8976: Add MDSS nodes arm64: dts: qcom: msm8976: Add Adreno GPU arm64: dts: qcom: msm8976: Add WCNSS node arch/arm64/boot/dts/qcom/msm8976.dtsi | 524 +- 1 file changed, 520 insertions(+), 4 deletions(-) -- 2.44.0
[RFC PATCH v2 0/4] tracing: improve symbolic printing
As I mentioned before, it's annoying to see this in dropreason tracing with trace-cmd: irq/65-iwlwifi:-401 [000]22.79: kfree_skb: skbaddr=0x6a89b000 protocol=0 location=ieee80211_rx_handlers_result+0x21a reason: 0x2 and much nicer to see irq/65-iwlwifi:-401 [000]22.79: kfree_skb: skbaddr=0x69142000 protocol=0 location=ieee80211_rx_handlers_result+0x21a reason: RX_DROP_MONITOR The reason for this is that the __print_symbolic() string in tracing for trace-cmd to parse it is created at build-time, from the long list of _core_ drop reasons, but the drop reasons are now more dynamic. So I came up with __print_sym() which is similar, except it doesn't build the big list of numbers at build time but rather at runtime, which is actually a big memory saving too. But building it then, at the time userspace is recording it, lets us include all the known reasons. v2: - rebased on 6.9-rc1 - always search for __print_sym() and get rid of the DYNPRINT flag and associated code; I think ideally we'll just remove the older __print_symbolic() entirely - use ':' as the separator instead of "//" since that makes searching for it much easier and it's still not a valid char in an identifier - fix RCU johannes
[PATCH v2 0/4] tracing: Optimize __string()/__assign_str() processing
The TRACE_EVENT() macro handles dynamic strings by having:
TP_PROTO(struct some_struct *s),
TP_ARGS(s),
TP_STRUCT__entry(
__string(my_string, s->string)
),
TP_fast_assign(
__assign_str(my_string, s->string);
)
TP_printk("%s", __get_str(my_string))
There's even some code that may call a function helper to find the
s->string value. The problem with the above is that the work to get the
s->string is done twice. Once at the __string() and again in the
__assign_str().
The length of the string is calculated via a strlen(), not once, but
twice (using strcpy). The length is actually already recorded in the data
location from __string() and here's no reason to call strcpy() in
__assign_str() as the length is already known.
The __string() macro uses dynamic_array() which has a helper structure that
is created holding the offsets and length of the string fields. Instead of
finding the string twice, just save it off in another field in that helper
structure, and have __assign_str() use that instead.
Changes since v1:
https://lore.kernel.org/linux-trace-kernel/20240222195111.139824...@goodmis.org/
- Both the __dynamic_array() and __rel_dynamic_array() macros end with
a semicolon and are used by __string() and __rel_string()
respectively. But __string() doesn't have a semicolon after
__dynamic_array() but __rel_string does have a semicolon after
__rel_dynamic_array() which is unneeded. Remove the unnecessary
semicolon to keep the two consistent.
- Fixed __rel_string_len() that was incorrectly using __get_str() and
not __get_rel_str().
- Added two cleanup patches. One to use the ?: shortcut and the other
to use the new macro EVENT_NULL_STR instead of open coding "(null)"
as the string must be consistent between __string() and __assign_str().
Steven Rostedt (Google) (4):
tracing: Rework __assign_str() and __string() to not duplicate getting
the string
tracing: Do not calculate strlen() twice for __string() fields
tracing: Use ? : shortcut in trace macros
tracing: Use EVENT_NULL_STR macro instead of open coding "(null)"
include/linux/trace_events.h | 3 +++
include/trace/events/sunrpc.h| 12 ++--
include/trace/stages/stage2_data_offsets.h | 4 ++--
include/trace/stages/stage5_get_offsets.h| 15 ++-
include/trace/stages/stage6_event_callback.h | 12
5 files changed, 29 insertions(+), 17 deletions(-)
[PATCH v2 0/4] tracing/user_events: Introduce multi-format events
Currently user_events supports 1 event with the same name and must have
the exact same format when referenced by multiple programs. This opens
an opportunity for malicous or poorly thought through programs to
create events that others use with different formats. Another scenario
is user programs wishing to use the same event name but add more fields
later when the software updates. Various versions of a program may be
running side-by-side, which is prevented by the current single format
requirement.
Add a new register flag (USER_EVENT_REG_MULTI_FORMAT) which indicates
the user program wishes to use the same user_event name, but may have
several different formats of the event in the future. When this flag is
used, create the underlying tracepoint backing the user_event with a
unique name per-version of the format. It's important that existing ABI
users do not get this logic automatically, even if one of the multi
format events matches the format. This ensures existing programs that
create events and assume the tracepoint name will match exactly continue
to work as expected. Add logic to only check multi-format events with
other multi-format events and single-format events to only check
single-format events during find.
Change system name of the multi-format event tracepoint to ensure that
multi-format events are isolated completely from single-format events.
This prevents single-format names from conflicting with multi-format
events if they end with the same suffix as the multi-format events.
Add a register_name (reg_name) to the user_event struct which allows for
split naming of events. We now have the name that was used to register
within user_events as well as the unique name for the tracepoint. Upon
registering events ensure matches based on first the reg_name, followed
by the fields and format of the event. This allows for multiple events
with the same registered name to have different formats. The underlying
tracepoint will have a unique name in the format of {reg_name}.{unique_id}.
For example, if both "test u32 value" and "test u64 value" are used with
the USER_EVENT_REG_MULTI_FORMAT the system would have 2 unique
tracepoints. The dynamic_events file would then show the following:
u:test u64 count
u:test u32 count
The actual tracepoint names look like this:
test.0
test.1
Both would be under the new user_events_multi system name to prevent the
older ABI from being used to squat on multi-formatted events and block
their use.
Deleting events via "!u:test u64 count" would only delete the first
tracepoint that matched that format. When the delete ABI is used all
events with the same name will be attempted to be deleted. If
per-version deletion is required, user programs should either not use
persistent events or delete them via dynamic_events.
Changes in v2:
Tracepoint names changed from "name:[id]" to "name.id". Feedback
was the : could conflict with system name formats. []'s are also
special characters for bash.
Updated self-test and docs to reflect the new suffix format.
Updated docs to include a regex example to help guide recording
programs find the correct event in ambiguous cases.
Beau Belgrave (4):
tracing/user_events: Prepare find/delete for same name events
tracing/user_events: Introduce multi-format events
selftests/user_events: Test multi-format events
tracing/user_events: Document multi-format flag
Documentation/trace/user_events.rst | 27 ++-
include/uapi/linux/user_events.h | 6 +-
kernel/trace/trace_events_user.c | 224 +-
.../testing/selftests/user_events/abi_test.c | 134 +++
4 files changed, 329 insertions(+), 62 deletions(-)
base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a
--
2.34.1
[PATCH v2 0/4] Introduction of a remoteproc tee to load signed firmware
Updates from the previous version [1]
- fix issues reported by kernel test robot,
- address Rob Herring comment on bindings.
[1]
https://lore.kernel.org/linux-arm-kernel/20240115135249.296822-1-arnaud.pouliq...@foss.st.com/T/
This series proposes the implementation of a remoteproc tee driver to
communicate with a TEE trusted application responsible for authenticating and
loading the remoteproc firmware image in an Arm secure context.
1) Principle:
The remoteproc tee driver provides services to communicate with the OP-TEE
trusted application running on the Trusted Execution Context (TEE).
The trusted application in TEE manages the remote processor lifecycle:
- authenticating and loading firmware images,
- isolating and securing the remote processor memories,
- supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33),
- managing the start and stop of the firmware by the TEE.
2) Format of the signed image:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc_core.c#L18-L57
3) OP-TEE trusted application API:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_remoteproc.h
4) OP-TEE signature script
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py
Example of usage:
sign_rproc_fw.py --in --in --out --key
${OP-TEE_PATH}/keys/default.pem
5) Impact on User space Application
No sysfs impact.the user only needs to provide the signed firmware image
instead of the ELF image.
For more information about the implementation, a presentation is available here
(note that the format of the signed image has evolved between the presentation
and the integration in OP-TEE).
https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds
Arnaud Pouliquen (4):
remoteproc: Add TEE support
dt-bindings: remoteproc: add compatibility for TEE support
remoteproc: stm32: create sub-functions to request shutdown and
release
remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
.../bindings/remoteproc/st,stm32-rproc.yaml | 52 ++-
drivers/remoteproc/Kconfig| 9 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/stm32_rproc.c | 233 +--
drivers/remoteproc/tee_remoteproc.c | 393 ++
include/linux/tee_remoteproc.h| 99 +
6 files changed, 740 insertions(+), 47 deletions(-)
create mode 100644 drivers/remoteproc/tee_remoteproc.c
create mode 100644 include/linux/tee_remoteproc.h
base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a
--
2.25.1
[PATCH v2 0/4] locking/atomic: arch_cmpxchg[64]_local undefined
This patch series implement arch_cmpxchg[64]_local for arc, openrisc and hexagon. For architectures that support native cmpxchg, we'd like to implement arch_cmpxchg[64]_local with the native variants of supported data size. If not, the generci_cmpxchg[64]_local will be used. wuqiang.matt (4): locking/atomic: arc: data size checking in arch_cmpxchg locking/atomic: arc: arch_cmpxchg[64]_local undefined locking/atomic: openrisc: arch_cmpxchg[64]_local undefined locking/atomic: hexagon: arch_cmpxchg[64]_local undefined arch/arc/include/asm/cmpxchg.h | 40 ++ arch/hexagon/include/asm/cmpxchg.h | 51 - arch/openrisc/include/asm/cmpxchg.h | 6 3 files changed, 90 insertions(+), 7 deletions(-) -- 2.40.1
[PATCH v2 0/4] Add samsung-matisselte and common matisse dtsi
This series adds a common samsung-matisse dtsi and reworks samsung-matisse-wifi to use it, and introduces samsung-matisselte. I choose matisselte over matisse-lte as this is how most other devices (klte, s3ve3g) do it and it is the codename that Samsung gave the device. See individual commits for more information. --- Changes since v1: - Rebased on latest linux-next - Added qcom,msm8226 compatible to matisselte inspired by recent Lumia 830 patch. This is done as in v1, the patch was rejected because I included the msm8226 dtsi despite not marking matisselte as compatible with msm8226, and I was not sure how to resolve that. As such, I'm copying what was done in the Lumia 830 (microsoft-tesla) patch given that it was accepted. Stefan Hansson (4): ARM: dts: qcom: samsung-matisse-common: Add initial common device tree dt-bindings: arm: qcom: Add Samsung Galaxy Tab 4 10.1 LTE ARM: dts: qcom: Add support for Samsung Galaxy Tab 4 10.1 LTE (SM-T535) ARM: dts: qcom: samsung-matisse-common: Add UART .../devicetree/bindings/arm/qcom.yaml | 1 + arch/arm/boot/dts/qcom/Makefile | 1 + .../qcom-apq8026-samsung-matisse-wifi.dts | 467 + .../qcom-msm8226-samsung-matisse-common.dtsi | 478 ++ .../qcom/qcom-msm8926-samsung-matisselte.dts | 36 ++ 5 files changed, 525 insertions(+), 458 deletions(-) create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8926-samsung-matisselte.dts -- 2.41.0
Re: [PATCH v2 0/4] Stylus-on-touchscreen device support
On Mon, Mar 08, 2021 at 06:41:49PM +0100, наб wrote: > This patchset adds support for stylus-on-touchscreen devices as found on > the OneMix 3 Pro and Dell Inspiron 15 7000 2-in-1 (7591), among others; > with it, they properly behave like a drawing tablet. > > Patches 2 and 4 funxionally depend on patch 1. > Patch 4 needs patch 3 to apply. > > The output of this patchset and the need for a kernel, rather than > userspace, patch was previously discussed here: > > https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/558#note_792834 > > Changes in v2: > Patch 4 now ANDs the secondary button with the tip switch, > since it's otherwise borderline useless to the user. > > Ahelenia Ziemiańska (4): > HID: multitouch: require Finger field to mark Win8 reports as MT > HID: multitouch: set Stylus suffix for Stylus-application devices, too > HID: input: replace outdated HID numbers+comments with macros > HID: input: work around Win8 stylus-on-touchscreen reporting > > drivers/hid/hid-input.c | 54 ++-- > drivers/hid/hid-multitouch.c | 18 +++- > 2 files changed, 62 insertions(+), 10 deletions(-) > > -- > 2.20.1 Bumping this after a monthish ‒ is it missing something? Am I? signature.asc Description: PGP signature
[PATCH v2 0/4] Convert powerpc to GENERIC_PTDUMP
This series converts powerpc to generic PTDUMP. For that, we first need to add missing hugepd support to pagewalk and ptdump. v2: - Reworked the pagewalk modification to add locking and check ops->pte_entry - Modified powerpc early IO mapping to have gaps between mappings - Removed the logic that checked for contiguous physical memory - Removed the articial level calculation in ptdump_pte_entry(), level 4 is ok for all. - Removed page_size argument to note_page() Christophe Leroy (4): mm: pagewalk: Fix walk for hugepage tables powerpc/mm: Leave a gap between early allocated IO areas powerpc/mm: Properly coalesce pages in ptdump powerpc/mm: Convert powerpc to GENERIC_PTDUMP arch/powerpc/Kconfig | 2 + arch/powerpc/Kconfig.debug| 30 - arch/powerpc/mm/Makefile | 2 +- arch/powerpc/mm/ioremap_32.c | 4 +- arch/powerpc/mm/ioremap_64.c | 2 +- arch/powerpc/mm/mmu_decl.h| 2 +- arch/powerpc/mm/ptdump/8xx.c | 6 +- arch/powerpc/mm/ptdump/Makefile | 9 +- arch/powerpc/mm/ptdump/book3s64.c | 6 +- arch/powerpc/mm/ptdump/ptdump.c | 187 -- arch/powerpc/mm/ptdump/shared.c | 6 +- mm/pagewalk.c | 58 - 12 files changed, 127 insertions(+), 187 deletions(-) -- 2.25.0
Re: (subset) [PATCH V2 0/4] Add RTC support for PMIC PMK8350
On Fri, 9 Apr 2021 19:29:22 +0530, satya priya wrote: > satya priya (4): > rtc: pm8xxx: Add RTC support for PMIC PMK8350 > dt-bindings: mfd: Add compatible for pmk8350 rtc > dt-bindings: mfd: Convert pm8xxx bindings to yaml > dt-bindings: rtc: qcom-pm8xxx-rtc: Add qcom pm8xxx rtc bindings > > .../devicetree/bindings/mfd/qcom-pm8xxx.txt| 99 > -- > .../devicetree/bindings/mfd/qcom-pm8xxx.yaml | 54 > .../devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml | 62 ++ > drivers/rtc/rtc-pm8xxx.c | 11 +++ > 4 files changed, 127 insertions(+), 99 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt > create mode 100644 Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml > create mode 100644 Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml Applied, thanks! [1/4] rtc: pm8xxx: Add RTC support for PMIC PMK8350 commit: c8f0ca8b7a4b91f637ccd9a55f37dbac73d6f6bf [4/4] dt-bindings: rtc: qcom-pm8xxx-rtc: Add qcom pm8xxx rtc bindings commit: 8138c5f0318c69a878582d2140dac08e6a99880d Best regards, -- Alexandre Belloni
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On Fri, Apr 16, 2021 at 09:43:48AM -0500, Madhavan T. Venkataraman wrote: > How would you prefer I handle this? Should I place all SYM_CODE functions that > are actually safe for the unwinder in a separate section? I could just take > some approach and solve this. But I would like to get your opinion and Mark > Rutland's opinion so we are all on the same page. That sounds reasonable to me, obviously we'd have to look at how exactly the annotation ends up getting done and general bikeshed colour discussions. I'm not sure if we want a specific "safe for unwinder section" or to split things up into sections per reason things are safe for the unwinder (kind of like what you were proposing for flagging things as a problem), that might end up being useful for other things at some point. signature.asc Description: PGP signature
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On 4/14/21 5:23 AM, Madhavan T. Venkataraman wrote: > In any case, I have absolutely no problems in implementing your section idea. > I will > make an attempt to do that in version 3 of my patch series. So, I attempted a patch with just declaring all .entry.text functions as unreliable by checking just the section bounds. It does work for EL1 exceptions. But there are other functions that are actually reliable that show up as unreliable. The example in my test is el0_sync() which is at the base of all system call stacks. How would you prefer I handle this? Should I place all SYM_CODE functions that are actually safe for the unwinder in a separate section? I could just take some approach and solve this. But I would like to get your opinion and Mark Rutland's opinion so we are all on the same page. Please let me know. Madhavan
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On Wed, Apr 14, 2021 at 05:23:38AM -0500, Madhavan T. Venkataraman wrote: > On 4/13/21 6:02 AM, Mark Brown wrote: > > On Mon, Apr 12, 2021 at 02:55:35PM -0500, Madhavan T. Venkataraman wrote: > >> 3. We are going to assume that the reliable unwinder is only for livepatch > >> purposes > >>and will only be invoked on a task that is not currently running. The > >> task either > > > > The reliable unwinder can also be invoked on itself. > I have not called out the self-directed case because I am assuming that the > reliable unwinder > is only used for livepatch. So, AFAICT, this is applicable to the task that > performs the > livepatch operation itself. In this case, there should be no unreliable > functions on the > self-directed stack trace (otherwise, livepatching would always fail). Someone might've added a probe of some kind which upsets things so there's a possibility things might fail. Like you say there's no way a system in such a state can succesfully apply a live patch but we might still run into that situation. > >> I suggest we do (3) first. Then, review the assembly functions to do (1). > >> Then, review the > >> remaining ones to see which ones must be blacklisted, if any. > > I'm not clear what the concrete steps you're planning to do first are > > there - your 3 seems like a statement of assumptions. For flagging > > functions I do think it'd be safer to default to assuming that all > > SYM_CODE functions can't be unwound reliably rather than only explicitly > > listing ones that cause problems. > They are not assumptions. They are true statements. But I probably did not do > a good > job of explaining. But Josh sent out a patch that updates the documentation > that > explains what I said a lot better. You say true statements, I say assumptions :) signature.asc Description: PGP signature
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On Tue, Apr 13, 2021 at 05:53:10PM -0500, Josh Poimboeuf wrote: > On Mon, Apr 12, 2021 at 05:59:33PM +0100, Mark Brown wrote: > > Some more explict pointer to live patching as the only user would > > definitely be good but I think the more important thing would be writing > > down any assumptions in the API that aren't already written down and > Something like so? Yeah, looks reasonable - it'll need rebasing against current code as I moved the docs in the source out of the arch code into the header this cycle (they were copied verbatim in a couple of places). > #ifdef CONFIG_ARCH_STACKWALK > > /** > - * stack_trace_consume_fn - Callback for arch_stack_walk() > + * stack_trace_consume_fn() - Callback for arch_stack_walk() > * @cookie: Caller supplied pointer handed back by arch_stack_walk() > * @addr:The stack entry address to consume > * > @@ -35,7 +35,7 @@ unsigned int stack_trace_save_user(unsigned long *store, > unsigned int size); > */ > typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr); > /** > - * arch_stack_walk - Architecture specific function to walk the stack > + * arch_stack_walk() - Architecture specific function to walk the stack > * @consume_entry: Callback which is invoked by the architecture code for > * each entry. > * @cookie: Caller supplied pointer which is handed back to These two should be separated. signature.asc Description: PGP signature
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On 4/13/21 6:02 AM, Mark Brown wrote: > On Mon, Apr 12, 2021 at 02:55:35PM -0500, Madhavan T. Venkataraman wrote: > >> >> OK. Just so I am clear on the whole picture, let me state my understanding >> so far. >> Correct me if I am wrong. > >> 1. We are hoping that we can convert a significant number of SYM_CODE >> functions to >>SYM_FUNC functions by providing them with a proper FP prolog and epilog >> so that >>we can get objtool coverage for them. These don't need any blacklisting. > > I wouldn't expect to be converting lots of SYM_CODE to SYM_FUNC. I'd > expect the overwhelming majority of SYM_CODE to be SYM_CODE because it's > required to be non standard due to some external interface - things like > the exception vectors, ftrace, and stuff around suspend/hibernate. A > quick grep seems to confirm this. > OK. Fair enough. >> 3. We are going to assume that the reliable unwinder is only for livepatch >> purposes >>and will only be invoked on a task that is not currently running. The >> task either > > The reliable unwinder can also be invoked on itself. > I have not called out the self-directed case because I am assuming that the reliable unwinder is only used for livepatch. So, AFAICT, this is applicable to the task that performs the livepatch operation itself. In this case, there should be no unreliable functions on the self-directed stack trace (otherwise, livepatching would always fail). >> 4. So, the only functions that will need blacklisting are the remaining >> SYM_CODE functions >>that might give up the CPU voluntarily. At this point, I am not even sure >> how >>many of these will exist. One hopes that all of these would have ended up >> as >>SYM_FUNC functions in (1). > > There's stuff like ret_from_fork there. > OK. There would be a few functions that fit this category. I agree. >> I suggest we do (3) first. Then, review the assembly functions to do (1). >> Then, review the >> remaining ones to see which ones must be blacklisted, if any. > > I'm not clear what the concrete steps you're planning to do first are > there - your 3 seems like a statement of assumptions. For flagging > functions I do think it'd be safer to default to assuming that all > SYM_CODE functions can't be unwound reliably rather than only explicitly > listing ones that cause problems. > They are not assumptions. They are true statements. But I probably did not do a good job of explaining. But Josh sent out a patch that updates the documentation that explains what I said a lot better. In any case, I have absolutely no problems in implementing your section idea. I will make an attempt to do that in version 3 of my patch series. Stay tuned. And, thanks for all the input. It is very helpful. Madhavan
[PATCH v2 0/4] arm: imx: Add i.mx6q DaSheng COM-9XX SBC board support
From: dillon min This patchset aims to add kernel support on DaSheng COM-8XX SBC board optimize ov2659 driver to handle xvclk on/off at proper stage to save power changes based on master branch, since commit id: 89698becf06d341a700913c3d89ce2a914af69a2 The DaSheng Com-9xx is and ARM based signle board computer (SBC) featuring: - i.MX6Q - 2GiB LPDDR3 DRAM - 8GiB eMMC 5.0 FLASH - 4MiB SPI Flash - USB 2.0 Host/Device - Multiple multi-protocol RS232/RS485 Serial ports - microSD socket - 5V DC power input - HDMI1.4a,1080p@60 - RGMIIx1 Gigabit Ethernet - CSI0x1, connect with ov2659 v2: - add "[PATCH v2 4/4] dt-bindings: add dasheng vendor prefix" to fix checkpatch.pl warning. dillon min (4): dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX SBC board dts support arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC board support media: i2c: ov2659: Add clk_prepare_enable(), clk_disable_unprepare() to handle xvclk dt-bindings: add dasheng vendor prefix Documentation/devicetree/bindings/arm/fsl.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/imx6q-ds.dts | 17 + arch/arm/boot/dts/imx6qdl-ds.dtsi | 465 + drivers/media/i2c/ov2659.c | 24 +- 6 files changed, 504 insertions(+), 6 deletions(-) create mode 100644 arch/arm/boot/dts/imx6q-ds.dts create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi -- 2.7.4
[PATCH v2 0/4] sched/fair: Fix load balancing of SMT siblings with ASYM_PACKING
=== Problem statement === On SMT-enabled hardware, ASYM_PACKING can cause the load balancer to choose low priority CPUs over medium priority CPUs. When balancing load in scheduling domains with the SD_ASYM_PACKING flag, idle CPUs of higher priority pull tasks from CPUs of lower priority. This balancing is done by comparing pairs of scheduling groups. There may also be scheduling groups composed of CPUs that are SMT siblings. When using SD_ASYM_PACKING on x86 with Intel Turbo Boost Max Technology 3.0 (ITMT), the priorities of a scheduling group of CPUs that has N SMT siblings are assigned as N*P, N*P/2, N*P/3, ..., P, where P is the priority assigned by the hardware to the physical core and N is the number of SMT siblings. Systems such as Intel Comet Lake can have some cores supporting SMT, while others do not. As a result, it is possible to have medium non-SMT priorities, Q, such that N*P > Q > P. When comparing groups for load balancing, the priority of the CPU doing the load balancing is only compared with the preferred CPU of the candidate busiest group (N*P vs Q in the example above). Thus, scheduling groups with a preferred CPU with priority N*P always pull tasks from the scheduling group with priority Q and then such tasks are spread across the “SMT” domain. Conversely, since N*P > Q, CPUs with priority Q cannot pull tasks from a group with a preferred CPU with priority N*P, even though Q > P. Doing load balancing based on load (i.e. if the busiest group is of type group_overloaded) will not help if the system is not fully busy as the involved groups will have only one task and load balancing will not be deemed as necessary. The behavior described above results in leaving CPUs with medium priority idle, while CPUs with lower priority are busy. Furthermore, such CPUs of lower priority are SMT siblings of high priority CPUs, which are also busy. This patchset fixes this behavior by also checking the idle state of the SMT siblings of both the CPU doing the load balance and the busiest candidate group. I ran a few benchmarks with and without this version of the patchset on an Intel(R) Core(TM) i9-7900X CPU. I kept online both SMT siblings of two high priority cores. I offlined the lower priority SMT siblings of four low priority cores. I offlined the rest of the cores. The resulting priority configuration meets the N*P > Q > P condition described above. The baseline for the results is an unmodified v5.12-rc3 kernel. Results show a comparative percentage of improvement (positive) or degradation (negative). Each test case is repeated five times, and the standard deviation among repetitions is also documented. In order to judge only the improvements this patchset provides, Table 1 shows the results when setting the CPU's frequency at 1000MHz. It can be observed that the patches bring an overall positive impact for tests that exhibit low variance. Some of the test cases, however, show a high variance and it is difficult to assess the impact. Table 2 shows the results when using hardware-controlled performance performance states (HWP), a common use case. In this case, the impact of the patches is also overall positive. schbench exhibits a small degradation. However, it also exhibits a large variance. v1 patches and test results can be found in [1]. Thanks and BR, Ricardo Changes since v1: * Don't bailout in update_sd_pick_busiest() if dst_cpu cannot pull tasks. Instead, reclassify the candidate busiest group, as it may still be selected. (PeterZ) * Avoid an expensive and unnecessary call to cpumask_weight() when determining if a sched_group is comprised of SMT siblings. (PeterZ). * Updated test results using the v2 patches. Table 1. Test results of patches at 1MHz === hackbench = caseloadbaseline(std%) compare%( std%) process-pipegroup-1 1.00 ( 4.01) +6.98 ( 3.05) process-pipegroup-2 1.00 ( 4.17) +1.20 ( 2.21) process-pipegroup-4 1.00 ( 5.26) +4.54 ( 2.67) process-pipegroup-8 1.00 ( 12.57) -2.49 ( 11.70) process-sockets group-1 1.00 ( 0.65) +3.77 ( 0.87) process-sockets group-2 1.00 ( 1.04) +0.45 ( 0.49) process-sockets group-4 1.00 ( 0.57) +0.16 ( 1.63) process-sockets group-8 1.00 ( 6.39) +0.58 ( 6.16) threads-pipegroup-1 1.00 ( 2.82) +1.04 ( 3.60) threads-pipegroup-2 1.00 ( 2.50) +3.53 ( 1.44) threads-pipegroup-4 1.00 ( 5.55) -0.02 ( 1.05) threads-pipegroup-8 1.00 ( 12.85) -1.00 ( 14.05) threads-sockets group-1 1.00 ( 1.26) +4.54 ( 1.92) threads-sockets group-2 1.00 ( 2.11) +2.80 ( 0.40) threads-sockets
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On Mon, Apr 12, 2021 at 05:59:33PM +0100, Mark Brown wrote: > On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote: > > > Hm, for that matter, even without renaming things, a comment above > > stack_trace_save_tsk_reliable() describing the meaning of "reliable" > > would be a good idea. > > Might be better to place something at the prototype for > arch_stack_walk_reliable() or cross link the two since that's where any > new architectures should be starting, or perhaps even better to extend > the document that Mark wrote further and point to that from both places. > > Some more explict pointer to live patching as the only user would > definitely be good but I think the more important thing would be writing > down any assumptions in the API that aren't already written down and > we're supposed to be relying on. Mark's document captured a lot of it > but it sounds like there's more here, and even with knowing that this > interface is only used by live patch and digging into what it does it's > not always clear what happens to work with the code right now and what's > something that's suitable to be relied on. Something like so? From: Josh Poimboeuf Subject: [PATCH] livepatch: Clarify the meaning of 'reliable' Update the comments and documentation to reflect what 'reliable' unwinding actually means, in the context of live patching. Suggested-by: Mark Brown Signed-off-by: Josh Poimboeuf --- .../livepatch/reliable-stacktrace.rst | 26 + arch/x86/kernel/stacktrace.c | 6 include/linux/stacktrace.h| 29 +-- kernel/stacktrace.c | 7 - 4 files changed, 53 insertions(+), 15 deletions(-) diff --git a/Documentation/livepatch/reliable-stacktrace.rst b/Documentation/livepatch/reliable-stacktrace.rst index 67459d2ca2af..e325efc7e952 100644 --- a/Documentation/livepatch/reliable-stacktrace.rst +++ b/Documentation/livepatch/reliable-stacktrace.rst @@ -72,7 +72,21 @@ The unwinding process varies across architectures, their respective procedure call standards, and kernel configurations. This section describes common details that architectures should consider. -4.1 Identifying successful termination +4.1 Only preemptible code needs reliability detection +- + +The only current user of reliable stacktracing is livepatch, which only +calls it for a) inactive tasks; or b) the current task in task context. + +Therefore, the unwinder only needs to detect the reliability of stacks +involving *preemptible* code. + +Practically speaking, reliability of stacks involving *non-preemptible* +code is a "don't-care". It may help to return a wrong reliability +result for such cases, if it results in reduced complexity, since such +cases will not happen in practice. + +4.2 Identifying successful termination -- Unwinding may terminate early for a number of reasons, including: @@ -95,7 +109,7 @@ architectures verify that a stacktrace ends at an expected location, e.g. * On a specific stack expected for a kernel entry point (e.g. if the architecture has separate task and IRQ stacks). -4.2 Identifying unwindable code +4.3 Identifying unwindable code --- Unwinding typically relies on code following specific conventions (e.g. @@ -129,7 +143,7 @@ unreliable to unwind from, e.g. * Identifying specific portions of code using bounds information. -4.3 Unwinding across interrupts and exceptions +4.4 Unwinding across interrupts and exceptions -- At function call boundaries the stack and other unwind state is expected to be @@ -156,7 +170,7 @@ have no such cases) should attempt to unwind across exception boundaries, as doing so can prevent unnecessarily stalling livepatch consistency checks and permits livepatch transitions to complete more quickly. -4.4 Rewriting of return addresses +4.5 Rewriting of return addresses - Some trampolines temporarily modify the return address of a function in order @@ -222,7 +236,7 @@ middle of return_to_handler and can report this as unreliable. Architectures are not required to unwind from other trampolines which modify the return address. -4.5 Obscuring of return addresses +4.6 Obscuring of return addresses - Some trampolines do not rewrite the return address in order to intercept @@ -249,7 +263,7 @@ than the link register as would usually be the case. Architectures must either ensure that unwinders either reliably unwind such cases, or report the unwinding as unreliable. -4.6 Link register unreliability +4.7 Link register unreliability --- On some other architectures, 'call' instructions place the return address into a diff --git a/arch/x86/kernel/stacktrace.c
Re: [PATCH V2 0/4] Add RTC support for PMIC PMK8350
Lee, On 09/04/2021 19:29:22+0530, satya priya wrote: > satya priya (4): > rtc: pm8xxx: Add RTC support for PMIC PMK8350 > dt-bindings: mfd: Add compatible for pmk8350 rtc > dt-bindings: mfd: Convert pm8xxx bindings to yaml > dt-bindings: rtc: qcom-pm8xxx-rtc: Add qcom pm8xxx rtc bindings > > .../devicetree/bindings/mfd/qcom-pm8xxx.txt| 99 > -- > .../devicetree/bindings/mfd/qcom-pm8xxx.yaml | 54 > .../devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml | 62 ++ > drivers/rtc/rtc-pm8xxx.c | 11 +++ > 4 files changed, 127 insertions(+), 99 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt > create mode 100644 Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml > create mode 100644 Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml > This is mostly about the RTC driver but the bindings doc is in mfd. How do you prefer that to be merged? there is no build dependency so I can take 1 and 4 and you could take 2 and 3. Or one of us can take all 4 patches. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[PATCH v2 0/4] stm32 usart add fifo threshold configuration
This series adds the support for two optional DT properties to configure RX and TX FIFO thresholds: - rx-threshold - tx-threshold This replaces hard-coded 8 bytes threshold. No functional change expected if unspecified (keep 8 as default). Changes in v2: Change added properties naming and factorize it in serial.yaml as proposed by Rob Herring. Erwan Le Ray (3): dt-bindings: serial: add RX and TX FIFO properties dt-bindings: serial: stm32: override FIFO threshold properties dt-bindings: serial: 8250: update TX FIFO trigger level Fabrice Gasnier (1): serial: stm32: add FIFO threshold configuration .../devicetree/bindings/serial/8250.yaml | 1 - .../devicetree/bindings/serial/serial.yaml| 10 .../bindings/serial/st,stm32-uart.yaml| 27 +- drivers/tty/serial/stm32-usart.c | 53 --- drivers/tty/serial/stm32-usart.h | 8 +-- 5 files changed, 85 insertions(+), 14 deletions(-) -- 2.17.1
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On Mon, Apr 12, 2021 at 02:55:35PM -0500, Madhavan T. Venkataraman wrote: > > OK. Just so I am clear on the whole picture, let me state my understanding so > far. > Correct me if I am wrong. > 1. We are hoping that we can convert a significant number of SYM_CODE > functions to >SYM_FUNC functions by providing them with a proper FP prolog and epilog so > that >we can get objtool coverage for them. These don't need any blacklisting. I wouldn't expect to be converting lots of SYM_CODE to SYM_FUNC. I'd expect the overwhelming majority of SYM_CODE to be SYM_CODE because it's required to be non standard due to some external interface - things like the exception vectors, ftrace, and stuff around suspend/hibernate. A quick grep seems to confirm this. > 3. We are going to assume that the reliable unwinder is only for livepatch > purposes >and will only be invoked on a task that is not currently running. The task > either The reliable unwinder can also be invoked on itself. > 4. So, the only functions that will need blacklisting are the remaining > SYM_CODE functions >that might give up the CPU voluntarily. At this point, I am not even sure > how >many of these will exist. One hopes that all of these would have ended up > as >SYM_FUNC functions in (1). There's stuff like ret_from_fork there. > I suggest we do (3) first. Then, review the assembly functions to do (1). > Then, review the > remaining ones to see which ones must be blacklisted, if any. I'm not clear what the concrete steps you're planning to do first are there - your 3 seems like a statement of assumptions. For flagging functions I do think it'd be safer to default to assuming that all SYM_CODE functions can't be unwound reliably rather than only explicitly listing ones that cause problems. signature.asc Description: PGP signature
[PATCH v2 0/4] staging: media: intel-ipu3: Cleanup patchset for style issues
Changes from v1:- Dropped patches 1/6 and 2/6 and compiled this as a patchset of 4 patches. [PATCH 1/4]:- No changes. [PATCH 2/4]:- No changes. [PATCH 3/4]:- Reduced length of a line under 80 characters. This was patch 5/6 previously. [PATCH 4/4]:- No changes. Mitali Borkar (4): staging: media: intel-ipu3: remove unnecessary blank line staging: media: intel-ipu3: reduce length of line staging: media: intel-ipu3: reduce length of line staging: media: intel-ipu3: remove space before tabs .../staging/media/ipu3/include/intel-ipu3.h| 13 - 1 file changed, 8 insertions(+), 5 deletions(-) -- 2.30.2
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On 4/12/21 12:36 PM, Mark Brown wrote: > On Fri, Apr 09, 2021 at 04:37:41PM -0500, Josh Poimboeuf wrote: >> On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote: > >>> Further, I believe all the special cases are assembly functions, and >>> most of those are already in special sections to begin with. I reckon >>> it'd be simpler and more robust to reject unwinding based on the >>> section. If we need to unwind across specific functions in those >>> sections, we could opt-in with some metadata. So e.g. we could reject >>> all functions in ".entry.text", special casing the EL0 entry functions >>> if necessary. > >> Couldn't this also end up being somewhat fragile? Saying "certain >> sections are deemed unreliable" isn't necessarily obvious to somebody >> who doesn't already know about it, and it could be overlooked or >> forgotten over time. And there's no way to enforce it stays that way. > > Anything in this area is going to have some opportunity for fragility > and missed assumptions somewhere. I do find the idea of using the > SYM_CODE annotations that we already have and use for other purposes to > flag code that we don't expect to be suitable for reliable unwinding > appealing from that point of view. It's pretty clear at the points > where they're used that they're needed, even with a pretty surface level > review, and the bit actually pushing things into a section is going to > be in a single place where the macro is defined. That seems relatively > robust as these things go, it seems no worse than our reliance on > SYM_FUNC to create BTI annotations. Missing those causes oopses when we > try to branch to the function. > OK. Just so I am clear on the whole picture, let me state my understanding so far. Correct me if I am wrong. 1. We are hoping that we can convert a significant number of SYM_CODE functions to SYM_FUNC functions by providing them with a proper FP prolog and epilog so that we can get objtool coverage for them. These don't need any blacklisting. 2. If we can locate the pt_regs structures created on the stack cleanly for EL1 exceptions, etc, then we can handle those cases in the unwinder without needing any black listing. I have a solution for this in version 3 that does it without encoding the FP or matching values on the stack. I have addressed all of the objections so far on that count. I will send the patch series out soon. 3. We are going to assume that the reliable unwinder is only for livepatch purposes and will only be invoked on a task that is not currently running. The task either voluntarily gave up the CPU or was pre-empted. We can safely ignore all SYM_CODE functions that will never voluntarily give up the CPU. They can only be pre-empted and pre-emption is already handled in (2). We don't need to blacklist any of these functions. 4. So, the only functions that will need blacklisting are the remaining SYM_CODE functions that might give up the CPU voluntarily. At this point, I am not even sure how many of these will exist. One hopes that all of these would have ended up as SYM_FUNC functions in (1). So, IMHO, placing code in a black listed section should be the last step and not the first one. This also satisfies Mark Rutland's requirement that no one muck with the entry text while he is sorting out that code. I suggest we do (3) first. Then, review the assembly functions to do (1). Then, review the remaining ones to see which ones must be blacklisted, if any. Do you agree? Madhavan
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On Fri, Apr 09, 2021 at 04:37:41PM -0500, Josh Poimboeuf wrote: > On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote: > > Further, I believe all the special cases are assembly functions, and > > most of those are already in special sections to begin with. I reckon > > it'd be simpler and more robust to reject unwinding based on the > > section. If we need to unwind across specific functions in those > > sections, we could opt-in with some metadata. So e.g. we could reject > > all functions in ".entry.text", special casing the EL0 entry functions > > if necessary. > Couldn't this also end up being somewhat fragile? Saying "certain > sections are deemed unreliable" isn't necessarily obvious to somebody > who doesn't already know about it, and it could be overlooked or > forgotten over time. And there's no way to enforce it stays that way. Anything in this area is going to have some opportunity for fragility and missed assumptions somewhere. I do find the idea of using the SYM_CODE annotations that we already have and use for other purposes to flag code that we don't expect to be suitable for reliable unwinding appealing from that point of view. It's pretty clear at the points where they're used that they're needed, even with a pretty surface level review, and the bit actually pushing things into a section is going to be in a single place where the macro is defined. That seems relatively robust as these things go, it seems no worse than our reliance on SYM_FUNC to create BTI annotations. Missing those causes oopses when we try to branch to the function. signature.asc Description: PGP signature
[PATCH v2 0/4] Add support for XMM fast hypercalls
Hyper-V supports the use of XMM registers to perform fast hypercalls. This allows guests to take advantage of the improved performance of the fast hypercall interface even though a hypercall may require more than (the current maximum of) two general purpose registers. The XMM fast hypercall interface uses an additional six XMM registers (XMM0 to XMM5) to allow the caller to pass an input parameter block of up to 112 bytes. Hyper-V can also return data back to the guest in the remaining XMM registers that are not used by the current hypercall. Although the Hyper-v TLFS mentions that a guest cannot use this feature unless the hypervisor advertises support for it, some hypercalls which we plan on upstreaming in future uses them anyway. This patchset adds necessary infrastructure for handling input/output via XMM registers and patches kvm_hv_flush_tlb() to use xmm input arguments. ~ Sid. v2: - Add hc.fast to is_xmm_fast_hypercall() check - Split CPUID feature bits for input and output Siddharth Chandrasekaran (4): KVM: x86: Move FPU register accessors into fpu.h KVM: hyper-v: Collect hypercall params into struct KVM: x86: kvm_hv_flush_tlb use inputs from XMM registers KVM: hyper-v: Advertise support for fast XMM hypercalls arch/x86/include/asm/hyperv-tlfs.h | 7 +- arch/x86/kvm/emulate.c | 138 +++- arch/x86/kvm/fpu.h | 140 + arch/x86/kvm/hyperv.c | 242 +++-- 4 files changed, 327 insertions(+), 200 deletions(-) create mode 100644 arch/x86/kvm/fpu.h -- 2.17.1 Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote: > Hm, for that matter, even without renaming things, a comment above > stack_trace_save_tsk_reliable() describing the meaning of "reliable" > would be a good idea. Might be better to place something at the prototype for arch_stack_walk_reliable() or cross link the two since that's where any new architectures should be starting, or perhaps even better to extend the document that Mark wrote further and point to that from both places. Some more explict pointer to live patching as the only user would definitely be good but I think the more important thing would be writing down any assumptions in the API that aren't already written down and we're supposed to be relying on. Mark's document captured a lot of it but it sounds like there's more here, and even with knowing that this interface is only used by live patch and digging into what it does it's not always clear what happens to work with the code right now and what's something that's suitable to be relied on. signature.asc Description: PGP signature
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On 4/9/21 5:53 PM, Josh Poimboeuf wrote: > On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote: >> On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote: FWIW, over the years we've had zero issues with encoding the frame pointer on x86. After you save pt_regs, you encode the frame pointer to point to it. Ideally in the same macro so it's hard to overlook. >>> >>> I had the same opinion. In fact, in my encoding scheme, I have additional >>> checks to make absolutely sure that it is a true encoding and not stack >>> corruption. The chances of all of those values accidentally matching are, >>> well, null. >> >> Right, stack corruption -- which is already exceedingly rare -- would >> have to be combined with a miracle or two in order to come out of the >> whole thing marked as 'reliable' :-) >> >> And really, we already take a similar risk today by "trusting" the frame >> pointer value on the stack to a certain extent. > > Oh yeah, I forgot to mention some more benefits of encoding the frame > pointer (or marking pt_regs in some other way): > > a) Stack addresses can be printed properly: '%pS' for printing regs->pc >and '%pB' for printing call returns. > >Using '%pS' for call returns (as arm64 seems to do today) will result >in printing the wrong function when you have tail calls to noreturn >functions on the stack (which is actually quite common for calls to >panic(), die(), etc). > >More details: > >https://lkml.kernel.org/r/20210403155948.ubbgtwmlsdyar7yp@treble > > b) Stack dumps to the console can dump the exception registers they find >along the way. This is actually quite nice for debugging. > > Great. I am preparing version 3 taking into account comments from yourself, Mark Rutland and Mark Brown. Stay tuned. Madhavan
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote: > On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote: > > > FWIW, over the years we've had zero issues with encoding the frame > > > pointer on x86. After you save pt_regs, you encode the frame pointer to > > > point to it. Ideally in the same macro so it's hard to overlook. > > > > > > > I had the same opinion. In fact, in my encoding scheme, I have additional > > checks to make absolutely sure that it is a true encoding and not stack > > corruption. The chances of all of those values accidentally matching are, > > well, null. > > Right, stack corruption -- which is already exceedingly rare -- would > have to be combined with a miracle or two in order to come out of the > whole thing marked as 'reliable' :-) > > And really, we already take a similar risk today by "trusting" the frame > pointer value on the stack to a certain extent. Oh yeah, I forgot to mention some more benefits of encoding the frame pointer (or marking pt_regs in some other way): a) Stack addresses can be printed properly: '%pS' for printing regs->pc and '%pB' for printing call returns. Using '%pS' for call returns (as arm64 seems to do today) will result in printing the wrong function when you have tail calls to noreturn functions on the stack (which is actually quite common for calls to panic(), die(), etc). More details: https://lkml.kernel.org/r/20210403155948.ubbgtwmlsdyar7yp@treble b) Stack dumps to the console can dump the exception registers they find along the way. This is actually quite nice for debugging. -- Josh
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote: > > FWIW, over the years we've had zero issues with encoding the frame > > pointer on x86. After you save pt_regs, you encode the frame pointer to > > point to it. Ideally in the same macro so it's hard to overlook. > > > > I had the same opinion. In fact, in my encoding scheme, I have additional > checks to make absolutely sure that it is a true encoding and not stack > corruption. The chances of all of those values accidentally matching are, > well, null. Right, stack corruption -- which is already exceedingly rare -- would have to be combined with a miracle or two in order to come out of the whole thing marked as 'reliable' :-) And really, we already take a similar risk today by "trusting" the frame pointer value on the stack to a certain extent. > >> I think there's a lot more code that we cannot unwind, e.g. KVM > >> exception code, or almost anything marked with SYM_CODE_END(). > > > > Just a reminder that livepatch only unwinds blocked tasks (plus the > > 'current' task which calls into livepatch). So practically speaking, it > > doesn't matter whether the 'unreliable' detection has full coverage. > > The only exceptions which really matter are those which end up calling > > schedule(), e.g. preemption or page faults. > > > > Being able to consistently detect *all* possible unreliable paths would > > be nice in theory, but it's unnecessary and may not be worth the extra > > complexity. > > > > You do have a point. I tried to think of arch_stack_walk_reliable() as > something that should be implemented independent of livepatching. But > I could not really come up with a single example of where else it would > really be useful. > > So, if we assume that the reliable stack trace is solely for the purpose > of livepatching, I agree with your earlier comments as well. One thought: if folks really view this as a problem, it might help to just rename things to reduce confusion. For example, instead of calling it 'reliable', we could call it something more precise, like 'klp_reliable', to indicate that its reliable enough for live patching. Then have a comment above 'klp_reliable' and/or stack_trace_save_tsk_klp_reliable() which describes what that means. Hm, for that matter, even without renaming things, a comment above stack_trace_save_tsk_reliable() describing the meaning of "reliable" would be a good idea. -- Josh
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On 4/9/21 4:37 PM, Josh Poimboeuf wrote: > On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote: >> On Mon, Apr 05, 2021 at 03:43:09PM -0500, madve...@linux.microsoft.com wrote: >>> From: "Madhavan T. Venkataraman" >>> >>> There are a number of places in kernel code where the stack trace is not >>> reliable. Enhance the unwinder to check for those cases and mark the >>> stack trace as unreliable. Once all of the checks are in place, the unwinder >>> can provide a reliable stack trace. But before this can be used for >>> livepatch, >>> some other entity needs to guarantee that the frame pointers are all set up >>> correctly in kernel functions. objtool is currently being worked on to >>> fill that gap. >>> >>> Except for the return address check, all the other checks involve checking >>> the return PC of every frame against certain kernel functions. To do this, >>> implement some infrastructure code: >>> >>> - Define a special_functions[] array and populate the array with >>> the special functions >> >> I'm not too keen on having to manually collate this within the unwinder, >> as it's very painful from a maintenance perspective. > > Agreed. > >> I'd much rather we could associate this information with the >> implementations of these functions, so that they're more likely to >> stay in sync. >> >> Further, I believe all the special cases are assembly functions, and >> most of those are already in special sections to begin with. I reckon >> it'd be simpler and more robust to reject unwinding based on the >> section. If we need to unwind across specific functions in those >> sections, we could opt-in with some metadata. So e.g. we could reject >> all functions in ".entry.text", special casing the EL0 entry functions >> if necessary. > > Couldn't this also end up being somewhat fragile? Saying "certain > sections are deemed unreliable" isn't necessarily obvious to somebody > who doesn't already know about it, and it could be overlooked or > forgotten over time. And there's no way to enforce it stays that way. > Good point! > FWIW, over the years we've had zero issues with encoding the frame > pointer on x86. After you save pt_regs, you encode the frame pointer to > point to it. Ideally in the same macro so it's hard to overlook. > I had the same opinion. In fact, in my encoding scheme, I have additional checks to make absolutely sure that it is a true encoding and not stack corruption. The chances of all of those values accidentally matching are, well, null. > If you're concerned about debuggers getting confused by the encoding - > which debuggers specifically? In my experience, if vmlinux has > debuginfo, gdb and most other debuggers will use DWARF (which is already > broken in asm code) and completely ignore frame pointers. > Yes. I checked gdb actually. It did not show a problem. >> I think there's a lot more code that we cannot unwind, e.g. KVM >> exception code, or almost anything marked with SYM_CODE_END(). > > Just a reminder that livepatch only unwinds blocked tasks (plus the > 'current' task which calls into livepatch). So practically speaking, it > doesn't matter whether the 'unreliable' detection has full coverage. > The only exceptions which really matter are those which end up calling > schedule(), e.g. preemption or page faults. > > Being able to consistently detect *all* possible unreliable paths would > be nice in theory, but it's unnecessary and may not be worth the extra > complexity. > You do have a point. I tried to think of arch_stack_walk_reliable() as something that should be implemented independent of livepatching. But I could not really come up with a single example of where else it would really be useful. So, if we assume that the reliable stack trace is solely for the purpose of livepatching, I agree with your earlier comments as well. Thanks! Madhavan
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote: > On Mon, Apr 05, 2021 at 03:43:09PM -0500, madve...@linux.microsoft.com wrote: > > From: "Madhavan T. Venkataraman" > > > > There are a number of places in kernel code where the stack trace is not > > reliable. Enhance the unwinder to check for those cases and mark the > > stack trace as unreliable. Once all of the checks are in place, the unwinder > > can provide a reliable stack trace. But before this can be used for > > livepatch, > > some other entity needs to guarantee that the frame pointers are all set up > > correctly in kernel functions. objtool is currently being worked on to > > fill that gap. > > > > Except for the return address check, all the other checks involve checking > > the return PC of every frame against certain kernel functions. To do this, > > implement some infrastructure code: > > > > - Define a special_functions[] array and populate the array with > > the special functions > > I'm not too keen on having to manually collate this within the unwinder, > as it's very painful from a maintenance perspective. Agreed. > I'd much rather we could associate this information with the > implementations of these functions, so that they're more likely to > stay in sync. > > Further, I believe all the special cases are assembly functions, and > most of those are already in special sections to begin with. I reckon > it'd be simpler and more robust to reject unwinding based on the > section. If we need to unwind across specific functions in those > sections, we could opt-in with some metadata. So e.g. we could reject > all functions in ".entry.text", special casing the EL0 entry functions > if necessary. Couldn't this also end up being somewhat fragile? Saying "certain sections are deemed unreliable" isn't necessarily obvious to somebody who doesn't already know about it, and it could be overlooked or forgotten over time. And there's no way to enforce it stays that way. FWIW, over the years we've had zero issues with encoding the frame pointer on x86. After you save pt_regs, you encode the frame pointer to point to it. Ideally in the same macro so it's hard to overlook. If you're concerned about debuggers getting confused by the encoding - which debuggers specifically? In my experience, if vmlinux has debuginfo, gdb and most other debuggers will use DWARF (which is already broken in asm code) and completely ignore frame pointers. > I think there's a lot more code that we cannot unwind, e.g. KVM > exception code, or almost anything marked with SYM_CODE_END(). Just a reminder that livepatch only unwinds blocked tasks (plus the 'current' task which calls into livepatch). So practically speaking, it doesn't matter whether the 'unreliable' detection has full coverage. The only exceptions which really matter are those which end up calling schedule(), e.g. preemption or page faults. Being able to consistently detect *all* possible unreliable paths would be nice in theory, but it's unnecessary and may not be worth the extra complexity. -- Josh
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
On 4/9/21 7:09 AM, Mark Rutland wrote: > Hi Madhavan, > > I've noted some concerns below. At a high-level, I'm not keen on the > blacklisting approach, and I think there's some other preparatory work > that would be more valuable in the short term. > Some kind of blacklisting has to be done whichever way you do it. > On Mon, Apr 05, 2021 at 03:43:09PM -0500, madve...@linux.microsoft.com wrote: >> From: "Madhavan T. Venkataraman" >> >> There are a number of places in kernel code where the stack trace is not >> reliable. Enhance the unwinder to check for those cases and mark the >> stack trace as unreliable. Once all of the checks are in place, the unwinder >> can provide a reliable stack trace. But before this can be used for >> livepatch, >> some other entity needs to guarantee that the frame pointers are all set up >> correctly in kernel functions. objtool is currently being worked on to >> fill that gap. >> >> Except for the return address check, all the other checks involve checking >> the return PC of every frame against certain kernel functions. To do this, >> implement some infrastructure code: >> >> - Define a special_functions[] array and populate the array with >>the special functions > > I'm not too keen on having to manually collate this within the unwinder, > as it's very painful from a maintenance perspective. I'd much rather we > could associate this information with the implementations of these > functions, so that they're more likely to stay in sync. > > Further, I believe all the special cases are assembly functions, and > most of those are already in special sections to begin with. I reckon > it'd be simpler and more robust to reject unwinding based on the > section. If we need to unwind across specific functions in those > sections, we could opt-in with some metadata. So e.g. we could reject > all functions in ".entry.text", special casing the EL0 entry functions > if necessary. > Yes. I have already agreed that using sections is the way to go. I am working on that now. > As I mentioned before, I'm currently reworking the entry assembly to > make this simpler to do. I'd prefer to not make invasive changes in that > area until that's sorted. > I don't plan to make any invasive changes. But a couple of cosmetic changes may be necessary. I don't know yet. But I will keep in mind that you don't want any invasive changes there. > I think there's a lot more code that we cannot unwind, e.g. KVM > exception code, or almost anything marked with SYM_CODE_END(). > As Mark Brown suggested, I will take a look at all code that is marked as SYM_CODE. His idea of placing all SYM_CODE in a separate section and blacklisting that to begin with and refining things as we go along appears to me to be a reasonable approach. >> - Using kallsyms_lookup(), lookup the symbol table entries for the >>functions and record their address ranges >> >> - Define an is_reliable_function(pc) to match a return PC against >>the special functions. >> >> The unwinder calls is_reliable_function(pc) for every return PC and marks >> the stack trace as reliable or unreliable accordingly. >> >> Return address check >> >> >> Check the return PC of every stack frame to make sure that it is a valid >> kernel text address (and not some generated code, for example). >> >> Detect EL1 exception frame >> == >> >> EL1 exceptions can happen on any instruction including instructions in >> the frame pointer prolog or epilog. Depending on where exactly they happen, >> they could render the stack trace unreliable. >> >> Add all of the EL1 exception handlers to special_functions[]. >> >> - el1_sync() >> - el1_irq() >> - el1_error() >> - el1_sync_invalid() >> - el1_irq_invalid() >> - el1_fiq_invalid() >> - el1_error_invalid() >> >> Detect ftrace frame >> === >> >> When FTRACE executes at the beginning of a traced function, it creates two >> frames and calls the tracer function: >> >> - One frame for the traced function >> >> - One frame for the caller of the traced function >> >> That gives a sensible stack trace while executing in the tracer function. >> When FTRACE returns to the traced function, the frames are popped and >> everything is back to normal. >> >> However, in cases like live patch, the tracer function redirects execution >> to a different function. When FTRACE returns, control will go to that target >> function. A stack trace taken in the tracer function will not show the target >> function. The target function is the real function that we want to track. >> So, the stack trace is unreliable. > > This doesn't match my understanding of the reliable stacktrace > requirements, but I might have misunderstood what you're saying here. > > IIUC what you're describing here is: > > 1) A calls B > 2) B is traced > 3) tracer replaces B with TARGET > 4) tracer returns to TARGET
[PATCH V2 0/4] Add RTC support for PMIC PMK8350
satya priya (4): rtc: pm8xxx: Add RTC support for PMIC PMK8350 dt-bindings: mfd: Add compatible for pmk8350 rtc dt-bindings: mfd: Convert pm8xxx bindings to yaml dt-bindings: rtc: qcom-pm8xxx-rtc: Add qcom pm8xxx rtc bindings .../devicetree/bindings/mfd/qcom-pm8xxx.txt| 99 -- .../devicetree/bindings/mfd/qcom-pm8xxx.yaml | 54 .../devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml | 62 ++ drivers/rtc/rtc-pm8xxx.c | 11 +++ 4 files changed, 127 insertions(+), 99 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt create mode 100644 Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml create mode 100644 Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
Hi Madhavan, I've noted some concerns below. At a high-level, I'm not keen on the blacklisting approach, and I think there's some other preparatory work that would be more valuable in the short term. On Mon, Apr 05, 2021 at 03:43:09PM -0500, madve...@linux.microsoft.com wrote: > From: "Madhavan T. Venkataraman" > > There are a number of places in kernel code where the stack trace is not > reliable. Enhance the unwinder to check for those cases and mark the > stack trace as unreliable. Once all of the checks are in place, the unwinder > can provide a reliable stack trace. But before this can be used for livepatch, > some other entity needs to guarantee that the frame pointers are all set up > correctly in kernel functions. objtool is currently being worked on to > fill that gap. > > Except for the return address check, all the other checks involve checking > the return PC of every frame against certain kernel functions. To do this, > implement some infrastructure code: > > - Define a special_functions[] array and populate the array with > the special functions I'm not too keen on having to manually collate this within the unwinder, as it's very painful from a maintenance perspective. I'd much rather we could associate this information with the implementations of these functions, so that they're more likely to stay in sync. Further, I believe all the special cases are assembly functions, and most of those are already in special sections to begin with. I reckon it'd be simpler and more robust to reject unwinding based on the section. If we need to unwind across specific functions in those sections, we could opt-in with some metadata. So e.g. we could reject all functions in ".entry.text", special casing the EL0 entry functions if necessary. As I mentioned before, I'm currently reworking the entry assembly to make this simpler to do. I'd prefer to not make invasive changes in that area until that's sorted. I think there's a lot more code that we cannot unwind, e.g. KVM exception code, or almost anything marked with SYM_CODE_END(). > - Using kallsyms_lookup(), lookup the symbol table entries for the > functions and record their address ranges > > - Define an is_reliable_function(pc) to match a return PC against > the special functions. > > The unwinder calls is_reliable_function(pc) for every return PC and marks > the stack trace as reliable or unreliable accordingly. > > Return address check > > > Check the return PC of every stack frame to make sure that it is a valid > kernel text address (and not some generated code, for example). > > Detect EL1 exception frame > == > > EL1 exceptions can happen on any instruction including instructions in > the frame pointer prolog or epilog. Depending on where exactly they happen, > they could render the stack trace unreliable. > > Add all of the EL1 exception handlers to special_functions[]. > > - el1_sync() > - el1_irq() > - el1_error() > - el1_sync_invalid() > - el1_irq_invalid() > - el1_fiq_invalid() > - el1_error_invalid() > > Detect ftrace frame > === > > When FTRACE executes at the beginning of a traced function, it creates two > frames and calls the tracer function: > > - One frame for the traced function > > - One frame for the caller of the traced function > > That gives a sensible stack trace while executing in the tracer function. > When FTRACE returns to the traced function, the frames are popped and > everything is back to normal. > > However, in cases like live patch, the tracer function redirects execution > to a different function. When FTRACE returns, control will go to that target > function. A stack trace taken in the tracer function will not show the target > function. The target function is the real function that we want to track. > So, the stack trace is unreliable. This doesn't match my understanding of the reliable stacktrace requirements, but I might have misunderstood what you're saying here. IIUC what you're describing here is: 1) A calls B 2) B is traced 3) tracer replaces B with TARGET 4) tracer returns to TARGET ... and if a stacktrace is taken at step 3 (before the return address is patched), the trace will show B rather than TARGET. My understanding is that this is legitimate behaviour. > To detect stack traces from a tracer function, add the following to > special_functions[]: > > - ftrace_call + 4 > > ftrace_call is the label at which the tracer function is patched in. So, > ftrace_call + 4 is its return address. This is what will show up in a > stack trace taken from the tracer function. > > When Function Graph Tracing is on, ftrace_graph_caller is patched in > at the label ftrace_graph_call. If a tracer function called before it has > redirected execution as mentioned above, the stack traces taken from within > ftrace_graph_caller will also
[PATCH V2 0/4] Add support for PMK8350 PON_HLOS PMIC peripheral
David Collins (2): input: pm8941-pwrkey: add support for PMK8350 PON_HLOS PMIC peripheral dt-bindings: input: pm8941-pwrkey: add pmk8350 compatible strings satya priya (2): dt-bindings: power: reset: qcom-pon: Convert qcom PON binding to yaml dt-bindings: input: pm8941-pwrkey: Convert pm8941 power key binding to yaml .../bindings/input/qcom,pm8941-pwrkey.txt | 53 --- .../bindings/input/qcom,pm8941-pwrkey.yaml | 88 ++ .../devicetree/bindings/power/reset/qcom,pon.txt | 49 -- .../devicetree/bindings/power/reset/qcom,pon.yaml | 41 drivers/input/misc/pm8941-pwrkey.c | 103 ++--- 5 files changed, 201 insertions(+), 133 deletions(-) delete mode 100644 Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt create mode 100644 Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml delete mode 100644 Documentation/devicetree/bindings/power/reset/qcom,pon.txt create mode 100644 Documentation/devicetree/bindings/power/reset/qcom,pon.yaml -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH V2 0/4] kernel/watchdog: Modify the explanation and doc related to watchdog thread
On Thu 2021-04-01 11:31:30, Wang Qing wrote: > "watchdog/%u" threads has be replaced by cpu_stop_work. The current > description is extremely misleading, so we need to modify the > explanation and documentation related to this. > > Wang Qing (4): > kernel: watchdog: Modify the explanation related to watchdog thread > doc: watchdog: Delete the explanation about "watchdog/%u". > doc: watchdog: Modify the explanation related to watchdog thread > doc: watchdog: Modify the doc related to "watchdog/%u" All four patches make sense to me: Reviewed-by: Petr Mladek Best Regards, Petr
Re: [PATCH v2 0/4] iommu/iova: Add CPU hotplug handler to flush rcaches to core code
On Thu, Mar 25, 2021 at 08:29:57PM +0800, John Garry wrote: > John Garry (4): > iova: Add CPU hotplug handler to flush rcaches > iommu/vt-d: Remove IOVA domain rcache flushing for CPU offlining > iommu: Delete iommu_dma_free_cpu_cached_iovas() > iommu: Stop exporting free_iova_fast() > > drivers/iommu/dma-iommu.c | 9 - > drivers/iommu/intel/iommu.c | 31 --- > drivers/iommu/iova.c| 34 +++--- > include/linux/cpuhotplug.h | 2 +- > include/linux/dma-iommu.h | 8 > include/linux/iova.h| 6 +- > 6 files changed, 33 insertions(+), 57 deletions(-) Okay, newer version. Applied this one instead, thanks.
[PATCH v2 0/4] crypto: add rsa pss support for x509
From: Hongbo Li
This series of patches adds support for x509 cert signed by RSA
with PSS encoding method. RSA PSS is described in rfc8017.
Patch1 make x509 support rsa pss encoding and parse hash parameter.
Patch2 add rsa pss template.
Patch3 add test vector for rsa pss.
Patch4 is the rsa-pss's ima patch.
Test by the following script, it tests different saltlen, hash, mgfhash.
keyctl newring test @u
while :; do
for modbits in 1024 2048 4096; do
if [ $modbits -eq 1024 ]; then
saltlen=(-1 -2 0 20 32 48 64 94)
elif [ $modbits -eq 2048 ]; then
saltlen=(-1 -2 0 20 32 48 64 222)
else
saltlen=(-1 -2 0 20 32 48 64 478)
fi
for slen in ${saltlen[@]}; do
for hash in sha1 sha224 sha256 sha384 sha512; do
for mgfhash in sha1 sha224 sha256 sha384 sha512; do
certfile="cert.der"
echo slen $slen
openssl req \
-x509 \
-${hash} \
-newkey rsa:$modbits \
-keyout key.pem \
-days 365 \
-subj '/CN=test' \
-nodes \
-sigopt rsa_padding_mode:pss \
-sigopt rsa_mgf1_md:$mgfhash \
-sigopt rsa_pss_saltlen:${slen} \
-outform der \
-out ${certfile} 2>/dev/null
exp=0
id=$(keyctl padd asymmetric testkey %keyring:test <
"${certfile}")
rc=$?
if [ $rc -ne $exp ]; then
case "$exp" in
0) echo "Error: Could not load rsa-pss
certificate!";;
esac
echo "modbits $modbits sha: $hash mgfhash $mgfhash
saltlen: $slen"
exit 1
else
case "$rc" in
0) echo "load cert: keyid: $id modbits $modbits
hash: $hash mgfhash $mgfhash saltlen $slen"
esac
fi
done
done
done
done
done
Best Regards
Hongbo
v1->v2:
-rebase patches to cryptodev/master to fix the issues that
reported-by: kernel test robot
Hongbo Li (5):
x509: add support for rsa-pss
crypto: support rsa-pss encoding
crypto: add rsa pss test vector
crypto: ecdsa ima support
ima: add support for rsa pss verification
crypto/Makefile | 7 +-
crypto/asymmetric_keys/Makefile | 7 +-
crypto/asymmetric_keys/public_key.c | 5 ++
crypto/asymmetric_keys/x509_cert_parser.c | 71 -
crypto/rsa.c | 14 ++--
crypto/rsa_helper.c | 127 ++
crypto/testmgr.c | 7 ++
crypto/testmgr.h | 87
include/crypto/internal/rsa.h | 25 +-
include/keys/asymmetric-type.h| 6 ++
include/linux/oid_registry.h | 2 +
security/integrity/digsig_asymmetric.c| 34
12 files changed, 363 insertions(+), 29 deletions(-)
--
1.8.3.1
Re: [PATCH v2 0/4] iommu/iova: Add CPU hotplug handler to flush rcaches to core code
On 25/03/2021 17:53, Will Deacon wrote: On Thu, Mar 25, 2021 at 08:29:57PM +0800, John Garry wrote: The Intel IOMMU driver supports flushing the per-CPU rcaches when a CPU is offlined. Let's move it to core code, so everyone can take advantage. Also throw in a patch to stop exporting free_iova_fast(). Differences to v1: - Add RB tags (thanks!) - Add patch to stop exporting free_iova_fast() - Drop patch to correct comment - Add patch to delete iommu_dma_free_cpu_cached_iovas() and associated changes John Garry (4): iova: Add CPU hotplug handler to flush rcaches iommu/vt-d: Remove IOVA domain rcache flushing for CPU offlining iommu: Delete iommu_dma_free_cpu_cached_iovas() iommu: Stop exporting free_iova_fast() Looks like this is all set for 5.13, so hopefully Joerg can stick it in -next for a bit more exposure. Hi Joerg, Can you kindly consider picking this up now? Thanks, John
[RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
From: "Madhavan T. Venkataraman" There are a number of places in kernel code where the stack trace is not reliable. Enhance the unwinder to check for those cases and mark the stack trace as unreliable. Once all of the checks are in place, the unwinder can provide a reliable stack trace. But before this can be used for livepatch, some other entity needs to guarantee that the frame pointers are all set up correctly in kernel functions. objtool is currently being worked on to fill that gap. Except for the return address check, all the other checks involve checking the return PC of every frame against certain kernel functions. To do this, implement some infrastructure code: - Define a special_functions[] array and populate the array with the special functions - Using kallsyms_lookup(), lookup the symbol table entries for the functions and record their address ranges - Define an is_reliable_function(pc) to match a return PC against the special functions. The unwinder calls is_reliable_function(pc) for every return PC and marks the stack trace as reliable or unreliable accordingly. Return address check Check the return PC of every stack frame to make sure that it is a valid kernel text address (and not some generated code, for example). Detect EL1 exception frame == EL1 exceptions can happen on any instruction including instructions in the frame pointer prolog or epilog. Depending on where exactly they happen, they could render the stack trace unreliable. Add all of the EL1 exception handlers to special_functions[]. - el1_sync() - el1_irq() - el1_error() - el1_sync_invalid() - el1_irq_invalid() - el1_fiq_invalid() - el1_error_invalid() Detect ftrace frame === When FTRACE executes at the beginning of a traced function, it creates two frames and calls the tracer function: - One frame for the traced function - One frame for the caller of the traced function That gives a sensible stack trace while executing in the tracer function. When FTRACE returns to the traced function, the frames are popped and everything is back to normal. However, in cases like live patch, the tracer function redirects execution to a different function. When FTRACE returns, control will go to that target function. A stack trace taken in the tracer function will not show the target function. The target function is the real function that we want to track. So, the stack trace is unreliable. To detect stack traces from a tracer function, add the following to special_functions[]: - ftrace_call + 4 ftrace_call is the label at which the tracer function is patched in. So, ftrace_call + 4 is its return address. This is what will show up in a stack trace taken from the tracer function. When Function Graph Tracing is on, ftrace_graph_caller is patched in at the label ftrace_graph_call. If a tracer function called before it has redirected execution as mentioned above, the stack traces taken from within ftrace_graph_caller will also be unreliable for the same reason as mentioned above. So, add ftrace_graph_caller to special_functions[] as well. Also, the Function Graph Tracer modifies the return address of a traced function to a return trampoline (return_to_handler()) to gather tracing data on function return. Stack traces taken from the traced function and functions it calls will not show the original caller of the traced function. The unwinder handles this case by getting the original caller from FTRACE. However, stack traces taken from the trampoline itself and functions it calls are unreliable as the original return address may not be available in that context. This is because the trampoline calls FTRACE to gather trace data as well as to obtain the actual return address and FTRACE discards the record of the original return address along the way. Add return_to_handler() to special_functions[]. Check for kretprobe === For functions with a kretprobe set up, probe code executes on entry to the function and replaces the return address in the stack frame with a kretprobe trampoline. Whenever the function returns, control is transferred to the trampoline. The trampoline eventually returns to the original return address. A stack trace taken while executing in the function (or in functions that get called from the function) will not show the original return address. Similarly, a stack trace taken while executing in the trampoline itself (and functions that get called from the trampoline) will not show the original return address. This means that the caller of the probed function will not show. This makes the stack trace unreliable. Add the kretprobe trampoline to special_functions[]. Optprobes = Optprobes may be implemented in the future for arm64. For optprobes, the relevant trampoline(s) can be added to
Re: [PATCH v2 0/4] crypto: hisilicon/zip - support new 'sqe' type in Kunpeng930
On Sat, Mar 27, 2021 at 03:28:44PM +0800, Yang Shen wrote: > In Kunpeng930, some field meanings in 'sqe' are changed, so driver need to > distinguish the type on different platform. > > To avoid checking the platform everytime when driver fills the 'sqe', add a > struct 'hisi_zip_sqe_ops' to describe the 'sqe' operations. The driver only > need to choose the 'ops' once when call 'hisi_zip_acomp_init'. > > v1 -> v2: > * fix a sparse warning > > Yang Shen (4): > crypto: hisilicon/zip - adjust functions location > crypto: hisilicon/zip - add comments for 'hisi_zip_sqe' > crypto: hisilicon/zip - initialize operations about 'sqe' in > 'acomp_alg.init' > crypto: hisilicon/zip - support new 'sqe' type in Kunpeng930 > > drivers/crypto/hisilicon/zip/zip.h| 46 +- > drivers/crypto/hisilicon/zip/zip_crypto.c | 706 > +- > 2 files changed, 438 insertions(+), 314 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH V2 0/4] kernel/watchdog: Modify the explanation and doc related to watchdog thread
"watchdog/%u" threads has be replaced by cpu_stop_work. The current description is extremely misleading, so we need to modify the explanation and documentation related to this. Wang Qing (4): kernel: watchdog: Modify the explanation related to watchdog thread doc: watchdog: Delete the explanation about "watchdog/%u". doc: watchdog: Modify the explanation related to watchdog thread doc: watchdog: Modify the doc related to "watchdog/%u" .../admin-guide/kernel-per-CPU-kthreads.rst | 20 Documentation/admin-guide/lockup-watchdogs.rst | 4 ++-- Documentation/admin-guide/sysctl/kernel.rst | 10 +- kernel/watchdog.c| 12 4 files changed, 11 insertions(+), 35 deletions(-) -- 2.7.4
[PATCH v2 0/4] drm/msm: Shrinker (and related) fixes
From: Rob Clark I've been spending some time looking into how things behave under high memory pressure. The first patch is a random cleanup I noticed along the way. The second improves the situation significantly when we are getting shrinker called from many threads in parallel. And the last two are $debugfs/gem fixes I needed so I could monitor the state of GEM objects (ie. how many are active/purgable/purged) while triggering high memory pressure. We could probably go a bit further with dropping the mm_lock in the shrinker->scan() loop, but this is already a pretty big improvement. The next step is probably actually to add support to unpin/evict inactive objects. (We are part way there since we have already de- coupled the iova lifetime from the pages lifetime, but there are a few sharp corners to work through.) Rob Clark (4): drm/msm: Remove unused freed llist node drm/msm: Avoid mutex in shrinker_count() drm/msm: Fix debugfs deadlock drm/msm: Improved debugfs gem stats drivers/gpu/drm/msm/msm_debugfs.c | 14 ++--- drivers/gpu/drm/msm/msm_drv.c | 4 ++ drivers/gpu/drm/msm/msm_drv.h | 15 -- drivers/gpu/drm/msm/msm_fb.c | 3 +- drivers/gpu/drm/msm/msm_gem.c | 65 ++- drivers/gpu/drm/msm/msm_gem.h | 72 +++--- drivers/gpu/drm/msm/msm_gem_shrinker.c | 28 -- 7 files changed, 150 insertions(+), 51 deletions(-) -- 2.30.2
[PATCH v2 0/4] MIPS: Remove get_fs/set_fs
This series replaces get_fs/set_fs and removes it from MIPS arch code. Changes in v2: - added copy_from_kernel_nofault_allowed() for !EVA to restrict access of __get/__put_kernel_nofault - replaced __get_data macro by helper functions - removed leftover set_fs calls in ftrace.c - further cleanup uaccess.h Thomas Bogendoerfer (4): MIPS: kernel: Remove not needed set_fs calls MIPS: uaccess: Added __get/__put_kernel_nofault MIPS: uaccess: Remove get_fs/set_fs call sites MIPS: Remove get_fs/set_fs arch/mips/Kconfig | 1 - arch/mips/include/asm/processor.h | 4 - arch/mips/include/asm/thread_info.h | 6 - arch/mips/include/asm/uaccess.h | 436 +++- arch/mips/kernel/access-helper.h| 53 arch/mips/kernel/asm-offsets.c | 1 - arch/mips/kernel/ftrace.c | 8 - arch/mips/kernel/process.c | 2 - arch/mips/kernel/scall32-o32.S | 4 +- arch/mips/kernel/traps.c| 105 +++ arch/mips/kernel/unaligned.c| 199 + arch/mips/lib/memcpy.S | 28 +- arch/mips/lib/memset.S | 3 - arch/mips/lib/strncpy_user.S| 48 +-- arch/mips/lib/strnlen_user.S| 44 +-- arch/mips/mm/Makefile | 4 + arch/mips/mm/maccess.c | 10 + 17 files changed, 392 insertions(+), 564 deletions(-) create mode 100644 arch/mips/kernel/access-helper.h create mode 100644 arch/mips/mm/maccess.c -- 2.29.2
[PATCH v2 0/4] Add peripheral support to imx8mq-nitrogen board
Hi, this patch set aims is to add support of multiple peripheral of the Boundary8M board: - USB Host; - USB device; - DB_DSIHD sub board for MIPI-DSI to HDMI output (via lt8912b chip). Updates in v2: - Use a GPIO hog to handle the USB HOST reset line; - Remove useless GPIO hog for lt8912b. Thanks, Adrien Grassein (4): arm64: dts: imx8mq-nitrogen: add USB OTG support arm64: dts: imx8mq-nitrogen: add USB HOST support arm64: dts: imx8mq-nitrogen: add lt8912 MIPI-DSI to HDMI arm64: defconfig: Enable LT8912B DRM bridge driver .../boot/dts/freescale/imx8mq-nitrogen.dts| 185 ++ arch/arm64/configs/defconfig | 1 + 2 files changed, 186 insertions(+) -- 2.25.1
[PATCH V2 0/4] remoteproc: imx: support remote cores booted early
From: Peng Fan V2: Patch [1,3]/4 is new Patch 4/4: Update commit message, drop unneeded code that already implemented by core This patchset is to support booted remote cores could be attached to linux. - Add missing of_node_put to decrease device node refcount - Enlarge IMX7D_RPROC_MEM_MAX because need more imx_rproc_mem, such as resource table. - Following stm32 remoteproc practice, move memory parsing to rproc_ops - Support attaching booted cores, by adding attach, get loaded resource table and etc. Peng Fan (4): remoteproc: imx: add missing of_node_put remoteproc: imx_rproc: enlarge IMX7D_RPROC_MEM_MAX remoteproc: imx: move memory parsing to rproc_ops remoteproc: imx_rproc: support remote cores booted before Linux Kernel drivers/remoteproc/imx_rproc.c | 65 -- 1 file changed, 55 insertions(+), 10 deletions(-) -- 2.30.0
[PATCH v2 0/4] cxl/mem: Fix memdev device setup
Changes since v1: [1] - switch percpu_ref to srcu (Jason) - introduce cxl_memdev_alloc() (Jason) [1]: http://lore.kernel.org/r/161661970558.1721612.10441826898835759137.st...@dwillia2-desk3.amr.corp.intel.com --- A small collection of fixes mostly inspired by Jason's recognition of dev_set_name() error handling mistakes on other driver review. dev_set_name() can fail and although device_add() might catch it that's not a reliable assumption. While fixing that I noticed that the unwind handling for cdev_device_add() failures leaked the device name. The sysfs_emit() fixup and unpublishing of device power management files are just sanity cleanups. --- Dan Williams (4): cxl/mem: Use sysfs_emit() for attribute show routines cxl/mem: Fix synchronization mechanism for device removal vs ioctl operations cxl/mem: Do not rely on device_add() side effects for dev_set_name() failures cxl/mem: Disable cxl device power management drivers/cxl/mem.c | 127 +++-- 1 file changed, 75 insertions(+), 52 deletions(-) base-commit: a38fd8748464831584a19438cbb3082b5a2dab15
[PATCH v2 0/4] Add Ampere's Altra SMPro hwmon driver
This patch series adds support for Ampere SMpro hwmon driver. This driver supports accessing various CPU sensors provided by the SMpro co-processor including temperature, power, voltages, and current found on Ampere Altra processor family. v2: + Used 'struct of_device_id's .data attribute [Lee Jones] + Removed "virtual" sensors [Guenter] + Fixed typo "mili" to "milli", "nanoWatt" to "microWatt" [Guenter] + Reported SOC_TDP as "Socket TDP" using max attributes [Guenter] + Clarified "highest" meaning in documentation [Guenter] + Corrected return error code when host is turn off [Guenter] + Reported MEM HOT Threshold for all DIMMs as temp*_crit [Guenter] + Removed license info as SPDX-License-Identifier existed [Guenter] + Added is_visible() support [Guenter] + Used HWMON_CHANNEL_INFO() macro and LABEL attributes [Guenter] + Made is_valid_id() return boolean [Guenter] + Returned -EPROBE_DEFER when smpro reg inaccessible [Guenter] + Removed unnecessary error message when dev register fail [Guenter] + Removed Socket TDP sensor [Quan] + Changed "ampere,ac01-smpro" to "ampere,smpro" [Quan] + Included sensor type and channel in labels [Quan] + Refactorized code to fix checkpatch.pl --strict complaint [Quan] Quan Nguyen (4): dt-bindings: mfd: Add bindings for Ampere Altra SMPro drivers mfd: simple-mfd-i2c: Adds Ampere's Altra SMpro support hwmon: smpro: Add Ampere's Altra smpro-hwmon driver docs: hwmon: (smpro-hwmon) Add documentation .../bindings/hwmon/ampere,ac01-hwmon.yaml | 27 + .../devicetree/bindings/mfd/ampere,smpro.yaml | 82 +++ Documentation/hwmon/index.rst | 1 + Documentation/hwmon/smpro-hwmon.rst | 101 drivers/hwmon/Kconfig | 8 + drivers/hwmon/Makefile| 1 + drivers/hwmon/smpro-hwmon.c | 494 ++ drivers/mfd/Kconfig | 10 + drivers/mfd/simple-mfd-i2c.c | 6 + 9 files changed, 730 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml create mode 100644 Documentation/devicetree/bindings/mfd/ampere,smpro.yaml create mode 100644 Documentation/hwmon/smpro-hwmon.rst create mode 100644 drivers/hwmon/smpro-hwmon.c -- 2.28.0
[PATCH v2 0/4] erofs: introduce on-disk compression configurations
From: Gao Xiang Hi folks, When we provides support for different algorithms or big pcluster, it'd be necessary to record some configuration in the per-fs basis. For example, when big pcluster feature for lz4 is enabled, we need to know the largest pclustersize in the whole fs instance to adjust per-CPU buffers in advance, which will be used to handle in-place decompression failure for inplace IO then. And we also need to record global arguments (e.g. dict_size) for the upcoming LZMA algorithm support. Therefore, this patchset introduces a new INCOMPAT feature called COMPR_CFGS, which provides an available algorithm bitmap in the sb and a variable array list to store corresponding arguments for each available algorithms. Since such a INCOMPAT sb feature will be introduced, it'd be better to reuse such bit for BIGPCLUSTER feature as well since BIGPCLUSTER feature depends on COMPR_CFGS and will be released together with COMPR_CFGS. If COMPR_CFGS is disabled, the field of available algorithm bitmap would become a lz4_max_distance (which is now reserved as 0), and max_distance can be safely ignored for old kernels since 64k lz4 dictionary is always enough even new images could reduce the sliding window. Thanks, Gao Xiang Changes since v1: - [2/4] add a comment on lz4_max_distance (Chao); - [4/4] fix a misplaced label (Chao); - [4/4] enable COMPR_CFGS with BIG_PCLUSTER later since they share the same bit. Gao Xiang (3): erofs: introduce erofs_sb_has_xxx() helpers erofs: introduce on-disk lz4 fs configurations erofs: add on-disk compression configurations Huang Jianan (1): erofs: support adjust lz4 history window size fs/erofs/decompressor.c | 35 -- fs/erofs/erofs_fs.h | 20 +- fs/erofs/internal.h | 33 + fs/erofs/super.c| 147 +++- 4 files changed, 224 insertions(+), 11 deletions(-) -- 2.20.1
[PATCH v2 0/4] crypto: hisilicon/zip - support new 'sqe' type in Kunpeng930
In Kunpeng930, some field meanings in 'sqe' are changed, so driver need to distinguish the type on different platform. To avoid checking the platform everytime when driver fills the 'sqe', add a struct 'hisi_zip_sqe_ops' to describe the 'sqe' operations. The driver only need to choose the 'ops' once when call 'hisi_zip_acomp_init'. v1 -> v2: * fix a sparse warning Yang Shen (4): crypto: hisilicon/zip - adjust functions location crypto: hisilicon/zip - add comments for 'hisi_zip_sqe' crypto: hisilicon/zip - initialize operations about 'sqe' in 'acomp_alg.init' crypto: hisilicon/zip - support new 'sqe' type in Kunpeng930 drivers/crypto/hisilicon/zip/zip.h| 46 +- drivers/crypto/hisilicon/zip/zip_crypto.c | 706 +- 2 files changed, 438 insertions(+), 314 deletions(-) -- 2.8.1
Re: [PATCH v2 0/4] iommu/iova: Add CPU hotplug handler to flush rcaches to core code
On Thu, Mar 25, 2021 at 08:29:57PM +0800, John Garry wrote: > The Intel IOMMU driver supports flushing the per-CPU rcaches when a CPU is > offlined. > > Let's move it to core code, so everyone can take advantage. > > Also throw in a patch to stop exporting free_iova_fast(). > > Differences to v1: > - Add RB tags (thanks!) > - Add patch to stop exporting free_iova_fast() > - Drop patch to correct comment > - Add patch to delete iommu_dma_free_cpu_cached_iovas() and associated > changes > > John Garry (4): > iova: Add CPU hotplug handler to flush rcaches > iommu/vt-d: Remove IOVA domain rcache flushing for CPU offlining > iommu: Delete iommu_dma_free_cpu_cached_iovas() > iommu: Stop exporting free_iova_fast() Looks like this is all set for 5.13, so hopefully Joerg can stick it in -next for a bit more exposure. Will
Re: [PATCH v2 0/4] vmalloc: Improve vmalloc(4MB) performance
On Thu, Mar 25, 2021 at 03:59:56PM +, David Laight wrote: > Even then it is probably better to use a typed pointer thank you for expressing your opinion
RE: [PATCH v2 0/4] vmalloc: Improve vmalloc(4MB) performance
From: Matthew Wilcox > Sent: 24 March 2021 15:05 > > I may have gone a little too far with the first patch. It turns out we > have a lot of code using the vmalloc caller functionality, and I decided > to convert it all to unsigned long instead of leaving some paths as void * > and casting later. What is the 'address of the caller' needed for? If it gets printed anywhere it ought to be a pointer type throughout so that it will get hashed and not leak the real address. Even then it is probably better to use a typed pointer (eg to an undefined structure) than 'void *'. That might also pick up more incorrect uses. Of course things like _RET_IP_ would need changing to return the same pointer type. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[PATCH v2 0/4] iommu/iova: Add CPU hotplug handler to flush rcaches to core code
The Intel IOMMU driver supports flushing the per-CPU rcaches when a CPU is offlined. Let's move it to core code, so everyone can take advantage. Also throw in a patch to stop exporting free_iova_fast(). Differences to v1: - Add RB tags (thanks!) - Add patch to stop exporting free_iova_fast() - Drop patch to correct comment - Add patch to delete iommu_dma_free_cpu_cached_iovas() and associated changes John Garry (4): iova: Add CPU hotplug handler to flush rcaches iommu/vt-d: Remove IOVA domain rcache flushing for CPU offlining iommu: Delete iommu_dma_free_cpu_cached_iovas() iommu: Stop exporting free_iova_fast() drivers/iommu/dma-iommu.c | 9 - drivers/iommu/intel/iommu.c | 31 --- drivers/iommu/iova.c| 34 +++--- include/linux/cpuhotplug.h | 2 +- include/linux/dma-iommu.h | 8 include/linux/iova.h| 6 +- 6 files changed, 33 insertions(+), 57 deletions(-) -- 2.26.2
[PATCH v2 0/4] vmalloc: Improve vmalloc(4MB) performance
I may have gone a little too far with the first patch. It turns out we have a lot of code using the vmalloc caller functionality, and I decided to convert it all to unsigned long instead of leaving some paths as void * and casting later. I can redo that if necessary. I've tested arm32, sh4 and powerpc32 builds as well as x86, but I wouldn't be surprised if the buildbots tell me I missed something. Matthew Wilcox (Oracle) (4): mm/vmalloc: Change the 'caller' type to unsigned long mm/util: Add kvmalloc_node_caller mm/vmalloc: Use kvmalloc to allocate the table of pages MAINTAINERS: Add Vlad Rezki as vmalloc maintainer MAINTAINERS | 7 +++ arch/arm/include/asm/io.h | 6 +-- arch/arm/include/asm/mach/map.h | 3 -- arch/arm/kernel/module.c | 4 +- arch/arm/mach-imx/mm-imx3.c | 2 +- arch/arm/mach-ixp4xx/common.c | 2 +- arch/arm/mach-mvebu/coherency.c | 2 +- arch/arm/mm/ioremap.c | 27 +-- arch/arm/mm/mmu.c | 10 ++-- arch/arm/mm/nommu.c | 16 +++--- arch/arm64/include/asm/vmap_stack.h | 2 +- arch/arm64/kernel/module.c| 5 +- arch/arm64/kernel/probes/kprobes.c| 2 +- arch/arm64/mm/ioremap.c | 7 ++- arch/arm64/mm/mmu.c | 2 +- arch/arm64/net/bpf_jit_comp.c | 3 +- arch/mips/kernel/module.c | 2 +- arch/nds32/kernel/module.c| 2 +- arch/parisc/kernel/module.c | 5 +- arch/powerpc/include/asm/io-workarounds.h | 2 +- arch/powerpc/include/asm/io.h | 6 +-- arch/powerpc/kernel/io-workarounds.c | 2 +- arch/powerpc/kernel/irq.c | 2 +- arch/powerpc/kernel/module.c | 3 +- arch/powerpc/kernel/pci_64.c | 3 +- arch/powerpc/mm/ioremap.c | 10 ++-- arch/powerpc/mm/ioremap_32.c | 8 +-- arch/powerpc/mm/ioremap_64.c | 4 +- arch/riscv/kernel/module.c| 2 +- arch/riscv/net/bpf_jit_comp64.c | 2 +- arch/s390/kernel/module.c | 2 +- arch/s390/kernel/setup.c | 3 +- arch/sh/include/asm/io.h | 11 ++--- arch/sh/kernel/cpu/sh4/sq.c | 2 +- arch/sh/mm/ioremap.c | 2 +- arch/sh/mm/pmb.c | 2 +- arch/sparc/kernel/module.c| 2 +- arch/x86/hyperv/hv_init.c | 3 +- arch/x86/kernel/module.c | 3 +- arch/x86/mm/ioremap.c | 20 include/linux/mm.h| 4 +- include/linux/slab.h | 2 + include/linux/vmalloc.h | 22 - kernel/bpf/syscall.c | 2 +- kernel/fork.c | 2 +- kernel/module.c | 2 +- kernel/scs.c | 3 +- lib/test_vmalloc.c| 7 ++- mm/ioremap.c | 3 +- mm/kasan/shadow.c | 5 +- mm/nommu.c| 4 +- mm/util.c | 52 +++- mm/vmalloc.c | 59 +-- 53 files changed, 172 insertions(+), 198 deletions(-) -- 2.30.2
Re: [PATCH v2 0/4] drm/bridge: ti-sn65dsi86: Support EDID reading
Quoting Laurent Pinchart (2021-03-22 17:00:23) > Hi Stephen, > > On Mon, Nov 02, 2020 at 05:15:24PM -0800, Stephen Boyd wrote: > > Quoting Sam Ravnborg (2020-11-01 09:37:41) > > > Hi Stephen. > > > > > > On Thu, Oct 29, 2020 at 06:17:34PM -0700, Stephen Boyd wrote: > > > > This patch series cleans up the DDC code a little bit so that > > > > it is more efficient time wise and supports grabbing the EDID > > > > of the eDP panel over the aux channel. I timed this on a board > > > > I have on my desk and it takes about 20ms to grab the EDID out > > > > of the panel and make sure it is valid. > > > > > > > > The first two patches seem less controversial so I stuck them at > > > > the beginning. The third patch does the EDID reading and caches > > > > it so we don't have to keep grabbing it over and over again. And > > > > finally the last patch updates the reply field so that short > > > > reads and nacks over the channel are reflected properly instead of > > > > treating them as some sort of error that can't be discerned. > > > > > > > > Stephen Boyd (4): > > > > drm/bridge: ti-sn65dsi86: Combine register accesses in > > > > ti_sn_aux_transfer() > > > > drm/bridge: ti-sn65dsi86: Make polling a busy loop > > > > drm/bridge: ti-sn65dsi86: Read EDID blob over DDC > > > > drm/bridge: ti-sn65dsi86: Update reply on aux failures > > > > > > Series looks good. You can add my a-b on the full series. > > > Acked-by: Sam Ravnborg > > > > > > I can apply after Douglas have had a look at the patches he did not r-b > > > yet. > > > > > > Any chance we can convince you to prepare this bridge driver for use in > > > a chained bridge setup where the connector is created by the display > > > driver and uses drm_bridge_funcs? > > > > > > First step wuld be to introduce the use of a panel_bridge. > > > Then add get_edid to drm_bridge_funcs and maybe more helpers. > > > > > > Then natural final step would be to move connector creation to the > > > display driver - see how other uses drm_bridge_connector_init() to do so > > > - it is relatively simple. > > > > > > Should be doable - and reach out if you need some help. > > > > I started to look at this and got stuck at ti_sn_bridge_get_bpp(). Where > > can I get the details of the bpc for the downstream bridge or panel? Is > > there some function that can tell this bridge what the bpc is for the > > attached connector? > > I've posted a patch series to convert to DRM_BRIDGE_ATTACH_NO_CONNECTOR > yesterday (and have CC'ed you), but I've overlooked this particular > problem :-S ! > > You can't get the connector in the .enable() operation, but you can get > it in .atomic_enable(), with > drm_atomic_get_new_connector_for_encoder(). This being said, it's > probably not the right option. > > What matters here isn't the bpc for the connector, but the format > expected by the next bridge in the chain. drm_bridge_funcs has two > operations, .atomic_get_output_bus_fmts() and > .atomic_get_input_bus_fmts(), to negotiate that format along a chain of > bridges. The panel bridge driver (drivers/gpu/drm/bridge/panel.c) > doesn't implement those operations, and neither does > display-connector.c, so that may be what we should start with. Ok, makes sense. I'd gladly test things out if you come up with some solution here.
Re: [PATCH v2 0/4] drm/bridge: ti-sn65dsi86: Support EDID reading
Hi Stephen, On Mon, Nov 02, 2020 at 05:15:24PM -0800, Stephen Boyd wrote: > Quoting Sam Ravnborg (2020-11-01 09:37:41) > > Hi Stephen. > > > > On Thu, Oct 29, 2020 at 06:17:34PM -0700, Stephen Boyd wrote: > > > This patch series cleans up the DDC code a little bit so that > > > it is more efficient time wise and supports grabbing the EDID > > > of the eDP panel over the aux channel. I timed this on a board > > > I have on my desk and it takes about 20ms to grab the EDID out > > > of the panel and make sure it is valid. > > > > > > The first two patches seem less controversial so I stuck them at > > > the beginning. The third patch does the EDID reading and caches > > > it so we don't have to keep grabbing it over and over again. And > > > finally the last patch updates the reply field so that short > > > reads and nacks over the channel are reflected properly instead of > > > treating them as some sort of error that can't be discerned. > > > > > > Stephen Boyd (4): > > > drm/bridge: ti-sn65dsi86: Combine register accesses in > > > ti_sn_aux_transfer() > > > drm/bridge: ti-sn65dsi86: Make polling a busy loop > > > drm/bridge: ti-sn65dsi86: Read EDID blob over DDC > > > drm/bridge: ti-sn65dsi86: Update reply on aux failures > > > > Series looks good. You can add my a-b on the full series. > > Acked-by: Sam Ravnborg > > > > I can apply after Douglas have had a look at the patches he did not r-b > > yet. > > > > Any chance we can convince you to prepare this bridge driver for use in > > a chained bridge setup where the connector is created by the display > > driver and uses drm_bridge_funcs? > > > > First step wuld be to introduce the use of a panel_bridge. > > Then add get_edid to drm_bridge_funcs and maybe more helpers. > > > > Then natural final step would be to move connector creation to the > > display driver - see how other uses drm_bridge_connector_init() to do so > > - it is relatively simple. > > > > Should be doable - and reach out if you need some help. > > I started to look at this and got stuck at ti_sn_bridge_get_bpp(). Where > can I get the details of the bpc for the downstream bridge or panel? Is > there some function that can tell this bridge what the bpc is for the > attached connector? I've posted a patch series to convert to DRM_BRIDGE_ATTACH_NO_CONNECTOR yesterday (and have CC'ed you), but I've overlooked this particular problem :-S You can't get the connector in the .enable() operation, but you can get it in .atomic_enable(), with drm_atomic_get_new_connector_for_encoder(). This being said, it's probably not the right option. What matters here isn't the bpc for the connector, but the format expected by the next bridge in the chain. drm_bridge_funcs has two operations, .atomic_get_output_bus_fmts() and .atomic_get_input_bus_fmts(), to negotiate that format along a chain of bridges. The panel bridge driver (drivers/gpu/drm/bridge/panel.c) doesn't implement those operations, and neither does display-connector.c, so that may be what we should start with. > I see that td_mode_valid() in > drivers/gpu/drm/bridge/tc358775.c stores away the bpc from the incoming > drm_display_info pointer but I'm not sure that is correct because can't > that be called for various and not necessarily the one we're using? You're right, .mode_valid() shouldn't do that. -- Regards, Laurent Pinchart
[PATCH v2 0/4] KVM: x86: MSR filtering and related fixes
Rework the MSR filtering implementation to treat a given filter instance as an atomic unit, and to properly protect it with SRCU. Fix two nVMX bugs related to MSR filtering (one directly, one indirectly), and additional cleanup on top. Regarding the macro insanity in patch 03, I verified the before and after binary output for vmx_set_intercept_for_msr() was identical, again. This required wrapping "if (msr <= 0x1fff)" with (un)likely in both the before and after versions; gcc made seemingly random choices without forcing it to favor a specific branch. v2: - Collect R-b. [Paolo, Alex]. - Make the macro insanity slightly less insane. [Paolo] v1: https://lkml.kernel.org/r/20210316184436.2544875-1-sea...@google.com Sean Christopherson (4): KVM: x86: Protect userspace MSR filter with SRCU, and set atomically-ish KVM: nVMX: Handle dynamic MSR intercept toggling KVM: VMX: Macrofy the MSR bitmap getters and setters KVM: nVMX: Clean up x2APIC MSR handling for L2 Documentation/virt/kvm/api.rst | 6 +- arch/x86/include/asm/kvm_host.h | 17 ++-- arch/x86/kvm/vmx/nested.c | 161 +--- arch/x86/kvm/vmx/vmx.c | 67 + arch/x86/kvm/vmx/vmx.h | 28 ++ arch/x86/kvm/x86.c | 109 - 6 files changed, 172 insertions(+), 216 deletions(-) -- 2.31.0.rc2.261.g7f71774620-goog
[PATCH v2 0/4] clk: ti: add am33xx spread spectrum clock support
As reported by the TI spruh73x RM, MPU and LCD modules support spread spectrum clocking (SSC) on their output clocks. SSC is used to spread the spectral peaking of the clock to reduce any electromagnetic interference (EMI) that may be caused due to the clock’s fundamental or any of its harmonics. The series allows you to enable and adjust the spread spectrum clocking for all am33xx PLLs for which it is supported. Changes in v2: - Remove SSC registers from dpll_core_ck@490 node (SSC is not supported) - Add SSC registers to dpll_mpu_ck@488 node. - Move the DT changes to the previous patch in the series. Dario Binacchi (4): clk: ti: fix typo in routine description dt-bindings: ti: dpll: add spread spectrum support ARM: dts: am33xx-clocks: add spread spectrum support clk: ti: add am33xx spread spectrum clock support .../devicetree/bindings/clock/ti/dpll.txt | 20 + arch/arm/boot/dts/am33xx-clocks.dtsi | 4 +- drivers/clk/ti/dpll.c | 41 + drivers/clk/ti/dpll3xxx.c | 87 ++- include/linux/clk/ti.h| 24 + 5 files changed, 173 insertions(+), 3 deletions(-) -- 2.17.1
[PATCH v2 0/4] Make UTF-8 encoding loadable
utf8data.h_shipped has a large database table which is an auto-generated
decodification trie for the unicode normalization functions and it is not
necessary to carry this large table in the kernel.
Goal is to make UTF-8 encoding loadable by converting it into a module
and adding a layer between the filesystems and the utf8 module which will
load the module whenever any filesystem that needs unicode is mounted.
Unicode is the subsystem and utf8 is a charachter encoding for the
subsystem, hence first two patches in the series are renaming functions
and file name to unicode for better understanding the difference between
UTF-8 module and unicode layer.
3rd patch resolves the warning reported by kernel test robot.
Last patch in the series adds the layer and utf8 module.
---
Changes in v2
- Remove the duplicate file from the last patch.
- Make the wrapper functions inline.
- Remove msleep and use try_module_get() and module_put()
for ensuring that module is loaded correctly and also
doesn't get unloaded while in use.
- Resolve the warning reported by kernel test robot.
- Resolve all the checkpatch.pl warnings.
Shreeya Patel (4):
fs: unicode: Rename function names from utf8 to unicode
fs: unicode: Rename utf8-core file to unicode-core
fs: unicode: Use strscpy() instead of strncpy()
fs: unicode: Add utf8 module and a unicode layer
fs/ext4/hash.c| 2 +-
fs/ext4/namei.c | 12 ++--
fs/ext4/super.c | 6 +-
fs/f2fs/dir.c | 12 ++--
fs/f2fs/super.c | 6 +-
fs/libfs.c| 6 +-
fs/unicode/Kconfig| 11 +++-
fs/unicode/Makefile | 5 +-
fs/unicode/unicode-core.c | 60
fs/unicode/utf8-selftest.c| 8 +--
fs/unicode/{utf8-core.c => utf8mod.c} | 80 +++
include/linux/unicode.h | 77 --
12 files changed, 206 insertions(+), 79 deletions(-)
create mode 100644 fs/unicode/unicode-core.c
rename fs/unicode/{utf8-core.c => utf8mod.c} (68%)
--
2.30.1
Re: [PATCH v2 0/4] Misc vSVA fixes for VT-d
On Tue, Mar 02, 2021 at 02:13:56AM -0800, Jacob Pan wrote: > Hi Baolu et al, > > This is a collection of SVA-related fixes. > > ChangeLog: > > v2: > - For guest SVA, call pasid_set_wpe directly w/o checking host CR0.wp > (Review comments by Kevin T.) > - Added fixes tag > > Thanks, > > Jacob > > Jacob Pan (4): > iommu/vt-d: Enable write protect for supervisor SVM > iommu/vt-d: Enable write protect propagation from guest > iommu/vt-d: Reject unsupported page request modes > iommu/vt-d: Calculate and set flags for handle_mm_fault > > drivers/iommu/intel/pasid.c | 29 + > drivers/iommu/intel/svm.c | 21 + > include/uapi/linux/iommu.h | 3 ++- > 3 files changed, 48 insertions(+), 5 deletions(-) Applied, thanks.
[PATCH v2 0/4] Fix RCU warnings in TDP MMU
The Linux Test Robot found a few RCU warnings in the TDP MMU: https://www.spinics.net/lists/kernel/msg3845500.html https://www.spinics.net/lists/kernel/msg3845521.html Fix these warnings and cleanup a hack in tdp_mmu_iter_cond_resched. Tested by compiling as suggested in the test robot report and confirmed that the warnings go away with this series applied. Also ran kvm-unit-tests on an Intel Skylake machine with the TDP MMU enabled and confirmed that the series introduced no new failures. Ben Gardon (4): KVM: x86/mmu: Fix RCU usage in handle_removed_tdp_mmu_page KVM: x86/mmu: Fix RCU usage when atomically zapping SPTEs KVM: x86/mmu: Factor out tdp_iter_return_to_root KVM: x86/mmu: Store the address space ID in the TDP iterator arch/x86/kvm/mmu/mmu_internal.h | 5 + arch/x86/kvm/mmu/tdp_iter.c | 30 +++-- arch/x86/kvm/mmu/tdp_iter.h | 4 +++- arch/x86/kvm/mmu/tdp_mmu.c | 40 + 4 files changed, 41 insertions(+), 38 deletions(-) -- 2.31.0.rc2.261.g7f71774620-goog
[PATCH v2 0/4] ALSA: hda/cirrus: Make CS8409 driver more generic by using fixups
This series of patches will address comments by Pierre-Louis Bossart, cleans up patch_cirrus.c source, reducing checkpatch.pl warnings from 19 to 0, fixing an issue reported by Canonical: BugLink: https://bugs.launchpad.net/bugs/1918378, and makes the CS8409 patch more generic by using fixups. Stefan Binding (4): ALSA: hda/cirrus: Add error handling into CS8409 I2C functions ALSA: hda/cirrus: Cleanup patch_cirrus.c code. ALSA: hda/cirrus: Fix CS42L42 Headset Mic volume control name ALSA: hda/cirrus: Make CS8409 driver more generic by using fixups. sound/pci/hda/patch_cirrus.c | 525 --- 1 file changed, 242 insertions(+), 283 deletions(-) -- 2.25.1
[PATCH v2 0/4] arm64: dts: renesas: Enable GMSL on R8A77970 V3M Eagle
Hello, this series adds a .dtsi fragment that allow to describe and enable GMSL cameras on the V3M Eagle board. The .dtsi supports connecting the RDACM20 and RDACM21 cameras to the FAKRA connectors installed on the board. Tested on V3M Eagle with RDACM20 and RDACM21 v1->v2: - Use a pattern property to describe the gpio-hog Thanks j Jacopo Mondi (1): dt-bindings: media: max9286: Describe gpio-hog Kieran Bingham (3): arm64: dts: renesas: eagle: Enable MAX9286 arm64: dts: renesas: eagle: Add GMSL .dtsi arm64: dts: renesas: eagle: Include eagle-gmsl .../bindings/media/i2c/maxim,max9286.yaml | 16 ++ arch/arm64/boot/dts/renesas/eagle-gmsl.dtsi | 186 ++ .../arm64/boot/dts/renesas/r8a77970-eagle.dts | 135 + 3 files changed, 337 insertions(+) create mode 100644 arch/arm64/boot/dts/renesas/eagle-gmsl.dtsi -- 2.30.0
Re: [PATCH v2 0/4] add device drivers for Siemens Industrial PCs
Am Mon, 15 Mar 2021 12:55:13 +0200 schrieb Andy Shevchenko : > On Mon, Mar 15, 2021 at 12:12 PM Henning Schild > wrote: > > > > changes since v1: > > > > - fixed lots of style issues found in v1 > > - (debug) printing > > - header ordering > > - fixed license issues GPLv2 and SPDX in all files > > - module_platform_driver instead of __init __exit > > - wdt simplifications cleanup > > - lots of fixes in wdt driver, all that was found in v1 > > - fixed dmi length in dmi helper > > - changed LED names to allowed ones > > - move led driver to simple/ > > - switched pmc_atom to dmi callback with global variable > > > > -- > > > > This series adds support for watchdogs and leds of several x86 > > devices from Siemens. > > > > It is structured with a platform driver that mainly does > > identification of the machines. It might trigger loading of the > > actual device drivers by attaching devices to the platform bus. > > > > The identification is vendor specific, parsing a special binary DMI > > entry. The implementation of that platform identification is > > applied on pmc_atom clock quirks in the final patch. > > > > It is all structured in a way that we can easily add more devices > > and more platform drivers later. Internally we have some more code > > for hardware monitoring, more leds, watchdogs etc. This will follow > > some day. > > Thanks for an update! > > I did review more thoughtfully the series and realized that you can > avoid that P2SB thingy and may the approach be much cleaner if you > register the real GPIO driver and convert your LEDs to be a GPIO LEDs. > Then you won't need any custom code for it (except some board file, or > what would be better to file _DSD in your ACPI tables. Thanks Andy. I will need to read through your comments and existing code. Are you saying there already is a GPIO driver that i should rather hook into ... given there is and will not be WDAT any time soon? Can you please point it out to me, the driver and maybe an example. If you are suggesting to write a generic GPIO driver, i would probably say that this can hopefully wait until we have a second user and need that level of abstraction. regards, Henning > -- > With Best Regards, > Andy Shevchenko
[PATCH v2 0/4] clk: add BCM63268 timer clock and reset
Broadcom BCM63268 has a timer clock and reset controller which has the following layout: #define POR_RESET_STATUS(1 << 31) #define HW_RESET_STATUS (1 << 30) #define SW_RESET_STATUS (1 << 29) #define USB_REF_CLKEN (1 << 18) #define UTO_EXTIN_CLKEN (1 << 17) #define UTO_CLK50_SEL (1 << 16) #define FAP2_PLL_CLKEN (1 << 15) #define FAP2_PLL_FREQ_SHIFT 12 #define FAP1_PLL_CLKEN (1 << 11) #define FAP1_PLL_FREQ_SHIFT 8 #define WAKEON_DSL (1 << 7) #define WAKEON_EPHY (1 << 6) #define DSL_ENERGY_DETECT_ENABLE(1 << 4) #define GPHY_1_ENERGY_DETECT_ENABLE (1 << 3) #define EPHY_3_ENERGY_DETECT_ENABLE (1 << 2) #define EPHY_2_ENERGY_DETECT_ENABLE (1 << 1) #define EPHY_1_ENERGY_DETECT_ENABLE (1 << 0) v2: add changes suggested by Stephen Boyd. Álvaro Fernández Rojas (4): dt-bindings: clk: add BCM63268 timer clock definitions dt-bindings: reset: add BCM63268 timer reset definitions dt-bindings: clock: Add BCM63268 timer binding clk: bcm: Add BCM63268 timer clock and reset driver .../clock/brcm,bcm63268-timer-clocks.yaml | 40 +++ drivers/clk/bcm/Kconfig | 9 + drivers/clk/bcm/Makefile | 1 + drivers/clk/bcm/clk-bcm63268-timer.c | 231 ++ include/dt-bindings/clock/bcm63268-clock.h| 13 + include/dt-bindings/reset/bcm63268-reset.h| 4 + 6 files changed, 298 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml create mode 100644 drivers/clk/bcm/clk-bcm63268-timer.c -- 2.20.1
Re: [PATCH v2 0/4] add device drivers for Siemens Industrial PCs
On Mon, Mar 15, 2021 at 12:12 PM Henning Schild wrote: > > changes since v1: > > - fixed lots of style issues found in v1 > - (debug) printing > - header ordering > - fixed license issues GPLv2 and SPDX in all files > - module_platform_driver instead of __init __exit > - wdt simplifications cleanup > - lots of fixes in wdt driver, all that was found in v1 > - fixed dmi length in dmi helper > - changed LED names to allowed ones > - move led driver to simple/ > - switched pmc_atom to dmi callback with global variable > > -- > > This series adds support for watchdogs and leds of several x86 devices > from Siemens. > > It is structured with a platform driver that mainly does identification > of the machines. It might trigger loading of the actual device drivers > by attaching devices to the platform bus. > > The identification is vendor specific, parsing a special binary DMI > entry. The implementation of that platform identification is applied on > pmc_atom clock quirks in the final patch. > > It is all structured in a way that we can easily add more devices and > more platform drivers later. Internally we have some more code for > hardware monitoring, more leds, watchdogs etc. This will follow some > day. Thanks for an update! I did review more thoughtfully the series and realized that you can avoid that P2SB thingy and may the approach be much cleaner if you register the real GPIO driver and convert your LEDs to be a GPIO LEDs. Then you won't need any custom code for it (except some board file, or what would be better to file _DSD in your ACPI tables. -- With Best Regards, Andy Shevchenko
[PATCH v2 0/4] add device drivers for Siemens Industrial PCs
changes since v1: - fixed lots of style issues found in v1 - (debug) printing - header ordering - fixed license issues GPLv2 and SPDX in all files - module_platform_driver instead of __init __exit - wdt simplifications cleanup - lots of fixes in wdt driver, all that was found in v1 - fixed dmi length in dmi helper - changed LED names to allowed ones - move led driver to simple/ - switched pmc_atom to dmi callback with global variable -- This series adds support for watchdogs and leds of several x86 devices from Siemens. It is structured with a platform driver that mainly does identification of the machines. It might trigger loading of the actual device drivers by attaching devices to the platform bus. The identification is vendor specific, parsing a special binary DMI entry. The implementation of that platform identification is applied on pmc_atom clock quirks in the final patch. It is all structured in a way that we can easily add more devices and more platform drivers later. Internally we have some more code for hardware monitoring, more leds, watchdogs etc. This will follow some day. Henning Schild (4): platform/x86: simatic-ipc: add main driver for Siemens devices leds: simatic-ipc-leds: add new driver for Siemens Industial PCs watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCs drivers/leds/Kconfig | 3 + drivers/leds/Makefile | 3 + drivers/leds/simple/Kconfig | 11 + drivers/leds/simple/Makefile | 2 + drivers/leds/simple/simatic-ipc-leds.c| 210 + drivers/platform/x86/Kconfig | 12 + drivers/platform/x86/Makefile | 3 + drivers/platform/x86/pmc_atom.c | 47 ++-- drivers/platform/x86/simatic-ipc.c| 168 ++ drivers/watchdog/Kconfig | 11 + drivers/watchdog/Makefile | 1 + drivers/watchdog/simatic-ipc-wdt.c| 215 ++ .../platform_data/x86/simatic-ipc-base.h | 29 +++ include/linux/platform_data/x86/simatic-ipc.h | 66 ++ 14 files changed, 761 insertions(+), 20 deletions(-) create mode 100644 drivers/leds/simple/Kconfig create mode 100644 drivers/leds/simple/Makefile create mode 100644 drivers/leds/simple/simatic-ipc-leds.c create mode 100644 drivers/platform/x86/simatic-ipc.c create mode 100644 drivers/watchdog/simatic-ipc-wdt.c create mode 100644 include/linux/platform_data/x86/simatic-ipc-base.h create mode 100644 include/linux/platform_data/x86/simatic-ipc.h -- 2.26.2
Re: [PATCH v2 0/4] enable flexspi support on imx8mp
On Mon, Mar 15, 2021 at 08:10:37AM +0100, Heiko Schocher wrote:
> Hello Shawn,
>
> On 15.03.21 07:47, Shawn Guo wrote:
> > On Tue, Mar 09, 2021 at 06:31:12AM +0100, Heiko Schocher wrote:
> >>
> >> This series enables support for the SPI NOR on the
> >> imx8mp based phyboard-pollux-rdk board.
> >>
> >> Patches new in v2:
> >> "spi: fspi: enable fspi driver for on imx8mp"
> >> which adds own compatible entry for imx8mp
> >>
> >> and seperate in own patch the documentation entry in
> >> patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
> >> controller"
> >> as checkpatch says:
> >>
> >> warning: DT binding docs and includes should be a separate patch. See:
> >> Documentation/devicetree/bindings/submitting-patches.rst
> >>
> >>
> >> Changes in v2:
> >> - work in comments from Marco
> >> add own compatible entry for imx8mp
> >> - work in comments from Marco
> >> - add own compatible entry "nxp,imx8mp-fspi"
> >> - reworked order of properties as Marco mentioned
> >> - work in comments from Marco and Teresa
> >> - rename node into "'som_flash: flash@0 { }"
> >> - compatible is now first entry
> >> - removed #size-cells and #address-cells
> >> as no child node. If bootloader adds them bootloader
> >> can add them too.
> >>
> >> Heiko Schocher (4):
> >> spi: fspi: enable fspi driver for on imx8mp
> >> dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
> >> controller
> >> arm64: dts: imx8mp: add flexspi node
> >> arm64: imx8mp: imx8mp-phycore-som enable spi nor
> >
> > Two DTS patch look good. Ping me when driver and bindings changes are
> > accepted.
>
> Thanks!
>
> Hmm.. I have not splitted this series into 2 series... should I do
> this now?
No, you do not need to. I sent the message only because I didn't
receive patch #1 and #2, so I will not be aware of their status.
Shawn
Re: [PATCH v2 0/4] enable flexspi support on imx8mp
Hello Shawn,
On 15.03.21 07:47, Shawn Guo wrote:
> On Tue, Mar 09, 2021 at 06:31:12AM +0100, Heiko Schocher wrote:
>>
>> This series enables support for the SPI NOR on the
>> imx8mp based phyboard-pollux-rdk board.
>>
>> Patches new in v2:
>> "spi: fspi: enable fspi driver for on imx8mp"
>> which adds own compatible entry for imx8mp
>>
>> and seperate in own patch the documentation entry in
>> patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
>> controller"
>> as checkpatch says:
>>
>> warning: DT binding docs and includes should be a separate patch. See:
>> Documentation/devicetree/bindings/submitting-patches.rst
>>
>>
>> Changes in v2:
>> - work in comments from Marco
>> add own compatible entry for imx8mp
>> - work in comments from Marco
>> - add own compatible entry "nxp,imx8mp-fspi"
>> - reworked order of properties as Marco mentioned
>> - work in comments from Marco and Teresa
>> - rename node into "'som_flash: flash@0 { }"
>> - compatible is now first entry
>> - removed #size-cells and #address-cells
>> as no child node. If bootloader adds them bootloader
>> can add them too.
>>
>> Heiko Schocher (4):
>> spi: fspi: enable fspi driver for on imx8mp
>> dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
>> controller
>> arm64: dts: imx8mp: add flexspi node
>> arm64: imx8mp: imx8mp-phycore-som enable spi nor
>
> Two DTS patch look good. Ping me when driver and bindings changes are
> accepted.
Thanks!
Hmm.. I have not splitted this series into 2 series... should I do
this now?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v2 0/4] enable flexspi support on imx8mp
On Tue, Mar 09, 2021 at 06:31:12AM +0100, Heiko Schocher wrote:
>
> This series enables support for the SPI NOR on the
> imx8mp based phyboard-pollux-rdk board.
>
> Patches new in v2:
> "spi: fspi: enable fspi driver for on imx8mp"
> which adds own compatible entry for imx8mp
>
> and seperate in own patch the documentation entry in
> patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
> controller"
> as checkpatch says:
>
> warning: DT binding docs and includes should be a separate patch. See:
> Documentation/devicetree/bindings/submitting-patches.rst
>
>
> Changes in v2:
> - work in comments from Marco
> add own compatible entry for imx8mp
> - work in comments from Marco
> - add own compatible entry "nxp,imx8mp-fspi"
> - reworked order of properties as Marco mentioned
> - work in comments from Marco and Teresa
> - rename node into "'som_flash: flash@0 { }"
> - compatible is now first entry
> - removed #size-cells and #address-cells
> as no child node. If bootloader adds them bootloader
> can add them too.
>
> Heiko Schocher (4):
> spi: fspi: enable fspi driver for on imx8mp
> dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
> controller
> arm64: dts: imx8mp: add flexspi node
> arm64: imx8mp: imx8mp-phycore-som enable spi nor
Two DTS patch look good. Ping me when driver and bindings changes are
accepted.
Shawn
Re: [PATCH v2 0/4] staging: rtl8723bs: remove unused code blocks
On Sun, Mar 14, 2021 at 04:57:38PM +0100, Greg KH wrote: > On Fri, Mar 12, 2021 at 07:33:13PM +0100, Fabio Aiuto wrote: > > This patch set removes unused code blocks as required in TODO file: > > > > find and remove code blocks guarded by never set CONFIG_FOO defines > > > > Changes in v2: > > - modified sunject lines to make them unique > > - added a patch previously excluded (removal of > > CONFIG_PNO_SET_DEBUG code) > > > > Fabio Aiuto (4): > > staging: rtl8723bs: remove unused code blocks conditioned by never set > > CONFIG_PNO_SET_DEBUG > > staging: rtl8723bs: remove unused code blocks conditioned by never set > > CONFIG_PNO_SUPPORT > > staging: rtl8723bs: remove unused code blocks conditioned by never set > > CONFIG_WOWLAN > > staging: rtl8723bs: remove unused code blocks conditioned by never set > > CONFIG_TCP_CSUM_OFFLOAD_RX > > The first 2 patches here worked, the others did not apply to my tree due > to other changes from other developers. Can you please rebase them and > resend? > > thanks, > > greg k-h just sent, thank you, fabio
Re: [PATCH v2 0/4] staging: rtl8723bs: remove unused code blocks
On Fri, Mar 12, 2021 at 07:33:13PM +0100, Fabio Aiuto wrote: > This patch set removes unused code blocks as required in TODO file: > > find and remove code blocks guarded by never set CONFIG_FOO defines > > Changes in v2: > - modified sunject lines to make them unique > - added a patch previously excluded (removal of > CONFIG_PNO_SET_DEBUG code) > > Fabio Aiuto (4): > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_PNO_SET_DEBUG > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_PNO_SUPPORT > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_WOWLAN > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_TCP_CSUM_OFFLOAD_RX The first 2 patches here worked, the others did not apply to my tree due to other changes from other developers. Can you please rebase them and resend? thanks, greg k-h
[PATCH v2 0/4] staging: rtl8723bs: remove unused code blocks
This patch set removes unused code blocks as required in TODO file: find and remove code blocks guarded by never set CONFIG_FOO defines Changes in v2: - modified sunject lines to make them unique - added a patch previously excluded (removal of CONFIG_PNO_SET_DEBUG code) Fabio Aiuto (4): staging: rtl8723bs: remove unused code blocks conditioned by never set CONFIG_PNO_SET_DEBUG staging: rtl8723bs: remove unused code blocks conditioned by never set CONFIG_PNO_SUPPORT staging: rtl8723bs: remove unused code blocks conditioned by never set CONFIG_WOWLAN staging: rtl8723bs: remove unused code blocks conditioned by never set CONFIG_TCP_CSUM_OFFLOAD_RX drivers/staging/rtl8723bs/core/rtw_mlme.c | 3 - drivers/staging/rtl8723bs/core/rtw_pwrctrl.c | 24 +- .../staging/rtl8723bs/core/rtw_wlan_util.c| 61 +- drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c | 872 +- .../staging/rtl8723bs/hal/rtl8723b_hal_init.c | 43 +- drivers/staging/rtl8723bs/hal/sdio_halinit.c | 253 + drivers/staging/rtl8723bs/hal/sdio_ops.c | 4 +- drivers/staging/rtl8723bs/include/autoconf.h | 3 - drivers/staging/rtl8723bs/include/drv_types.h | 5 - .../rtl8723bs/include/drv_types_sdio.h| 2 +- .../staging/rtl8723bs/include/hal_com_h2c.h | 88 +- drivers/staging/rtl8723bs/include/hal_intf.h | 5 - .../staging/rtl8723bs/include/rtl8723b_cmd.h | 4 +- .../staging/rtl8723bs/include/rtl8723b_hal.h | 17 - .../staging/rtl8723bs/include/rtl8723b_spec.h | 10 - drivers/staging/rtl8723bs/include/rtw_mp.h| 3 - .../staging/rtl8723bs/include/rtw_pwrctrl.h | 62 -- drivers/staging/rtl8723bs/include/rtw_recv.h | 5 - .../staging/rtl8723bs/include/rtw_security.h | 3 - drivers/staging/rtl8723bs/include/sdio_ops.h | 8 +- drivers/staging/rtl8723bs/include/sta_info.h | 5 - .../staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 56 -- .../staging/rtl8723bs/os_dep/ioctl_linux.c| 3 - drivers/staging/rtl8723bs/os_dep/os_intfs.c | 238 + drivers/staging/rtl8723bs/os_dep/recv_linux.c | 8 - drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 5 - 26 files changed, 28 insertions(+), 1762 deletions(-) -- 2.20.1
Re: [PATCH v2 0/4] KVM: x86: Fixups and PAE+SME fixes
On 09/03/21 23:42, Sean Christopherson wrote: A few stragglers bundled together to hopefully avoid more messy conflicts. v2 (relative to the fixup mini-series): - Moved SME fixes from "PCID fixup" to its correct location, in "Mark PAE roots decrypted". - Collected Reviewed/Tested-by tags for MMU_PRESENT+MMIO snafu, though I expect they'll get squashed away. - Added the PAE patches from the SME shadow paging fixes to avoid spreading out the dependencies. Sean Christopherson (4): KVM: x86: Fixup "Get active PCID only when writing a CR3 value" KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation KVM: x86/mmu: Use '0' as the one and only value for an invalid PAE root KVM: x86/mmu: Mark the PAE roots as decrypted for shadow paging arch/x86/kvm/mmu/mmu.c | 46 - arch/x86/kvm/mmu/mmu_audit.c| 2 +- arch/x86/kvm/mmu/mmu_internal.h | 10 +++ arch/x86/kvm/mmu/spte.h | 12 + arch/x86/kvm/svm/svm.c | 9 +-- 5 files changed, 59 insertions(+), 20 deletions(-) Queued, thanks. Paolo
[PATCH v2 0/4] KVM: x86: Fixups and PAE+SME fixes
A few stragglers bundled together to hopefully avoid more messy conflicts. v2 (relative to the fixup mini-series): - Moved SME fixes from "PCID fixup" to its correct location, in "Mark PAE roots decrypted". - Collected Reviewed/Tested-by tags for MMU_PRESENT+MMIO snafu, though I expect they'll get squashed away. - Added the PAE patches from the SME shadow paging fixes to avoid spreading out the dependencies. Sean Christopherson (4): KVM: x86: Fixup "Get active PCID only when writing a CR3 value" KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation KVM: x86/mmu: Use '0' as the one and only value for an invalid PAE root KVM: x86/mmu: Mark the PAE roots as decrypted for shadow paging arch/x86/kvm/mmu/mmu.c | 46 - arch/x86/kvm/mmu/mmu_audit.c| 2 +- arch/x86/kvm/mmu/mmu_internal.h | 10 +++ arch/x86/kvm/mmu/spte.h | 12 + arch/x86/kvm/svm/svm.c | 9 +-- 5 files changed, 59 insertions(+), 20 deletions(-) -- 2.30.1.766.gb4fecdf3b7-goog
[PATCH v2 0/4] kbuild: build speed improvement of CONFIG_TRIM_UNUSED_KSYMS
Now CONFIG_TRIM_UNUSED_KSYMS is revived, but Linus is still unhappy
about the build speed.
I re-implemented this feature, and the build time cost is now
almost unnoticeable level.
(no changes since v1)
Masahiro Yamada (4):
export.h: make __ksymtab_strings per-symbol section
kbuild: separate out vmlinux.lds generation
kbuild: re-implement CONFIG_TRIM_UNUSED_KSYMS to make it work in
one-pass
kbuild: remove guarding from TRIM_UNUSED_KSYMS
Makefile | 34 -
arch/alpha/kernel/Makefile| 3 +-
arch/arc/kernel/Makefile | 3 +-
arch/arm/kernel/Makefile | 3 +-
arch/arm64/kernel/Makefile| 3 +-
arch/arm64/kvm/hyp/nvhe/hyp.lds.S | 1 +
arch/csky/kernel/Makefile | 3 +-
arch/h8300/kernel/Makefile| 2 +-
arch/hexagon/kernel/Makefile | 3 +-
arch/ia64/kernel/Makefile | 3 +-
arch/m68k/kernel/Makefile | 2 +-
arch/microblaze/kernel/Makefile | 3 +-
arch/mips/kernel/Makefile | 3 +-
arch/nds32/kernel/Makefile| 3 +-
arch/nios2/kernel/Makefile| 2 +-
arch/openrisc/kernel/Makefile | 3 +-
arch/parisc/kernel/Makefile | 3 +-
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/vdso32/vdso32.lds.S | 1 +
arch/powerpc/kernel/vdso64/vdso64.lds.S | 1 +
arch/riscv/kernel/Makefile| 2 +-
arch/s390/kernel/Makefile | 3 +-
arch/s390/purgatory/purgatory.lds.S | 1 +
arch/sh/kernel/Makefile | 3 +-
arch/sparc/kernel/Makefile| 2 +-
arch/um/kernel/Makefile | 2 +-
arch/x86/kernel/Makefile | 2 +-
arch/xtensa/kernel/Makefile | 3 +-
include/asm-generic/export.h | 25 +--
include/asm-generic/vmlinux.lds.h | 13 ++--
include/linux/export.h| 56 --
include/linux/ksyms.lds.h | 22 ++
init/Kconfig | 3 +-
scripts/Makefile.build| 7 +-
scripts/Makefile.lib | 1 +
scripts/adjust_autoksyms.sh | 73 ---
.../{gen_autoksyms.sh => gen-keep-ksyms.sh} | 43 ---
scripts/gen_ksymdeps.sh | 25 ---
scripts/module.lds.S | 23 +++---
39 files changed, 152 insertions(+), 238 deletions(-)
create mode 100644 include/linux/ksyms.lds.h
delete mode 100755 scripts/adjust_autoksyms.sh
rename scripts/{gen_autoksyms.sh => gen-keep-ksyms.sh} (66%)
delete mode 100755 scripts/gen_ksymdeps.sh
--
2.27.0
Re: [PATCH v2 0/4] arm64: dts: ti: am642x: add CPSW3g DT nodes
On 23:10-20210304, Grygorii Strashko wrote: > Hi > > This series adds corresponding AM642x CPSW3g nodes required to enable > networking > on TI am642-evm/sk platforms and adds required pinmux/PHY nodes in > corresponding > board files. > > Kernel Boot Log: > EVM: https://pastebin.ubuntu.com/p/6Qkbw35Jg3/ > SK: https://pastebin.ubuntu.com/p/Pd3xxP9J9K/ > > Changes in v2: > - minor comment fixed > - add Reviewed-by: Lokesh Vutla > > v1: https://lore.kernel.org/patchwork/cover/1389305/ > > Grygorii Strashko (1): > arm64: dts: ti: k3-am64-main: add main CPTS entry > Thanks, applied to ti-k3-dts-next. PS: my -next branches are being rebased to 5.12-rc2 to keep a future bisect clean. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 0/4] enable flexspi support on imx8mp
Hello Marco, On 09.03.21 09:19, Marco Felsch wrote: > Hi Heiko, > > On 21-03-09 06:31, Heiko Schocher wrote: >> >> This series enables support for the SPI NOR on the >> imx8mp based phyboard-pollux-rdk board. >> >> Patches new in v2: >> "spi: fspi: enable fspi driver for on imx8mp" >> which adds own compatible entry for imx8mp >> >> and seperate in own patch the documentation entry in >> patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI >> controller" >> as checkpatch says: >> >> warning: DT binding docs and includes should be a separate patch. See: >> Documentation/devicetree/bindings/submitting-patches.rst > > Thanks for picking up the comments :) Did you missed to send them or did > you used an other Cc: and To: for the new patches? Damn, I use patman tool from u-boot source whoch generates cc list and missed to add you explicitely to Cc... sorry They are all on linux-arm-kernel: http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643290.html http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643291.html http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643292.html http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643293.html bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v2 0/4] enable flexspi support on imx8mp
Hi Heiko, On 21-03-09 06:31, Heiko Schocher wrote: > > This series enables support for the SPI NOR on the > imx8mp based phyboard-pollux-rdk board. > > Patches new in v2: > "spi: fspi: enable fspi driver for on imx8mp" > which adds own compatible entry for imx8mp > > and seperate in own patch the documentation entry in > patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI > controller" > as checkpatch says: > > warning: DT binding docs and includes should be a separate patch. See: > Documentation/devicetree/bindings/submitting-patches.rst Thanks for picking up the comments :) Did you missed to send them or did you used an other Cc: and To: for the new patches? Regards, Marco
[PATCH v2 0/4] enable flexspi support on imx8mp
This series enables support for the SPI NOR on the
imx8mp based phyboard-pollux-rdk board.
Patches new in v2:
"spi: fspi: enable fspi driver for on imx8mp"
which adds own compatible entry for imx8mp
and seperate in own patch the documentation entry in
patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller"
as checkpatch says:
warning: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
Changes in v2:
- work in comments from Marco
add own compatible entry for imx8mp
- work in comments from Marco
- add own compatible entry "nxp,imx8mp-fspi"
- reworked order of properties as Marco mentioned
- work in comments from Marco and Teresa
- rename node into "'som_flash: flash@0 { }"
- compatible is now first entry
- removed #size-cells and #address-cells
as no child node. If bootloader adds them bootloader
can add them too.
Heiko Schocher (4):
spi: fspi: enable fspi driver for on imx8mp
dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
controller
arm64: dts: imx8mp: add flexspi node
arm64: imx8mp: imx8mp-phycore-som enable spi nor
.../devicetree/bindings/spi/spi-nxp-fspi.txt | 1 +
.../dts/freescale/imx8mp-phycore-som.dtsi | 25 +++
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16
drivers/spi/spi-nxp-fspi.c| 1 +
4 files changed, 43 insertions(+)
--
2.29.2
[PATCH v2 0/4] Stylus-on-touchscreen device support
This patchset adds support for stylus-on-touchscreen devices as found on the OneMix 3 Pro and Dell Inspiron 15 7000 2-in-1 (7591), among others; with it, they properly behave like a drawing tablet. Patches 2 and 4 funxionally depend on patch 1. Patch 4 needs patch 3 to apply. The output of this patchset and the need for a kernel, rather than userspace, patch was previously discussed here: https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/558#note_792834 Changes in v2: Patch 4 now ANDs the secondary button with the tip switch, since it's otherwise borderline useless to the user. Ahelenia Ziemiańska (4): HID: multitouch: require Finger field to mark Win8 reports as MT HID: multitouch: set Stylus suffix for Stylus-application devices, too HID: input: replace outdated HID numbers+comments with macros HID: input: work around Win8 stylus-on-touchscreen reporting drivers/hid/hid-input.c | 54 ++-- drivers/hid/hid-multitouch.c | 18 +++- 2 files changed, 62 insertions(+), 10 deletions(-) -- 2.20.1 signature.asc Description: PGP signature
[PATCH V2 0/4] vDPA/ifcvf: enables Intel C5000X-PL virtio-net
This series enabled Intel FGPA SmartNIC C5000X-PL virtio-net for vDPA changes from V1: remove version number string(Leon) add new device ids and remove original device ids in separate patches(Jason) Zhu Lingshan (4): vDPA/ifcvf: get_vendor_id returns a device specific vendor id vDPA/ifcvf: enable Intel C5000X-PL virtio-net for vDPA vDPA/ifcvf: rename original IFCVF dev ids to N3000 ids vDPA/ifcvf: remove the version number string drivers/vdpa/ifcvf/ifcvf_base.h | 13 + drivers/vdpa/ifcvf/ifcvf_main.c | 20 +--- 2 files changed, 22 insertions(+), 11 deletions(-) -- 2.27.0
[PATCH v2 0/4] Cleanup and fixup for khugepaged
Hi all, This series contains cleanups to remove unneeded return value, use helper function and so on. And there is one fix to correct the wrong result value for trace_mm_collapse_huge_page_isolate(). More details can be found in the respective changelogs. Thanks! v1->v2: drop patch "khugepaged: remove unnecessary mem_cgroup_uncharge() in collapse_[file|huge_page]" collect Acked-by Miaohe Lin (4): khugepaged: remove unneeded return value of khugepaged_collapse_pte_mapped_thps() khugepaged: reuse the smp_wmb() inside __SetPageUptodate() khugepaged: use helper khugepaged_test_exit() in __khugepaged_enter() khugepaged: fix wrong result value for trace_mm_collapse_huge_page_isolate() mm/khugepaged.c | 43 --- 1 file changed, 20 insertions(+), 23 deletions(-) -- 2.19.1
Re: [PATCH v2 0/4] ALSA: hda/cirrus: Add support for CS8409 HDA bridge and CS42L42 companion codec
On Thu, 04 Mar 2021 20:02:37 +0100, Vitaly Rodionov wrote: > > Dell's laptops Inspiron 3500, Inspiron 3501, Inspiron 3505 are using > Cirrus Logic CS8409 HDA bridge with CS42L42 companion codec. > > The CS8409 is a multichannel HD audio routing controller. > CS8409 includes support for four channels of digital > microphone data and two bidirectional ASPs for up to 32 > channels of TDM data or 4 channels of I2S data. The CS8409 is > intended to be used with a remote companion codec that implements > high performance analog functions in close physical > proximity to the end-equipment audio port or speaker driver. > > The CS42L42 is a low-power audio codec with integrated MIPI > SoundWire interface or I2C/I2S/TDM interfaces designed > for portable applications. It provides a high-dynamic range, > stereo DAC for audio playback and a mono high-dynamic-range > ADC for audio capture > > Changes since version 1: > > ALSA: hda/cirrus: Increase AUTO_CFG_MAX_INS from 8 to 18 > * No change > > ALSA: hda/cirrus: Add support for CS8409 HDA bridge and CS42L42 > companion codec. > * Removed redundant fields in fixup table > * Handle gpio via spec->gpio_dir, spec->gpio_data and spec->gpio_mask > * Moved cs8409_cs42l42_init() from patch 2, to handle resume correctly > > ALSA: hda/cirrus: Add jack detect interrupt support from CS42L42 > companion codec. > * Run scripts/checkpatch.pl, fixed new warnings > > ALSA: hda/cirrus: Add Headphone and Headset MIC Volume Control > * Moved control values to cache to avoid i2c read at each time. > > Stefan Binding (1): > ALSA: hda/cirrus: Add Headphone and Headset MIC Volume Control > > Vitaly Rodionov (3): > ALSA: hda/cirrus: Increase AUTO_CFG_MAX_INS from 8 to 18 > ALSA: hda/cirrus: Add support for CS8409 HDA bridge and CS42L42 > companion codec. > ALSA: hda/cirrus: Add jack detect interrupt support from CS42L42 > companion codec. It seems that 0-day bot caught a few issues. I'll wait for the next respin :) thanks, Takashi
[PATCH v2 0/4] arm64: dts: ti: am642x: add CPSW3g DT nodes
Hi This series adds corresponding AM642x CPSW3g nodes required to enable networking on TI am642-evm/sk platforms and adds required pinmux/PHY nodes in corresponding board files. Kernel Boot Log: EVM: https://pastebin.ubuntu.com/p/6Qkbw35Jg3/ SK: https://pastebin.ubuntu.com/p/Pd3xxP9J9K/ Changes in v2: - minor comment fixed - add Reviewed-by: Lokesh Vutla v1: https://lore.kernel.org/patchwork/cover/1389305/ Grygorii Strashko (1): arm64: dts: ti: k3-am64-main: add main CPTS entry Vignesh Raghavendra (3): arm64: dts: ti: am64-main: Add CPSW DT node arm64: dts: ti: k3-am642-evm: add CPSW3g DT nodes arm64: dts: ti: k3-am642-sk: Add CPSW DT nodes arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 89 +++ arch/arm64/boot/dts/ti/k3-am64.dtsi | 2 + arch/arm64/boot/dts/ti/k3-am642-evm.dts | 93 arch/arm64/boot/dts/ti/k3-am642-sk.dts | 73 +++ 4 files changed, 257 insertions(+) -- 2.17.1
[PATCH v2 0/4] ALSA: hda/cirrus: Add support for CS8409 HDA bridge and CS42L42 companion codec
Dell's laptops Inspiron 3500, Inspiron 3501, Inspiron 3505 are using Cirrus Logic CS8409 HDA bridge with CS42L42 companion codec. The CS8409 is a multichannel HD audio routing controller. CS8409 includes support for four channels of digital microphone data and two bidirectional ASPs for up to 32 channels of TDM data or 4 channels of I2S data. The CS8409 is intended to be used with a remote companion codec that implements high performance analog functions in close physical proximity to the end-equipment audio port or speaker driver. The CS42L42 is a low-power audio codec with integrated MIPI SoundWire interface or I2C/I2S/TDM interfaces designed for portable applications. It provides a high-dynamic range, stereo DAC for audio playback and a mono high-dynamic-range ADC for audio capture Changes since version 1: ALSA: hda/cirrus: Increase AUTO_CFG_MAX_INS from 8 to 18 * No change ALSA: hda/cirrus: Add support for CS8409 HDA bridge and CS42L42 companion codec. * Removed redundant fields in fixup table * Handle gpio via spec->gpio_dir, spec->gpio_data and spec->gpio_mask * Moved cs8409_cs42l42_init() from patch 2, to handle resume correctly ALSA: hda/cirrus: Add jack detect interrupt support from CS42L42 companion codec. * Run scripts/checkpatch.pl, fixed new warnings ALSA: hda/cirrus: Add Headphone and Headset MIC Volume Control * Moved control values to cache to avoid i2c read at each time. Stefan Binding (1): ALSA: hda/cirrus: Add Headphone and Headset MIC Volume Control Vitaly Rodionov (3): ALSA: hda/cirrus: Increase AUTO_CFG_MAX_INS from 8 to 18 ALSA: hda/cirrus: Add support for CS8409 HDA bridge and CS42L42 companion codec. ALSA: hda/cirrus: Add jack detect interrupt support from CS42L42 companion codec. sound/pci/hda/hda_auto_parser.h |2 +- sound/pci/hda/hda_local.h |2 +- sound/pci/hda/patch_cirrus.c| 1068 +++ 3 files changed, 1070 insertions(+), 2 deletions(-) -- 2.25.1
Re: [PATCH v2 0/4] man2: udpate mm/userfaultfd manpages to latest
On Thu, Mar 4, 2021 at 8:31 AM Peter Xu wrote: > > v2 changes: > - Fix wordings as suggested [MikeR] > - convert ".BR" to ".B" where proper for the patchset [Alex] > - rearrange a few lines in the last two patches where they got messed up > - document more things, e.g. UFFDIO_COPY_MODE_WP; and also on how to resolve a > wr-protect page fault. > > There're two features missing in current manpage, namely: > > (1) Userfaultfd Thread-ID feature > (2) Userfaultfd write protect mode > > There's also a 3rd one which was just contributed from Axel - Axel, I think it > would be great if you can add that part too, probably after the whole > hugetlbfs/shmem minor mode reaches the linux master branch. Ack, this is on my list of "todos". Agree it makes sense to wait until the code is in Linus' tree, then I'll send a patch for the man pages. > > Please review, thanks. > > Peter Xu (4): > userfaultfd.2: Add UFFD_FEATURE_THREAD_ID docs > userfaultfd.2: Add write-protect mode > ioctl_userfaultfd.2: Add UFFD_FEATURE_THREAD_ID docs > ioctl_userfaultfd.2: Add write-protect mode docs > > man2/ioctl_userfaultfd.2 | 81 ++-- > man2/userfaultfd.2 | 111 ++- > 2 files changed, 187 insertions(+), 5 deletions(-) > > -- > 2.26.2 > >
[PATCH v2 0/4] man2: udpate mm/userfaultfd manpages to latest
v2 changes: - Fix wordings as suggested [MikeR] - convert ".BR" to ".B" where proper for the patchset [Alex] - rearrange a few lines in the last two patches where they got messed up - document more things, e.g. UFFDIO_COPY_MODE_WP; and also on how to resolve a wr-protect page fault. There're two features missing in current manpage, namely: (1) Userfaultfd Thread-ID feature (2) Userfaultfd write protect mode There's also a 3rd one which was just contributed from Axel - Axel, I think it would be great if you can add that part too, probably after the whole hugetlbfs/shmem minor mode reaches the linux master branch. Please review, thanks. Peter Xu (4): userfaultfd.2: Add UFFD_FEATURE_THREAD_ID docs userfaultfd.2: Add write-protect mode ioctl_userfaultfd.2: Add UFFD_FEATURE_THREAD_ID docs ioctl_userfaultfd.2: Add write-protect mode docs man2/ioctl_userfaultfd.2 | 81 ++-- man2/userfaultfd.2 | 111 ++- 2 files changed, 187 insertions(+), 5 deletions(-) -- 2.26.2
Re: [PATCH V2 0/4] scsi: ufs-debugfs: Add UFS Exception Event reporting
On Tue, 9 Feb 2021 08:24:33 +0200, Adrian Hunter wrote: > Here are V2 patches to add a tracepoint for UFS Exception Events and to > allow users to enable specific exception events without affecting the > driver's use of exception events. > > > Changes in V2: > > [...] Applied to 5.13/scsi-queue, thanks! [1/4] scsi: ufs: Add exception event tracepoint https://git.kernel.org/mkp/scsi/c/26b01633fac8 [2/4] scsi: ufs: Add exception event definitions https://git.kernel.org/mkp/scsi/c/8fd31fc2b84f [3/4] scsi: ufs-debugfs: Add user-defined exception_event_mask https://git.kernel.org/mkp/scsi/c/e1c8b528dd23 [4/4] scsi: ufs-debugfs: Add user-defined exception event rate limiting https://git.kernel.org/mkp/scsi/c/c3f04083d653 -- Martin K. Petersen Oracle Linux Engineering
Re: [Patch v2 0/4] NXP Flexspi driver patches
On Tue, 2 Mar 2021 18:19:32 +0530, Kuldeep Singh wrote: > This patchset involves changes in NXP Flexspi driver. > > Patch1 adds support for disabling AHB and enabling IP read only using a > quirk which is later used by patch3 and patch4. > > Patch3 and Patch4 are not related to each and are rather dependent on > patch1 and that's why I kept them in series. This also helps in easy > application of series. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/4] spi: spi-nxp-fspi: Add support for IP read only commit: 1e1c30db2ccba3ec891e683f5e8eca2aca6238eb [2/4] dt-bindings: spi: spi-nxp-fspi: Add imx8dxl support commit: a53a9159a6774b393bb4b620430328940fa853b8 [3/4] spi: spi-nxp-fspi: Add imx8dxl driver support commit: 99a6a399a61e95cd6639453f87d5c96a121dec07 [4/4] spi: spi-nxp-fspi: Implement errata workaround for LS1028A commit: 94f302f374b4544fa4d84526569f884ebb008f4d All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [External] Re: [PATCH v2 0/4] psi: Add PSI_CPU_FULL state and some code optimization
在 2021/3/4 上午12:05, Peter Zijlstra 写道: > On Wed, Mar 03, 2021 at 04:32:18PM +0100, Peter Zijlstra wrote: > >> Yes, I can do that. Thanks! > Please double check the patches as found here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=sched/core > > I've manually edited the tags. Looks good to me, thanks!
Re: [PATCH v2 0/4] psi: Add PSI_CPU_FULL state and some code optimization
On Wed, Mar 03, 2021 at 05:05:15PM +0100, Peter Zijlstra wrote: > On Wed, Mar 03, 2021 at 04:32:18PM +0100, Peter Zijlstra wrote: > > > Yes, I can do that. Thanks! > > Please double check the patches as found here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=sched/core > > I've manually edited the tags. Looks good to me, thanks!
Re: [PATCH v2 0/4] psi: Add PSI_CPU_FULL state and some code optimization
On Wed, Mar 03, 2021 at 04:32:18PM +0100, Peter Zijlstra wrote: > Yes, I can do that. Thanks! Please double check the patches as found here: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=sched/core I've manually edited the tags.
