* Patch "powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again" has been added to the 4.4-stable tree
From: gregkh @ 2019-04-29 9:51 UTC (permalink / raw)
To: christophe.leroy, diana.craciun, gregkh, linuxppc-dev, mauricfo,
mpe, msuchanek, npiggin
Cc: stable-commits
In-Reply-To: <20190421142037.21881-7-mpe@ellerman.id.au>
This is a note to let you know that I've just added the patch titled
powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-rfi-flush-make-it-possible-to-call-setup_rfi_flush-again.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From foo@baz Mon 29 Apr 2019 11:38:37 AM CEST
From: Michael Ellerman <mpe@ellerman.id.au>
Date: Mon, 22 Apr 2019 00:19:51 +1000
Subject: powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again
To: stable@vger.kernel.org, gregkh@linuxfoundation.org
Cc: linuxppc-dev@ozlabs.org, diana.craciun@nxp.com, msuchanek@suse.de, npiggin@gmail.com, christophe.leroy@c-s.fr
Message-ID: <20190421142037.21881-7-mpe@ellerman.id.au>
From: Michael Ellerman <mpe@ellerman.id.au>
commit abf110f3e1cea40f5ea15e85f5d67c39c14568a7 upstream.
For PowerVM migration we want to be able to call setup_rfi_flush()
again after we've migrated the partition.
To support that we need to check that we're not trying to allocate the
fallback flush area after memblock has gone away (i.e., boot-time only).
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/kernel/setup_64.c | 6 +++++-
2 files changed, 6 insertions(+), 2 deletions(-)
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -36,7 +36,7 @@ enum l1d_flush_type {
L1D_FLUSH_MTTRIG = 0x8,
};
-void __init setup_rfi_flush(enum l1d_flush_type, bool enable);
+void setup_rfi_flush(enum l1d_flush_type, bool enable);
void do_rfi_flush_fixups(enum l1d_flush_type types);
#endif /* !__ASSEMBLY__ */
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -887,6 +887,10 @@ static void init_fallback_flush(void)
u64 l1d_size, limit;
int cpu;
+ /* Only allocate the fallback flush area once (at boot time). */
+ if (l1d_flush_fallback_area)
+ return;
+
l1d_size = ppc64_caches.dsize;
limit = min(safe_stack_limit(), ppc64_rma_size);
@@ -904,7 +908,7 @@ static void init_fallback_flush(void)
}
}
-void __init setup_rfi_flush(enum l1d_flush_type types, bool enable)
+void setup_rfi_flush(enum l1d_flush_type types, bool enable)
{
if (types & L1D_FLUSH_FALLBACK) {
pr_info("rfi-flush: Using fallback displacement flush\n");
Patches currently in stable-queue which might be from mpe@ellerman.id.au are
queue-4.4/powerpc-64s-add-support-for-a-store-forwarding-barrier-at-kernel-entry-exit.patch
queue-4.4/powerpc-64-make-stf-barrier-ppc_book3s_64-specific.patch
queue-4.4/powerpc-pseries-set-or-clear-security-feature-flags.patch
queue-4.4/powerpc-fsl-fix-spectre_v2-mitigations-reporting.patch
queue-4.4/powerpc-64s-patch-barrier_nospec-in-modules.patch
queue-4.4/powerpc-pseries-support-firmware-disable-of-rfi-flush.patch
queue-4.4/powerpc-rfi-flush-call-setup_rfi_flush-after-lpm-migration.patch
queue-4.4/powerpc-pseries-query-hypervisor-for-count-cache-flush-settings.patch
queue-4.4/powerpc-powernv-set-or-clear-security-feature-flags.patch
queue-4.4/powerpc-64s-add-support-for-software-count-cache-flush.patch
queue-4.4/powerpc64s-show-ori31-availability-in-spectre_v1-sysfs-file-not-v2.patch
queue-4.4/powerpc-fsl-flush-the-branch-predictor-at-each-kernel-entry-64bit.patch
queue-4.4/powerpc-fsl-update-spectre-v2-reporting.patch
queue-4.4/powerpc-64s-wire-up-cpu_show_spectre_v2.patch
queue-4.4/powerpc-64-make-meltdown-reporting-book3s-64-specific.patch
queue-4.4/powerpc-rfi-flush-make-it-possible-to-call-setup_rfi_flush-again.patch
queue-4.4/powerpc-64s-add-support-for-ori-barrier_nospec-patching.patch
queue-4.4/powerpc-use-barrier_nospec-in-copy_from_user.patch
queue-4.4/powerpc-64s-fix-section-mismatch-warnings-from-setup_rfi_flush.patch
queue-4.4/powerpc-avoid-code-patching-freed-init-sections.patch
queue-4.4/powerpc-fsl-add-macro-to-flush-the-branch-predictor.patch
queue-4.4/powerpc-xmon-add-rfi-flush-related-fields-to-paca-dump.patch
queue-4.4/powerpc-fsl-add-barrier_nospec-implementation-for-nxp-powerpc-book3e.patch
queue-4.4/powerpc-security-fix-spectre_v2-reporting.patch
queue-4.4/powerpc-add-security-feature-flags-for-spectre-meltdown.patch
queue-4.4/powerpc-powernv-use-the-security-flags-in-pnv_setup_rfi_flush.patch
queue-4.4/powerpc-64-disable-the-speculation-barrier-from-the-command-line.patch
queue-4.4/powerpc-fsl-fix-the-flush-of-branch-predictor.patch
queue-4.4/powerpc-pseries-use-the-security-flags-in-pseries_setup_rfi_flush.patch
queue-4.4/powerpc-64-add-config_ppc_barrier_nospec.patch
queue-4.4/powerpc-64s-move-cpu_show_meltdown.patch
queue-4.4/powerpc-64-use-barrier_nospec-in-syscall-entry.patch
queue-4.4/powerpc-fsl-add-nospectre_v2-command-line-argument.patch
queue-4.4/powerpc-64s-add-new-security-feature-flags-for-count-cache-flush.patch
queue-4.4/powerpc-fsl-add-infrastructure-to-fixup-branch-predictor-flush.patch
queue-4.4/powerpc-rfi-flush-differentiate-enabled-and-patched-flush-types.patch
queue-4.4/powerpc-64s-enhance-the-information-in-cpu_show_spectre_v1.patch
queue-4.4/powerpc-64-call-setup_barrier_nospec-from-setup_arch.patch
queue-4.4/powerpc-rfi-flush-always-enable-fallback-flush-on-pseries.patch
queue-4.4/powerpc-64s-improve-rfi-l1-d-cache-flush-fallback.patch
queue-4.4/powerpc-asm-add-a-patch_site-macro-helpers-for-patching-instructions.patch
queue-4.4/powerpc-pseries-add-new-h_get_cpu_characteristics-flags.patch
queue-4.4/powerpc-64s-enable-barrier_nospec-based-on-firmware-settings.patch
queue-4.4/powerpc-powernv-support-firmware-disable-of-rfi-flush.patch
queue-4.4/powerpc-rfi-flush-move-the-logic-to-avoid-a-redo-into-the-debugfs-code.patch
queue-4.4/powerpc-powernv-query-firmware-for-count-cache-flush-settings.patch
queue-4.4/powerpc-64s-wire-up-cpu_show_spectre_v1.patch
queue-4.4/powerpc-64s-add-barrier_nospec.patch
queue-4.4/powerpc-64s-enhance-the-information-in-cpu_show_meltdown.patch
queue-4.4/powerpc-move-default-security-feature-flags.patch
queue-4.4/powerpc-pseries-fix-clearing-of-security-feature-flags.patch
queue-4.4/powerpc-pseries-restore-default-security-feature-flags-on-setup.patch
^ permalink raw reply
* Patch "powerpc/xmon: Add RFI flush related fields to paca dump" has been added to the 4.4-stable tree
From: gregkh @ 2019-04-29 9:51 UTC (permalink / raw)
To: christophe.leroy, diana.craciun, gregkh, linuxppc-dev, mpe,
msuchanek, npiggin
Cc: stable-commits
In-Reply-To: <20190421142037.21881-2-mpe@ellerman.id.au>
This is a note to let you know that I've just added the patch titled
powerpc/xmon: Add RFI flush related fields to paca dump
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-xmon-add-rfi-flush-related-fields-to-paca-dump.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From foo@baz Mon 29 Apr 2019 11:38:37 AM CEST
From: Michael Ellerman <mpe@ellerman.id.au>
Date: Mon, 22 Apr 2019 00:19:46 +1000
Subject: powerpc/xmon: Add RFI flush related fields to paca dump
To: stable@vger.kernel.org, gregkh@linuxfoundation.org
Cc: linuxppc-dev@ozlabs.org, diana.craciun@nxp.com, msuchanek@suse.de, npiggin@gmail.com, christophe.leroy@c-s.fr
Message-ID: <20190421142037.21881-2-mpe@ellerman.id.au>
From: Michael Ellerman <mpe@ellerman.id.au>
commit 274920a3ecd5f43af0cc380bc0a9ee73a52b9f8a upstream.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/xmon/xmon.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2144,6 +2144,10 @@ static void dump_one_paca(int cpu)
DUMP(p, slb_cache_ptr, "x");
for (i = 0; i < SLB_CACHE_ENTRIES; i++)
printf(" slb_cache[%d]: = 0x%016lx\n", i, p->slb_cache[i]);
+
+ DUMP(p, rfi_flush_fallback_area, "px");
+ DUMP(p, l1d_flush_congruence, "llx");
+ DUMP(p, l1d_flush_sets, "llx");
#endif
DUMP(p, dscr_default, "llx");
#ifdef CONFIG_PPC_BOOK3E
Patches currently in stable-queue which might be from mpe@ellerman.id.au are
queue-4.4/powerpc-64s-add-support-for-a-store-forwarding-barrier-at-kernel-entry-exit.patch
queue-4.4/powerpc-64-make-stf-barrier-ppc_book3s_64-specific.patch
queue-4.4/powerpc-pseries-set-or-clear-security-feature-flags.patch
queue-4.4/powerpc-fsl-fix-spectre_v2-mitigations-reporting.patch
queue-4.4/powerpc-64s-patch-barrier_nospec-in-modules.patch
queue-4.4/powerpc-pseries-support-firmware-disable-of-rfi-flush.patch
queue-4.4/powerpc-rfi-flush-call-setup_rfi_flush-after-lpm-migration.patch
queue-4.4/powerpc-pseries-query-hypervisor-for-count-cache-flush-settings.patch
queue-4.4/powerpc-powernv-set-or-clear-security-feature-flags.patch
queue-4.4/powerpc-64s-add-support-for-software-count-cache-flush.patch
queue-4.4/powerpc64s-show-ori31-availability-in-spectre_v1-sysfs-file-not-v2.patch
queue-4.4/powerpc-fsl-flush-the-branch-predictor-at-each-kernel-entry-64bit.patch
queue-4.4/powerpc-fsl-update-spectre-v2-reporting.patch
queue-4.4/powerpc-64s-wire-up-cpu_show_spectre_v2.patch
queue-4.4/powerpc-64-make-meltdown-reporting-book3s-64-specific.patch
queue-4.4/powerpc-rfi-flush-make-it-possible-to-call-setup_rfi_flush-again.patch
queue-4.4/powerpc-64s-add-support-for-ori-barrier_nospec-patching.patch
queue-4.4/powerpc-use-barrier_nospec-in-copy_from_user.patch
queue-4.4/powerpc-64s-fix-section-mismatch-warnings-from-setup_rfi_flush.patch
queue-4.4/powerpc-avoid-code-patching-freed-init-sections.patch
queue-4.4/powerpc-fsl-add-macro-to-flush-the-branch-predictor.patch
queue-4.4/powerpc-xmon-add-rfi-flush-related-fields-to-paca-dump.patch
queue-4.4/powerpc-fsl-add-barrier_nospec-implementation-for-nxp-powerpc-book3e.patch
queue-4.4/powerpc-security-fix-spectre_v2-reporting.patch
queue-4.4/powerpc-add-security-feature-flags-for-spectre-meltdown.patch
queue-4.4/powerpc-powernv-use-the-security-flags-in-pnv_setup_rfi_flush.patch
queue-4.4/powerpc-64-disable-the-speculation-barrier-from-the-command-line.patch
queue-4.4/powerpc-fsl-fix-the-flush-of-branch-predictor.patch
queue-4.4/powerpc-pseries-use-the-security-flags-in-pseries_setup_rfi_flush.patch
queue-4.4/powerpc-64-add-config_ppc_barrier_nospec.patch
queue-4.4/powerpc-64s-move-cpu_show_meltdown.patch
queue-4.4/powerpc-64-use-barrier_nospec-in-syscall-entry.patch
queue-4.4/powerpc-fsl-add-nospectre_v2-command-line-argument.patch
queue-4.4/powerpc-64s-add-new-security-feature-flags-for-count-cache-flush.patch
queue-4.4/powerpc-fsl-add-infrastructure-to-fixup-branch-predictor-flush.patch
queue-4.4/powerpc-rfi-flush-differentiate-enabled-and-patched-flush-types.patch
queue-4.4/powerpc-64s-enhance-the-information-in-cpu_show_spectre_v1.patch
queue-4.4/powerpc-64-call-setup_barrier_nospec-from-setup_arch.patch
queue-4.4/powerpc-rfi-flush-always-enable-fallback-flush-on-pseries.patch
queue-4.4/powerpc-64s-improve-rfi-l1-d-cache-flush-fallback.patch
queue-4.4/powerpc-asm-add-a-patch_site-macro-helpers-for-patching-instructions.patch
queue-4.4/powerpc-pseries-add-new-h_get_cpu_characteristics-flags.patch
queue-4.4/powerpc-64s-enable-barrier_nospec-based-on-firmware-settings.patch
queue-4.4/powerpc-powernv-support-firmware-disable-of-rfi-flush.patch
queue-4.4/powerpc-rfi-flush-move-the-logic-to-avoid-a-redo-into-the-debugfs-code.patch
queue-4.4/powerpc-powernv-query-firmware-for-count-cache-flush-settings.patch
queue-4.4/powerpc-64s-wire-up-cpu_show_spectre_v1.patch
queue-4.4/powerpc-64s-add-barrier_nospec.patch
queue-4.4/powerpc-64s-enhance-the-information-in-cpu_show_meltdown.patch
queue-4.4/powerpc-move-default-security-feature-flags.patch
queue-4.4/powerpc-pseries-fix-clearing-of-security-feature-flags.patch
queue-4.4/powerpc-pseries-restore-default-security-feature-flags-on-setup.patch
^ permalink raw reply
* Patch "powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2" has been added to the 4.4-stable tree
From: gregkh @ 2019-04-29 9:51 UTC (permalink / raw)
To: christophe.leroy, diana.craciun, gregkh, linuxppc-dev, mpe,
msuchanek, npiggin
Cc: stable-commits
In-Reply-To: <20190421142037.21881-33-mpe@ellerman.id.au>
This is a note to let you know that I've just added the patch titled
powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc64s-show-ori31-availability-in-spectre_v1-sysfs-file-not-v2.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From foo@baz Mon 29 Apr 2019 11:38:37 AM CEST
From: Michael Ellerman <mpe@ellerman.id.au>
Date: Mon, 22 Apr 2019 00:20:17 +1000
Subject: powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2
To: stable@vger.kernel.org, gregkh@linuxfoundation.org
Cc: linuxppc-dev@ozlabs.org, diana.craciun@nxp.com, msuchanek@suse.de, npiggin@gmail.com, christophe.leroy@c-s.fr
Message-ID: <20190421142037.21881-33-mpe@ellerman.id.au>
From: Michael Ellerman <mpe@ellerman.id.au>
commit 6d44acae1937b81cf8115ada8958e04f601f3f2e upstream.
When I added the spectre_v2 information in sysfs, I included the
availability of the ori31 speculation barrier.
Although the ori31 barrier can be used to mitigate v2, it's primarily
intended as a spectre v1 mitigation. Spectre v2 is mitigated by
hardware changes.
So rework the sysfs files to show the ori31 information in the
spectre_v1 file, rather than v2.
Currently we display eg:
$ grep . spectre_v*
spectre_v1:Mitigation: __user pointer sanitization
spectre_v2:Mitigation: Indirect branch cache disabled, ori31 speculation barrier enabled
After:
$ grep . spectre_v*
spectre_v1:Mitigation: __user pointer sanitization, ori31 speculation barrier enabled
spectre_v2:Mitigation: Indirect branch cache disabled
Fixes: d6fbe1c55c55 ("powerpc/64s: Wire up cpu_show_spectre_v2()")
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/security.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -118,25 +118,35 @@ ssize_t cpu_show_meltdown(struct device
ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr, char *buf)
{
- if (!security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR))
- return sprintf(buf, "Not affected\n");
+ struct seq_buf s;
+
+ seq_buf_init(&s, buf, PAGE_SIZE - 1);
+
+ if (security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR)) {
+ if (barrier_nospec_enabled)
+ seq_buf_printf(&s, "Mitigation: __user pointer sanitization");
+ else
+ seq_buf_printf(&s, "Vulnerable");
- if (barrier_nospec_enabled)
- return sprintf(buf, "Mitigation: __user pointer sanitization\n");
+ if (security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31))
+ seq_buf_printf(&s, ", ori31 speculation barrier enabled");
- return sprintf(buf, "Vulnerable\n");
+ seq_buf_printf(&s, "\n");
+ } else
+ seq_buf_printf(&s, "Not affected\n");
+
+ return s.len;
}
ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr, char *buf)
{
- bool bcs, ccd, ori;
struct seq_buf s;
+ bool bcs, ccd;
seq_buf_init(&s, buf, PAGE_SIZE - 1);
bcs = security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED);
ccd = security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED);
- ori = security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31);
if (bcs || ccd) {
seq_buf_printf(&s, "Mitigation: ");
@@ -152,9 +162,6 @@ ssize_t cpu_show_spectre_v2(struct devic
} else
seq_buf_printf(&s, "Vulnerable");
- if (ori)
- seq_buf_printf(&s, ", ori31 speculation barrier enabled");
-
seq_buf_printf(&s, "\n");
return s.len;
Patches currently in stable-queue which might be from mpe@ellerman.id.au are
queue-4.4/powerpc-64s-add-support-for-a-store-forwarding-barrier-at-kernel-entry-exit.patch
queue-4.4/powerpc-64-make-stf-barrier-ppc_book3s_64-specific.patch
queue-4.4/powerpc-pseries-set-or-clear-security-feature-flags.patch
queue-4.4/powerpc-fsl-fix-spectre_v2-mitigations-reporting.patch
queue-4.4/powerpc-64s-patch-barrier_nospec-in-modules.patch
queue-4.4/powerpc-pseries-support-firmware-disable-of-rfi-flush.patch
queue-4.4/powerpc-rfi-flush-call-setup_rfi_flush-after-lpm-migration.patch
queue-4.4/powerpc-pseries-query-hypervisor-for-count-cache-flush-settings.patch
queue-4.4/powerpc-powernv-set-or-clear-security-feature-flags.patch
queue-4.4/powerpc-64s-add-support-for-software-count-cache-flush.patch
queue-4.4/powerpc64s-show-ori31-availability-in-spectre_v1-sysfs-file-not-v2.patch
queue-4.4/powerpc-fsl-flush-the-branch-predictor-at-each-kernel-entry-64bit.patch
queue-4.4/powerpc-fsl-update-spectre-v2-reporting.patch
queue-4.4/powerpc-64s-wire-up-cpu_show_spectre_v2.patch
queue-4.4/powerpc-64-make-meltdown-reporting-book3s-64-specific.patch
queue-4.4/powerpc-rfi-flush-make-it-possible-to-call-setup_rfi_flush-again.patch
queue-4.4/powerpc-64s-add-support-for-ori-barrier_nospec-patching.patch
queue-4.4/powerpc-use-barrier_nospec-in-copy_from_user.patch
queue-4.4/powerpc-64s-fix-section-mismatch-warnings-from-setup_rfi_flush.patch
queue-4.4/powerpc-avoid-code-patching-freed-init-sections.patch
queue-4.4/powerpc-fsl-add-macro-to-flush-the-branch-predictor.patch
queue-4.4/powerpc-xmon-add-rfi-flush-related-fields-to-paca-dump.patch
queue-4.4/powerpc-fsl-add-barrier_nospec-implementation-for-nxp-powerpc-book3e.patch
queue-4.4/powerpc-security-fix-spectre_v2-reporting.patch
queue-4.4/powerpc-add-security-feature-flags-for-spectre-meltdown.patch
queue-4.4/powerpc-powernv-use-the-security-flags-in-pnv_setup_rfi_flush.patch
queue-4.4/powerpc-64-disable-the-speculation-barrier-from-the-command-line.patch
queue-4.4/powerpc-fsl-fix-the-flush-of-branch-predictor.patch
queue-4.4/powerpc-pseries-use-the-security-flags-in-pseries_setup_rfi_flush.patch
queue-4.4/powerpc-64-add-config_ppc_barrier_nospec.patch
queue-4.4/powerpc-64s-move-cpu_show_meltdown.patch
queue-4.4/powerpc-64-use-barrier_nospec-in-syscall-entry.patch
queue-4.4/powerpc-fsl-add-nospectre_v2-command-line-argument.patch
queue-4.4/powerpc-64s-add-new-security-feature-flags-for-count-cache-flush.patch
queue-4.4/powerpc-fsl-add-infrastructure-to-fixup-branch-predictor-flush.patch
queue-4.4/powerpc-rfi-flush-differentiate-enabled-and-patched-flush-types.patch
queue-4.4/powerpc-64s-enhance-the-information-in-cpu_show_spectre_v1.patch
queue-4.4/powerpc-64-call-setup_barrier_nospec-from-setup_arch.patch
queue-4.4/powerpc-rfi-flush-always-enable-fallback-flush-on-pseries.patch
queue-4.4/powerpc-64s-improve-rfi-l1-d-cache-flush-fallback.patch
queue-4.4/powerpc-asm-add-a-patch_site-macro-helpers-for-patching-instructions.patch
queue-4.4/powerpc-pseries-add-new-h_get_cpu_characteristics-flags.patch
queue-4.4/powerpc-64s-enable-barrier_nospec-based-on-firmware-settings.patch
queue-4.4/powerpc-powernv-support-firmware-disable-of-rfi-flush.patch
queue-4.4/powerpc-rfi-flush-move-the-logic-to-avoid-a-redo-into-the-debugfs-code.patch
queue-4.4/powerpc-powernv-query-firmware-for-count-cache-flush-settings.patch
queue-4.4/powerpc-64s-wire-up-cpu_show_spectre_v1.patch
queue-4.4/powerpc-64s-add-barrier_nospec.patch
queue-4.4/powerpc-64s-enhance-the-information-in-cpu_show_meltdown.patch
queue-4.4/powerpc-move-default-security-feature-flags.patch
queue-4.4/powerpc-pseries-fix-clearing-of-security-feature-flags.patch
queue-4.4/powerpc-pseries-restore-default-security-feature-flags-on-setup.patch
^ permalink raw reply
* Patch "powerpc: Use barrier_nospec in copy_from_user()" has been added to the 4.4-stable tree
From: gregkh @ 2019-04-29 9:51 UTC (permalink / raw)
To: christophe.leroy, diana.craciun, gregkh, linuxppc-dev, mpe,
msuchanek, npiggin
Cc: stable-commits
In-Reply-To: <20190421142037.21881-31-mpe@ellerman.id.au>
This is a note to let you know that I've just added the patch titled
powerpc: Use barrier_nospec in copy_from_user()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-use-barrier_nospec-in-copy_from_user.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From foo@baz Mon 29 Apr 2019 11:38:37 AM CEST
From: Michael Ellerman <mpe@ellerman.id.au>
Date: Mon, 22 Apr 2019 00:20:15 +1000
Subject: powerpc: Use barrier_nospec in copy_from_user()
To: stable@vger.kernel.org, gregkh@linuxfoundation.org
Cc: linuxppc-dev@ozlabs.org, diana.craciun@nxp.com, msuchanek@suse.de, npiggin@gmail.com, christophe.leroy@c-s.fr
Message-ID: <20190421142037.21881-31-mpe@ellerman.id.au>
From: Michael Ellerman <mpe@ellerman.id.au>
commit ddf35cf3764b5a182b178105f57515b42e2634f8 upstream.
Based on the x86 commit doing the same.
See commit 304ec1b05031 ("x86/uaccess: Use __uaccess_begin_nospec()
and uaccess_try_nospec") and b3bbfb3fb5d2 ("x86: Introduce
__uaccess_begin_nospec() and uaccess_try_nospec") for more detail.
In all cases we are ordering the load from the potentially
user-controlled pointer vs a previous branch based on an access_ok()
check or similar.
Base on a patch from Michal Suchanek.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/include/asm/uaccess.h | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -269,6 +269,7 @@ do { \
__chk_user_ptr(ptr); \
if (!is_kernel_addr((unsigned long)__gu_addr)) \
might_fault(); \
+ barrier_nospec(); \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
@@ -283,6 +284,7 @@ do { \
__chk_user_ptr(ptr); \
if (!is_kernel_addr((unsigned long)__gu_addr)) \
might_fault(); \
+ barrier_nospec(); \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__force __typeof__(*(ptr)))__gu_val; \
__gu_err; \
@@ -295,8 +297,10 @@ do { \
unsigned long __gu_val = 0; \
__typeof__(*(ptr)) __user *__gu_addr = (ptr); \
might_fault(); \
- if (access_ok(VERIFY_READ, __gu_addr, (size))) \
+ if (access_ok(VERIFY_READ, __gu_addr, (size))) { \
+ barrier_nospec(); \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
+ } \
(x) = (__force __typeof__(*(ptr)))__gu_val; \
__gu_err; \
})
@@ -307,6 +311,7 @@ do { \
unsigned long __gu_val; \
__typeof__(*(ptr)) __user *__gu_addr = (ptr); \
__chk_user_ptr(ptr); \
+ barrier_nospec(); \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__force __typeof__(*(ptr)))__gu_val; \
__gu_err; \
@@ -323,8 +328,10 @@ extern unsigned long __copy_tofrom_user(
static inline unsigned long copy_from_user(void *to,
const void __user *from, unsigned long n)
{
- if (likely(access_ok(VERIFY_READ, from, n)))
+ if (likely(access_ok(VERIFY_READ, from, n))) {
+ barrier_nospec();
return __copy_tofrom_user((__force void __user *)to, from, n);
+ }
memset(to, 0, n);
return n;
}
@@ -359,21 +366,27 @@ static inline unsigned long __copy_from_
switch (n) {
case 1:
+ barrier_nospec();
__get_user_size(*(u8 *)to, from, 1, ret);
break;
case 2:
+ barrier_nospec();
__get_user_size(*(u16 *)to, from, 2, ret);
break;
case 4:
+ barrier_nospec();
__get_user_size(*(u32 *)to, from, 4, ret);
break;
case 8:
+ barrier_nospec();
__get_user_size(*(u64 *)to, from, 8, ret);
break;
}
if (ret == 0)
return 0;
}
+
+ barrier_nospec();
return __copy_tofrom_user((__force void __user *)to, from, n);
}
@@ -400,6 +413,7 @@ static inline unsigned long __copy_to_us
if (ret == 0)
return 0;
}
+
return __copy_tofrom_user(to, (__force const void __user *)from, n);
}
Patches currently in stable-queue which might be from mpe@ellerman.id.au are
queue-4.4/powerpc-64s-add-support-for-a-store-forwarding-barrier-at-kernel-entry-exit.patch
queue-4.4/powerpc-64-make-stf-barrier-ppc_book3s_64-specific.patch
queue-4.4/powerpc-pseries-set-or-clear-security-feature-flags.patch
queue-4.4/powerpc-fsl-fix-spectre_v2-mitigations-reporting.patch
queue-4.4/powerpc-64s-patch-barrier_nospec-in-modules.patch
queue-4.4/powerpc-pseries-support-firmware-disable-of-rfi-flush.patch
queue-4.4/powerpc-rfi-flush-call-setup_rfi_flush-after-lpm-migration.patch
queue-4.4/powerpc-pseries-query-hypervisor-for-count-cache-flush-settings.patch
queue-4.4/powerpc-powernv-set-or-clear-security-feature-flags.patch
queue-4.4/powerpc-64s-add-support-for-software-count-cache-flush.patch
queue-4.4/powerpc64s-show-ori31-availability-in-spectre_v1-sysfs-file-not-v2.patch
queue-4.4/powerpc-fsl-flush-the-branch-predictor-at-each-kernel-entry-64bit.patch
queue-4.4/powerpc-fsl-update-spectre-v2-reporting.patch
queue-4.4/powerpc-64s-wire-up-cpu_show_spectre_v2.patch
queue-4.4/powerpc-64-make-meltdown-reporting-book3s-64-specific.patch
queue-4.4/powerpc-rfi-flush-make-it-possible-to-call-setup_rfi_flush-again.patch
queue-4.4/powerpc-64s-add-support-for-ori-barrier_nospec-patching.patch
queue-4.4/powerpc-use-barrier_nospec-in-copy_from_user.patch
queue-4.4/powerpc-64s-fix-section-mismatch-warnings-from-setup_rfi_flush.patch
queue-4.4/powerpc-avoid-code-patching-freed-init-sections.patch
queue-4.4/powerpc-fsl-add-macro-to-flush-the-branch-predictor.patch
queue-4.4/powerpc-xmon-add-rfi-flush-related-fields-to-paca-dump.patch
queue-4.4/powerpc-fsl-add-barrier_nospec-implementation-for-nxp-powerpc-book3e.patch
queue-4.4/powerpc-security-fix-spectre_v2-reporting.patch
queue-4.4/powerpc-add-security-feature-flags-for-spectre-meltdown.patch
queue-4.4/powerpc-powernv-use-the-security-flags-in-pnv_setup_rfi_flush.patch
queue-4.4/powerpc-64-disable-the-speculation-barrier-from-the-command-line.patch
queue-4.4/powerpc-fsl-fix-the-flush-of-branch-predictor.patch
queue-4.4/powerpc-pseries-use-the-security-flags-in-pseries_setup_rfi_flush.patch
queue-4.4/powerpc-64-add-config_ppc_barrier_nospec.patch
queue-4.4/powerpc-64s-move-cpu_show_meltdown.patch
queue-4.4/powerpc-64-use-barrier_nospec-in-syscall-entry.patch
queue-4.4/powerpc-fsl-add-nospectre_v2-command-line-argument.patch
queue-4.4/powerpc-64s-add-new-security-feature-flags-for-count-cache-flush.patch
queue-4.4/powerpc-fsl-add-infrastructure-to-fixup-branch-predictor-flush.patch
queue-4.4/powerpc-rfi-flush-differentiate-enabled-and-patched-flush-types.patch
queue-4.4/powerpc-64s-enhance-the-information-in-cpu_show_spectre_v1.patch
queue-4.4/powerpc-64-call-setup_barrier_nospec-from-setup_arch.patch
queue-4.4/powerpc-rfi-flush-always-enable-fallback-flush-on-pseries.patch
queue-4.4/powerpc-64s-improve-rfi-l1-d-cache-flush-fallback.patch
queue-4.4/powerpc-asm-add-a-patch_site-macro-helpers-for-patching-instructions.patch
queue-4.4/powerpc-pseries-add-new-h_get_cpu_characteristics-flags.patch
queue-4.4/powerpc-64s-enable-barrier_nospec-based-on-firmware-settings.patch
queue-4.4/powerpc-powernv-support-firmware-disable-of-rfi-flush.patch
queue-4.4/powerpc-rfi-flush-move-the-logic-to-avoid-a-redo-into-the-debugfs-code.patch
queue-4.4/powerpc-powernv-query-firmware-for-count-cache-flush-settings.patch
queue-4.4/powerpc-64s-wire-up-cpu_show_spectre_v1.patch
queue-4.4/powerpc-64s-add-barrier_nospec.patch
queue-4.4/powerpc-64s-enhance-the-information-in-cpu_show_meltdown.patch
queue-4.4/powerpc-move-default-security-feature-flags.patch
queue-4.4/powerpc-pseries-fix-clearing-of-security-feature-flags.patch
queue-4.4/powerpc-pseries-restore-default-security-feature-flags-on-setup.patch
^ permalink raw reply
* Re: [PATCH 40/41] drivers: tty: serial: helper for setting mmio range
From: Enrico Weigelt, metux IT consult @ 2019-04-29 10:12 UTC (permalink / raw)
To: Andy Shevchenko, Enrico Weigelt, metux IT consult
Cc: lorenzo.pieralisi, linux-ia64, linux-serial, andrew, gregkh,
sudeep.holla, liviu.dudau, linux-kernel, vz, linux, sparclinux,
khilman, macro, slemieux.tyco, matthias.bgg, jacmet,
linux-amlogic, linux-mips, linuxppc-dev, davem
In-Reply-To: <20190428153905.GR9224@smile.fi.intel.com>
On 28.04.19 17:39, Andy Shevchenko wrote:
Hi,
seems I've forgot to add "RFC:" in the subject - I'm not entirely happy
w/ that patch myself, just want to hear your oppinions.
>> - port->port.iotype = UPIO_MEM;>> - port->port.mapbase = pci_resource_start(pcidev, bar) + offset;>> +
uart_memres_set_start_len(&port->port,>> +
pci_resource_start(pcidev, bar) + offset,>> +
pci_resource_len(pcidev, bar));>> +> > I don't see how it's better.>
Moreover, the size argument seems wrong here.
hmm, I'm actually not sure yet, what the correct size really would be,
where the value actually comes from. Just assumed that it would be the
whole area that the BAR tells. But now I recognized that I'd need to
substract 'offset' here.
Rethinking it further, we'd probably could deduce the UPIO_* from the
struct resource, too.
>> + uart_memres_set_start_len(>> + &port,>> + FRODO_BASE + FRODO_APCI_OFFSET(1), 0);> > Please,
avoid such splitting, first parameter is quite fit above line.
Ok. My intention was having both parameters starting at the same line,
but then the second line would get too long again. > ...and here, and
maybe in other places you split the assignments to the members> in two
part. Better to call your function before or after these blocks of>
assignments.
the reason what I've just replaced the exactly the assignments, trying
not to touch too much ;-)
I'll have a closer look on what can be moved w/o side effects.
>> - uport->mapsize = ZS_CHAN_IO_SIZE;
>> - uport->mapbase = dec_kn_slot_base +
>> - zs_parms.scc[chip] +
>> - (side ^ ZS_CHAN_B) * ZS_CHAN_IO_SIZE;
>> +
>> + uart_memres_set_start_len(dec_kn_slot_base +
>> + zs_parms.scc[chip] +
>> + (side ^ ZS_CHAN_B) *
>> + ZS_CHAN_IO_SIZE,
>> + ZS_CHAN_IO_SIZE);
>
> This looks hard to read. Think of temporary variables and better formatting
> style.
Ok.
>
>> /*
>> + * set physical io range from struct resource
>> + * if resource is NULL, clear the fields
>> + * also set the iotype to UPIO_MEM
>
> Something wrong with punctuation and style. Please, use proper casing and
> sentences split.
Ok. fixed it.
>> +static inline void uart_memres_set_res(struct uart_port *port,
>
> Perhaps better name can be found.
> Especially taking into account that it handles IO / MMIO here.
hmm, lacking creativity here ;-)
any suggestions ?
>
>> + struct resource *res)
>> +{
>> + if (!res) {
>
> It should return an error in such case.
It's not an error, but desired behaviour: NULL resource
clears the value.
>> + port->mapsize = 0;
>> + port->mapbase = 0;
>> + port->iobase = 0;
>> + return;
>> + }
>> +
>> + if (resource_type(res) == IORESOURCE_IO) {
>> + port->iotype = UPIO_PORT;
>> + port->iobase = resource->start;
>> + return;
>> + }
>> +
>> + uart->mapbase = res->start;
>> + uart->mapsize = resource_size(res);
>
>> + uart->iotype = UPIO_MEM;
>
> Only one type? Why type is even set here?
It's the default case. The special cases (eg. UPIO_MEM32) need to be
set explicitly, after that call.
Not really nice, but haven't found a better solution yet. I don't like
the idea of passing an UPIO_* parameter to the function, most callers
should not care, if they don't really need to.
>> + */
>
>> +static inline void uart_memres_set_start_len(struct uart_driver *uart,
>> + resource_size_t start,
>> + resource_size_t len)
>
> The comment doesn't tell why this is needed when we have one for struct
> resource.
Renamed it to uart_memres_set_mmio_range().
This helper is meant for drivers that don't work w/ struct resource,
or explicitly set their own len.
Thanks for your review.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* [PATCH 1/3] powerpc: Move PPC_HA() PPC_HI() and PPC_LO() to ppc-opcode.h
From: Christophe Leroy @ 2019-04-29 10:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
PPC_HA() PPC_HI() and PPC_LO() macros are nice macros. Move them
from module64.c to ppc-opcode.h in order to use them in other places.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/include/asm/ppc-opcode.h | 7 +++++++
arch/powerpc/kernel/module_64.c | 7 -------
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index 23f7ed796f38..c5ff44400d4d 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -412,6 +412,13 @@
#define __PPC_SPR(r) ((((r) & 0x1f) << 16) | ((((r) >> 5) & 0x1f) << 11))
#define __PPC_RC21 (0x1 << 10)
+/* Both low and high 16 bits are added as SIGNED additions, so if low
+ 16 bits has high bit set, high 16 bits must be adjusted. These
+ macros do that (stolen from binutils). */
+#define PPC_LO(v) ((v) & 0xffff)
+#define PPC_HI(v) (((v) >> 16) & 0xffff)
+#define PPC_HA(v) PPC_HI ((v) + 0x8000)
+
/*
* Only use the larx hint bit on 64bit CPUs. e500v1/v2 based CPUs will treat a
* larx with EH set as an illegal instruction.
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 8661eea78503..c2e1b06253b8 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -400,13 +400,6 @@ static inline unsigned long my_r2(const Elf64_Shdr *sechdrs, struct module *me)
return (sechdrs[me->arch.toc_section].sh_addr & ~0xfful) + 0x8000;
}
-/* Both low and high 16 bits are added as SIGNED additions, so if low
- 16 bits has high bit set, high 16 bits must be adjusted. These
- macros do that (stolen from binutils). */
-#define PPC_LO(v) ((v) & 0xffff)
-#define PPC_HI(v) (((v) >> 16) & 0xffff)
-#define PPC_HA(v) PPC_HI ((v) + 0x8000)
-
/* Patch stub to reference function and correct r2 value. */
static inline int create_stub(const Elf64_Shdr *sechdrs,
struct ppc64_stub_entry *entry,
--
2.13.3
^ permalink raw reply related
* [PATCH 3/3] powerpc/module64: Use symbolic instructions names.
From: Christophe Leroy @ 2019-04-29 10:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <23167861f6095456b4ba3b52c55a514201ca738f.1556534520.git.christophe.leroy@c-s.fr>
To increase readability/maintainability, replace hard coded
instructions values by symbolic names.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/kernel/module_64.c | 54 ++++++++++++++++++++++++++++-------------
1 file changed, 37 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index c2e1b06253b8..87097eae600b 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -135,18 +135,28 @@ struct ppc64_stub_entry
* to the TOC ptr, r2) into the stub.
*/
+ unsigned int i, num_stubs;
+ /*
+ * addis r11,r2, <high>
+ * addi r11,r11, <low>
+ * std r2,R2_STACK_OFFSET(r1)
+ * ld r12,32(r11)
+ * ld r2,40(r11)
+ * mtctr r12
+ * bctr
+ */
static u32 ppc64_stub_insns[] = {
- 0x3d620000, /* addis r11,r2, <high> */
- 0x396b0000, /* addi r11,r11, <low> */
+ PPC_INST_ADDIS | __PPC_RT(R11) | __PPC_RA(R2),
+ PPC_INST_ADDI | __PPC_RT(R11) | __PPC_RA(R11),
/* Save current r2 value in magic place on the stack. */
- 0xf8410000|R2_STACK_OFFSET, /* std r2,R2_STACK_OFFSET(r1) */
- 0xe98b0020, /* ld r12,32(r11) */
+ PPC_INST_STD | __PPC_RS(R2) | __PPC_RA(R1) | R2_STACK_OFFSET,
+ PPC_INST_LD | __PPC_RT(R12) | __PPC_RA(R11) | 32,
#ifdef PPC64_ELF_ABI_v1
/* Set up new r2 from function descriptor */
- 0xe84b0028, /* ld r2,40(r11) */
+ PPC_INST_LD | __PPC_RT(R2) | __PPC_RA(R11) | 40,
#endif
- 0x7d8903a6, /* mtctr r12 */
- 0x4e800420 /* bctr */
+ PPC_INST_MTCTR | __PPC_RS(R12),
+ PPC_INST_BCTR,
};
#ifdef CONFIG_DYNAMIC_FTRACE
@@ -704,18 +714,21 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
* ld r2, ...(r12)
* add r2, r2, r12
*/
- if ((((uint32_t *)location)[0] & ~0xfffc)
- != 0xe84c0000)
+ if ((((uint32_t *)location)[0] & ~0xfffc) !=
+ PPC_INST_LD | __PPC_RT(R2) | __PPC_RA(R12))
break;
- if (((uint32_t *)location)[1] != 0x7c426214)
+ if (((uint32_t *)location)[1] !=
+ PPC_INST_ADD | __PPC_RT(R2) | __PPC_RA(R2) | __PPC_RB(R12))
break;
/*
* If found, replace it with:
* addis r2, r12, (.TOC.-func)@ha
* addi r2, r12, (.TOC.-func)@l
*/
- ((uint32_t *)location)[0] = 0x3c4c0000 + PPC_HA(value);
- ((uint32_t *)location)[1] = 0x38420000 + PPC_LO(value);
+ ((uint32_t *)location)[0] = PPC_INST_ADDIS | __PPC_RT(R2) |
+ __PPC_RA(R12) | PPC_HA(value);
+ ((uint32_t *)location)[1] = PPC_INST_ADDI | __PPC_RT(R2) |
+ __PPC_RA(R12) | PPC_LO(value);
break;
case R_PPC64_REL16_HA:
@@ -769,12 +782,19 @@ static unsigned long create_ftrace_stub(const Elf64_Shdr *sechdrs,
{
struct ppc64_stub_entry *entry;
unsigned int i, num_stubs;
+ /*
+ * ld r12,PACATOC(r13)
+ * addis r12,r12,<high>
+ * addi r12,r12,<low>
+ * mtctr r12
+ * bctr
+ */
static u32 stub_insns[] = {
- 0xe98d0000 | PACATOC, /* ld r12,PACATOC(r13) */
- 0x3d8c0000, /* addis r12,r12,<high> */
- 0x398c0000, /* addi r12,r12,<low> */
- 0x7d8903a6, /* mtctr r12 */
- 0x4e800420, /* bctr */
+ PPC_INST_LD | __PPC_RT(R12) | __PPC_RA(R13) | PACATOC,
+ PPC_INST_ADDIS | __PPC_RT(R12) | __PPC_RA(R12),
+ PPC_INST_ADDI | __PPC_RT(R12) | __PPC_RA(R12),
+ PPC_INST_MTCTR | __PPC_RS(R12),
+ PPC_INST_BCTR,
};
long reladdr;
--
2.13.3
^ permalink raw reply related
* [PATCH 2/3] powerpc/module32: Use symbolic instructions names.
From: Christophe Leroy @ 2019-04-29 10:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <23167861f6095456b4ba3b52c55a514201ca738f.1556534520.git.christophe.leroy@c-s.fr>
To increase readability/maintainability, replace hard coded
instructions values by symbolic names.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/kernel/module_32.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c
index 88d83771f462..c5197f856c75 100644
--- a/arch/powerpc/kernel/module_32.c
+++ b/arch/powerpc/kernel/module_32.c
@@ -170,10 +170,14 @@ int module_frob_arch_sections(Elf32_Ehdr *hdr,
return 0;
}
+ /* lis r12,sym@ha */
+#define ENTRY_JMP0(sym) (PPC_INST_ADDIS | __PPC_RT(R12) | PPC_HA(sym))
+ /* addi r12,r12,sym@l */
+#define ENTRY_JMP1(sym) (PPC_INST_ADDI | __PPC_RT(R12) | __PPC_RA(R12) | PPC_LO(sym))
+
static inline int entry_matches(struct ppc_plt_entry *entry, Elf32_Addr val)
{
- if (entry->jump[0] == 0x3d800000 + ((val + 0x8000) >> 16)
- && entry->jump[1] == 0x398c0000 + (val & 0xffff))
+ if (entry->jump[0] == ENTRY_JMP0(val) && entry->jump[1] == ENTRY_JMP1(val))
return 1;
return 0;
}
@@ -200,10 +204,10 @@ static uint32_t do_plt_call(void *location,
entry++;
}
- entry->jump[0] = 0x3d800000+((val+0x8000)>>16); /* lis r12,sym@ha */
- entry->jump[1] = 0x398c0000 + (val&0xffff); /* addi r12,r12,sym@l*/
- entry->jump[2] = 0x7d8903a6; /* mtctr r12 */
- entry->jump[3] = 0x4e800420; /* bctr */
+ entry->jump[0] = ENTRY_JMP0(val);
+ entry->jump[1] = ENTRY_JMP1(val);
+ entry->jump[2] = PPC_INST_MTCTR | __PPC_RS(R12);
+ entry->jump[3] = PPC_INST_BCTR;
pr_debug("Initialized plt for 0x%x at %p\n", val, entry);
return (uint32_t)entry;
--
2.13.3
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv/npu: Fix reference leak
From: Greg Kurz @ 2019-04-29 10:36 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, linux-kernel, stable, Alistair Popple
In-Reply-To: <962c1d9e-719c-cb82-cabc-1cf619e1510b@ozlabs.ru>
On Mon, 29 Apr 2019 16:01:29 +1000
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 20/04/2019 01:34, Greg Kurz wrote:
> > Since 902bdc57451c, get_pci_dev() calls pci_get_domain_bus_and_slot(). This
> > has the effect of incrementing the reference count of the PCI device, as
> > explained in drivers/pci/search.c:
> >
> > * Given a PCI domain, bus, and slot/function number, the desired PCI
> > * device is located in the list of PCI devices. If the device is
> > * found, its reference count is increased and this function returns a
> > * pointer to its data structure. The caller must decrement the
> > * reference count by calling pci_dev_put(). If no device is found,
> > * %NULL is returned.
> >
> > Nothing was done to call pci_dev_put() and the reference count of GPU and
> > NPU PCI devices rockets up.
> >
> > A natural way to fix this would be to teach the callers about the change,
> > so that they call pci_dev_put() when done with the pointer. This turns
> > out to be quite intrusive, as it affects many paths in npu-dma.c,
> > pci-ioda.c and vfio_pci_nvlink2.c.
>
>
> afaict this referencing is only done to protect the current traverser
> and what you've done is actually a natural way (and the generic
> pci_get_dev_by_id() does exactly the same), although this looks a bit weird.
>
Not exactly the same: pci_get_dev_by_id() always increment the refcount
of the returned PCI device. The refcount is only decremented when this
device is passed to pci_get_dev_by_id() to continue searching.
That means that the users of the PCI device pointer returned by
pci_get_dev_by_id() or its exported variants pci_get_subsys(),
pci_get_device() and pci_get_class() do handle the refcount. They
all pass the pointer to pci_dev_put() or continue the search,
which calls pci_dev_put() internally.
Direct and indirect callers of get_pci_dev() don't care for the
refcount at all unless I'm missing something.
>
> > Also, the issue appeared in 4.16 and
> > some affected code got moved around since then: it would be problematic
> > to backport the fix to stable releases.
> >
> > All that code never cared for reference counting anyway. Call pci_dev_put()
> > from get_pci_dev() to revert to the previous behavior.
> >> Fixes: 902bdc57451c ("powerpc/powernv/idoa: Remove unnecessary pcidev
> from pci_dn")
> > Cc: stable@vger.kernel.org # v4.16
> > Signed-off-by: Greg Kurz <groug@kaod.org>
> > ---
> > arch/powerpc/platforms/powernv/npu-dma.c | 15 ++++++++++++++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/platforms/powernv/npu-dma.c b/arch/powerpc/platforms/powernv/npu-dma.c
> > index e713ade30087..d8f3647e8fb2 100644
> > --- a/arch/powerpc/platforms/powernv/npu-dma.c
> > +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> > @@ -31,9 +31,22 @@ static DEFINE_SPINLOCK(npu_context_lock);
> > static struct pci_dev *get_pci_dev(struct device_node *dn)
> > {
> > struct pci_dn *pdn = PCI_DN(dn);
> > + struct pci_dev *pdev;
> >
> > - return pci_get_domain_bus_and_slot(pci_domain_nr(pdn->phb->bus),
> > + pdev = pci_get_domain_bus_and_slot(pci_domain_nr(pdn->phb->bus),
> > pdn->busno, pdn->devfn);
> > +
> > + /*
> > + * pci_get_domain_bus_and_slot() increased the reference count of
> > + * the PCI device, but callers don't need that actually as the PE
> > + * already holds a reference to the device.
>
> Imho this would be just enough.
>
> Anyway,
>
> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>
Thanks !
I now realize that I forgot to add the --cc option for stable on my stgit
command line :-\.
Cc'ing now.
>
> How did you find it? :)
>
While reading code to find some inspiration for OpenCAPI passthrough. :)
I saw the following in vfio_pci_ibm_npu2_init():
if (!pnv_pci_get_gpu_dev(vdev->pdev))
return -ENODEV;
and simply followed the function calls.
>
> > Since callers aren't
> > + * aware of the reference count change, call pci_dev_put() now to
> > + * avoid leaks.
> > + */
> > + if (pdev)
> > + pci_dev_put(pdev);
> > +
> > + return pdev;
> > }
> >
> > /* Given a NPU device get the associated PCI device. */
> >
>
^ permalink raw reply
* [PATCH] powerpc: remove the __kernel_io_end export
From: Christoph Hellwig @ 2019-04-29 11:52 UTC (permalink / raw)
To: mpe; +Cc: aneesh.kumar, linuxppc-dev, linux-kernel
This export was added in this merge window, but without any actual
user, or justification for a modular user.
Fixes: a35a3c6f6065 ("powerpc/mm/hash64: Add a variable to track the end of IO mapping")
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/powerpc/mm/pgtable_64.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 72f58c076e26..1fddc81cc682 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -96,7 +96,6 @@ unsigned long __vmalloc_end;
EXPORT_SYMBOL(__vmalloc_end);
unsigned long __kernel_io_start;
EXPORT_SYMBOL(__kernel_io_start);
-unsigned long __kernel_io_end;
EXPORT_SYMBOL(__kernel_io_end);
struct page *vmemmap;
EXPORT_SYMBOL(vmemmap);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 2/3] powerpc/module32: Use symbolic instructions names.
From: Segher Boessenkool @ 2019-04-29 11:54 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <14f88b27ff94f2d5a07a8cbc33ec75e2f8af9cf9.1556534520.git.christophe.leroy@c-s.fr>
On Mon, Apr 29, 2019 at 10:43:27AM +0000, Christophe Leroy wrote:
> To increase readability/maintainability, replace hard coded
> instructions values by symbolic names.
> + /* lis r12,sym@ha */
> +#define ENTRY_JMP0(sym) (PPC_INST_ADDIS | __PPC_RT(R12) | PPC_HA(sym))
> + /* addi r12,r12,sym@l */
> +#define ENTRY_JMP1(sym) (PPC_INST_ADDI | __PPC_RT(R12) | __PPC_RA(R12) | PPC_LO(sym))
Those aren't "jump" instructions though, as the name suggests... And you
only have names for the first two of the four insns. ("2" and "3" were
still available ;-) )
> - entry->jump[0] = 0x3d800000+((val+0x8000)>>16); /* lis r12,sym@ha */
> - entry->jump[1] = 0x398c0000 + (val&0xffff); /* addi r12,r12,sym@l*/
> - entry->jump[2] = 0x7d8903a6; /* mtctr r12 */
> - entry->jump[3] = 0x4e800420; /* bctr */
> + entry->jump[0] = ENTRY_JMP0(val);
> + entry->jump[1] = ENTRY_JMP1(val);
> + entry->jump[2] = PPC_INST_MTCTR | __PPC_RS(R12);
> + entry->jump[3] = PPC_INST_BCTR;
Deleting the comment here is not an improvement imo.
Segher
^ permalink raw reply
* Re: [PATCH stable v4.4 00/52] powerpc spectre backports for 4.4
From: Michael Ellerman @ 2019-04-29 11:56 UTC (permalink / raw)
To: Greg KH; +Cc: npiggin, diana.craciun, linuxppc-dev, stable, msuchanek
In-Reply-To: <20190429070357.GA3167@kroah.com>
Greg KH <gregkh@linuxfoundation.org> writes:
> On Mon, Apr 29, 2019 at 04:26:45PM +1000, Michael Ellerman wrote:
>> Michael Ellerman <mpe@ellerman.id.au> writes:
>> > Greg KH <gregkh@linuxfoundation.org> writes:
>> >> On Mon, Apr 22, 2019 at 12:19:45AM +1000, Michael Ellerman wrote:
>> >>> -----BEGIN PGP SIGNED MESSAGE-----
>> >>> Hash: SHA1
>> >>>
>> >>> Hi Greg/Sasha,
>> >>>
>> >>> Please queue up these powerpc patches for 4.4 if you have no objections.
>> >>
>> >> why? Do you, or someone else, really care about spectre issues in 4.4?
>> >> Who is using ppc for 4.4 becides a specific enterprise distro (and they
>> >> don't seem to be pulling in my stable updates anyway...)?
>> >
>> > Someone asked for it, but TBH I can't remember who it was. I can chase
>> > it up if you like.
>>
>> Yeah it was a request from one of the distros. They plan to take it once
>> it lands in 4.4 stable.
>
> Ok, thanks for confirming, I'll work on this this afternoon.
Thanks. If there's any problems let us know.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: remove the __kernel_io_end export
From: Segher Boessenkool @ 2019-04-29 11:57 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, linux-kernel, aneesh.kumar
In-Reply-To: <20190429115241.12621-1-hch@lst.de>
On Mon, Apr 29, 2019 at 06:52:41AM -0500, Christoph Hellwig wrote:
> This export was added in this merge window, but without any actual
> user, or justification for a modular user.
Hi Christoph,
> -unsigned long __kernel_io_end;
> EXPORT_SYMBOL(__kernel_io_end);
Does that work? Don't you need to remove that second line, as well?
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: remove the __kernel_io_end export
From: Christoph Hellwig @ 2019-04-29 12:00 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Christoph Hellwig, linux-kernel, aneesh.kumar
In-Reply-To: <20190429115706.GO8599@gate.crashing.org>
On Mon, Apr 29, 2019 at 06:57:06AM -0500, Segher Boessenkool wrote:
> On Mon, Apr 29, 2019 at 06:52:41AM -0500, Christoph Hellwig wrote:
> > This export was added in this merge window, but without any actual
> > user, or justification for a modular user.
>
> Hi Christoph,
>
> > -unsigned long __kernel_io_end;
> > EXPORT_SYMBOL(__kernel_io_end);
>
> Does that work? Don't you need to remove that second line, as well?
Actually just the second line. That's what you get for hacking things
up on the plane just before falling asleep, sigh..
^ permalink raw reply
* Re: [PATCH] powerpc/32s: fix BATs setting with CONFIG_STRICT_KERNEL_RWX
From: Segher Boessenkool @ 2019-04-29 12:03 UTC (permalink / raw)
To: Christophe Leroy
Cc: Serge Belyshev, linux-kernel, stable, Paul Mackerras,
linuxppc-dev
In-Reply-To: <3a21c6f19637847e6ed080186a834ede619f3849.1556528569.git.christophe.leroy@c-s.fr>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
(But see comments below.)
On Mon, Apr 29, 2019 at 09:08:09AM +0000, Christophe Leroy wrote:
> diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
> index bf1de3ca39bc..37cf2af98f6a 100644
> --- a/arch/powerpc/mm/ppc_mmu_32.c
> +++ b/arch/powerpc/mm/ppc_mmu_32.c
> @@ -101,7 +101,7 @@ static int find_free_bat(void)
> static unsigned int block_size(unsigned long base, unsigned long top)
> {
> unsigned int max_size = (cpu_has_feature(CPU_FTR_601) ? 8 : 256) << 20;
> - unsigned int base_shift = (fls(base) - 1) & 31;
> + unsigned int base_shift = (ffs(base) - 1) & 31;
> unsigned int block_shift = (fls(top - base) - 1) & 31;
The code is quite confusing now... Add a comment, or improve it?
Segher
^ permalink raw reply
* Re: [PATCH 01/41] drivers: tty: serial: dz: use dev_err() instead of printk()
From: Enrico Weigelt, metux IT consult @ 2019-04-29 12:37 UTC (permalink / raw)
To: Greg KH, Enrico Weigelt, metux IT consult
Cc: linux-ia64, lorenzo.pieralisi, linux-mips, linux-serial, andrew,
khilman, sudeep.holla, liviu.dudau, linux-kernel, vz, linux,
sparclinux, macro, slemieux.tyco, matthias.bgg, jacmet,
linux-amlogic, andriy.shevchenko, linuxppc-dev, davem
In-Reply-To: <20190427133117.GC11368@kroah.com>
On 27.04.19 15:31, Greg KH wrote:
> On Sat, Apr 27, 2019 at 02:51:42PM +0200, Enrico Weigelt, metux IT consult wrote:
>> Using dev_err() instead of printk() for more consistent output.
>> (prints device name, etc).
>>
>> Signed-off-by: Enrico Weigelt <info@metux.net>
>> ---
>> drivers/tty/serial/dz.c | 8 ++++----
>
> Do you have this hardware to test any of these changes with?
Unfortunately not :(
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 01/41] drivers: tty: serial: dz: use dev_err() instead of printk()
From: Greg KH @ 2019-04-29 13:12 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-ia64, lorenzo.pieralisi, linux-mips, linux-serial, andrew,
khilman, sudeep.holla, liviu.dudau, linux-kernel, vz, linux,
linuxppc-dev, sparclinux, macro, slemieux.tyco, matthias.bgg,
jacmet, linux-amlogic, andriy.shevchenko,
Enrico Weigelt, metux IT consult, davem
In-Reply-To: <bae3f23b-8823-f089-c40e-024ba225555f@metux.net>
On Mon, Apr 29, 2019 at 02:37:04PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 27.04.19 15:31, Greg KH wrote:
> > On Sat, Apr 27, 2019 at 02:51:42PM +0200, Enrico Weigelt, metux IT consult wrote:
> >> Using dev_err() instead of printk() for more consistent output.
> >> (prints device name, etc).
> >>
> >> Signed-off-by: Enrico Weigelt <info@metux.net>
> >> ---
> >> drivers/tty/serial/dz.c | 8 ++++----
> >
> > Do you have this hardware to test any of these changes with?
>
> Unfortunately not :(
Then I can take the "basic" types of patches for the driver (like this
one), but not any others, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 37/41] drivers: tty: serial: 8250: simplify io resource size computation
From: Andy Shevchenko @ 2019-04-29 13:19 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: sparclinux, lorenzo.pieralisi, linux-ia64, linux-serial, andrew,
gregkh, sudeep.holla, liviu.dudau, linux-kernel, vz, linux,
linuxppc-dev, khilman, macro, slemieux.tyco, matthias.bgg, jacmet,
linux-amlogic, linux-mips, Enrico Weigelt, metux IT consult,
davem
In-Reply-To: <431b36fe-3071-fcfd-b04e-b4b293e79a80@metux.net>
On Mon, Apr 29, 2019 at 08:48:53AM +0200, Enrico Weigelt, metux IT consult wrote:
> On 28.04.19 17:21, Andy Shevchenko wrote:
> >> +#define SERIAL_RT2880_IOSIZE 0x100
> >
> > And why this is in the header file and not in corresponding C one?
>
> hmm, no particular reason, maybe just an old habit to put definitions
> into .h files ;-)
>
> I can move it to 8250_of.c if you like me to.
Please, do.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 40/41] drivers: tty: serial: helper for setting mmio range
From: Andy Shevchenko @ 2019-04-29 13:28 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: sparclinux, lorenzo.pieralisi, linux-ia64, linux-serial, andrew,
gregkh, sudeep.holla, liviu.dudau, linux-kernel, vz, linux,
linuxppc-dev, khilman, macro, slemieux.tyco, matthias.bgg, jacmet,
linux-amlogic, linux-mips, Enrico Weigelt, metux IT consult,
davem
In-Reply-To: <c75f4ca9-367c-25d5-2597-75f2dccf6e1c@metux.net>
On Mon, Apr 29, 2019 at 12:12:35PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 28.04.19 17:39, Andy Shevchenko wrote:
> seems I've forgot to add "RFC:" in the subject - I'm not entirely happy
> w/ that patch myself, just want to hear your oppinions.
>
> Moreover, the size argument seems wrong here.
Something went wrong with quoting style in your reply.
> hmm, I'm actually not sure yet, what the correct size really would be,
> where the value actually comes from. Just assumed that it would be the
> whole area that the BAR tells. But now I recognized that I'd need to
> substract 'offset' here.
It will be still wrong. The driver in question defines resource window based on
several parameters. So, this should be supplied with a real understanding of
all variety of hardware the certain driver serves for.
> Rethinking it further, we'd probably could deduce the UPIO_* from the
> struct resource, too.
>
> >> + uart_memres_set_start_len(>> + &port,>> + FRODO_BASE + FRODO_APCI_OFFSET(1), 0);> > Please,
> avoid such splitting, first parameter is quite fit above line.
>
> Ok. My intention was having both parameters starting at the same line,
> but then the second line would get too long again. > ...and here, and
> maybe in other places you split the assignments to the members> in two
> part. Better to call your function before or after these blocks of>
> assignments.
> the reason what I've just replaced the exactly the assignments, trying
> not to touch too much ;-)
> I'll have a closer look on what can be moved w/o side effects.
Just try to avoid
foo(
bar, ...
-like splitting.
> >> +static inline void uart_memres_set_res(struct uart_port *port,
> >
> > Perhaps better name can be found.
> > Especially taking into account that it handles IO / MMIO here.
>
> hmm, lacking creativity here ;-)
> any suggestions ?
No immediate suggestions.
uart_set_io_resource()
uart_clear_io_resource()
at least sounds more plausible to me.
> >> + struct resource *res)
> >> +{
> >> + if (!res) {
> >
> > It should return an error in such case.
>
> It's not an error, but desired behaviour: NULL resource
> clears the value.
Oh, then why it's in this function, which is *setter* according to its name,
at all?
>
> >> + port->mapsize = 0;
> >> + port->mapbase = 0;
> >> + port->iobase = 0;
> >> + return;
> >> + }
> >> +
> >> + if (resource_type(res) == IORESOURCE_IO) {
> >> + port->iotype = UPIO_PORT;
> >> + port->iobase = resource->start;
> >> + return;
> >> + }
> >> +
> >> + uart->mapbase = res->start;
> >> + uart->mapsize = resource_size(res);
> >
> >> + uart->iotype = UPIO_MEM;
> >
> > Only one type? Why type is even set here?
>
> It's the default case. The special cases (eg. UPIO_MEM32) need to be
> set explicitly, after that call.
Which is weird.
> Not really nice, but haven't found a better solution yet.
Just simple not touching it?
> I don't like
> the idea of passing an UPIO_* parameter to the function, most callers
> should not care, if they don't really need to.
They do care. The driver on its own knows better than any generic code what
type of hardware it serves to.
> >> + */
> >
> >> +static inline void uart_memres_set_start_len(struct uart_driver *uart,
> >> + resource_size_t start,
> >> + resource_size_t len)
> >
> > The comment doesn't tell why this is needed when we have one for struct
> > resource.
>
> Renamed it to uart_memres_set_mmio_range().
See also above about naming patterns.
>
> This helper is meant for drivers that don't work w/ struct resource,
> or explicitly set their own len.
Then why it's not mentioned in the description of the function?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 01/41] drivers: tty: serial: dz: use dev_err() instead of printk()
From: Enrico Weigelt, metux IT consult @ 2019-04-29 14:11 UTC (permalink / raw)
To: Greg KH, Enrico Weigelt, metux IT consult
Cc: linux-ia64, lorenzo.pieralisi, linux-mips, linux-serial, andrew,
khilman, sudeep.holla, liviu.dudau, linux-kernel, vz, linux,
sparclinux, macro, slemieux.tyco, matthias.bgg, jacmet,
linux-amlogic, andriy.shevchenko, linuxppc-dev, davem
In-Reply-To: <20190427132959.GA11368@kroah.com>
On 27.04.19 15:29, Greg KH wrote:
> On Sat, Apr 27, 2019 at 02:51:42PM +0200, Enrico Weigelt, metux IT consult wrote:
>> Using dev_err() instead of printk() for more consistent output.
>> (prints device name, etc).
>>
>> Signed-off-by: Enrico Weigelt <info@metux.net>
>
> Your "From:" line does not match the signed-off-by line, so I can't take
> any of these if I wanted to :(
Grmpf. I've manually changed it, as you isisted in having my company
name remove from it ....
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 01/41] drivers: tty: serial: dz: use dev_err() instead of printk()
From: Greg KH @ 2019-04-29 14:23 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-ia64, lorenzo.pieralisi, linux-mips, linux-serial, andrew,
khilman, sudeep.holla, liviu.dudau, linux-kernel, vz, linux,
linuxppc-dev, sparclinux, macro, slemieux.tyco, matthias.bgg,
jacmet, linux-amlogic, andriy.shevchenko,
Enrico Weigelt, metux IT consult, davem
In-Reply-To: <e10175d0-bc3b-a4ab-cb47-0b4761bfb629@metux.net>
On Mon, Apr 29, 2019 at 04:11:15PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 27.04.19 15:29, Greg KH wrote:
> > On Sat, Apr 27, 2019 at 02:51:42PM +0200, Enrico Weigelt, metux IT consult wrote:
> >> Using dev_err() instead of printk() for more consistent output.
> >> (prints device name, etc).
> >>
> >> Signed-off-by: Enrico Weigelt <info@metux.net>
> >
> > Your "From:" line does not match the signed-off-by line, so I can't take
> > any of these if I wanted to :(
>
> Grmpf. I've manually changed it, as you isisted in having my company
> name remove from it ....
Yes, that's fine, but the lines have to match. See the documentation
for how to have a "From:" in the changelog text to override whatever
your email client happens to pollute the email with :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 36/41] drivers: tty: serial: 8250: store mmio resource size in port struct
From: Enrico Weigelt, metux IT consult @ 2019-04-29 14:55 UTC (permalink / raw)
To: Andy Shevchenko, Enrico Weigelt, metux IT consult
Cc: lorenzo.pieralisi, linux-ia64, linux-serial, andrew, gregkh,
sudeep.holla, liviu.dudau, linux-kernel, vz, linux, sparclinux,
khilman, macro, slemieux.tyco, matthias.bgg, jacmet,
linux-amlogic, linux-mips, linuxppc-dev, davem
In-Reply-To: <20190428151848.GO9224@smile.fi.intel.com>
On 28.04.19 17:18, Andy Shevchenko wrote:
> On Sat, Apr 27, 2019 at 02:52:17PM +0200, Enrico Weigelt, metux IT consult wrote:
>> The io resource size is currently recomputed when it's needed but this
>> actually needs to be done once (or drivers could specify fixed values)
>
> io -> IO
fixed.
>> Simplify that by doing this computation only once and storing the result
>> into the mapsize field. serial8250_register_8250_port() is now called
>> only once on driver init, the previous call sites now just fetch the
>> value from the mapsize field.
>
> Do I understand correctly that this has no side effects?
I don't know of any. (except someting changes things like regshift after
the initialization phase ... :o)
>> @@ -979,6 +979,9 @@ int serial8250_register_8250_port(struct uart_8250_port *up)
>> if (up->port.uartclk == 0)
>> return -EINVAL;
>>
>> + /* compute the mapsize in case the driver didn't specify one */
>> + up->mapsize = serial8250_port_size(up);
>
> I don't know all quirks in 8250 drivers by heart, though can you guarantee that
> at this point the device reports correct IO resource size? (If I'm not mistaken
> some broken hardware needs some magic to be done before card can be properly
> handled)
Actually, I don't see anything talking to the hardware at all here.
It's all derived from values that are set up before
serial8250_register_8250_port() is called.
>> - unsigned int size = serial8250_port_size(up);
>> struct uart_port *port = &up->port;
>
>> - int ret = 0;
>
> This and Co is a separate change that can be done in its own patch.
I don't really understand :(
Do you mean the splitting off the retval part from the rest ?
>> + port->membase = ioremap_nocache(port->mapbase,
>> + port->mapsize);
>
> You may increase readability by introducing temporary variables
>
> ... mapbase = port->mapbase;
> ... mapsize = port->mapsize;
> ...
> port->membase = ioremap_nocache(mapbase, mapsize);
> ...
Is that really necessary ? Maybe it's just my personal taste, but I
don't feel the more more verbose one is really easier to read.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 13/41] drivers: tty: serial: uartlite: fill mapsize and use it
From: Peter Korsgaard @ 2019-04-29 15:19 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: lorenzo.pieralisi, linux-ia64, macro, andrew, gregkh,
slemieux.tyco, liviu.dudau, linux-kernel, andriy.shevchenko,
linux-mips, linux, matthias.bgg, khilman, linux-serial,
sudeep.holla, sparclinux, jacmet, linux-amlogic, vz, linuxppc-dev,
davem
In-Reply-To: <1556369542-13247-14-git-send-email-info@metux.net>
>>>>> "Enrico" == Enrico Weigelt, metux IT consult <info@metux.net> writes:
> Fill the struct uart_port->mapsize field and use it, insteaf of
s/insteaf/instead/
> hardcoded values in many places. This makes the code layout a bit
> more consistent and easily allows using generic helpers for the
> io memory handling.
> Candidates for such helpers could be eg. the request+ioremap and
> iounmap+release combinations.
> Signed-off-by: Enrico Weigelt <info@metux.net>
Acked-by: Peter Korsgaard <peter@korsgaard.com>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 14/41] drivers: tty: serial: uartlite: remove unnecessary braces
From: Peter Korsgaard @ 2019-04-29 15:20 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: lorenzo.pieralisi, linux-ia64, macro, andrew, gregkh,
slemieux.tyco, liviu.dudau, linux-kernel, andriy.shevchenko,
linux-mips, linux, matthias.bgg, khilman, linux-serial,
sudeep.holla, sparclinux, jacmet, linux-amlogic, vz, linuxppc-dev,
davem
In-Reply-To: <1556369542-13247-15-git-send-email-info@metux.net>
>>>>> "Enrico" == Enrico Weigelt, metux IT consult <info@metux.net> writes:
> checkpatch complains:
> WARNING: braces {} are not necessary for any arm of this statement
> #489: FILE: drivers/tty/serial/uartlite.c:489:
> + if (oops_in_progress) {
> [...]
> + } else
> [...]
> Signed-off-by: Enrico Weigelt <info@metux.net>
Acked-by: Peter Korsgaard <peter@korsgaard.com>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 15/41] drivers: tty: serial: uartlite: fix use fix bare 'unsigned'
From: Peter Korsgaard @ 2019-04-29 15:21 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: lorenzo.pieralisi, linux-ia64, macro, andrew, gregkh,
slemieux.tyco, liviu.dudau, linux-kernel, andriy.shevchenko,
linux-mips, linux, matthias.bgg, khilman, linux-serial,
sudeep.holla, sparclinux, jacmet, linux-amlogic, vz, linuxppc-dev,
davem
In-Reply-To: <1556369542-13247-16-git-send-email-info@metux.net>
>>>>> "Enrico" == Enrico Weigelt, metux IT consult <info@metux.net> writes:
> Fix checkpatch warnings:
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> #562: FILE: drivers/tty/serial/uartlite.c:562:
> + unsigned retries = 1000000;
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> #574: FILE: drivers/tty/serial/uartlite.c:574:
> + const char *s, unsigned n)
s/fix use fix/fix use of/ in Subject. Other than that:
Acked-by: Peter Korsgaard <peter@korsgaard.com>
--
Bye, Peter Korsgaard
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox