* [PATCH v2 0/5] Implement huge VMAP and VMALLOC on powerpc 8xx
From: Christophe Leroy @ 2021-05-12 5:00 UTC (permalink / raw)
To: Andrew Morton, Nicholas Piggin, Mike Kravetz, Mike Rapoport
Cc: linux-arch, linux-kernel, linux-mm, sparclinux, linuxppc-dev,
linux-arm-kernel
This series implements huge VMAP and VMALLOC on powerpc 8xx.
Powerpc 8xx has 4 page sizes:
- 4k
- 16k
- 512k
- 8M
At the time being, vmalloc and vmap only support huge pages which are
leaf at PMD level.
Here the PMD level is 4M, it doesn't correspond to any supported
page size.
For now, implement use of 16k and 512k pages which is done
at PTE level.
Support of 8M pages will be implemented later, it requires use of
hugepd tables.
To allow this, the architecture provides two functions:
- arch_vmap_pte_range_map_size() which tells vmap_pte_range() what
page size to use. A stub returning PAGE_SIZE is provided when the
architecture doesn't provide this function.
- arch_vmap_pte_supported_shift() which tells __vmalloc_node_range()
what page shift to use for a given area size. A stub returning
PAGE_SHIFT is provided when the architecture doesn't provide this
function.
The main change in v2 compared to the RFC is that powerpc 8xx
specificities are not plugged anymore directly inside vmalloc code.
Christophe Leroy (5):
mm/hugetlb: Change parameters of arch_make_huge_pte()
mm/pgtable: Add stubs for {pmd/pub}_{set/clear}_huge
mm/vmalloc: Enable mapping of huge pages at pte level in vmap
mm/vmalloc: Enable mapping of huge pages at pte level in vmalloc
powerpc/8xx: Add support for huge pages on VMAP and VMALLOC
arch/arm64/include/asm/hugetlb.h | 3 +-
arch/arm64/mm/hugetlbpage.c | 5 +--
arch/powerpc/Kconfig | 2 +-
.../include/asm/nohash/32/hugetlb-8xx.h | 5 +--
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 43 +++++++++++++++++++
arch/sparc/include/asm/pgtable_64.h | 3 +-
arch/sparc/mm/hugetlbpage.c | 6 +--
include/linux/hugetlb.h | 4 +-
include/linux/pgtable.h | 26 ++++++++++-
include/linux/vmalloc.h | 15 +++++++
mm/hugetlb.c | 6 ++-
mm/migrate.c | 4 +-
mm/vmalloc.c | 34 +++++++++++----
13 files changed, 126 insertions(+), 30 deletions(-)
--
2.25.0
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/makefile: Do not redefine $(CPP) for preprocessor
From: Alexey Kardashevskiy @ 2021-05-12 3:52 UTC (permalink / raw)
To: Nathan Chancellor, linuxppc-dev
Cc: Michal Marek, linux-kbuild, Masahiro Yamada, Nick Desaulniers,
linux-kernel, Nicholas Piggin, clang-built-linux
In-Reply-To: <3579aa0d-0470-9a6b-e35b-48f997a5b48b@kernel.org>
On 5/12/21 05:18, Nathan Chancellor wrote:
> On 5/10/2021 9:48 PM, Alexey Kardashevskiy wrote:
>> The $(CPP) (do only preprocessing) macro is already defined in Makefile.
>> However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results
>> in flags duplication. Which is not a big deal by itself except for
>> the flags which depend on other flags and the compiler checks them
>> as it parses the command line.
>>
>> Specifically, scripts/Makefile.build:304 generates ksyms for .S files.
>> If clang+llvm+sanitizer are enabled, this results in
>>
>> -emit-llvm-bc -fno-lto -flto -fvisibility=hidden \
>> -fsanitize=cfi-mfcall -fno-lto ...
>>
>> in the clang command line and triggers error:
>>
>> clang-13: error: invalid argument '-fsanitize=cfi-mfcall' only allowed
>> with '-flto'
>>
>> This removes unnecessary CPP redefinition. Which works fine as in most
>> place KBUILD_CFLAGS is passed to $CPP except
>> arch/powerpc/kernel/vdso64/vdso(32|64).lds (and probably some others,
>> not yet detected). To fix vdso, we do:
>> 1. explicitly add -m(big|little)-endian to $CPP
>> 2. (for clang) add $CLANG_FLAGS to $KBUILD_CPPFLAGS as otherwise clang
>> silently ignores -m(big|little)-endian if the building platform does not
>> support big endian (such as x86) so --prefix= is required.
>>
>> While at this, remove some duplication from CPPFLAGS_vdso(32|64)
>> as cmd_cpp_lds_S has them anyway. It still puzzles me why we need -C
>> (preserve comments in the preprocessor output) flag here.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v2:
>> * fix KBUILD_CPPFLAGS
>> * add CLANG_FLAGS to CPPFLAGS
>> ---
>> Makefile | 1 +
>> arch/powerpc/Makefile | 3 ++-
>> arch/powerpc/kernel/vdso32/Makefile | 2 +-
>> arch/powerpc/kernel/vdso64/Makefile | 2 +-
>> 4 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 72af8e423f11..13acd2183d55 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -591,6 +591,7 @@ CLANG_FLAGS +=
>> --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
>> endif
>> CLANG_FLAGS += -Werror=unknown-warning-option
>> KBUILD_CFLAGS += $(CLANG_FLAGS)
>> +KBUILD_CPPFLAGS += $(CLANG_FLAGS)
>
> This is going to cause flag duplication, which would be nice to avoid. I
> do not know if we can get away with just adding $(CLANG_FLAGS) to
> KBUILD_CPPFLAGS instead of KBUILD_CFLAGS though. It seems like this
> assignment might be better in arch/powerpc/Makefile with the
> KBUILD_CPPFLAGS additions there.
It is a fair point about the duplication (which is woooow, I often see
-mbig-endian 3 - three - times) and I think I only need --prefix= there
but this is still exactly the place to do such thing as it potentially
affects all archs supporting both endianness (not many though, yeah).
Thanks,
>
> Cheers,
> Nathan
>
>> KBUILD_AFLAGS += $(CLANG_FLAGS)
>> export CLANG_FLAGS
>> endif
>> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>> index 3212d076ac6a..306bfd2797ad 100644
>> --- a/arch/powerpc/Makefile
>> +++ b/arch/powerpc/Makefile
>> @@ -76,6 +76,7 @@ endif
>> ifdef CONFIG_CPU_LITTLE_ENDIAN
>> KBUILD_CFLAGS += -mlittle-endian
>> +KBUILD_CPPFLAGS += -mlittle-endian
>> KBUILD_LDFLAGS += -EL
>> LDEMULATION := lppc
>> GNUTARGET := powerpcle
>> @@ -83,6 +84,7 @@ MULTIPLEWORD := -mno-multiple
>> KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect)
>> else
>> KBUILD_CFLAGS += $(call cc-option,-mbig-endian)
>> +KBUILD_CPPFLAGS += $(call cc-option,-mbig-endian)
>> KBUILD_LDFLAGS += -EB
>> LDEMULATION := ppc
>> GNUTARGET := powerpc
>> @@ -208,7 +210,6 @@ KBUILD_CPPFLAGS += -I $(srctree)/arch/$(ARCH)
>> $(asinstr)
>> KBUILD_AFLAGS += $(AFLAGS-y)
>> KBUILD_CFLAGS += $(call cc-option,-msoft-float)
>> KBUILD_CFLAGS += -pipe $(CFLAGS-y)
>> -CPP = $(CC) -E $(KBUILD_CFLAGS)
>> CHECKFLAGS += -m$(BITS) -D__powerpc__ -D__powerpc$(BITS)__
>> ifdef CONFIG_CPU_BIG_ENDIAN
>> diff --git a/arch/powerpc/kernel/vdso32/Makefile
>> b/arch/powerpc/kernel/vdso32/Makefile
>> index 7d9a6fee0e3d..ea001c6df1fa 100644
>> --- a/arch/powerpc/kernel/vdso32/Makefile
>> +++ b/arch/powerpc/kernel/vdso32/Makefile
>> @@ -44,7 +44,7 @@ asflags-y := -D__VDSO32__ -s
>> obj-y += vdso32_wrapper.o
>> targets += vdso32.lds
>> -CPPFLAGS_vdso32.lds += -P -C -Upowerpc
>> +CPPFLAGS_vdso32.lds += -C
>> # link rule for the .so file, .lds has to be first
>> $(obj)/vdso32.so.dbg: $(src)/vdso32.lds $(obj-vdso32)
>> $(obj)/vgettimeofday.o FORCE
>> diff --git a/arch/powerpc/kernel/vdso64/Makefile
>> b/arch/powerpc/kernel/vdso64/Makefile
>> index 2813e3f98db6..07eadba48c7a 100644
>> --- a/arch/powerpc/kernel/vdso64/Makefile
>> +++ b/arch/powerpc/kernel/vdso64/Makefile
>> @@ -30,7 +30,7 @@ ccflags-y := -shared -fno-common -fno-builtin
>> -nostdlib \
>> asflags-y := -D__VDSO64__ -s
>> targets += vdso64.lds
>> -CPPFLAGS_vdso64.lds += -P -C -U$(ARCH)
>> +CPPFLAGS_vdso64.lds += -C
>> # link rule for the .so file, .lds has to be first
>> $(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64)
>> $(obj)/vgettimeofday.o FORCE
>>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/makefile: Do not redefine $(CPP) for preprocessor
From: Alexey Kardashevskiy @ 2021-05-12 3:48 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Michal Marek, linux-kbuild, Masahiro Yamada, Nick Desaulniers,
linux-kernel, Nicholas Piggin, Nathan Chancellor,
clang-built-linux, linuxppc-dev
In-Reply-To: <20210511231635.GR10366@gate.crashing.org>
On 5/12/21 09:16, Segher Boessenkool wrote:
> On Tue, May 11, 2021 at 11:30:17PM +1000, Alexey Kardashevskiy wrote:
>>> In any case, please mention the reasoning (and the fact that you are
>>> removing these flags!) in the commit message. Thanks!
>>
>> but i did mention this, the last paragraph... they are duplicated.
>
> Oh! I completely missed those few lines. Sorry for that :-(
Well, I probably should have made it a separate patch anyway, I'll
repost separately.
> To compensate a bit:
>
>> It still puzzles me why we need -C
>> (preserve comments in the preprocessor output) flag here.
>
> It is so that a human can look at the output and read it. Comments are
> very significant to human readers :-)
I seriously doubt anyone ever read those :) I suspect this is to pull
all the licenses in one place and do some checking but I did not dig deep.
--
Alexey
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Fix kvm_unmap_gfn_range_hv() for Hash MMU
From: Michael Ellerman @ 2021-05-12 3:20 UTC (permalink / raw)
To: Sean Christopherson; +Cc: kvm-ppc, pbonzini, linuxppc-dev, kvm, npiggin
In-Reply-To: <YJqzJyBvU0A8VG9p@google.com>
Sean Christopherson <seanjc@google.com> writes:
> On Tue, May 11, 2021, Michael Ellerman wrote:
>> Commit 32b48bf8514c ("KVM: PPC: Book3S HV: Fix conversion to gfn-based
>> MMU notifier callbacks") fixed kvm_unmap_gfn_range_hv() by adding a for
>> loop over each gfn in the range.
>>
>> But for the Hash MMU it repeatedly calls kvm_unmap_rmapp() with the
>> first gfn of the range, rather than iterating through the range.
>>
>> This exhibits as strange guest behaviour, sometimes crashing in firmare,
>> or booting and then guest userspace crashing unexpectedly.
>>
>> Fix it by passing the iterator, gfn, to kvm_unmap_rmapp().
>>
>> Fixes: 32b48bf8514c ("KVM: PPC: Book3S HV: Fix conversion to gfn-based MMU notifier callbacks")
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> ---
>> arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> I plan to take this via the powerpc fixes branch.
>
> FWIW,
>
> Reviewed-by: Sean Christopherson <seanjc@google.com>
Thanks.
cheers
^ permalink raw reply
* Re: [PATCH v3 0/4] P2040/P2041 i2c recovery erratum
From: Chris Packham @ 2021-05-12 1:48 UTC (permalink / raw)
To: Joakim Tjernlund, andy.shevchenko@gmail.com,
andriy.shevchenko@linux.intel.com, mpe@ellerman.id.au,
wsa@kernel.org, robh+dt@kernel.org
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <b90f48cfdc31af08190e7a8eaa71b7bd488fcbaa.camel@infinera.com>
On 12/05/21 10:10 am, Joakim Tjernlund wrote:
> On Wed, 2021-05-12 at 09:20 +1200, Chris Packham wrote:
>> The P2040/P2041 has an erratum where the i2c recovery scheme
>> documented in the reference manual (and currently implemented
>> in the i2c-mpc.c driver) does not work. The errata document
>> provides an alternative that does work. This series implements
>> that alternative and uses a property in the devicetree to
>> decide when the alternative mechanism is needed.
>>
>> Chris Packham (4):
>> dt-bindings: i2c: mpc: Add fsl,i2c-erratum-a004447 flag
>> powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c
>> controllers
>> powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P1010 i2c
>> controllers
>> i2c: mpc: implement erratum A-004447 workaround
>>
>> .../devicetree/bindings/i2c/i2c-mpc.yaml | 7 ++
>> arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 8 ++
>> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 16 ++++
>> drivers/i2c/busses/i2c-mpc.c | 81 ++++++++++++++++++-
>> 4 files changed, 110 insertions(+), 2 deletions(-)
>>
> This now reminds me about the current I2C reset procedure, it didn't work for us and I came up with this one:
> https://www.spinics.net/lists/linux-i2c/msg29490.html
> it never got in but we are still using it.
For those reading along the v2 mentioned in that thread was posted as
https://lore.kernel.org/linux-i2c/20170511122033.22471-1-joakim.tjernlund@infinera.com/
there was a bit of discussion but it seemed to die out without reaching
a conclusion.
The i2c-mpc driver is now using the generic recovery mechanism so that
addresses one bit of feedback from the original thread.
I do wonder if the reason the recovery wasn't working for your case was
because of the erratum. Do you happen to remember which SoC your issue
was on?
I've been doing my recent work with a P2040 and prior to that I did test
out the recovery on a T2081 (which isn't documented to have this
erratum) when I was re-working the driver. The "new" recovery actually
seems better but I don't have a reliably faulty i2c device so that's
only based on me writing some code to manually trigger the recovery
(using the snippet below) and observing it with an oscilloscope.
---8<---
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index c85d6618723f..8fa4363414bc 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1217,6 +1217,25 @@ new_device_store(struct device *dev, struct
device_attribute *attr,
}
static DEVICE_ATTR_WO(new_device);
+static ssize_t recover_store(struct device *dev, struct
device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct i2c_adapter *adap = to_i2c_adapter(dev);
+ int ret;
+
+ dev_info(dev, "Recovering bus\n");
+
+ ret = i2c_recover_bus(adap);
+ if (ret == -EOPNOTSUPP)
+ dev_info(dev, "recovery not supported\n");
+ else if (ret)
+ dev_err(dev, "recovery failed %d\n", ret);
+
+ return count;
+}
+
+static DEVICE_ATTR_WO(recover);
+
/*
* And of course let the users delete the devices they instantiated, if
* they got it wrong. This interface can only be used to delete devices
@@ -1277,6 +1296,7 @@ static struct attribute *i2c_adapter_attrs[] = {
&dev_attr_name.attr,
&dev_attr_new_device.attr,
&dev_attr_delete_device.attr,
+ &dev_attr_recover.attr,
NULL
};
ATTRIBUTE_GROUPS(i2c_adapter);
---8<---
^ permalink raw reply related
* Re: [PATCH kernel v2] powerpc/makefile: Do not redefine $(CPP) for preprocessor
From: Segher Boessenkool @ 2021-05-11 23:16 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Michal Marek, linux-kbuild, Masahiro Yamada, Nick Desaulniers,
linux-kernel, Nicholas Piggin, Nathan Chancellor,
clang-built-linux, linuxppc-dev
In-Reply-To: <1795b9efa40.27bb.1ca38dd7e845b990cd13d431eb58563d@ozlabs.ru>
On Tue, May 11, 2021 at 11:30:17PM +1000, Alexey Kardashevskiy wrote:
> >In any case, please mention the reasoning (and the fact that you are
> >removing these flags!) in the commit message. Thanks!
>
> but i did mention this, the last paragraph... they are duplicated.
Oh! I completely missed those few lines. Sorry for that :-(
To compensate a bit:
> It still puzzles me why we need -C
> (preserve comments in the preprocessor output) flag here.
It is so that a human can look at the output and read it. Comments are
very significant to human readers :-)
Segher
^ permalink raw reply
* Re: [PATCH v5 9/9] powerpc/mm: Enable move pmd/pud
From: Andrew Morton @ 2021-05-11 22:19 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: npiggin, linux-mm, kaleshsingh, joel, linuxppc-dev
In-Reply-To: <20210422054323.150993-10-aneesh.kumar@linux.ibm.com>
On Thu, 22 Apr 2021 11:13:23 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
> mremap HAVE_MOVE_PMD/PUD optimization time comparison for 1GB region:
> 1GB mremap - Source PTE-aligned, Destination PTE-aligned
> mremap time: 1127034ns
> 1GB mremap - Source PMD-aligned, Destination PMD-aligned
> mremap time: 508817ns
> 1GB mremap - Source PUD-aligned, Destination PUD-aligned
> mremap time: 23046ns
Well that's nice.
How significant is this in practice? How common is it for applications
to successfully align the region? Do real-world applications actually
benefit from this?
Are there userspace libraries (malloc() etc) which should be reworked
to fully exploit this?
^ permalink raw reply
* Re: [PATCH v3 0/4] P2040/P2041 i2c recovery erratum
From: Joakim Tjernlund @ 2021-05-11 22:10 UTC (permalink / raw)
To: andy.shevchenko@gmail.com, andriy.shevchenko@linux.intel.com,
mpe@ellerman.id.au, chris.packham@alliedtelesis.co.nz,
wsa@kernel.org, robh+dt@kernel.org
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20210511212052.27242-1-chris.packham@alliedtelesis.co.nz>
On Wed, 2021-05-12 at 09:20 +1200, Chris Packham wrote:
> The P2040/P2041 has an erratum where the i2c recovery scheme
> documented in the reference manual (and currently implemented
> in the i2c-mpc.c driver) does not work. The errata document
> provides an alternative that does work. This series implements
> that alternative and uses a property in the devicetree to
> decide when the alternative mechanism is needed.
>
> Chris Packham (4):
> dt-bindings: i2c: mpc: Add fsl,i2c-erratum-a004447 flag
> powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c
> controllers
> powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P1010 i2c
> controllers
> i2c: mpc: implement erratum A-004447 workaround
>
> .../devicetree/bindings/i2c/i2c-mpc.yaml | 7 ++
> arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 8 ++
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 16 ++++
> drivers/i2c/busses/i2c-mpc.c | 81 ++++++++++++++++++-
> 4 files changed, 110 insertions(+), 2 deletions(-)
>
This now reminds me about the current I2C reset procedure, it didn't work for us and I came up with this one:
https://www.spinics.net/lists/linux-i2c/msg29490.html
it never got in but we are still using it.
Jocke
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: i2c: mpc: Add fsl, i2c-erratum-a004447 flag
From: Chris Packham @ 2021-05-11 21:20 UTC (permalink / raw)
To: wsa, andriy.shevchenko, andy.shevchenko, robh+dt, mpe
Cc: devicetree, Chris Packham, linuxppc-dev, linux-i2c, linux-kernel
In-Reply-To: <20210511212052.27242-1-chris.packham@alliedtelesis.co.nz>
Document the fsl,i2c-erratum-a004447 flag which indicates the presence
of an i2c erratum on some QorIQ SoCs.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: Rob Herring <robh@kernel.org>
---
Notes:
Changes in v3:
- Add Ack from Rob
Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
index 7b553d559c83..98c6fcf7bf26 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
@@ -46,6 +46,13 @@ properties:
description: |
I2C bus timeout in microseconds
+ fsl,i2c-erratum-a004447:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ Indicates the presence of QorIQ erratum A-004447, which
+ says that the standard i2c recovery scheme mechanism does
+ not work and an alternate implementation is needed.
+
required:
- compatible
- reg
--
2.31.1
^ permalink raw reply related
* [PATCH v3 3/4] powerpc/fsl: set fsl, i2c-erratum-a004447 flag for P1010 i2c controllers
From: Chris Packham @ 2021-05-11 21:20 UTC (permalink / raw)
To: wsa, andriy.shevchenko, andy.shevchenko, robh+dt, mpe
Cc: devicetree, linux-kernel, Chris Packham, Paul Mackerras,
linux-i2c, linuxppc-dev
In-Reply-To: <20210511212052.27242-1-chris.packham@alliedtelesis.co.nz>
The i2c controllers on the P1010 have an erratum where the documented
scheme for i2c bus recovery will not work (A-004447). A different
mechanism is needed which is documented in the P1010 Chip Errata Rev L.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
Notes:
Changes in v3:
- New
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
index c2717f31925a..ccda0a91abf0 100644
--- a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
@@ -122,7 +122,15 @@ memory-controller@2000 {
};
/include/ "pq3-i2c-0.dtsi"
+ i2c@3000 {
+ fsl,i2c-erratum-a004447;
+ };
+
/include/ "pq3-i2c-1.dtsi"
+ i2c@3100 {
+ fsl,i2c-erratum-a004447;
+ };
+
/include/ "pq3-duart-0.dtsi"
/include/ "pq3-espi-0.dtsi"
spi0: spi@7000 {
--
2.31.1
^ permalink raw reply related
* [PATCH v3 2/4] powerpc/fsl: set fsl, i2c-erratum-a004447 flag for P2041 i2c controllers
From: Chris Packham @ 2021-05-11 21:20 UTC (permalink / raw)
To: wsa, andriy.shevchenko, andy.shevchenko, robh+dt, mpe
Cc: devicetree, linux-kernel, Chris Packham, Paul Mackerras,
linux-i2c, linuxppc-dev
In-Reply-To: <20210511212052.27242-1-chris.packham@alliedtelesis.co.nz>
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q (latest available at the time of writing).
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
index 872e4485dc3f..ddc018d42252 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
@@ -371,7 +371,23 @@ sdhc@114000 {
};
/include/ "qoriq-i2c-0.dtsi"
+ i2c@118000 {
+ fsl,i2c-erratum-a004447;
+ };
+
+ i2c@118100 {
+ fsl,i2c-erratum-a004447;
+ };
+
/include/ "qoriq-i2c-1.dtsi"
+ i2c@119000 {
+ fsl,i2c-erratum-a004447;
+ };
+
+ i2c@119100 {
+ fsl,i2c-erratum-a004447;
+ };
+
/include/ "qoriq-duart-0.dtsi"
/include/ "qoriq-duart-1.dtsi"
/include/ "qoriq-gpio-0.dtsi"
--
2.31.1
^ permalink raw reply related
* [PATCH v3 0/4] P2040/P2041 i2c recovery erratum
From: Chris Packham @ 2021-05-11 21:20 UTC (permalink / raw)
To: wsa, andriy.shevchenko, andy.shevchenko, robh+dt, mpe
Cc: devicetree, Chris Packham, linuxppc-dev, linux-i2c, linux-kernel
The P2040/P2041 has an erratum where the i2c recovery scheme
documented in the reference manual (and currently implemented
in the i2c-mpc.c driver) does not work. The errata document
provides an alternative that does work. This series implements
that alternative and uses a property in the devicetree to
decide when the alternative mechanism is needed.
Chris Packham (4):
dt-bindings: i2c: mpc: Add fsl,i2c-erratum-a004447 flag
powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c
controllers
powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P1010 i2c
controllers
i2c: mpc: implement erratum A-004447 workaround
.../devicetree/bindings/i2c/i2c-mpc.yaml | 7 ++
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 8 ++
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 16 ++++
drivers/i2c/busses/i2c-mpc.c | 81 ++++++++++++++++++-
4 files changed, 110 insertions(+), 2 deletions(-)
--
2.31.1
^ permalink raw reply
* [PATCH v3 4/4] i2c: mpc: implement erratum A-004447 workaround
From: Chris Packham @ 2021-05-11 21:20 UTC (permalink / raw)
To: wsa, andriy.shevchenko, andy.shevchenko, robh+dt, mpe
Cc: devicetree, Chris Packham, linuxppc-dev, linux-i2c, linux-kernel
In-Reply-To: <20210511212052.27242-1-chris.packham@alliedtelesis.co.nz>
The P2040/P2041 has an erratum where the normal i2c recovery mechanism
does not work. Implement the alternative recovery mechanism documented
in the P2040 Chip Errata Rev Q.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
Notes:
Changes in v3:
- Further code reduction in i2c_mpc_wait_sr()
Changes in v2:
- Use readb_poll_timeout instead of open-coded loop
drivers/i2c/busses/i2c-mpc.c | 81 +++++++++++++++++++++++++++++++++++-
1 file changed, 79 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 30d9e89a3db2..dcca9c2396db 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -19,6 +19,7 @@
#include <linux/clk.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/fsl_devices.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
@@ -45,6 +46,7 @@
#define CCR_MTX 0x10
#define CCR_TXAK 0x08
#define CCR_RSTA 0x04
+#define CCR_RSVD 0x02
#define CSR_MCF 0x80
#define CSR_MAAS 0x40
@@ -97,7 +99,7 @@ struct mpc_i2c {
u32 block;
int rc;
int expect_rxack;
-
+ bool has_errata_A004447;
};
struct mpc_i2c_divider {
@@ -136,6 +138,75 @@ static void mpc_i2c_fixup(struct mpc_i2c *i2c)
}
}
+static int i2c_mpc_wait_sr(struct mpc_i2c *i2c, int mask)
+{
+ void __iomem *addr = i2c->base + MPC_I2C_SR;
+ u8 val;
+
+ return readb_poll_timeout(addr, val, val & mask, 0, 100);
+}
+
+/*
+ * Workaround for Erratum A004447. From the P2040CE Rev Q
+ *
+ * 1. Set up the frequency divider and sampling rate.
+ * 2. I2CCR - a0h
+ * 3. Poll for I2CSR[MBB] to get set.
+ * 4. If I2CSR[MAL] is set (an indication that SDA is stuck low), then go to
+ * step 5. If MAL is not set, then go to step 13.
+ * 5. I2CCR - 00h
+ * 6. I2CCR - 22h
+ * 7. I2CCR - a2h
+ * 8. Poll for I2CSR[MBB] to get set.
+ * 9. Issue read to I2CDR.
+ * 10. Poll for I2CSR[MIF] to be set.
+ * 11. I2CCR - 82h
+ * 12. Workaround complete. Skip the next steps.
+ * 13. Issue read to I2CDR.
+ * 14. Poll for I2CSR[MIF] to be set.
+ * 15. I2CCR - 80h
+ */
+static void mpc_i2c_fixup_A004447(struct mpc_i2c *i2c)
+{
+ int ret;
+ u32 val;
+
+ writeccr(i2c, CCR_MEN | CCR_MSTA);
+ ret = i2c_mpc_wait_sr(i2c, CSR_MBB);
+ if (ret) {
+ dev_err(i2c->dev, "timeout waiting for CSR_MBB\n");
+ return;
+ }
+
+ val = readb(i2c->base + MPC_I2C_SR);
+
+ if (val & CSR_MAL) {
+ writeccr(i2c, 0x00);
+ writeccr(i2c, CCR_MSTA | CCR_RSVD);
+ writeccr(i2c, CCR_MEN | CCR_MSTA | CCR_RSVD);
+ ret = i2c_mpc_wait_sr(i2c, CSR_MBB);
+ if (ret) {
+ dev_err(i2c->dev, "timeout waiting for CSR_MBB\n");
+ return;
+ }
+ val = readb(i2c->base + MPC_I2C_DR);
+ ret = i2c_mpc_wait_sr(i2c, CSR_MIF);
+ if (ret) {
+ dev_err(i2c->dev, "timeout waiting for CSR_MIF\n");
+ return;
+ }
+ writeccr(i2c, CCR_MEN | CCR_RSVD);
+ } else {
+ val = readb(i2c->base + MPC_I2C_DR);
+ ret = i2c_mpc_wait_sr(i2c, CSR_MIF);
+ if (ret) {
+ dev_err(i2c->dev, "timeout waiting for CSR_MIF\n");
+ return;
+ }
+ writeccr(i2c, CCR_MEN);
+ }
+}
+
#if defined(CONFIG_PPC_MPC52xx) || defined(CONFIG_PPC_MPC512x)
static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
@@ -670,7 +741,10 @@ static int fsl_i2c_bus_recovery(struct i2c_adapter *adap)
{
struct mpc_i2c *i2c = i2c_get_adapdata(adap);
- mpc_i2c_fixup(i2c);
+ if (i2c->has_errata_A004447)
+ mpc_i2c_fixup_A004447(i2c);
+ else
+ mpc_i2c_fixup(i2c);
return 0;
}
@@ -767,6 +841,9 @@ static int fsl_i2c_probe(struct platform_device *op)
}
dev_info(i2c->dev, "timeout %u us\n", mpc_ops.timeout * 1000000 / HZ);
+ if (of_property_read_bool(op->dev.of_node, "fsl,i2c-erratum-a004447"))
+ i2c->has_errata_A004447 = true;
+
i2c->adap = mpc_ops;
scnprintf(i2c->adap.name, sizeof(i2c->adap.name),
"MPC adapter (%s)", of_node_full_name(op->dev.of_node));
--
2.31.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] powerpc/sstep: Add emulation support for ‘setb’ instruction
From: Segher Boessenkool @ 2021-05-11 19:57 UTC (permalink / raw)
To: Sathvika Vasireddy; +Cc: naveen.n.rao, linuxppc-dev, dja
In-Reply-To: <7b735b0c898da0db2af8628a64df2f5114596f22.1620727160.git.sathvika@linux.vnet.ibm.com>
On Tue, May 11, 2021 at 07:18:32AM -0500, Sathvika Vasireddy wrote:
> This adds emulation support for the following instruction:
> * Set Boolean (setb)
>
> Signed-off-by: Sathvika Vasireddy <sathvika@linux.vnet.ibm.com>
This looks fine to me, thanks!
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/makefile: Do not redefine $(CPP) for preprocessor
From: Nathan Chancellor @ 2021-05-11 19:18 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Michal Marek, linux-kbuild, Masahiro Yamada, Nick Desaulniers,
linux-kernel, Nicholas Piggin, clang-built-linux
In-Reply-To: <20210511044812.267965-1-aik@ozlabs.ru>
On 5/10/2021 9:48 PM, Alexey Kardashevskiy wrote:
> The $(CPP) (do only preprocessing) macro is already defined in Makefile.
> However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results
> in flags duplication. Which is not a big deal by itself except for
> the flags which depend on other flags and the compiler checks them
> as it parses the command line.
>
> Specifically, scripts/Makefile.build:304 generates ksyms for .S files.
> If clang+llvm+sanitizer are enabled, this results in
>
> -emit-llvm-bc -fno-lto -flto -fvisibility=hidden \
> -fsanitize=cfi-mfcall -fno-lto ...
>
> in the clang command line and triggers error:
>
> clang-13: error: invalid argument '-fsanitize=cfi-mfcall' only allowed with '-flto'
>
> This removes unnecessary CPP redefinition. Which works fine as in most
> place KBUILD_CFLAGS is passed to $CPP except
> arch/powerpc/kernel/vdso64/vdso(32|64).lds (and probably some others,
> not yet detected). To fix vdso, we do:
> 1. explicitly add -m(big|little)-endian to $CPP
> 2. (for clang) add $CLANG_FLAGS to $KBUILD_CPPFLAGS as otherwise clang
> silently ignores -m(big|little)-endian if the building platform does not
> support big endian (such as x86) so --prefix= is required.
>
> While at this, remove some duplication from CPPFLAGS_vdso(32|64)
> as cmd_cpp_lds_S has them anyway. It still puzzles me why we need -C
> (preserve comments in the preprocessor output) flag here.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v2:
> * fix KBUILD_CPPFLAGS
> * add CLANG_FLAGS to CPPFLAGS
> ---
> Makefile | 1 +
> arch/powerpc/Makefile | 3 ++-
> arch/powerpc/kernel/vdso32/Makefile | 2 +-
> arch/powerpc/kernel/vdso64/Makefile | 2 +-
> 4 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 72af8e423f11..13acd2183d55 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -591,6 +591,7 @@ CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
> endif
> CLANG_FLAGS += -Werror=unknown-warning-option
> KBUILD_CFLAGS += $(CLANG_FLAGS)
> +KBUILD_CPPFLAGS += $(CLANG_FLAGS)
This is going to cause flag duplication, which would be nice to avoid. I
do not know if we can get away with just adding $(CLANG_FLAGS) to
KBUILD_CPPFLAGS instead of KBUILD_CFLAGS though. It seems like this
assignment might be better in arch/powerpc/Makefile with the
KBUILD_CPPFLAGS additions there.
Cheers,
Nathan
> KBUILD_AFLAGS += $(CLANG_FLAGS)
> export CLANG_FLAGS
> endif
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 3212d076ac6a..306bfd2797ad 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -76,6 +76,7 @@ endif
>
> ifdef CONFIG_CPU_LITTLE_ENDIAN
> KBUILD_CFLAGS += -mlittle-endian
> +KBUILD_CPPFLAGS += -mlittle-endian
> KBUILD_LDFLAGS += -EL
> LDEMULATION := lppc
> GNUTARGET := powerpcle
> @@ -83,6 +84,7 @@ MULTIPLEWORD := -mno-multiple
> KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect)
> else
> KBUILD_CFLAGS += $(call cc-option,-mbig-endian)
> +KBUILD_CPPFLAGS += $(call cc-option,-mbig-endian)
> KBUILD_LDFLAGS += -EB
> LDEMULATION := ppc
> GNUTARGET := powerpc
> @@ -208,7 +210,6 @@ KBUILD_CPPFLAGS += -I $(srctree)/arch/$(ARCH) $(asinstr)
> KBUILD_AFLAGS += $(AFLAGS-y)
> KBUILD_CFLAGS += $(call cc-option,-msoft-float)
> KBUILD_CFLAGS += -pipe $(CFLAGS-y)
> -CPP = $(CC) -E $(KBUILD_CFLAGS)
>
> CHECKFLAGS += -m$(BITS) -D__powerpc__ -D__powerpc$(BITS)__
> ifdef CONFIG_CPU_BIG_ENDIAN
> diff --git a/arch/powerpc/kernel/vdso32/Makefile b/arch/powerpc/kernel/vdso32/Makefile
> index 7d9a6fee0e3d..ea001c6df1fa 100644
> --- a/arch/powerpc/kernel/vdso32/Makefile
> +++ b/arch/powerpc/kernel/vdso32/Makefile
> @@ -44,7 +44,7 @@ asflags-y := -D__VDSO32__ -s
>
> obj-y += vdso32_wrapper.o
> targets += vdso32.lds
> -CPPFLAGS_vdso32.lds += -P -C -Upowerpc
> +CPPFLAGS_vdso32.lds += -C
>
> # link rule for the .so file, .lds has to be first
> $(obj)/vdso32.so.dbg: $(src)/vdso32.lds $(obj-vdso32) $(obj)/vgettimeofday.o FORCE
> diff --git a/arch/powerpc/kernel/vdso64/Makefile b/arch/powerpc/kernel/vdso64/Makefile
> index 2813e3f98db6..07eadba48c7a 100644
> --- a/arch/powerpc/kernel/vdso64/Makefile
> +++ b/arch/powerpc/kernel/vdso64/Makefile
> @@ -30,7 +30,7 @@ ccflags-y := -shared -fno-common -fno-builtin -nostdlib \
> asflags-y := -D__VDSO64__ -s
>
> targets += vdso64.lds
> -CPPFLAGS_vdso64.lds += -P -C -U$(ARCH)
> +CPPFLAGS_vdso64.lds += -C
>
> # link rule for the .so file, .lds has to be first
> $(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) $(obj)/vgettimeofday.o FORCE
>
^ permalink raw reply
* Re: [PATCH v3 1/3] audit: replace magic audit syscall class numbers with macros
From: Richard Guy Briggs @ 2021-05-11 18:50 UTC (permalink / raw)
To: Paul Moore
Cc: linux-s390, linux-ia64, linux-parisc, Arnd Bergmann, x86, LKML,
Eric Paris, sparclinux, Aleksa Sarai, Linux-Audit Mailing List,
Alexander Viro, linux-alpha, linux-fsdevel, Eric Paris,
Steve Grubb, linuxppc-dev
In-Reply-To: <CAHC9VhShi4u26h5OsahveQDNxO_uZ+KgzGOYEp5W7w6foA-uKg@mail.gmail.com>
On 2021-05-10 21:23, Paul Moore wrote:
> On Fri, Apr 30, 2021 at 4:36 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> >
> > Replace audit syscall class magic numbers with macros.
> >
> > This required putting the macros into new header file
> > include/linux/auditscm.h since the syscall macros were included for both 64
> > bit and 32 bit in any compat code, causing redefinition warnings.
>
> The ifndef/define didn't protect against redeclaration? Huh. Maybe
> I'm not thinking about this correctly, or the arch specific code is
> doing something wonky ...
I had a chat with Arnd about it in IRC upstream and started digging
deeper and it got quite messy. As seen from the cover letter, audit.h
pulled in a chain of things which weren't entirely unreasonable given it
was compiling compat support in with native support by default. I
suppose I could have defined _ASM_X86_UNISTD_64_H to prevent it from
being added, but that would be ugly on a generated file, have caused a
failure elsewhere and would need to be done for each compat file. I
thought of defining CONFIG_X86_32 in arch/x86/ia32/audit.c but that
would cause other problems. This was the cleanest solution. Otherwise
I leave them as magic numbers like in V1.
> Regardless, assuming that it is necessary, I would prefer if we called
> it auditsc.h instead of auditscm.h; the latter makes me think of
> sockets and not syscalls.
>
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > MAINTAINERS | 1 +
> > arch/alpha/kernel/audit.c | 8 ++++----
> > arch/ia64/kernel/audit.c | 8 ++++----
> > arch/parisc/kernel/audit.c | 8 ++++----
> > arch/parisc/kernel/compat_audit.c | 9 +++++----
> > arch/powerpc/kernel/audit.c | 10 +++++-----
> > arch/powerpc/kernel/compat_audit.c | 11 ++++++-----
> > arch/s390/kernel/audit.c | 10 +++++-----
> > arch/s390/kernel/compat_audit.c | 11 ++++++-----
> > arch/sparc/kernel/audit.c | 10 +++++-----
> > arch/sparc/kernel/compat_audit.c | 11 ++++++-----
> > arch/x86/ia32/audit.c | 11 ++++++-----
> > arch/x86/kernel/audit_64.c | 8 ++++----
> > include/linux/audit.h | 1 +
> > include/linux/auditscm.h | 23 +++++++++++++++++++++++
> > kernel/auditsc.c | 12 ++++++------
> > lib/audit.c | 10 +++++-----
> > lib/compat_audit.c | 11 ++++++-----
> > 18 files changed, 102 insertions(+), 71 deletions(-)
> > create mode 100644 include/linux/auditscm.h
>
> ...
>
> > diff --git a/include/linux/auditscm.h b/include/linux/auditscm.h
> > new file mode 100644
> > index 000000000000..1c4f0ead5931
> > --- /dev/null
> > +++ b/include/linux/auditscm.h
> > @@ -0,0 +1,23 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/* auditscm.h -- Auditing support syscall macros
> > + *
> > + * Copyright 2021 Red Hat Inc., Durham, North Carolina.
> > + * All Rights Reserved.
> > + *
> > + * Author: Richard Guy Briggs <rgb@redhat.com>
> > + */
> > +#ifndef _LINUX_AUDITSCM_H_
> > +#define _LINUX_AUDITSCM_H_
> > +
> > +enum auditsc_class_t {
> > + AUDITSC_NATIVE = 0,
> > + AUDITSC_COMPAT,
> > + AUDITSC_OPEN,
> > + AUDITSC_OPENAT,
> > + AUDITSC_SOCKETCALL,
> > + AUDITSC_EXECVE,
> > +
> > + AUDITSC_NVALS /* count */
> > +};
> > +
> > +#endif
>
> --
> paul moore
> www.paul-moore.com
>
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH v3 1/3] audit: replace magic audit syscall class numbers with macros
From: Paul Moore @ 2021-05-11 17:51 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-s390, linux-ia64, linux-parisc, Arnd Bergmann, x86, LKML,
Eric Paris, sparclinux, Aleksa Sarai, Linux-Audit Mailing List,
Alexander Viro, linux-alpha, linux-fsdevel, Eric Paris,
Steve Grubb, linuxppc-dev
In-Reply-To: <20210511171356.GN3141668@madcap2.tricolour.ca>
On Tue, May 11, 2021 at 1:14 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> On 2021-05-10 21:23, Paul Moore wrote:
> > On Fri, Apr 30, 2021 at 4:36 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > >
> > > Replace audit syscall class magic numbers with macros.
> > >
> > > This required putting the macros into new header file
> > > include/linux/auditscm.h since the syscall macros were included for both 64
> > > bit and 32 bit in any compat code, causing redefinition warnings.
> >
> > The ifndef/define didn't protect against redeclaration? Huh. Maybe
> > I'm not thinking about this correctly, or the arch specific code is
> > doing something wonky ...
> >
> > Regardless, assuming that it is necessary, I would prefer if we called
> > it auditsc.h instead of auditscm.h; the latter makes me think of
> > sockets and not syscalls.
>
> The "m" was for "macros", since there are auditsc bits in audit.h as
> well, but I have no significant objection.
Yes, I figured as much, but my comment about it looking like a socket
"thing" still stands. I'm open to other ideas if you don't like
auditsc.h, I just don't like auditscm.h.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 1/3] audit: replace magic audit syscall class numbers with macros
From: Richard Guy Briggs @ 2021-05-11 17:13 UTC (permalink / raw)
To: Paul Moore
Cc: linux-s390, linux-ia64, linux-parisc, Arnd Bergmann, x86, LKML,
Eric Paris, sparclinux, Aleksa Sarai, Linux-Audit Mailing List,
Alexander Viro, linux-alpha, linux-fsdevel, Eric Paris,
Steve Grubb, linuxppc-dev
In-Reply-To: <CAHC9VhShi4u26h5OsahveQDNxO_uZ+KgzGOYEp5W7w6foA-uKg@mail.gmail.com>
On 2021-05-10 21:23, Paul Moore wrote:
> On Fri, Apr 30, 2021 at 4:36 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> >
> > Replace audit syscall class magic numbers with macros.
> >
> > This required putting the macros into new header file
> > include/linux/auditscm.h since the syscall macros were included for both 64
> > bit and 32 bit in any compat code, causing redefinition warnings.
>
> The ifndef/define didn't protect against redeclaration? Huh. Maybe
> I'm not thinking about this correctly, or the arch specific code is
> doing something wonky ...
>
> Regardless, assuming that it is necessary, I would prefer if we called
> it auditsc.h instead of auditscm.h; the latter makes me think of
> sockets and not syscalls.
The "m" was for "macros", since there are auditsc bits in audit.h as
well, but I have no significant objection.
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > MAINTAINERS | 1 +
> > arch/alpha/kernel/audit.c | 8 ++++----
> > arch/ia64/kernel/audit.c | 8 ++++----
> > arch/parisc/kernel/audit.c | 8 ++++----
> > arch/parisc/kernel/compat_audit.c | 9 +++++----
> > arch/powerpc/kernel/audit.c | 10 +++++-----
> > arch/powerpc/kernel/compat_audit.c | 11 ++++++-----
> > arch/s390/kernel/audit.c | 10 +++++-----
> > arch/s390/kernel/compat_audit.c | 11 ++++++-----
> > arch/sparc/kernel/audit.c | 10 +++++-----
> > arch/sparc/kernel/compat_audit.c | 11 ++++++-----
> > arch/x86/ia32/audit.c | 11 ++++++-----
> > arch/x86/kernel/audit_64.c | 8 ++++----
> > include/linux/audit.h | 1 +
> > include/linux/auditscm.h | 23 +++++++++++++++++++++++
> > kernel/auditsc.c | 12 ++++++------
> > lib/audit.c | 10 +++++-----
> > lib/compat_audit.c | 11 ++++++-----
> > 18 files changed, 102 insertions(+), 71 deletions(-)
> > create mode 100644 include/linux/auditscm.h
>
> ...
>
> > diff --git a/include/linux/auditscm.h b/include/linux/auditscm.h
> > new file mode 100644
> > index 000000000000..1c4f0ead5931
> > --- /dev/null
> > +++ b/include/linux/auditscm.h
> > @@ -0,0 +1,23 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/* auditscm.h -- Auditing support syscall macros
> > + *
> > + * Copyright 2021 Red Hat Inc., Durham, North Carolina.
> > + * All Rights Reserved.
> > + *
> > + * Author: Richard Guy Briggs <rgb@redhat.com>
> > + */
> > +#ifndef _LINUX_AUDITSCM_H_
> > +#define _LINUX_AUDITSCM_H_
> > +
> > +enum auditsc_class_t {
> > + AUDITSC_NATIVE = 0,
> > + AUDITSC_COMPAT,
> > + AUDITSC_OPEN,
> > + AUDITSC_OPENAT,
> > + AUDITSC_SOCKETCALL,
> > + AUDITSC_EXECVE,
> > +
> > + AUDITSC_NVALS /* count */
> > +};
> > +
> > +#endif
>
> --
> paul moore
> www.paul-moore.com
>
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH v6 04/15] swiotlb: Add restricted DMA pool initialization
From: Claire Chang @ 2021-05-11 16:42 UTC (permalink / raw)
To: Christoph Hellwig
Cc: heikki.krogerus, thomas.hellstrom, peterz, joonas.lahtinen,
dri-devel, chris, grant.likely, paulus, Frank Rowand, mingo,
Marek Szyprowski, sstabellini, Saravana Kannan, Joerg Roedel,
Rafael J . Wysocki, Bartosz Golaszewski, bskeggs, linux-pci,
xen-devel, Thierry Reding, intel-gfx, matthew.auld,
linux-devicetree, Jianxiong Gao, Daniel Vetter, Will Deacon,
Konrad Rzeszutek Wilk, maarten.lankhorst, airlied, Dan Williams,
linuxppc-dev, jani.nikula, Rob Herring, rodrigo.vivi,
Bjorn Helgaas, boris.ostrovsky, Andy Shevchenko, jgross,
Nicolas Boichat, nouveau, Greg KH, Randy Dunlap, lkml,
Tomasz Figa, list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
Robin Murphy, bauerman
In-Reply-To: <20210510150256.GC28066@lst.de>
On Mon, May 10, 2021 at 11:03 PM Christoph Hellwig <hch@lst.de> wrote:
>
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > +#include <linux/io.h>
> > +#include <linux/of.h>
> > +#include <linux/of_fdt.h>
> > +#include <linux/of_reserved_mem.h>
> > +#include <linux/slab.h>
> > +#endif
>
> I don't think any of this belongs into swiotlb.c. Marking
> swiotlb_init_io_tlb_mem non-static and having all this code in a separate
> file is probably a better idea.
Will do in the next version.
>
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
> > + struct device *dev)
> > +{
> > + struct io_tlb_mem *mem = rmem->priv;
> > + unsigned long nslabs = rmem->size >> IO_TLB_SHIFT;
> > +
> > + if (dev->dma_io_tlb_mem)
> > + return 0;
> > +
> > + /* Since multiple devices can share the same pool, the private data,
> > + * io_tlb_mem struct, will be initialized by the first device attached
> > + * to it.
> > + */
>
> This is not the normal kernel comment style.
Will fix this in the next version.
>
> > +#ifdef CONFIG_ARM
> > + if (!PageHighMem(pfn_to_page(PHYS_PFN(rmem->base)))) {
> > + kfree(mem);
> > + return -EINVAL;
> > + }
> > +#endif /* CONFIG_ARM */
>
> And this is weird. Why would ARM have such a restriction? And if we have
> such rstrictions it absolutely belongs into an arch helper.
Now I think the CONFIG_ARM can just be removed?
The goal here is to make sure we're using linear map and can safely
use phys_to_dma/dma_to_phys.
>
> > + swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false);
> > +
> > + rmem->priv = mem;
> > +
> > +#ifdef CONFIG_DEBUG_FS
> > + if (!debugfs_dir)
> > + debugfs_dir = debugfs_create_dir("swiotlb", NULL);
> > +
> > + swiotlb_create_debugfs(mem, rmem->name, debugfs_dir);
>
> Doesn't the debugfs_create_dir belong into swiotlb_create_debugfs? Also
> please use IS_ENABLEd or a stub to avoid ifdefs like this.
Will move it into swiotlb_create_debugfs and use IS_ENABLED in the next version.
^ permalink raw reply
* Re: [PATCH v6 05/15] swiotlb: Add a new get_io_tlb_mem getter
From: Claire Chang @ 2021-05-11 16:42 UTC (permalink / raw)
To: Christoph Hellwig
Cc: heikki.krogerus, thomas.hellstrom, peterz, joonas.lahtinen,
dri-devel, chris, grant.likely, paulus, Frank Rowand, mingo,
Marek Szyprowski, sstabellini, Saravana Kannan, Joerg Roedel,
Rafael J . Wysocki, Bartosz Golaszewski, bskeggs, linux-pci,
xen-devel, Thierry Reding, intel-gfx, matthew.auld,
linux-devicetree, Jianxiong Gao, Daniel Vetter, Will Deacon,
Konrad Rzeszutek Wilk, maarten.lankhorst, airlied, Dan Williams,
linuxppc-dev, jani.nikula, Rob Herring, rodrigo.vivi,
Bjorn Helgaas, boris.ostrovsky, Andy Shevchenko, jgross,
Nicolas Boichat, nouveau, Greg KH, Randy Dunlap, lkml,
Tomasz Figa, list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
Robin Murphy, bauerman
In-Reply-To: <20210510150342.GD28066@lst.de>
On Mon, May 10, 2021 at 11:03 PM Christoph Hellwig <hch@lst.de> wrote:
>
> > +static inline struct io_tlb_mem *get_io_tlb_mem(struct device *dev)
> > +{
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > + if (dev && dev->dma_io_tlb_mem)
> > + return dev->dma_io_tlb_mem;
> > +#endif /* CONFIG_DMA_RESTRICTED_POOL */
> > +
> > + return io_tlb_default_mem;
>
> Given that we're also looking into a not addressing restricted pool
> I'd rather always assign the active pool to dev->dma_io_tlb_mem and
> do away with this helper.
Where do you think is the proper place to do the assignment? First
time calling swiotlb_map? or in of_dma_configure_id?
^ permalink raw reply
* Re: [PATCH v6 08/15] swiotlb: Bounce data from/to restricted DMA pool if available
From: Claire Chang @ 2021-05-11 16:42 UTC (permalink / raw)
To: Christoph Hellwig
Cc: heikki.krogerus, thomas.hellstrom, peterz, joonas.lahtinen,
dri-devel, chris, grant.likely, paulus, Frank Rowand, mingo,
Marek Szyprowski, sstabellini, Saravana Kannan, Joerg Roedel,
Rafael J . Wysocki, Bartosz Golaszewski, bskeggs, linux-pci,
xen-devel, Thierry Reding, intel-gfx, matthew.auld,
linux-devicetree, Jianxiong Gao, Daniel Vetter, Will Deacon,
Konrad Rzeszutek Wilk, maarten.lankhorst, airlied, Dan Williams,
linuxppc-dev, jani.nikula, Rob Herring, rodrigo.vivi,
Bjorn Helgaas, boris.ostrovsky, Andy Shevchenko, jgross,
Nicolas Boichat, nouveau, Greg KH, Randy Dunlap, lkml,
Tomasz Figa, list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
Robin Murphy, bauerman
In-Reply-To: <20210510150516.GE28066@lst.de>
On Mon, May 10, 2021 at 11:05 PM Christoph Hellwig <hch@lst.de> wrote:
>
> > +static inline bool is_dev_swiotlb_force(struct device *dev)
> > +{
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > + if (dev->dma_io_tlb_mem)
> > + return true;
> > +#endif /* CONFIG_DMA_RESTRICTED_POOL */
> > + return false;
> > +}
> > +
>
> > /* If SWIOTLB is active, use its maximum mapping size */
> > if (is_swiotlb_active(dev) &&
> > - (dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE))
> > + (dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE ||
> > + is_dev_swiotlb_force(dev)))
>
> This is a mess. I think the right way is to have an always_bounce flag
> in the io_tlb_mem structure instead. Then the global swiotlb_force can
> go away and be replace with this and the fact that having no
> io_tlb_mem structure at all means forced no buffering (after a little
> refactoring).
Will do in the next version.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Fix kvm_unmap_gfn_range_hv() for Hash MMU
From: Sean Christopherson @ 2021-05-11 16:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: kvm-ppc, pbonzini, linuxppc-dev, kvm, npiggin
In-Reply-To: <20210511105459.800788-1-mpe@ellerman.id.au>
On Tue, May 11, 2021, Michael Ellerman wrote:
> Commit 32b48bf8514c ("KVM: PPC: Book3S HV: Fix conversion to gfn-based
> MMU notifier callbacks") fixed kvm_unmap_gfn_range_hv() by adding a for
> loop over each gfn in the range.
>
> But for the Hash MMU it repeatedly calls kvm_unmap_rmapp() with the
> first gfn of the range, rather than iterating through the range.
>
> This exhibits as strange guest behaviour, sometimes crashing in firmare,
> or booting and then guest userspace crashing unexpectedly.
>
> Fix it by passing the iterator, gfn, to kvm_unmap_rmapp().
>
> Fixes: 32b48bf8514c ("KVM: PPC: Book3S HV: Fix conversion to gfn-based MMU notifier callbacks")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> I plan to take this via the powerpc fixes branch.
FWIW,
Reviewed-by: Sean Christopherson <seanjc@google.com>
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 2d9193cd73be..c63e263312a4 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -840,7 +840,7 @@ bool kvm_unmap_gfn_range_hv(struct kvm *kvm, struct kvm_gfn_range *range)
> kvm_unmap_radix(kvm, range->slot, gfn);
> } else {
> for (gfn = range->start; gfn < range->end; gfn++)
> - kvm_unmap_rmapp(kvm, range->slot, range->start);
> + kvm_unmap_rmapp(kvm, range->slot, gfn);
> }
>
> return false;
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: i2c: mpc: Add fsl, i2c-erratum-a004447 flag
From: Rob Herring @ 2021-05-11 15:33 UTC (permalink / raw)
To: Chris Packham
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
wsa@kernel.org, andy.shevchenko@gmail.com,
linux-i2c@vger.kernel.org, andriy.shevchenko@linux.intel.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <c5d6f8d0-9b8a-b3bf-b7c3-884f03f7ecee@alliedtelesis.co.nz>
On Sun, May 9, 2021 at 4:08 PM Chris Packham
<Chris.Packham@alliedtelesis.co.nz> wrote:
>
>
> On 8/05/21 9:49 am, Rob Herring wrote:
> > On Fri, May 07, 2021 at 12:40:45PM +1200, Chris Packham wrote:
> >> Document the fsl,i2c-erratum-a004447 flag which indicates the presence
> >> of an i2c erratum on some QorIQ SoCs.
> >>
> >> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> >> ---
> >> Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
> >> index 7b553d559c83..98c6fcf7bf26 100644
> >> --- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
> >> +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
> >> @@ -46,6 +46,13 @@ properties:
> >> description: |
> >> I2C bus timeout in microseconds
> >>
> >> + fsl,i2c-erratum-a004447:
> >> + $ref: /schemas/types.yaml#/definitions/flag
> >> + description: |
> >> + Indicates the presence of QorIQ erratum A-004447, which
> >> + says that the standard i2c recovery scheme mechanism does
> >> + not work and an alternate implementation is needed.
> > The problem with adding a property for an errata is you have to update
> > the dtb. If you use the compatible string, then only an OS update is
> > needed. That assumes you have specific enough compatible strings.
>
> I was following the style of the existing fsl,usb-erratum-a007792 or
> fsl,erratum-a008585 properties. But that's not really a compelling reason.
>
> The existing compatible string is "fsl-i2c" and it's used by pretty much
> every powerpc QorIQ SoC. There are some specific compatible strings in
> the driver for some of the older mpc SoCs. A more specific compatible
> string will work although determining which ones are affected might be a
> bit troublesome. That we know of the P2041 and P1010 are affected but I
> suspect there may be more. One disadvantage of using the compatible
> string is that as affected SoCs are identified we'll have to update the
> driver to know that SoC is affected and update the dtb to use it. With
> the property we'd just have to update the dtb.
If you don't have specific compatibles in the dtb already, then it's
mute as the point was to avoid the dtb update.
> I'm not too fussed either way so if that's a hard NACK on the property I
> can send a version that uses compatible strings instead.
Acked-by: Rob Herring <robh@kernel.org>
You could still add compatibles for the next time...
^ permalink raw reply
* [PATCH v2 0/2] powerpc/sstep: Add emulation support and tests for 'setb' instruction
From: Sathvika Vasireddy @ 2021-05-11 12:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sathvika, naveen.n.rao, dja
This patchset adds emulation support and tests for setb instruction.
Test cases are written to test different CR fields with different
bits set in each field.
v1->v2:
- Extract all the bits of the CR field (bfa) and check if the
LT, GT bits of that CR field (bfa) are set.
- Place 'setb' emulation code after 'mfcr' instruction emulation.
- Add 'cpu_feature' in the selftests patch to restrict them to ISA v3.0
Sathvika Vasireddy (2):
powerpc/sstep: Add emulation support for ‘setb’ instruction
powerpc/sstep: Add tests for setb instruction
arch/powerpc/include/asm/ppc-opcode.h | 1 +
arch/powerpc/lib/sstep.c | 22 ++++++++++++++++++++++
arch/powerpc/lib/test_emulate_step.c | 29 +++++++++++++++++++++++++++++
3 files changed, 52 insertions(+)
--
2.16.4
^ permalink raw reply
* [PATCH v2 2/2] powerpc/sstep: Add tests for setb instruction
From: Sathvika Vasireddy @ 2021-05-11 12:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sathvika, naveen.n.rao, dja
In-Reply-To: <cover.1620727160.git.sathvika@linux.vnet.ibm.com>
This adds selftests for setb instruction.
Signed-off-by: Sathvika Vasireddy <sathvika@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/ppc-opcode.h | 1 +
arch/powerpc/lib/test_emulate_step.c | 29 +++++++++++++++++++++++++++++
2 files changed, 30 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index ac41776661e9..927551dd870b 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -245,6 +245,7 @@
#define PPC_INST_STRING 0x7c00042a
#define PPC_INST_STRING_MASK 0xfc0007fe
#define PPC_INST_STRING_GEN_MASK 0xfc00067e
+#define PPC_INST_SETB 0x7c000100
#define PPC_INST_STSWI 0x7c0005aa
#define PPC_INST_STSWX 0x7c00052a
#define PPC_INST_TRECHKPT 0x7c0007dd
diff --git a/arch/powerpc/lib/test_emulate_step.c b/arch/powerpc/lib/test_emulate_step.c
index 783d1b85ecfe..a0a52fe5e979 100644
--- a/arch/powerpc/lib/test_emulate_step.c
+++ b/arch/powerpc/lib/test_emulate_step.c
@@ -53,6 +53,8 @@
ppc_inst_prefix(PPC_PREFIX_MLS | __PPC_PRFX_R(pr) | IMM_H(i), \
PPC_RAW_ADDI(t, a, i))
+#define TEST_SETB(t, bfa) ppc_inst(PPC_INST_SETB | ___PPC_RT(t) | ___PPC_RA((bfa & 0x7) << 2))
+
static void __init init_pt_regs(struct pt_regs *regs)
{
@@ -929,6 +931,33 @@ static struct compute_test compute_tests[] = {
}
}
},
+ {
+ .mnemonic = "setb",
+ .cpu_feature = CPU_FTR_ARCH_300,
+ .subtests = {
+ {
+ .descr = "BFA = 1, CR = GT",
+ .instr = TEST_SETB(20, 1),
+ .regs = {
+ .ccr = 0x4000000,
+ }
+ },
+ {
+ .descr = "BFA = 4, CR = LT",
+ .instr = TEST_SETB(20, 4),
+ .regs = {
+ .ccr = 0x8000,
+ }
+ },
+ {
+ .descr = "BFA = 5, CR = EQ",
+ .instr = TEST_SETB(20, 5),
+ .regs = {
+ .ccr = 0x200,
+ }
+ }
+ }
+ },
{
.mnemonic = "add",
.subtests = {
--
2.16.4
^ permalink raw reply related
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