* Re: [PATCH v2 06/11] dt-bindings: arm: samsung: Convert Exynos Chipid bindings to json-schema
From: Rob Herring @ 2019-09-18 12:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, linux-samsung-soc,
devicetree, linux-iio, linux-pm, linux-kernel, linux-arm-kernel,
Paweł Chmiel
In-Reply-To: <20190907092007.9946-6-krzk@kernel.org>
On Sat, 7 Sep 2019 11:20:02 +0200, Krzysztof Kozlowski wrote:
> Convert Samsung Exynos Chipid bindings to DT schema format using
> json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../bindings/arm/samsung/exynos-chipid.txt | 12 ---------
> .../bindings/arm/samsung/exynos-chipid.yaml | 25 +++++++++++++++++++
> 2 files changed, 25 insertions(+), 12 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
> create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml
>
Applied, thanks.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 09/11] dt-bindings: rtc: s3c: Convert S3C/Exynos RTC bindings to json-schema
From: Rob Herring @ 2019-09-18 12:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, linux-samsung-soc,
devicetree, linux-iio, linux-pm, linux-kernel, linux-arm-kernel,
Paweł Chmiel
In-Reply-To: <20190907092007.9946-9-krzk@kernel.org>
On Sat, 7 Sep 2019 11:20:05 +0200, Krzysztof Kozlowski wrote:
> Convert Samsung S3C/Exynos Real Time Clock bindings to DT schema format
> using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Changes since v1:
> 1. Use deprecated property instead of custom select,
> 2. Rework clocks and clock-names matching for specific compatibles.
> ---
> .../devicetree/bindings/rtc/s3c-rtc.txt | 31 -------
> .../devicetree/bindings/rtc/s3c-rtc.yaml | 85 +++++++++++++++++++
> 2 files changed, 85 insertions(+), 31 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/rtc/s3c-rtc.txt
> create mode 100644 Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
>
Applied, thanks.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 10/11] dt-bindings: iio: adc: exynos: Convert Exynos ADC bindings to json-schema
From: Rob Herring @ 2019-09-18 12:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, linux-samsung-soc,
devicetree, linux-iio, linux-pm, linux-kernel, linux-arm-kernel,
Paweł Chmiel
In-Reply-To: <20190907092007.9946-10-krzk@kernel.org>
On Sat, 7 Sep 2019 11:20:06 +0200, Krzysztof Kozlowski wrote:
> Convert Samsung Exynos Analog to Digital Converter bindings to DT schema
> format using json-schema.
>
> This is a direct conversion of existing bindings so it also copies the
> existing error in the bindings regarding the requirement of two register
> address ranges for certain compatibles. The inconsistency in binding
> was caused by commit fafb37cfae6d ("iio: exyno-adc: use syscon for PMU
> register access").
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Changes since v1:
> 1. Rework reg, clocks and clock-names matching for specific compatibles,
> 2. Make samsung,syscon-phandle required only on certain compatibles,
> 3. Fix indentation.
> ---
> .../bindings/iio/adc/samsung,exynos-adc.txt | 107 ------------
> .../bindings/iio/adc/samsung,exynos-adc.yaml | 163 ++++++++++++++++++
> 2 files changed, 163 insertions(+), 107 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt
> create mode 100644 Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
>
Applied, thanks.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 11/11] dt-bindings: iio: adc: exynos: Remove old requirement of two register address ranges
From: Rob Herring @ 2019-09-18 12:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, linux-samsung-soc,
devicetree, linux-iio, linux-pm, linux-kernel, linux-arm-kernel,
Paweł Chmiel
In-Reply-To: <20190907092007.9946-11-krzk@kernel.org>
On Sat, 7 Sep 2019 11:20:07 +0200, Krzysztof Kozlowski wrote:
> Commit fafb37cfae6d ("iio: exyno-adc: use syscon for PMU
> register access") changed the Exynos ADC driver so the PMU syscon
> phandle is required instead of second register address space. The
> bindings were not updated so fix them now.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Changes since v1:
> 1. New patch.
> ---
> .../bindings/iio/adc/samsung,exynos-adc.yaml | 16 ++--------------
> 1 file changed, 2 insertions(+), 14 deletions(-)
>
Applied, thanks.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [arm-platforms:irq/gic-v4.1-devel 12/36] drivers/irqchip/irq-gic-v3-its.c:2172:9: error: implicit declaration of function 'gits_read_vpropbaser'; did you mean 'gicr_read_vpropbaser'?
From: kbuild test robot @ 2019-09-18 13:00 UTC (permalink / raw)
To: Marc Zyngier; +Cc: kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2609 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/gic-v4.1-devel
head: 9da741398299fcfba5e250ee337754b7c0e10cdd
commit: c65d1f89c69acba491e723d72ddb09e4fb9721b8 [12/36] irqchip/gic-v4.1: Revamp VPENDBASER table allocation
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c65d1f89c69acba491e723d72ddb09e4fb9721b8
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/irqchip/irq-gic-v3-its.c: In function 'inherit_vpe_l1_table_from_rd':
>> drivers/irqchip/irq-gic-v3-its.c:2172:9: error: implicit declaration of function 'gits_read_vpropbaser'; did you mean 'gicr_read_vpropbaser'? [-Werror=implicit-function-declaration]
val = gits_read_vpropbaser(base + SZ_128K + GICR_VPROPBASER);
^~~~~~~~~~~~~~~~~~~~
gicr_read_vpropbaser
cc1: some warnings being treated as errors
vim +2172 drivers/irqchip/irq-gic-v3-its.c
2144
2145 static u64 inherit_vpe_l1_table_from_rd(cpumask_t **mask)
2146 {
2147 u32 aff;
2148 u64 val;
2149 int cpu;
2150
2151 val = gic_read_typer(gic_data_rdist_rd_base() + GICR_TYPER);
2152 aff = compute_common_aff(val);
2153
2154 for_each_possible_cpu(cpu) {
2155 void __iomem *base = gic_data_rdist_cpu(cpu)->rd_base;
2156 u32 tmp;
2157
2158 if (!base || cpu == smp_processor_id())
2159 continue;
2160
2161 val = gic_read_typer(base + GICR_TYPER);
2162 tmp = compute_common_aff(val);
2163 if (tmp != aff)
2164 continue;
2165
2166 /*
2167 * At this point, we have a victim. This particular CPU
2168 * has already booted, and has an affinity that matches
2169 * ours wrt CommonLPIAff. Let's use its own VPROPBASER.
2170 * Make sure we don't write the Z bit in that case.
2171 */
> 2172 val = gits_read_vpropbaser(base + SZ_128K + GICR_VPROPBASER);
2173 val &= ~GICR_VPROPBASER_4_1_Z;
2174
2175 *mask = gic_data_rdist_cpu(cpu)->vpe_table_mask;
2176
2177 return val;
2178 }
2179
2180 return 0;
2181 }
2182
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47994 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 08/11] dt-bindings: arm: samsung: Convert Exynos System Registers bindings to json-schema
From: Krzysztof Kozlowski @ 2019-09-18 13:07 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni,
Lars-Peter Clausen, devicetree, linux-iio, linux-pm,
Sebastian Reichel, linux-kernel@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, Kukjin Kim, linux-arm-kernel,
Peter Meerwald-Stadler, Hartmut Knaack, linux-rtc,
Jonathan Cameron, Paweł Chmiel
In-Reply-To: <20190918123654.GA318@bogus>
On Wed, 18 Sep 2019 at 14:36, Rob Herring <robh@kernel.org> wrote:
>
> On Sat, Sep 07, 2019 at 11:20:04AM +0200, Krzysztof Kozlowski wrote:
> > Convert Samsung Exynos System Registers (SYSREG) bindings to DT schema
> > format using json-schema.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> >
> > ---
> >
> > Example somehow fails:
> > Documentation/devicetree/bindings/arm/samsung/pmu.example.dt.yaml:
> > system-controller@10040000: compatible:0: 'samsung,exynos5250-pmu' is
> > not one of ['samsung,exynos4-sysreg', 'samsung,exynos5-sysreg']
> >
> > It seems that PMU schema is applied to sysreq nodes (and vice-versa).
> > ---
> > .../bindings/arm/samsung/sysreg.txt | 19 -----------
> > .../bindings/arm/samsung/sysreg.yaml | 33 +++++++++++++++++++
> > 2 files changed, 33 insertions(+), 19 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/samsung/sysreg.txt
> > create mode 100644 Documentation/devicetree/bindings/arm/samsung/sysreg.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
> > deleted file mode 100644
> > index 4fced6e9d5e4..000000000000
> > --- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
> > +++ /dev/null
> > @@ -1,19 +0,0 @@
> > -SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
> > -
> > -Properties:
> > - - compatible : should contain two values. First value must be one from following list:
> > - - "samsung,exynos4-sysreg" - for Exynos4 based SoCs,
> > - - "samsung,exynos5-sysreg" - for Exynos5 based SoCs.
> > - second value must be always "syscon".
> > - - reg : offset and length of the register set.
> > -
> > -Example:
> > - syscon@10010000 {
> > - compatible = "samsung,exynos4-sysreg", "syscon";
> > - reg = <0x10010000 0x400>;
> > - };
> > -
> > - syscon@10050000 {
> > - compatible = "samsung,exynos5-sysreg", "syscon";
> > - reg = <0x10050000 0x5000>;
> > - };
> > diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml b/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml
> > new file mode 100644
> > index 000000000000..a3d44646e441
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml
> > @@ -0,0 +1,33 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/samsung/sysreg.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Samsung S5P/Exynos SoC series System Registers (SYSREG)
> > +
> > +maintainers:
> > + - Krzysztof Kozlowski <krzk@kernel.org>
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - enum:
> > + - samsung,exynos4-sysreg
> > + - samsung,exynos5-sysreg
> > + - const: syscon
>
> The problem is this will by default match any node with 'syscon'. You
> have to add a custom 'select' entry. See the LVDS panel bindings for an
> example.
>
> I'd like to kill off 'syscon'...
I see that panels use empty {} match but some other examples use
custom select. The panel approach in my case does not actually check
whether last compatible is syscon. I'll go then with a separate select
approach.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 07/11] dt-bindings: arm: samsung: Convert Exynos PMU bindings to json-schema
From: Krzysztof Kozlowski @ 2019-09-18 13:17 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni,
Lars-Peter Clausen, devicetree, linux-iio, linux-pm,
Sebastian Reichel, linux-kernel, linux-samsung-soc, Kukjin Kim,
linux-arm-kernel, Peter Meerwald-Stadler, Hartmut Knaack,
linux-rtc, Jonathan Cameron, Paweł Chmiel
In-Reply-To: <20190918124306.GB318@bogus>
On Wed, Sep 18, 2019 at 07:43:06AM -0500, Rob Herring wrote:
> On Sat, Sep 07, 2019 at 11:20:03AM +0200, Krzysztof Kozlowski wrote:
> > Convert Samsung Exynos Power Management Unit (PMU) bindings to DT schema
> > format using json-schema.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> >
> > ---
> >
> > Changes since v1:
> > 1. Fix clock-names to match all elements against schema (any number of
> > any clkoutN values).
> > This currently fails:
> > properties:clock-names:items: {'enum': ['clkout0', 'clkout1', 'clkout2',
> > 'clkout3', 'clkout4', 'clkout5', 'clkout6', 'clkout7', 'clkout8',
> > 'clkout9', 'clkout10', 'clkout11', 'clkout12', 'clkout13', 'clkout14',
> > 'clkout15', 'clkout16']} is not of type 'array
> >
> > 2. Add syscon reboot and poweroff nodes.
> > ---
> > .../devicetree/bindings/arm/samsung/pmu.txt | 72 -----------
> > .../devicetree/bindings/arm/samsung/pmu.yaml | 117 ++++++++++++++++++
> > 2 files changed, 117 insertions(+), 72 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/samsung/pmu.txt
> > create mode 100644 Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> > deleted file mode 100644
> > index 433bfd7593ac..000000000000
> > --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> > +++ /dev/null
> > @@ -1,72 +0,0 @@
> > -SAMSUNG Exynos SoC series PMU Registers
> > -
> > -Properties:
> > - - compatible : should contain two values. First value must be one from following list:
> > - - "samsung,exynos3250-pmu" - for Exynos3250 SoC,
> > - - "samsung,exynos4210-pmu" - for Exynos4210 SoC,
> > - - "samsung,exynos4412-pmu" - for Exynos4412 SoC,
> > - - "samsung,exynos5250-pmu" - for Exynos5250 SoC,
> > - - "samsung,exynos5260-pmu" - for Exynos5260 SoC.
> > - - "samsung,exynos5410-pmu" - for Exynos5410 SoC,
> > - - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
> > - - "samsung,exynos5433-pmu" - for Exynos5433 SoC.
> > - - "samsung,exynos7-pmu" - for Exynos7 SoC.
> > - second value must be always "syscon".
> > -
> > - - reg : offset and length of the register set.
> > -
> > - - #clock-cells : must be <1>, since PMU requires once cell as clock specifier.
> > - The single specifier cell is used as index to list of clocks
> > - provided by PMU, which is currently:
> > - 0 : SoC clock output (CLKOUT pin)
> > -
> > - - clock-names : list of clock names for particular CLKOUT mux inputs in
> > - following format:
> > - "clkoutN", where N is a decimal number corresponding to
> > - CLKOUT mux control bits value for given input, e.g.
> > - "clkout0", "clkout7", "clkout15".
> > -
> > - - clocks : list of phandles and specifiers to all input clocks listed in
> > - clock-names property.
> > -
> > -Optional properties:
> > -
> > -Some PMUs are capable of behaving as an interrupt controller (mostly
> > -to wake up a suspended PMU). In which case, they can have the
> > -following properties:
> > -
> > -- interrupt-controller: indicate that said PMU is an interrupt controller
> > -
> > -- #interrupt-cells: must be identical to the that of the parent interrupt
> > - controller.
> > -
> > -
> > -Optional nodes:
> > -
> > -- nodes defining the restart and poweroff syscon children
> > -
> > -
> > -Example :
> > -pmu_system_controller: system-controller@10040000 {
> > - compatible = "samsung,exynos5250-pmu", "syscon";
> > - reg = <0x10040000 0x5000>;
> > - interrupt-controller;
> > - #interrupt-cells = <3>;
> > - interrupt-parent = <&gic>;
> > - #clock-cells = <1>;
> > - clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
> > - "clkout4", "clkout8", "clkout9";
> > - clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
> > - <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
> > - <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
> > - <&clock CLK_XUSBXTI>;
> > -};
> > -
> > -Example of clock consumer :
> > -
> > -usb3503: usb3503@8 {
> > - /* ... */
> > - clock-names = "refclk";
> > - clocks = <&pmu_system_controller 0>;
> > - /* ... */
> > -};
> > diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> > new file mode 100644
> > index 000000000000..a5a02f8237fb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> > @@ -0,0 +1,117 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/samsung/pmu.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Samsung Exynos SoC series Power Management Unit (PMU)
> > +
> > +maintainers:
> > + - Krzysztof Kozlowski <krzk@kernel.org>
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - enum:
> > + - samsung,exynos3250-pmu
> > + - samsung,exynos4210-pmu
> > + - samsung,exynos4412-pmu
> > + - samsung,exynos5250-pmu
> > + - samsung,exynos5260-pmu
> > + - samsung,exynos5410-pmu
> > + - samsung,exynos5420-pmu
> > + - samsung,exynos5433-pmu
> > + - samsung,exynos7-pmu
> > + - const: syscon
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + '#clock-cells':
> > + const: 1
> > +
> > + clock-names:
> > + description:
> > + List of clock names for particular CLKOUT mux inputs
> > + minItems: 1
> > + maxItems: 32
> > + items:
> > + enum:
> > + - clkout0
> > + - clkout1
>
> Looking at this again, instead of enum, we can just do:
>
> pattern: '^clkout([0-9]|[12][0-9]|3[0-1])$'
Indeed looks better.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 0/3] fix double page fault on arm64
From: Jia He @ 2019-09-18 13:19 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Andrew Morton, Anshuman Khandual, Jun Yao,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Thomas Gleixner, Robin Murphy, Alex Van Brunt
When we tested pmdk unit test vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
Changes
v4: introduce cpu_has_hw_af (Suzuki)
bail out if !pte_same (Kirill)
v3: add vmf->ptl lock/unlock (by Kirill A. Shutemov)
add arch_faults_on_old_pte (Matthew, Catalin)
v2: remove FAULT_FLAG_WRITE when setting pte access flag (by Catalin)
Jia He (3):
arm64: cpufeature: introduce helper cpu_has_hw_af()
arm64: mm: implement arch_faults_on_old_pte() on arm64
mm: fix double page fault on arm64 if PTE_AF is cleared
arch/arm64/include/asm/cpufeature.h | 1 +
arch/arm64/include/asm/pgtable.h | 12 ++++++++++
arch/arm64/kernel/cpufeature.c | 6 +++++
mm/memory.c | 35 ++++++++++++++++++++++++-----
4 files changed, 49 insertions(+), 5 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
From: Jia He @ 2019-09-18 13:19 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Andrew Morton, Anshuman Khandual, Jun Yao,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Thomas Gleixner, Robin Murphy, Alex Van Brunt
In-Reply-To: <20190918131914.38081-1-justin.he@arm.com>
We unconditionally set the HW_AFDBM capability and only enable it on
CPUs which really have the feature. But sometimes we need to know
whether this cpu has the capability of HW AF. So decouple AF from
DBM by new helper cpu_has_hw_af().
Signed-off-by: Jia He <justin.he@arm.com>
Suggested-by: Suzuki Poulose <Suzuki.Poulose@arm.com>
---
arch/arm64/include/asm/cpufeature.h | 1 +
arch/arm64/kernel/cpufeature.c | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index c96ffa4722d3..206b6e3954cf 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -390,6 +390,7 @@ extern DECLARE_BITMAP(boot_capabilities, ARM64_NPATCHABLE);
for_each_set_bit(cap, cpu_hwcaps, ARM64_NCAPS)
bool this_cpu_has_cap(unsigned int cap);
+bool cpu_has_hw_af(void);
void cpu_set_feature(unsigned int num);
bool cpu_have_feature(unsigned int num);
unsigned long cpu_get_elf_hwcap(void);
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index b1fdc486aed8..c5097f58649d 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1141,6 +1141,12 @@ static bool has_hw_dbm(const struct arm64_cpu_capabilities *cap,
return true;
}
+/* Decouple AF from AFDBM. */
+bool cpu_has_hw_af(void)
+{
+ return (read_cpuid(ID_AA64MMFR1_EL1) & 0xf);
+}
+
#endif
#ifdef CONFIG_ARM64_VHE
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64
From: Jia He @ 2019-09-18 13:19 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Andrew Morton, Anshuman Khandual, Jun Yao,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Thomas Gleixner, Robin Murphy, Alex Van Brunt
In-Reply-To: <20190918131914.38081-1-justin.he@arm.com>
On arm64 without hardware Access Flag, copying fromuser will fail because
the pte is old and cannot be marked young. So we always end up with zeroed
page after fork() + CoW for pfn mappings. we don't always have a
hardware-managed access flag on arm64.
Hence implement arch_faults_on_old_pte on arm64 to indicate that it might
cause page fault when accessing old pte.
Signed-off-by: Jia He <justin.he@arm.com>
---
arch/arm64/include/asm/pgtable.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e09760ece844..4a9939615e41 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -868,6 +868,18 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
#define phys_to_ttbr(addr) (addr)
#endif
+/*
+ * On arm64 without hardware Access Flag, copying fromuser will fail because
+ * the pte is old and cannot be marked young. So we always end up with zeroed
+ * page after fork() + CoW for pfn mappings. we don't always have a
+ * hardware-managed access flag on arm64.
+ */
+static inline bool arch_faults_on_old_pte(void)
+{
+ return !cpu_has_hw_af();
+}
+#define arch_faults_on_old_pte arch_faults_on_old_pte
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_PGTABLE_H */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Jia He @ 2019-09-18 13:19 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Andrew Morton, Anshuman Khandual, Jun Yao,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Thomas Gleixner, Robin Murphy, Alex Van Brunt
In-Reply-To: <20190918131914.38081-1-justin.he@arm.com>
When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
Below call trace is from arm64 do_page_fault for debugging purpose
[ 110.016195] Call trace:
[ 110.016826] do_page_fault+0x5a4/0x690
[ 110.017812] do_mem_abort+0x50/0xb0
[ 110.018726] el1_da+0x20/0xc4
[ 110.019492] __arch_copy_from_user+0x180/0x280
[ 110.020646] do_wp_page+0xb0/0x860
[ 110.021517] __handle_mm_fault+0x994/0x1338
[ 110.022606] handle_mm_fault+0xe8/0x180
[ 110.023584] do_page_fault+0x240/0x690
[ 110.024535] do_mem_abort+0x50/0xb0
[ 110.025423] el0_da+0x20/0x24
The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
[ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
This patch fix it by calling pte_mkyoung. Also, the parameter is
changed because vmf should be passed to cow_user_page()
[1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
Reported-by: Yibo Cai <Yibo.Cai@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
---
mm/memory.c | 35 ++++++++++++++++++++++++++++++-----
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index e2bb51b6242e..d2c130a5883b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
2;
#endif
+#ifndef arch_faults_on_old_pte
+static inline bool arch_faults_on_old_pte(void)
+{
+ return false;
+}
+#endif
+
static int __init disable_randmaps(char *s)
{
randomize_va_space = 0;
@@ -2140,8 +2147,12 @@ static inline int pte_unmap_same(struct mm_struct *mm, pmd_t *pmd,
return same;
}
-static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
+static inline void cow_user_page(struct page *dst, struct page *src,
+ struct vm_fault *vmf)
{
+ struct vm_area_struct *vma = vmf->vma;
+ unsigned long addr = vmf->address;
+
debug_dma_assert_idle(src);
/*
@@ -2152,20 +2163,34 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
*/
if (unlikely(!src)) {
void *kaddr = kmap_atomic(dst);
- void __user *uaddr = (void __user *)(va & PAGE_MASK);
+ void __user *uaddr = (void __user *)(addr & PAGE_MASK);
+ pte_t entry;
/*
* This really shouldn't fail, because the page is there
* in the page tables. But it might just be unreadable,
* in which case we just give up and fill the result with
- * zeroes.
+ * zeroes. On architectures with software "accessed" bits,
+ * we would take a double page fault here, so mark it
+ * accessed here.
*/
+ if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
+ spin_lock(vmf->ptl);
+ if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
+ entry = pte_mkyoung(vmf->orig_pte);
+ if (ptep_set_access_flags(vma, addr,
+ vmf->pte, entry, 0))
+ update_mmu_cache(vma, addr, vmf->pte);
+ }
+ spin_unlock(vmf->ptl);
+ }
+
if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
clear_page(kaddr);
kunmap_atomic(kaddr);
flush_dcache_page(dst);
} else
- copy_user_highpage(dst, src, va, vma);
+ copy_user_highpage(dst, src, addr, vma);
}
static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
@@ -2318,7 +2343,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
vmf->address);
if (!new_page)
goto oom;
- cow_user_page(new_page, old_page, vmf->address, vma);
+ cow_user_page(new_page, old_page, vmf);
}
if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL, &memcg, false))
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] media: dt-bindings: Fix building error for dt_binding_check
From: Maxime Ripard @ 2019-09-18 13:24 UTC (permalink / raw)
To: Pragnesh Patel
Cc: Mark Rutland, devicetree, linux-kernel, Chen-Yu Tsai, Rob Herring,
Mauro Carvalho Chehab, linux-arm-kernel, linux-media
In-Reply-To: <1568808060-17516-1-git-send-email-pragnesh.patel@sifive.com>
On Wed, Sep 18, 2019 at 05:31:00PM +0530, Pragnesh Patel wrote:
> $id doesn't match the actual filename, so update the $id
>
> Signed-off-by: Pragnesh Patel <pragnesh.patel@sifive.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Thanks!
Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ethernet: Use devm_platform_ioremap_resource() in three functions
From: Markus Elfring @ 2019-09-18 13:30 UTC (permalink / raw)
To: netdev, linux-arm-kernel, David S. Miller, Hans Ulli Kroll,
Hauke Mehrtens, Linus Walleij, Michal Simek, Radhey Shyam Pandey
Cc: Bartosz Golaszewski, kernel-janitors, LKML, Himanshu Jha
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 18 Sep 2019 15:15:06 +0200
Simplify these function implementations by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/cortina/gemini.c | 6 +-----
drivers/net/ethernet/lantiq_xrx200.c | 11 +----------
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 +--------
3 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index e736ce2c58ca..f009415ee4d8 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -2549,17 +2549,13 @@ static int gemini_ethernet_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct gemini_ethernet *geth;
unsigned int retry = 5;
- struct resource *res;
u32 val;
/* Global registers */
geth = devm_kzalloc(dev, sizeof(*geth), GFP_KERNEL);
if (!geth)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
- geth->base = devm_ioremap_resource(dev, res);
+ geth->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(geth->base))
return PTR_ERR(geth->base);
geth->dev = dev;
diff --git a/drivers/net/ethernet/lantiq_xrx200.c b/drivers/net/ethernet/lantiq_xrx200.c
index 900affbdcc0e..0a7ea45b9e59 100644
--- a/drivers/net/ethernet/lantiq_xrx200.c
+++ b/drivers/net/ethernet/lantiq_xrx200.c
@@ -424,7 +424,6 @@ static int xrx200_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
- struct resource *res;
struct xrx200_priv *priv;
struct net_device *net_dev;
const u8 *mac;
@@ -443,15 +442,7 @@ static int xrx200_probe(struct platform_device *pdev)
SET_NETDEV_DEV(net_dev, dev);
net_dev->min_mtu = ETH_ZLEN;
net_dev->max_mtu = XRX200_DMA_DATA_LEN;
-
- /* load the memory ranges */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "failed to get resources\n");
- return -ENOENT;
- }
-
- priv->pmac_reg = devm_ioremap_resource(dev, res);
+ priv->pmac_reg = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->pmac_reg)) {
dev_err(dev, "failed to request and remap io ranges\n");
return PTR_ERR(priv->pmac_reg);
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 4fc627fb4d11..92783aaaa0a2 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1787,14 +1787,7 @@ static int axienet_probe(struct platform_device *pdev)
of_node_put(np);
lp->eth_irq = platform_get_irq(pdev, 0);
} else {
- /* Check for these resources directly on the Ethernet node. */
- struct resource *res = platform_get_resource(pdev,
- IORESOURCE_MEM, 1);
- if (!res) {
- dev_err(&pdev->dev, "unable to get DMA memory resource\n");
- goto free_netdev;
- }
- lp->dma_regs = devm_ioremap_resource(&pdev->dev, res);
+ lp->dma_regs = devm_platform_ioremap_resource(pdev, 1);
lp->rx_irq = platform_get_irq(pdev, 1);
lp->tx_irq = platform_get_irq(pdev, 0);
lp->eth_irq = platform_get_irq(pdev, 2);
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
From: Jassi Brar @ 2019-09-18 13:31 UTC (permalink / raw)
To: Andre Przywara
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190918110037.4edefb2f@donnerap.cambridge.arm.com>
On Wed, Sep 18, 2019 at 5:00 AM Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > >
> > > > + };
> > > > +};
> > >
> > > If this is the data structure that this mailbox controller uses, I would expect
> > > this to be documented somewhere, or even exported.
> >
> > Export this structure in include/linux/mailbox/smc-mailbox.h?
>
> For instance, even though I am not sure this is really desired or helpful, since we expect a generic mailbox client (the SCPI or SCMI driver) to deal with that mailbox.
>
> But at least the expected format should be documented, which could just be in writing, not necessarily in code.
>
Yes, the packet format is specified by the controller and defined in
some header for clients to include. Other platforms do that already.
> > > > +
> > > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
> > > > + unsigned long, unsigned long,
> > > > + unsigned long, unsigned long,
> > > > + unsigned long);
> > > > +static smc_mbox_fn *invoke_smc_mbox_fn;
> > > > +
> > > > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > > > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > > > + struct arm_smccc_mbox_cmd *cmd = data;
> > > > + unsigned long ret;
> > > > + u32 function_id;
> > > > +
> > > > + function_id = chan_data->function_id;
> > > > + if (!function_id)
> > > > + function_id = cmd->function_id;
> > > > +
> > > > + if (function_id & BIT(30)) {
> > >
> > > if (ARM_SMCCC_IS_64(function_id)) {
> >
> > ok
> >
> > >
> > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0],
> > > > + cmd->args_smccc64[1],
> > > > + cmd->args_smccc64[2],
> > > > + cmd->args_smccc64[3],
> > > > + cmd->args_smccc64[4],
> > > > + cmd->args_smccc64[5]);
> > > > + } else {
> > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0],
> > > > + cmd->args_smccc32[1],
> > > > + cmd->args_smccc32[2],
> > > > + cmd->args_smccc32[3],
> > > > + cmd->args_smccc32[4],
> > > > + cmd->args_smccc32[5]);
> > > > + }
> > > > +
> > > > + mbox_chan_received_data(link, (void *)ret);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static unsigned long __invoke_fn_hvc(unsigned int function_id,
> > > > + unsigned long arg0, unsigned long arg1,
> > > > + unsigned long arg2, unsigned long arg3,
> > > > + unsigned long arg4, unsigned long arg5) {
> > > > + struct arm_smccc_res res;
> > > > +
> > > > + arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
> > > > + arg5, 0, &res);
> > > > + return res.a0;
> > > > +}
> > > > +
> > > > +static unsigned long __invoke_fn_smc(unsigned int function_id,
> > > > + unsigned long arg0, unsigned long arg1,
> > > > + unsigned long arg2, unsigned long arg3,
> > > > + unsigned long arg4, unsigned long arg5) {
> > > > + struct arm_smccc_res res;
> > > > +
> > > > + arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
> > > > + arg5, 0, &res);
> > > > + return res.a0;
> > > > +}
> > > > +
> > > > +static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
> > > > + .send_data = arm_smc_send_data,
> > > > +};
> > > > +
> > > > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > > > + struct device *dev = &pdev->dev;
> > > > + struct mbox_controller *mbox;
> > > > + struct arm_smc_chan_data *chan_data;
> > > > + int ret;
> > > > + u32 function_id = 0;
> > > > +
> > > > + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox"))
> > > > + invoke_smc_mbox_fn = __invoke_fn_smc;
> > > > + else
> > > > + invoke_smc_mbox_fn = __invoke_fn_hvc;
> > > > +
> > > > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> > > > + if (!mbox)
> > > > + return -ENOMEM;
> > > > +
> > > > + mbox->num_chans = 1;
> > > > + mbox->chans = devm_kzalloc(dev, sizeof(*mbox->chans), GFP_KERNEL);
> > > > + if (!mbox->chans)
> > > > + return -ENOMEM;
> > > > +
> > > > + chan_data = devm_kzalloc(dev, sizeof(*chan_data), GFP_KERNEL);
> > > > + if (!chan_data)
> > > > + return -ENOMEM;
> > > > +
> > > > + of_property_read_u32(dev->of_node, "arm,func-id", &function_id);
> > > > + chan_data->function_id = function_id;
> > > > +
> > > > + mbox->chans->con_priv = chan_data;
> > > > +
> > > > + mbox->txdone_poll = false;
> > > > + mbox->txdone_irq = false;
> > >
> > > Don't we need to provide something to confirm reception to the client? In our
> > > case we can set this as soon as the smc/hvc returns.
> >
> > As smc/hvc returns, it means the transfer is over and receive is done.
>
> I understand that, but was wondering if the Linux mailbox framework knows about that? In my older version I was calling mbox_chan_received_data() after the smc call returned.
>
The code already does that at the end of send_data
> Also there is mbox_chan_txdone() with which a controller driver can signal TX completion explicitly.
>
No. Controller can use that only if it has specified txdone_irq, which
is not the case here.
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: etnaviv: Add #cooling-cells
From: Rob Herring @ 2019-09-18 13:33 UTC (permalink / raw)
To: Guido Günther
Cc: devicetree, Pengutronix Kernel Team, Anson Huang, Carlo Caione,
David Airlie, linux-kernel, Sascha Hauer, Angus Ainslie (Purism),
etnaviv, dri-devel, Abel Vesa, Andrey Smirnov, Christian Gmeiner,
NXP Linux Team, Daniel Vetter, Russell King, Fabio Estevam,
Guido Günther, linux-arm-kernel, To : Lucas Stach
In-Reply-To: <6e9d761598b2361532146f43161fd05f3eee6545.1568255903.git.agx@sigxcpu.org>
On Wed, 11 Sep 2019 19:40:36 -0700, =?UTF-8?q?Guido=20G=C3=BCnther?= wrote:
> Add #cooling-cells for when the gpu acts as a cooling device.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> .../devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Jassi Brar @ 2019-09-18 13:34 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, Andre Przywara,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, dl-linux-imx,
sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR04MB44811AE46803D10FD8A5B8B0888E0@AM0PR04MB4481.eurprd04.prod.outlook.com>
On Wed, Sep 18, 2019 at 3:53 AM Peng Fan <peng.fan@nxp.com> wrote:
> > >
> > > > +
> > > > + "#mbox-cells":
> > > > + const: 1
> > >
> > > Why is this "1"? What is this number used for? It used to be the channel ID,
> > but since you are describing a single channel controller only, this should be 0
> > now.
> > >
> > Yes. I overlooked it and actually queued the patch for pull request.
>
> In Documentation/devicetree/bindings/mailbox/mailbox.txt
> #mbox-cells: Must be at least 1.
>
> So I use 1 here, 0 not work. Because of_mbox_index_xlate expect at least 1 here.
> So I need modify Documentation/devicetree/bindings/mailbox/mailbox.txt
> and add xlate for smc mailbox?
>
No, you just can not use the generic xlate() provided by the api.
Please implement your own xlate() that requires no argument.
Cheers!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [arm-platforms:irq/gic-v4.1-devel 28/37] drivers/irqchip/irq-gic-v3-its.c:3700:3: error: implicit declaration of function 'writeq_relaxed'; did you mean 'writew_relaxed'?
From: kbuild test robot @ 2019-09-18 13:34 UTC (permalink / raw)
To: Marc Zyngier; +Cc: kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/gic-v4.1-devel
head: 4d3e7d5251c6b82f804bea4fe4c6d476e18722c0
commit: 5da1b7cd29c4632a7b60472f9f85b556fd362508 [28/37] irqchip/gic-v4.1: Plumb get/set_irqchip_state SGI callbacks
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 5da1b7cd29c4632a7b60472f9f85b556fd362508
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/irqchip/irq-gic-v3-its.c: In function 'inherit_vpe_l1_table_from_rd':
drivers/irqchip/irq-gic-v3-its.c:2339:9: error: implicit declaration of function 'gits_read_vpropbaser'; did you mean 'gicr_read_vpropbaser'? [-Werror=implicit-function-declaration]
val = gits_read_vpropbaser(base + SZ_128K + GICR_VPROPBASER);
^~~~~~~~~~~~~~~~~~~~
gicr_read_vpropbaser
drivers/irqchip/irq-gic-v3-its.c: In function 'its_sgi_set_irqchip_state':
>> drivers/irqchip/irq-gic-v3-its.c:3700:3: error: implicit declaration of function 'writeq_relaxed'; did you mean 'writew_relaxed'? [-Werror=implicit-function-declaration]
writeq_relaxed(val, its->sgir_base + GITS_SGIR - SZ_128K);
^~~~~~~~~~~~~~
writew_relaxed
cc1: some warnings being treated as errors
vim +3700 drivers/irqchip/irq-gic-v3-its.c
3685
3686 static int its_sgi_set_irqchip_state(struct irq_data *d,
3687 enum irqchip_irq_state which,
3688 bool state)
3689 {
3690 if (which != IRQCHIP_STATE_PENDING)
3691 return -EINVAL;
3692
3693 if (state) {
3694 struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
3695 struct its_node *its = find_4_1_its();
3696 u64 val;
3697
3698 val = FIELD_PREP(GITS_SGIR_VPEID, vpe->vpe_id);
3699 val |= FIELD_PREP(GITS_SGIR_VINTID, d->hwirq);
> 3700 writeq_relaxed(val, its->sgir_base + GITS_SGIR - SZ_128K);
3701 } else {
3702 its_configure_sgi(d, true);
3703 }
3704
3705 return 0;
3706 }
3707
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47994 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/9] mfd: wm8994: Add support for MCLKn clock control
From: Sylwester Nawrocki @ 2019-09-18 13:36 UTC (permalink / raw)
To: Charles Keepax
Cc: devicetree, alsa-devel, linux-samsung-soc, b.zolnierkie, sbkim73,
patches, broonie, lgirdwood, krzk, robh+dt, lee.jones,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20190918125435.GF10204@ediswmail.ad.cirrus.com>
On 9/18/19 14:54, Charles Keepax wrote:
>>> + ret = devm_clk_bulk_get_optional(wm8994->dev, ARRAY_SIZE(wm8994->mclk),
>>> + wm8994->mclk);
>>> + if (ret != 0)
>>> + return ret;
>
> Would be nice to print a message here as well, make it clear what
> failed in the log. Apart from that minor nit:
Thanks for reviewing, I will add that modification for v2.
--
Regards,
Sylwester
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] hwmon: (aspeed-pwm-tacho) Use devm_platform_ioremap_resource() in aspeed_pwm_tacho_probe()
From: Guenter Roeck @ 2019-09-18 13:39 UTC (permalink / raw)
To: Markus Elfring
Cc: linux-hwmon, Jean Delvare, linux-aspeed, Andrew Jeffery,
kernel-janitors, LKML, Bartosz Golaszewski, Joel Stanley,
linux-arm-kernel, Himanshu Jha
In-Reply-To: <cd5bab7b-9333-2a43-bcf0-a47bbbe719eb@web.de>
On Wed, Sep 18, 2019 at 10:20:09AM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 18 Sep 2019 10:12:31 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied to hwmon-next.
Thanks,
Guenter
> ---
> drivers/hwmon/aspeed-pwm-tacho.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> --
> 2.23.0
>
> diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
> index 40c489be62ea..33fb54845bf6 100644
> --- a/drivers/hwmon/aspeed-pwm-tacho.c
> +++ b/drivers/hwmon/aspeed-pwm-tacho.c
> @@ -891,17 +891,12 @@ static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
> struct device_node *np, *child;
> struct aspeed_pwm_tacho_data *priv;
> void __iomem *regs;
> - struct resource *res;
> struct device *hwmon;
> struct clk *clk;
> int ret;
>
> np = dev->of_node;
> -
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res)
> - return -ENOENT;
> - regs = devm_ioremap_resource(dev, res);
> + regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(regs))
> return PTR_ERR(regs);
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 05/12] namei: obey trailing magic-link DAC permissions
From: Aleksa Sarai @ 2019-09-18 13:51 UTC (permalink / raw)
To: Jann Horn
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, kernel list, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Jiri Olsa,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Shuah Khan,
Alexander Shishkin, Ingo Molnar, linux-arm-kernel, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, linuxppc-dev, linux-m68k,
Al Viro, Andy Lutomirski, Shuah Khan, Namhyung Kim,
David Drysdale, Christian Brauner, J. Bruce Fields, linux-parisc,
Linux API, Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
Linux Containers
In-Reply-To: <CAG48ez1_64249RdX6Nj_32YS+jhuXZBAd_ZL9ozggbSQy+cc-A@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3875 bytes --]
On 2019-09-17, Jann Horn <jannh@google.com> wrote:
> On Wed, Sep 4, 2019 at 10:21 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
> > The ability for userspace to "re-open" file descriptors through
> > /proc/self/fd has been a very useful tool for all sorts of usecases
> > (container runtimes are one common example). However, the current
> > interface for doing this has resulted in some pretty subtle security
> > holes. Userspace can re-open a file descriptor with more permissions
> > than the original, which can result in cases such as /proc/$pid/exe
> > being re-opened O_RDWR at a later date even though (by definition)
> > /proc/$pid/exe cannot be opened for writing. When combined with O_PATH
> > the results can get even more confusing.
> [...]
> > Instead we have to restrict it in such a way that it doesn't break
> > (good) users but does block potential attackers. The solution applied in
> > this patch is to restrict *re-opening* (not resolution through)
> > magic-links by requiring that mode of the link be obeyed. Normal
> > symlinks have modes of a+rwx but magic-links have other modes. These
> > magic-link modes were historically ignored during path resolution, but
> > they've now been re-purposed for more useful ends.
>
> Thanks for dealing with this issue!
>
> [...]
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 209c51a5226c..54d57dad0f91 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -872,7 +872,7 @@ void nd_jump_link(struct path *path)
> >
> > nd->path = *path;
> > nd->inode = nd->path.dentry->d_inode;
> > - nd->flags |= LOOKUP_JUMPED;
> > + nd->flags |= LOOKUP_JUMPED | LOOKUP_MAGICLINK_JUMPED;
> > }
> [...]
> > +static int trailing_magiclink(struct nameidata *nd, int acc_mode,
> > + fmode_t *opath_mask)
> > +{
> > + struct inode *inode = nd->link_inode;
> > + fmode_t upgrade_mask = 0;
> > +
> > + /* Was the trailing_symlink() a magic-link? */
> > + if (!(nd->flags & LOOKUP_MAGICLINK_JUMPED))
> > + return 0;
> > +
> > + /*
> > + * Figure out the upgrade-mask of the link_inode. Since these aren't
> > + * strictly POSIX semantics we don't do an acl_permission_check() here,
> > + * so we only care that at least one bit is set for each upgrade-mode.
> > + */
> > + if (inode->i_mode & S_IRUGO)
> > + upgrade_mask |= FMODE_PATH_READ;
> > + if (inode->i_mode & S_IWUGO)
> > + upgrade_mask |= FMODE_PATH_WRITE;
> > + /* Restrict the O_PATH upgrade-mask of the caller. */
> > + if (opath_mask)
> > + *opath_mask &= upgrade_mask;
> > + return may_open_magiclink(upgrade_mask, acc_mode);
> > }
>
> This looks racy because entries in the file descriptor table can be
> switched out as long as task->files->file_lock isn't held. Unless I'm
> missing something, something like the following (untested) would
> bypass this restriction:
You're absolutely right -- good catch!
> Perhaps you could change nd_jump_link() to "void nd_jump_link(struct
> path *path, umode_t link_mode)", and let proc_pid_get_link() pass the
> link_mode through from an out-argument of .proc_get_link()? Then
> proc_fd_link() could grab the proper mode in a race-free manner. And
> nd_jump_link() could stash the mode in the nameidata.
This indeed does appear to be the simplest solution -- I'm currently
testing a variation of the patch you proposed (with a few extra bits to
deal with nd_jump_link and proc_get_link being used elsewhere).
I'll include this change (assuming it fixes the flaw you found) in the
v13 series I'll send around next week. Thanks, Jann!
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan @ 2019-09-18 13:51 UTC (permalink / raw)
To: Jassi Brar
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, Andre Przywara,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, dl-linux-imx,
sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY09pPqM-47zNFVGMNM9wrDF9iiVuqKTXrEd4-PdOxBPrQ@mail.gmail.com>
> Subject: Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the
> ARM SMC/HVC mailbox
>
> On Wed, Sep 18, 2019 at 3:53 AM Peng Fan <peng.fan@nxp.com> wrote:
>
> > > >
> > > > > +
> > > > > + "#mbox-cells":
> > > > > + const: 1
> > > >
> > > > Why is this "1"? What is this number used for? It used to be the
> > > > channel ID,
> > > but since you are describing a single channel controller only, this
> > > should be 0 now.
> > > >
> > > Yes. I overlooked it and actually queued the patch for pull request.
> >
> > In Documentation/devicetree/bindings/mailbox/mailbox.txt
> > #mbox-cells: Must be at least 1.
> >
> > So I use 1 here, 0 not work. Because of_mbox_index_xlate expect at least 1
> here.
> > So I need modify Documentation/devicetree/bindings/mailbox/mailbox.txt
> > and add xlate for smc mailbox?
> >
> No, you just can not use the generic xlate() provided by the api.
> Please implement your own xlate() that requires no argument.
ok. Will add xlate.
Thanks,
Peng.
>
> Cheers!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 3/9] ASoC: wm8994: Add support for setting MCLKn clock rate
From: Charles Keepax @ 2019-09-18 13:51 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, b.zolnierkie, sbkim73,
patches, broonie, lgirdwood, krzk, robh+dt, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190918104634.15216-4-s.nawrocki@samsung.com>
On Wed, Sep 18, 2019 at 12:46:28PM +0200, Sylwester Nawrocki wrote:
> Extend the set_sysclk() handler so we also set frequency of the MCLK1,
> MCLK2 clocks through clk API when those clocks are specified in DT for
> the device.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
From: Andre Przywara @ 2019-09-18 13:58 UTC (permalink / raw)
To: Jassi Brar
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY2G8s9gV8Pu+f__8-bubjCJsVQrQikbVMZXmpTwSMBxiQ@mail.gmail.com>
On Wed, 18 Sep 2019 08:31:57 -0500
Jassi Brar <jassisinghbrar@gmail.com> wrote:
Hi,
> On Wed, Sep 18, 2019 at 5:00 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> > >
> > > >
> > > > > + };
> > > > > +};
> > > >
> > > > If this is the data structure that this mailbox controller uses, I would expect
> > > > this to be documented somewhere, or even exported.
> > >
> > > Export this structure in include/linux/mailbox/smc-mailbox.h?
> >
> > For instance, even though I am not sure this is really desired or helpful, since we expect a generic mailbox client (the SCPI or SCMI driver) to deal with that mailbox.
> >
> > But at least the expected format should be documented, which could just be in writing, not necessarily in code.
> >
> Yes, the packet format is specified by the controller and defined in
> some header for clients to include. Other platforms do that already.
Yeah, I saw some examples as well, but not every driver was following this apparently.
I guess since we have a fixed data format we should export the struct then, maybe with a remark that the actual usage of registers is up to the protocol (within the SMCCC limits), so is optional.
> > > > > +
> > > > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
> > > > > + unsigned long, unsigned long,
> > > > > + unsigned long, unsigned long,
> > > > > + unsigned long);
> > > > > +static smc_mbox_fn *invoke_smc_mbox_fn;
> > > > > +
> > > > > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > > > > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > > > > + struct arm_smccc_mbox_cmd *cmd = data;
> > > > > + unsigned long ret;
> > > > > + u32 function_id;
> > > > > +
> > > > > + function_id = chan_data->function_id;
> > > > > + if (!function_id)
> > > > > + function_id = cmd->function_id;
> > > > > +
> > > > > + if (function_id & BIT(30)) {
> > > >
> > > > if (ARM_SMCCC_IS_64(function_id)) {
> > >
> > > ok
> > >
> > > >
> > > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0],
> > > > > + cmd->args_smccc64[1],
> > > > > + cmd->args_smccc64[2],
> > > > > + cmd->args_smccc64[3],
> > > > > + cmd->args_smccc64[4],
> > > > > + cmd->args_smccc64[5]);
> > > > > + } else {
> > > > > + ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0],
> > > > > + cmd->args_smccc32[1],
> > > > > + cmd->args_smccc32[2],
> > > > > + cmd->args_smccc32[3],
> > > > > + cmd->args_smccc32[4],
> > > > > + cmd->args_smccc32[5]);
> > > > > + }
> > > > > +
> > > > > + mbox_chan_received_data(link, (void *)ret);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +static unsigned long __invoke_fn_hvc(unsigned int function_id,
> > > > > + unsigned long arg0, unsigned long arg1,
> > > > > + unsigned long arg2, unsigned long arg3,
> > > > > + unsigned long arg4, unsigned long arg5) {
> > > > > + struct arm_smccc_res res;
> > > > > +
> > > > > + arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
> > > > > + arg5, 0, &res);
> > > > > + return res.a0;
> > > > > +}
> > > > > +
> > > > > +static unsigned long __invoke_fn_smc(unsigned int function_id,
> > > > > + unsigned long arg0, unsigned long arg1,
> > > > > + unsigned long arg2, unsigned long arg3,
> > > > > + unsigned long arg4, unsigned long arg5) {
> > > > > + struct arm_smccc_res res;
> > > > > +
> > > > > + arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
> > > > > + arg5, 0, &res);
> > > > > + return res.a0;
> > > > > +}
> > > > > +
> > > > > +static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
> > > > > + .send_data = arm_smc_send_data,
> > > > > +};
> > > > > +
> > > > > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > > > > + struct device *dev = &pdev->dev;
> > > > > + struct mbox_controller *mbox;
> > > > > + struct arm_smc_chan_data *chan_data;
> > > > > + int ret;
> > > > > + u32 function_id = 0;
> > > > > +
> > > > > + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox"))
> > > > > + invoke_smc_mbox_fn = __invoke_fn_smc;
> > > > > + else
> > > > > + invoke_smc_mbox_fn = __invoke_fn_hvc;
> > > > > +
> > > > > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> > > > > + if (!mbox)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + mbox->num_chans = 1;
> > > > > + mbox->chans = devm_kzalloc(dev, sizeof(*mbox->chans), GFP_KERNEL);
> > > > > + if (!mbox->chans)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + chan_data = devm_kzalloc(dev, sizeof(*chan_data), GFP_KERNEL);
> > > > > + if (!chan_data)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + of_property_read_u32(dev->of_node, "arm,func-id", &function_id);
> > > > > + chan_data->function_id = function_id;
> > > > > +
> > > > > + mbox->chans->con_priv = chan_data;
> > > > > +
> > > > > + mbox->txdone_poll = false;
> > > > > + mbox->txdone_irq = false;
> > > >
> > > > Don't we need to provide something to confirm reception to the client? In our
> > > > case we can set this as soon as the smc/hvc returns.
> > >
> > > As smc/hvc returns, it means the transfer is over and receive is done.
> >
> > I understand that, but was wondering if the Linux mailbox framework knows about that? In my older version I was calling mbox_chan_received_data() after the smc call returned.
> >
> The code already does that at the end of send_data
True, for some reason I totally missed that line, sorry for that.
> > Also there is mbox_chan_txdone() with which a controller driver can signal TX completion explicitly.
> >
> No. Controller can use that only if it has specified txdone_irq, which
> is not the case here.
I see. So does the framework handle the case where both txdone_poll and txdone_irq are false?
Cheers,
Andre.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Kirill A. Shutemov @ 2019-09-18 14:00 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Catalin Marinas, linux-mm, Punit Agrawal,
Will Deacon, Alex Van Brunt, Marc Zyngier, Anshuman Khandual,
Matthew Wilcox, Jun Yao, Kaly Xin, hejianet, Ralph Campbell,
Suzuki Poulose, Jérôme Glisse, Thomas Gleixner,
linux-arm-kernel, linux-kernel, James Morse, Andrew Morton,
Robin Murphy, Kirill A. Shutemov
In-Reply-To: <20190918131914.38081-4-justin.he@arm.com>
On Wed, Sep 18, 2019 at 09:19:14PM +0800, Jia He wrote:
> When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
> will be a double page fault in __copy_from_user_inatomic of cow_user_page.
>
> Below call trace is from arm64 do_page_fault for debugging purpose
> [ 110.016195] Call trace:
> [ 110.016826] do_page_fault+0x5a4/0x690
> [ 110.017812] do_mem_abort+0x50/0xb0
> [ 110.018726] el1_da+0x20/0xc4
> [ 110.019492] __arch_copy_from_user+0x180/0x280
> [ 110.020646] do_wp_page+0xb0/0x860
> [ 110.021517] __handle_mm_fault+0x994/0x1338
> [ 110.022606] handle_mm_fault+0xe8/0x180
> [ 110.023584] do_page_fault+0x240/0x690
> [ 110.024535] do_mem_abort+0x50/0xb0
> [ 110.025423] el0_da+0x20/0x24
>
> The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
>
> As told by Catalin: "On arm64 without hardware Access Flag, copying from
> user will fail because the pte is old and cannot be marked young. So we
> always end up with zeroed page after fork() + CoW for pfn mappings. we
> don't always have a hardware-managed access flag on arm64."
>
> This patch fix it by calling pte_mkyoung. Also, the parameter is
> changed because vmf should be passed to cow_user_page()
>
> [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
>
> Reported-by: Yibo Cai <Yibo.Cai@arm.com>
> Signed-off-by: Jia He <justin.he@arm.com>
> ---
> mm/memory.c | 35 ++++++++++++++++++++++++++++++-----
> 1 file changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index e2bb51b6242e..d2c130a5883b 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> 2;
> #endif
>
> +#ifndef arch_faults_on_old_pte
> +static inline bool arch_faults_on_old_pte(void)
> +{
> + return false;
> +}
> +#endif
> +
> static int __init disable_randmaps(char *s)
> {
> randomize_va_space = 0;
> @@ -2140,8 +2147,12 @@ static inline int pte_unmap_same(struct mm_struct *mm, pmd_t *pmd,
> return same;
> }
>
> -static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
> +static inline void cow_user_page(struct page *dst, struct page *src,
> + struct vm_fault *vmf)
> {
> + struct vm_area_struct *vma = vmf->vma;
> + unsigned long addr = vmf->address;
> +
> debug_dma_assert_idle(src);
>
> /*
> @@ -2152,20 +2163,34 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
> */
> if (unlikely(!src)) {
> void *kaddr = kmap_atomic(dst);
> - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> + void __user *uaddr = (void __user *)(addr & PAGE_MASK);
> + pte_t entry;
>
> /*
> * This really shouldn't fail, because the page is there
> * in the page tables. But it might just be unreadable,
> * in which case we just give up and fill the result with
> - * zeroes.
> + * zeroes. On architectures with software "accessed" bits,
> + * we would take a double page fault here, so mark it
> + * accessed here.
> */
> + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
> + spin_lock(vmf->ptl);
> + if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> + entry = pte_mkyoung(vmf->orig_pte);
> + if (ptep_set_access_flags(vma, addr,
> + vmf->pte, entry, 0))
> + update_mmu_cache(vma, addr, vmf->pte);
> + }
I don't follow.
So if pte has changed under you, you don't set the accessed bit, but never
the less copy from the user.
What makes you think it will not trigger the same problem?
I think we need to make cow_user_page() fail in this case and caller --
wp_page_copy() -- return zero. If the fault was solved by other thread, we
are fine. If not userspace would re-fault on the same address and we will
handle the fault from the second attempt.
> + spin_unlock(vmf->ptl);
> + }
> +
> if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> clear_page(kaddr);
> kunmap_atomic(kaddr);
> flush_dcache_page(dst);
> } else
> - copy_user_highpage(dst, src, va, vma);
> + copy_user_highpage(dst, src, addr, vma);
> }
>
> static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
> @@ -2318,7 +2343,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
> vmf->address);
> if (!new_page)
> goto oom;
> - cow_user_page(new_page, old_page, vmf->address, vma);
> + cow_user_page(new_page, old_page, vmf);
> }
>
> if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL, &memcg, false))
> --
> 2.17.1
>
>
--
Kirill A. Shutemov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND 00/14] Next round of associating ddc adapters with connectors
From: Andrzej Pietrasiewicz @ 2019-09-18 14:01 UTC (permalink / raw)
To: dri-devel
Cc: Neil Armstrong, David Airlie, Matthias Brugger, Thierry Reding,
Laurent Pinchart, kernel, Anthony Koo, Emil Velikov,
linux-samsung-soc, Tomi Valkeinen, David Francis,
Krzysztof Kozlowski, Jonathan Hunter, linux-rockchip, Kukjin Kim,
Jonas Karlman, Leo Li, linux-arm-msm, intel-gfx, Jyri Sarha,
Mamta Shukla, linux-mediatek, Rodrigo Vivi, linux-tegra,
Thomas Gleixner, Bhawanpreet Lakha, linux-arm-kernel, Sean Paul,
Jernej Skrabec, amd-gfx, Shawn Guo, Seung-Woo Kim, linux-kernel,
Christian König, Todor Tomov, Kyungmin Park, Alex Deucher,
freedreno, Nicholas Kazlauskas
In-Reply-To: <cover.1566845537.git.andrzej.p@collabora.com>
Hi All,
A gentle ping.
Andrzej
W dniu 26.08.2019 o 21:25, Andrzej Pietrasiewicz pisze:
> I'm resending the patches which have somehow got lost: one patch
> from Geert and 13 patches from me.
>
> Geert's patch updates the error message to reflect the actually
> called function's name.
>
> Most of patches from me have their Acked-by and Reviewed-by tags
> and deal with providing a ddc symlink in connector's sysfs directory.
>
> Rebased onto drm-misc-next as of 26th August.
>
> Andrzej Pietrasiewicz (13):
> drm/radeon: Provide ddc symlink in connector sysfs directory
> drm/amdgpu: Provide ddc symlink in dm connector's sysfs directory
> drm/exynos: Provide ddc symlink in connector's sysfs
> drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory
> drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory
> drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory
> drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory
> drm/tegra: Provide ddc symlink in output connector sysfs directory
> drm/vc4: Provide ddc symlink in connector sysfs directory
> drm: zte: Provide ddc symlink in hdmi connector sysfs directory
> drm: zte: Provide ddc symlink in vga connector sysfs directory
> drm/tilcdc: Provide ddc symlink in connector sysfs directory
> drm/i915: Provide ddc symlink in hdmi connector sysfs directory
>
> Geert Uytterhoeven (1):
> drm/bridge: ti-tfp410: Update drm_connector_init_with_ddc() error
> message
>
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +-
> drivers/gpu/drm/bridge/ti-tfp410.c | 3 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +-
> drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 +-
> drivers/gpu/drm/radeon/radeon_connectors.c | 143 +++++++++++++-----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 +-
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 7 +-
> drivers/gpu/drm/tegra/hdmi.c | 7 +-
> drivers/gpu/drm/tegra/sor.c | 7 +-
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 6 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 12 +-
> drivers/gpu/drm/zte/zx_hdmi.c | 6 +-
> drivers/gpu/drm/zte/zx_vga.c | 6 +-
> 15 files changed, 168 insertions(+), 71 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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