Re: [PATCH v6 RESED 1/2] dma: replace zone_dma_bits by zone_dma_limit
Hi Robin,
On 29/08/2024 16:38, Robin Murphy wrote:
On 2024-08-29 2:42 pm, Neil Armstrong wrote:
Hi,
On 11/08/2024 09:09, Baruch Siach wrote:
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use plain address for DMA zone limit.
Since DMA zone can now potentially span beyond 4GB physical limit of
DMA32, make sure to use DMA zone for GFP_DMA32 allocations in that case.
Signed-off-by: Catalin Marinas
Co-developed-by: Baruch Siach
Signed-off-by: Baruch Siach
---
arch/arm64/mm/init.c | 30 +++---
arch/powerpc/mm/mem.c | 5 -
arch/s390/mm/init.c | 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c | 6 +++---
kernel/dma/pool.c | 4 ++--
kernel/dma/swiotlb.c | 6 +++---
7 files changed, 29 insertions(+), 26 deletions(-)
This change breaks the Qualcomm SM8550-HDK boot since next-20240826.
It doesn't affect SM8550-QRD or other similar SoCs like SM8650 or SM8450.
The last CI run on next-20240828 can be found at:
https://git.codelinaro.org/linaro/qcomlt/ci/staging/cdba-tester/-/pipelines/100936
SM8550-HDK boot log:
https://git.codelinaro.org/linaro/qcomlt/ci/staging/cdba-tester/-/jobs/165617
[...]
Yeah, a 35-bit ZONE_DMA is sure to make stuff go wrong:
[ 0.00] Zone ranges:
[ 0.00] DMA [mem 0x8000-0x000a]
[ 0.00] DMA32 empty
[ 0.00] Normal empty
Compared to before:
[ 0.00] DMA [mem 0x8000-0x]
[ 0.00] DMA32 empty
[ 0.00] Normal [mem 0x0001-0x000a]
This'll be because the SoC DT is describing a general non-restrictive range:
dma-ranges = <0 0 0 0 0x10 0>;
Which proves we need more information than {acpi,of}_dma_get_max_cpu_address()
are currently able to give us, because what zone_dma_limit actually wants to be
is the *minimum* of the lowest highest CPU address of any DMA range, and the
lowest CPU address of any DMA range + 2^32. I was thinking it had all ended up
looking a bit too easy... :)
I think v1 of the fix[1] might actually work out for this, albeit still for the
wrong reasons - if so, I concede that maybe at this point it might be safest to
go back to that one as a quick short-term fix (with a big fat comment to say
so) rather than try to rush the proper solution or revert everything.
Indeed v1 patches makes boot work again:
[0.00] Zone ranges:
[0.00] DMA [mem 0x8000-0x]
[0.00] DMA32empty
[0.00] Normal [mem 0x0001-0x000a]
Please add my:
Tested-by: Neil Armstrong # on SM8550-HDK
Thanks,
Neil
Thanks,
Robin.
[1]
https://lore.kernel.org/linux-arm-kernel/731d204f5f556ad61bbaf004b1d984f83c90b4f5.1724748249.git.bar...@tkos.co.il/
Re: [PATCH v6 RESED 1/2] dma: replace zone_dma_bits by zone_dma_limit
Hi, On 11/08/2024 09:09, Baruch Siach wrote: From: Catalin Marinas Hardware DMA limit might not be power of 2. When RAM range starts above 0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit can not encode this limit. Use plain address for DMA zone limit. Since DMA zone can now potentially span beyond 4GB physical limit of DMA32, make sure to use DMA zone for GFP_DMA32 allocations in that case. Signed-off-by: Catalin Marinas Co-developed-by: Baruch Siach Signed-off-by: Baruch Siach --- arch/arm64/mm/init.c | 30 +++--- arch/powerpc/mm/mem.c | 5 - arch/s390/mm/init.c| 2 +- include/linux/dma-direct.h | 2 +- kernel/dma/direct.c| 6 +++--- kernel/dma/pool.c | 4 ++-- kernel/dma/swiotlb.c | 6 +++--- 7 files changed, 29 insertions(+), 26 deletions(-) This change breaks the Qualcomm SM8550-HDK boot since next-20240826. It doesn't affect SM8550-QRD or other similar SoCs like SM8650 or SM8450. The last CI run on next-20240828 can be found at: https://git.codelinaro.org/linaro/qcomlt/ci/staging/cdba-tester/-/pipelines/100936 SM8550-HDK boot log: https://git.codelinaro.org/linaro/qcomlt/ci/staging/cdba-tester/-/jobs/165617 bisect log: # bad: [b18bbfc14a38b5234e09c2adcf713e38063a7e6e] Add linux-next specific files for 20240829 # good: [5be63fc19fcaa4c236b307420483578a56986a37] Linux 6.11-rc5 git bisect start 'FETCH_HEAD' 'v6.11-rc5' # bad: [dc09f0263a0accf41821d260f4bf7ad9a4f7b7d8] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git git bisect bad dc09f0263a0accf41821d260f4bf7ad9a4f7b7d8 # bad: [97c7e618752776e03f50311400bb73c01489fb17] Merge branch 'for-next' of git://github.com/Xilinx/linux-xlnx.git git bisect bad 97c7e618752776e03f50311400bb73c01489fb17 # good: [27ad8eb339a5e3f96aed5f3a3b5901994ce7856d] Merge branch 'clang-format' of https://github.com/ojeda/linux.git git bisect good 27ad8eb339a5e3f96aed5f3a3b5901994ce7856d # bad: [fd34d49f6d8dbd157b17b675dc51a145cdad580c] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git git bisect bad fd34d49f6d8dbd157b17b675dc51a145cdad580c # bad: [29f35e8cf8bff7c69a740edb1cf3d62d211f5a43] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git git bisect bad 29f35e8cf8bff7c69a740edb1cf3d62d211f5a43 # good: [41860d49473c0c09dc0a2a4d148047f97aaa2539] perf sched: Use perf_tool__init() git bisect good 41860d49473c0c09dc0a2a4d148047f97aaa2539 # good: [6236ebe07131a7746d870f1d8eb3637a8df13e70] perf daemon: Fix the build on more 32-bit architectures git bisect good 6236ebe07131a7746d870f1d8eb3637a8df13e70 # good: [92b0d033c80c882e6be26dfeeb2f24c53bd6] Merge branches 'for-next/acpi', 'for-next/misc', 'for-next/perf', 'for-next/selftests' and 'for-next/timers' into for-next/core git bisect good 92b0d033c80c882e6be26dfeeb2f24c53bd6 # bad: [5db893307df81f0c1dd6b6f167dc263e88ba855a] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux.git git bisect bad 5db893307df81f0c1dd6b6f167dc263e88ba855a # bad: [f65eaf209abc5f4761623aaa1e110bdb6de124ed] Merge branch 'for-next' of git://git.infradead.org/users/hch/dma-mapping.git git bisect bad f65eaf209abc5f4761623aaa1e110bdb6de124ed # bad: [f69e342eec008e1bab772d3963c3dd9979293e13] dma-mapping: call ->unmap_page and ->unmap_sg unconditionally git bisect bad f69e342eec008e1bab772d3963c3dd9979293e13 # bad: [ba0fb44aed47693cc2482427f63ba6cd19051327] dma-mapping: replace zone_dma_bits by zone_dma_limit git bisect bad ba0fb44aed47693cc2482427f63ba6cd19051327 # good: [fa3c109a6d302b56437a6412c5f3044c3e12de03] dma-mapping: use bit masking to check VM_DMA_COHERENT git bisect good fa3c109a6d302b56437a6412c5f3044c3e12de03 # first bad commit: [ba0fb44aed47693cc2482427f63ba6cd19051327] dma-mapping: replace zone_dma_bits by zone_dma_limit Boot log with earlycon: [0.00] Booting Linux on physical CPU 0x00 [0x411fd461] [0.00] Linux version 6.11.0-rc5-next-20240829-07694-gb36219e63903 (narmstr...@arrakeen.starnux.net) (aarch64-none-linux-gnu-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009, GNU ld (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 2.41.0.20231009) #397 SMP PREEMPT Thu Aug 29 15:25:39 CEST 2024 [0.00] KASLR enabled [0.00] random: crng init done [0.00] Machine model: Qualcomm Technologies, Inc. SM8550 HDK [0.00] printk: debug: ignoring loglevel setting. [0.00] efi: UEFI not found. [0.00] [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader! [0.00] OF: reserved mem: 0x8000..0x809f (10240 KiB) nomap non-reusable hyp-region@8000 [0.00] OF: reserved mem: 0x80a0..0x80df (4096 KiB) nomap non-reusable cpusys-vm-region@80a0 [0.00] OF: reserved mem: 0x80e0..0x000
Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
Le 30/03/2023 à 12:03, Arnd Bergmann a écrit : On Thu, Mar 30, 2023, at 09:48, Neil Armstrong wrote: On 27/03/2023 14:13, Arnd Bergmann wrote: From: Arnd Bergmann The cache management operations for noncoherent DMA on ARMv6 work in two different ways: * When CONFIG_DMA_CACHE_RWFO is set, speculative prefetches on in-flight DMA buffers lead to data corruption when the prefetched data is written back on top of data from the device. * When CONFIG_DMA_CACHE_RWFO is disabled, a cache flush on one CPU is not seen by the other core(s), leading to inconsistent contents accross the system. As a consequence, neither configuration is actually safe to use in a general-purpose kernel that is used on both MPCore systems and ARM1176 with prefetching enabled. We could add further workarounds to make the behavior more dynamic based on the system, but realistically, there are close to zero remaining users on any ARM11MPCore anyway, and nobody seems too interested in it, compared to the more popular ARM1176 used in BMC2835 and AST2500. The Oxnas platform has some minimal support in OpenWRT, but most of the drivers and dts files never made it into the mainline kernel, while the Arm Versatile/Realview platform mainly serves as a reference system but is not necessary to be kept working once all other ARM11MPCore are gone. Acked-by: Neil Armstrong It's sad but it's the reality, there's no chance full OXNAS support will ever come upstream and no real work has been done for years. I think OXNAS support can be programmed for removal for next release, it would need significant work to rework current support to make it acceptable before trying to upstream missing bits anyway. Ok, thanks for your reply! To clarify, do you think we should plan for removal after the next stable release (6.3, removed in 6.4), or after the next LTS release (probably 6.6, removed in 6.7)? As far as I understand, the next OpenWRT release (23.x) will be based on linux-5.15, and the one after that (24.x) would likely still use 6.1, unless they skip an LTS kernel. I think it's ok to remove it ASAP, or at least before the next LTS, not having SMP makes the platform barely usable so the earliest is the best. Neil Arnd
Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
On 27/03/2023 14:13, Arnd Bergmann wrote: From: Arnd Bergmann The cache management operations for noncoherent DMA on ARMv6 work in two different ways: * When CONFIG_DMA_CACHE_RWFO is set, speculative prefetches on in-flight DMA buffers lead to data corruption when the prefetched data is written back on top of data from the device. * When CONFIG_DMA_CACHE_RWFO is disabled, a cache flush on one CPU is not seen by the other core(s), leading to inconsistent contents accross the system. As a consequence, neither configuration is actually safe to use in a general-purpose kernel that is used on both MPCore systems and ARM1176 with prefetching enabled. We could add further workarounds to make the behavior more dynamic based on the system, but realistically, there are close to zero remaining users on any ARM11MPCore anyway, and nobody seems too interested in it, compared to the more popular ARM1176 used in BMC2835 and AST2500. The Oxnas platform has some minimal support in OpenWRT, but most of the drivers and dts files never made it into the mainline kernel, while the Arm Versatile/Realview platform mainly serves as a reference system but is not necessary to be kept working once all other ARM11MPCore are gone. Acked-by: Neil Armstrong It's sad but it's the reality, there's no chance full OXNAS support will ever come upstream and no real work has been done for years. I think OXNAS support can be programmed for removal for next release, it would need significant work to rework current support to make it acceptable before trying to upstream missing bits anyway. Thanks, Neil Take the easy way out here and drop support for multiprocessing on ARMv6, along with the CONFIG_DMA_CACHE_RWFO option and the cache management implementation for it. This also helps with other ARMv6 issues, but for the moment leaves the ability to build a kernel that can run on both ARMv7 SMP and single-processor ARMv6, which we probably want to stop supporting as well, but not as part of this series. Cc: Neil Armstrong Cc: Daniel Golle Cc: Linus Walleij Cc: linux-ox...@groups.io Signed-off-by: Arnd Bergmann --- I could use some help clarifying the above changelog text to describe the exact problem, and how the CONFIG_DMA_CACHE_RWFO actually works on MPCore. The TRMs for both 1176 and 11MPCore only describe prefetching into the instruction cache, not the data cache, but this can end up in the outercache as a result. The 1176 has some extra control bits to control prefetching, but I found no reference that explains why an MPCore does not run into the problem. --- arch/arm/mach-oxnas/Kconfig| 4 - arch/arm/mach-oxnas/Makefile | 1 - arch/arm/mach-oxnas/headsmp.S | 23 -- arch/arm/mach-oxnas/platsmp.c | 96 -- arch/arm/mach-versatile/platsmp-realview.c | 4 - arch/arm/mm/Kconfig| 19 - arch/arm/mm/cache-v6.S | 31 --- 7 files changed, 178 deletions(-) delete mode 100644 arch/arm/mach-oxnas/headsmp.S delete mode 100644 arch/arm/mach-oxnas/platsmp.c diff --git a/arch/arm/mach-oxnas/Kconfig b/arch/arm/mach-oxnas/Kconfig index a9ded7079268..a054235c3d6c 100644 --- a/arch/arm/mach-oxnas/Kconfig +++ b/arch/arm/mach-oxnas/Kconfig @@ -28,10 +28,6 @@ config MACH_OX820 bool "Support OX820 Based Products" depends on ARCH_MULTI_V6 select ARM_GIC - select DMA_CACHE_RWFO if SMP - select HAVE_SMP - select HAVE_ARM_SCU if SMP - select HAVE_ARM_TWD if SMP help Include Support for the Oxford Semiconductor OX820 SoC Based Products. diff --git a/arch/arm/mach-oxnas/Makefile b/arch/arm/mach-oxnas/Makefile index 0e78ecfe6c49..a4e40e534e6a 100644 --- a/arch/arm/mach-oxnas/Makefile +++ b/arch/arm/mach-oxnas/Makefile @@ -1,2 +1 @@ # SPDX-License-Identifier: GPL-2.0-only -obj-$(CONFIG_SMP) += platsmp.o headsmp.o diff --git a/arch/arm/mach-oxnas/headsmp.S b/arch/arm/mach-oxnas/headsmp.S deleted file mode 100644 index 9c0f1479f33a.. --- a/arch/arm/mach-oxnas/headsmp.S +++ /dev/null @@ -1,23 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* - * Copyright (C) 2013 Ma Haijun - * Copyright (c) 2003 ARM Limited - * All Rights Reserved - */ -#include -#include - - __INIT - -/* - * OX820 specific entry point for secondary CPUs. - */ -ENTRY(ox820_secondary_startup) - mov r4, #0 - /* invalidate both caches and branch target cache */ - mcr p15, 0, r4, c7, c7, 0 - /* -* we've been released from the holding pen: secondary_stack -* should now contain the SVC stack for this core -*/ - b secondary_startup diff --git a/arch/arm/mach-oxnas/platsmp.c b/arch/arm/mach-oxnas/platsmp.c deleted file mode 100644 index f0a50b9e61df.. --- a/arch/arm/mach-oxnas/platsmp.c +++ /dev/null @@ -1,96 +0,0 @@ -/
Re: [PATCH RESEND v5 15/18] PCI: dwc: Add dw_ prefix to the pcie_port structure name
struct uniphier_pcie *pcie = to_uniphier_pcie(pci);
unsigned long flags;
@@ -225,7 +225,7 @@ static const struct irq_domain_ops uniphier_intx_domain_ops
= {
static void uniphier_pcie_irq_handler(struct irq_desc *desc)
{
- struct pcie_port *pp = irq_desc_get_handler_data(desc);
+ struct dw_pcie_rp *pp = irq_desc_get_handler_data(desc);
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
struct uniphier_pcie *pcie = to_uniphier_pcie(pci);
struct irq_chip *chip = irq_desc_get_chip(desc);
@@ -258,7 +258,7 @@ static void uniphier_pcie_irq_handler(struct irq_desc *desc)
chained_irq_exit(chip, desc);
}
-static int uniphier_pcie_config_legacy_irq(struct pcie_port *pp)
+static int uniphier_pcie_config_legacy_irq(struct dw_pcie_rp *pp)
{
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
struct uniphier_pcie *pcie = to_uniphier_pcie(pci);
@@ -295,7 +295,7 @@ static int uniphier_pcie_config_legacy_irq(struct pcie_port
*pp)
return ret;
}
-static int uniphier_pcie_host_init(struct pcie_port *pp)
+static int uniphier_pcie_host_init(struct dw_pcie_rp *pp)
{
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
struct uniphier_pcie *pcie = to_uniphier_pcie(pci);
diff --git a/drivers/pci/controller/dwc/pcie-visconti.c
b/drivers/pci/controller/dwc/pcie-visconti.c
index 50f80f07e4db..71026fefa366 100644
--- a/drivers/pci/controller/dwc/pcie-visconti.c
+++ b/drivers/pci/controller/dwc/pcie-visconti.c
@@ -178,7 +178,7 @@ static void visconti_pcie_stop_link(struct dw_pcie *pci)
*/
static u64 visconti_pcie_cpu_addr_fixup(struct dw_pcie *pci, u64 cpu_addr)
{
- struct pcie_port *pp = &pci->pp;
+ struct dw_pcie_rp *pp = &pci->pp;
return cpu_addr & ~pp->io_base;
}
@@ -190,7 +190,7 @@ static const struct dw_pcie_ops dw_pcie_ops = {
.stop_link = visconti_pcie_stop_link,
};
-static int visconti_pcie_host_init(struct pcie_port *pp)
+static int visconti_pcie_host_init(struct dw_pcie_rp *pp)
{
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
struct visconti_pcie *pcie = dev_get_drvdata(pci->dev);
@@ -278,7 +278,7 @@ static int visconti_add_pcie_port(struct visconti_pcie
*pcie,
struct platform_device *pdev)
{
struct dw_pcie *pci = &pcie->pci;
- struct pcie_port *pp = &pci->pp;
+ struct dw_pcie_rp *pp = &pci->pp;
pp->irq = platform_get_irq_byname(pdev, "intr");
if (pp->irq < 0)
For pci-meson.c:
Reviewed-by: Neil Armstrong
Re: [PATCH v2 21/34] dt-bindings: arm: Convert Oxford Semi board/soc bindings to json-schema
On 03/12/2018 22:32, Rob Herring wrote: > Convert Oxford Semi SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland > Cc: Neil Armstrong > Cc: devicet...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-ox...@groups.io > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/oxnas.txt | 14 --- > .../devicetree/bindings/arm/oxnas.yaml| 25 +++ > 2 files changed, 25 insertions(+), 14 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/oxnas.txt > create mode 100644 Documentation/devicetree/bindings/arm/oxnas.yaml > > diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt > b/Documentation/devicetree/bindings/arm/oxnas.txt > deleted file mode 100644 > index ac64e60f99f1.. > --- a/Documentation/devicetree/bindings/arm/oxnas.txt > +++ /dev/null > @@ -1,14 +0,0 @@ > -Oxford Semiconductor OXNAS SoCs Family device tree bindings > > - > -Boards with the OX810SE SoC shall have the following properties: > - Required root node property: > -compatible: "oxsemi,ox810se" > - > -Boards with the OX820 SoC shall have the following properties: > - Required root node property: > -compatible: "oxsemi,ox820" > - > -Board compatible values: > - - "wd,mbwe" (OX810SE) > - - "cloudengines,pogoplugv3" (OX820) > diff --git a/Documentation/devicetree/bindings/arm/oxnas.yaml > b/Documentation/devicetree/bindings/arm/oxnas.yaml > new file mode 100644 > index ..6ae51ef513be > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/oxnas.yaml > @@ -0,0 +1,25 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/oxnas.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Oxford Semiconductor OXNAS SoCs Family device tree bindings > + > +maintainers: > + - Neil Armstrong > + > +properties: > + $nodename: > +const: '/' > + compatible: > +oneOf: > + - items: > +- enum: > +- wd,mbwe > +- const: oxsemi,ox810se > + > + - items: > +- enum: > +- cloudengines,pogoplugv3 > +- const: oxsemi,ox820 > We also loose all the "human friendly" description of board/SoC relationship here, and I think it's a shame. Neil
Re: [PATCH v2 14/34] dt-bindings: arm: Convert Amlogic board/soc bindings to json-schema
> - - "amlogic,p212" (Meson gxl s905x) > - - "hwacom,amazetv" (Meson gxl s905x) > - - "khadas,vim" (Meson gxl s905x) > - - "libretech,cc" (Meson gxl s905x) > - > - - "amlogic,p230" (Meson gxl s905d) > - - "amlogic,p231" (Meson gxl s905d) > - > - - "amlogic,p241" (Meson gxl s805x) > - > - - "amlogic,p281" (Meson gxl s905w) > - - "oranth,tx3-mini" (Meson gxl s905w) > - > - - "amlogic,q200" (Meson gxm s912) > - - "amlogic,q201" (Meson gxm s912) > - - "khadas,vim2" (Meson gxm s912) > - - "kingnovel,r-box-pro" (Meson gxm S912) > - - "nexbox,a1" (Meson gxm s912) > - - "tronsmart,vega-s96" (Meson gxm s912) > - > - - "amlogic,s400" (Meson axg a113d) > - > - - "amlogic,u200" (Meson g12a s905d2) > diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml > b/Documentation/devicetree/bindings/arm/amlogic.yaml > new file mode 100644 > index ..8b4b11194658 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml > @@ -0,0 +1,109 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/amlogic.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Amlogic MesonX device tree bindings > + > +maintainers: > + - Neil Armstrong The maintainer is Kevin Hilman. > + - Carlo Caione > +description: |+ > + Work in progress statement: > + > + Device tree files and bindings applying to Amlogic SoCs and boards are > + considered "unstable". Any Amlogic device tree binding may change at > + any time. Be sure to use a device tree binary and a kernel image > + generated from the same source tree. > + > + Please refer to Documentation/devicetree/bindings/ABI.txt for a definition > of a > + stable binding/ABI. > + > +properties: > + $nodename: > +const: '/' > + compatible: > +oneOf: > + - items: > + - enum: > + - geniatech,atv1200 > + - const: amlogic,meson6 > + - items: > + - enum: > + - minix,neo-x8 > + - const: amlogic,meson8 > + - items: > + - enum: > + - tronsmart,mxiii-plus > + - const: amlogic,meson8m2 > + - items: > + - enum: > + - endless,ec100 > + - hardkernel,odroid-c1 > + - tronfy,mxq > + - const: amlogic,meson8b > + - items: > + - enum: > + - amlogic,p200 > + - amlogic,p201 > + - friendlyarm,nanopi-k2 > + - hardkernel,odroid-c2 > + - nexbox,a95x > + - wetek,hub > + - wetek,play2 > + - const: amlogic,meson-gxbb > + - items: > + - enum: > + - tronsmart,vega-s95-pro > + - tronsmart,vega-s95-meta > + - tronsmart,vega-s95-telos > + - const: tronsmart,vega-s95 > + - const: amlogic,meson-gxbb > + - items: > + - enum: > + - amlogic,p241 > + - const: amlogic,s805x > + - const: amlogic,meson-gxl > + - items: > + - enum: > + - amlogic,p281 > + - oranth,tx3-mini > + - const: amlogic,s905w > + - const: amlogic,meson-gxl > + - items: > + - enum: > + - amlogic,p212 > + - hwacom,amazetv > + - khadas,vim > + - libretech,cc > + - nexbox,a95x > + - const: amlogic,s905x > + - const: amlogic,meson-gxl > + - items: > + - enum: > + - amlogic,p230 > + - amlogic,p231 > + - const: amlogic,s905d > + - const: amlogic,meson-gxl > + - items: > + - enum: > + - amlogic,q200 > + - amlogic,q201 > + - khadas,vim2 > + - kingnovel,r-box-pro > + - nexbox,a1 > + - tronsmart,vega-s96 > + - const: amlogic,s912 > + - const: amlogic,meson-gxm > + - items: > + - enum: > + - amlogic,s400 > + - const: amlogic,a113d > + - const: amlogic,meson-axg > + - items: > + - enum: > + - amlogic,u200 > + - const: amlogic,g12a but all this feels wrong for me. First of all, this yaml description is not human friendly and not intuitive at all, and secondly with this conversion we loose all the comments about the SoC family relationship with the compatible strings ! I really understand the point to have automated verification, but really it's a pain to read (I can't imagine newcomers... the actual DT bindings are already hard to read...) and I feel it will be a real pain to write ! Can't we mix an "humam text" with a "yaml" part on a same document ? we are in 2018 (nearly 2019), and it should be easy to extract a yaml description from a text document without pain and keep all the human description, no ? What will be the case for all the bindings with ASCII art to describe the architecture of the HW ? will you simply drop it to replace it with cold yaml description ? Neil > + > +... >
Re: [PATCH v2 13/34] dt-bindings: arm: amlogic: Move 'amlogic, meson-gx-ao-secure' binding to its own file
On 03/12/2018 22:32, Rob Herring wrote:
> It is best practice to have 1 binding per file, so board level bindings
> should be separate for various misc SoC bindings.
>
> Cc: Mark Rutland
> Cc: Carlo Caione
> Cc: Kevin Hilman
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Signed-off-by: Rob Herring
> ---
> .../devicetree/bindings/arm/amlogic.txt | 29 ---
> .../amlogic/amlogic,meson-gx-ao-secure.txt| 28 ++
> 2 files changed, 28 insertions(+), 29 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt
> b/Documentation/devicetree/bindings/arm/amlogic.txt
> index 4498292b833d..f5c8d50a3506 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -107,32 +107,3 @@ Board compatible values (alphabetically, grouped by SoC):
>- "amlogic,s400" (Meson axg a113d)
>
>- "amlogic,u200" (Meson g12a s905d2)
> -
> -Amlogic Meson Firmware registers Interface
> ---
> -
> -The Meson SoCs have a register bank with status and data shared with the
> -secure firmware.
> -
> -Required properties:
> - - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure",
> "syscon"
> -
> -Properties should indentify components of this register interface :
> -
> -Meson GX SoC Information
> -
> -A firmware register encodes the SoC type, package and revision information on
> -the Meson GX SoCs.
> -If present, the following property should be added :
> -
> -Optional properties:
> - - amlogic,has-chip-id: If present, the interface gives the current SoC
> version.
> -
> -Example
>
> -
> -ao-secure@140 {
> - compatible = "amlogic,meson-gx-ao-secure", "syscon";
> - reg = <0x0 0x140 0x0 0x140>;
> - amlogic,has-chip-id;
> -};
> diff --git
> a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
>
> b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
> new file mode 100644
> index ..c67d9f48fb91
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
> @@ -0,0 +1,28 @@
> +Amlogic Meson Firmware registers Interface
> +--
> +
> +The Meson SoCs have a register bank with status and data shared with the
> +secure firmware.
> +
> +Required properties:
> + - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure",
> "syscon"
> +
> +Properties should indentify components of this register interface :
> +
> +Meson GX SoC Information
> +
> +A firmware register encodes the SoC type, package and revision information on
> +the Meson GX SoCs.
> +If present, the following property should be added :
> +
> +Optional properties:
> + - amlogic,has-chip-id: If present, the interface gives the current SoC
> version.
> +
> +Example
> +---
> +
> +ao-secure@140 {
> + compatible = "amlogic,meson-gx-ao-secure", "syscon";
> + reg = <0x0 0x140 0x0 0x140>;
> + amlogic,has-chip-id;
> +};
>
Acked-by: Neil Armstrong
Re: [PATCH v2 7/7] net: stmmac: dwmac-meson8b: use xxxsetbits32
Hi Florian,
On 24/09/2018 21:17, Florian Fainelli wrote:
> On 09/24/2018 12:04 PM, Corentin Labbe wrote:
>> This patch convert meson stmmac glue driver to use all xxxsetbits32
>> functions.
>>
>> Signed-off-by: Corentin Labbe
>> ---
>> .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c| 56
>> +-
>> 1 file changed, 22 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> index c5979569fd60..abcf65588576 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> @@ -23,6 +23,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "stmmac_platform.h"
>>
>> @@ -75,18 +76,6 @@ struct meson8b_dwmac_clk_configs {
>> struct clk_gate rgmii_tx_en;
>> };
>>
>> -static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
>> -u32 mask, u32 value)
>> -{
>> -u32 data;
>> -
>> -data = readl(dwmac->regs + reg);
>> -data &= ~mask;
>> -data |= (value & mask);
>> -
>> -writel(data, dwmac->regs + reg);
>> -}
>
> Why not make mseon8b_dwmac_mask_bits() a wrapper around
> clrsetbits_le32() whose purpose is only to dereference dwmac->regs and
> pass it to clrsetbits_le32()? That would be far less changes to review
> and audit for correctness, same goes with every other patch in this
> series touching the meson drivers.
>
Personally, I'll prefer dropping my custom writel_bits_relaxed() with something
more future proof (I also use it in spi-meson-spicc and ao-cec),
and I think the same for dwmac-meson8b.c
Neil
Re: [PATCH v2 7/7] net: stmmac: dwmac-meson8b: use xxxsetbits32
On 24/09/2018 21:04, Corentin Labbe wrote: > This patch convert meson stmmac glue driver to use all xxxsetbits32 functions. > > Signed-off-by: Corentin Labbe > --- > .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c| 56 > +- > 1 file changed, 22 insertions(+), 34 deletions(-) > [...] Reviewed-by: Neil Armstrong
Re: [PATCH v2 6/7] drm: meson: use xxxsetbits32
Hi Corentin, On 24/09/2018 21:04, Corentin Labbe wrote: > This patch convert meson DRM driver to use all xxxsetbits32 functions. > > Signed-off-by: Corentin Labbe > --- > drivers/gpu/drm/meson/meson_crtc.c | 14 --- > drivers/gpu/drm/meson/meson_dw_hdmi.c | 33 + > drivers/gpu/drm/meson/meson_plane.c | 13 --- > drivers/gpu/drm/meson/meson_registers.h | 3 -- > drivers/gpu/drm/meson/meson_venc.c | 13 --- > drivers/gpu/drm/meson/meson_venc_cvbs.c | 4 +- > drivers/gpu/drm/meson/meson_viu.c | 65 > + > drivers/gpu/drm/meson/meson_vpp.c | 22 +-- > 8 files changed, 86 insertions(+), 81 deletions(-) > [...] Reviewed-by: Neil Armstrong Tested-by: Neil Armstrong
Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem
x60_wdt.c | 6 ++-- > drivers/watchdog/ni903x_wdt.c | 11 +--- > drivers/watchdog/nic7018_wdt.c | 11 +--- > drivers/watchdog/nuc900_wdt.c | 7 ++--- > drivers/watchdog/nv_tco.c | 6 +--- > drivers/watchdog/nv_tco.h | 10 +-- > drivers/watchdog/octeon-wdt-main.c | 11 +--- > drivers/watchdog/octeon-wdt-nmi.S | 5 +--- > drivers/watchdog/of_xilinx_wdt.c | 8 ++ > drivers/watchdog/omap_wdt.c| 1 + > drivers/watchdog/omap_wdt.h| 21 +- > drivers/watchdog/orion_wdt.c | 5 +--- > drivers/watchdog/pc87413_wdt.c | 10 +-- > drivers/watchdog/pcwd.c| 1 + > drivers/watchdog/pcwd_pci.c| 10 +-- > drivers/watchdog/pcwd_usb.c| 10 +-- > drivers/watchdog/pic32-dmt.c | 5 +--- > drivers/watchdog/pic32-wdt.c | 6 +--- > drivers/watchdog/pika_wdt.c| 1 + > drivers/watchdog/pnx4008_wdt.c | 7 ++--- > drivers/watchdog/pnx833x_wdt.c | 6 +--- > drivers/watchdog/pretimeout_noop.c | 7 + > drivers/watchdog/pretimeout_panic.c| 7 + > drivers/watchdog/qcom-wdt.c| 14 ++ > drivers/watchdog/renesas_wdt.c | 4 +-- > drivers/watchdog/retu_wdt.c| 10 +-- > drivers/watchdog/riowd.c | 1 + > drivers/watchdog/rn5t618_wdt.c | 8 +- > drivers/watchdog/rt2880_wdt.c | 5 +--- > drivers/watchdog/rtd119x_wdt.c | 2 +- > drivers/watchdog/rza_wdt.c | 5 +--- > drivers/watchdog/s3c2410_wdt.c | 11 +--- > drivers/watchdog/sa1100_wdt.c | 11 +--- > drivers/watchdog/sama5d4_wdt.c | 3 +- > drivers/watchdog/sb_wdog.c | 5 +--- > drivers/watchdog/sbc60xxwdt.c | 10 +-- > drivers/watchdog/sbc7240_wdt.c | 12 ++-- > drivers/watchdog/sbc8360.c | 10 +-- > drivers/watchdog/sbc_epx_c3.c | 6 +--- > drivers/watchdog/sbc_fitpc2_wdt.c | 7 ++--- > drivers/watchdog/sbsa_gwdt.c | 10 +-- > drivers/watchdog/sc1200wdt.c | 10 +-- > drivers/watchdog/sc520_wdt.c | 10 +-- > drivers/watchdog/sch311x_wdt.c | 10 +-- > drivers/watchdog/scx200_wdt.c | 10 ++- > drivers/watchdog/shwdt.c | 6 +--- > drivers/watchdog/sirfsoc_wdt.c | 5 ++-- > drivers/watchdog/smsc37b787_wdt.c | 10 +-- > drivers/watchdog/softdog.c | 10 +-- > drivers/watchdog/sp5100_tco.c | 6 +--- > drivers/watchdog/sp805_wdt.c | 5 +--- > drivers/watchdog/sprd_wdt.c| 10 +-- > drivers/watchdog/st_lpc_wdt.c | 6 +--- > drivers/watchdog/stmp3xxx_rtc_wdt.c| 5 +--- > drivers/watchdog/sun4v_wdt.c | 6 +--- > drivers/watchdog/sunxi_wdt.c | 6 +--- > drivers/watchdog/tangox_wdt.c | 6 +--- > drivers/watchdog/tegra_wdt.c | 10 +-- > drivers/watchdog/ts4800_wdt.c | 5 +--- > drivers/watchdog/ts72xx_wdt.c | 7 ++--- > drivers/watchdog/twl4030_wdt.c | 15 +- > drivers/watchdog/txx9wdt.c | 9 ++ > drivers/watchdog/uniphier_wdt.c| 10 +-- > drivers/watchdog/ux500_wdt.c | 5 ++-- > drivers/watchdog/via_wdt.c | 4 +-- > drivers/watchdog/w83627hf_wdt.c| 10 +-- > drivers/watchdog/w83877f_wdt.c | 10 +-- > drivers/watchdog/w83977f_wdt.c | 9 +- > drivers/watchdog/wafer5823wdt.c| 11 +--- > drivers/watchdog/watchdog_core.c | 10 +-- > drivers/watchdog/watchdog_core.h | 10 +-- > drivers/watchdog/watchdog_dev.c| 10 +-- > drivers/watchdog/watchdog_pretimeout.c | 6 +--- > drivers/watchdog/wd501p.h | 1 + > drivers/watchdog/wdat_wdt.c| 5 +--- > drivers/watchdog/wdrtas.c | 15 +- > drivers/watchdog/wdt.c | 11 +--- > drivers/watchdog/wdt285.c | 7 + > drivers/watchdog/wdt977.c | 8 +- > drivers/watchdog/wdt_pci.c | 11 +--- > drivers/watchdog/wm831x_wdt.c | 5 +--- > drivers/watchdog/wm8350_wdt.c | 5 +--- > drivers/watchdog/xen_wdt.c | 6 +--- > drivers/watchdog/ziirave_wdt.c | 11 +--- > drivers/watchdog/zx2967_wdt.c | 3 +- > 162 files changed, 195 insertions(+), 1051 deletions(-) > [...] > diff --git a/drivers/watchdog/meson_gxbb_wdt.c > b/drivers/watchdog/meson_gxbb_wdt.c > index 69a5a57f1446..69adeab3fde7 100644 > --- a/d
Re: [PATCH] watchdog: add SPDX identifiers for watchdog subsystem
Hi Marcus, On 20/02/2018 10:59, Marcus Folkesson wrote: > On Tue, Feb 20, 2018 at 10:47:03AM +0100, Neil Armstrong wrote: >> Hi Marcus, >> >> On 20/02/2018 10:31, Marcus Folkesson wrote: >>> - Add SPDX identifier >>> - Remove boiler plate license text >>> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate >>> license >>> >>> Signed-off-by: Marcus Folkesson >>> --- >>> >>> Notes: >>> v1: Please have an extra look at meson_gxbb_wdt.c >>> >>> drivers/watchdog/acquirewdt.c | 6 +--- >>> drivers/watchdog/advantechwdt.c| 6 +--- >>> drivers/watchdog/alim1535_wdt.c| 6 +--- >>> drivers/watchdog/alim7101_wdt.c| 1 + >>> drivers/watchdog/ar7_wdt.c | 14 + >>> drivers/watchdog/asm9260_wdt.c | 2 +- >>> drivers/watchdog/aspeed_wdt.c | 5 +--- >>> drivers/watchdog/at91rm9200_wdt.c | 5 +--- >>> drivers/watchdog/at91sam9_wdt.c| 5 +--- >>> drivers/watchdog/at91sam9_wdt.h| 5 +--- >>> drivers/watchdog/ath79_wdt.c | 4 +-- >>> drivers/watchdog/atlas7_wdt.c | 2 +- >>> drivers/watchdog/bcm2835_wdt.c | 5 +--- >>> drivers/watchdog/bcm47xx_wdt.c | 5 +--- >>> drivers/watchdog/bcm63xx_wdt.c | 5 +--- >>> drivers/watchdog/bcm7038_wdt.c | 12 ++-- >>> drivers/watchdog/bcm_kona_wdt.c| 9 +- >>> drivers/watchdog/bfin_wdt.c| 2 +- >>> drivers/watchdog/booke_wdt.c | 5 +--- >>> drivers/watchdog/cadence_wdt.c | 5 +--- >>> drivers/watchdog/coh901327_wdt.c | 7 ++--- >>> drivers/watchdog/cpu5wdt.c | 15 +- >>> drivers/watchdog/cpwd.c| 1 + >>> drivers/watchdog/da9052_wdt.c | 6 +--- >>> drivers/watchdog/da9055_wdt.c | 6 +--- >>> drivers/watchdog/da9062_wdt.c | 10 +-- >>> drivers/watchdog/da9063_wdt.c | 5 +--- >>> drivers/watchdog/davinci_wdt.c | 7 ++--- >>> drivers/watchdog/diag288_wdt.c | 1 + >>> drivers/watchdog/digicolor_wdt.c | 5 +--- >>> drivers/watchdog/dw_wdt.c | 6 +--- >>> drivers/watchdog/ebc-c384_wdt.c| 9 +- >>> drivers/watchdog/ep93xx_wdt.c | 7 ++--- >>> drivers/watchdog/eurotechwdt.c | 6 +--- >>> drivers/watchdog/f71808e_wdt.c | 16 +- >>> drivers/watchdog/ftwdt010_wdt.c| 6 ++-- >>> drivers/watchdog/gef_wdt.c | 6 +--- >>> drivers/watchdog/geodewdt.c| 5 +--- >>> drivers/watchdog/gpio_wdt.c| 5 +--- >>> drivers/watchdog/hpwdt.c | 7 ++--- >>> drivers/watchdog/i6300esb.c| 6 +--- >>> drivers/watchdog/iTCO_vendor_support.c | 9 +- >>> drivers/watchdog/iTCO_wdt.c| 10 +-- >>> drivers/watchdog/ib700wdt.c| 6 +--- >>> drivers/watchdog/ibmasr.c | 3 +- >>> drivers/watchdog/ie6xx_wdt.c | 18 ++- >>> drivers/watchdog/imgpdc_wdt.c | 5 +--- >>> drivers/watchdog/imx2_wdt.c| 5 +--- >>> drivers/watchdog/indydog.c | 6 +--- >>> drivers/watchdog/intel-mid_wdt.c | 6 ++-- >>> drivers/watchdog/intel_scu_watchdog.c | 18 ++- >>> drivers/watchdog/intel_scu_watchdog.h | 16 +- >>> drivers/watchdog/iop_wdt.c | 16 ++ >>> drivers/watchdog/it8712f_wdt.c | 10 +-- >>> drivers/watchdog/it87_wdt.c| 10 +-- >>> drivers/watchdog/ixp4xx_wdt.c | 6 ++-- >>> drivers/watchdog/jz4740_wdt.c | 10 +-- >>> drivers/watchdog/kempld_wdt.c | 12 ++-- >>> drivers/watchdog/ks8695_wdt.c | 6 ++-- >>> drivers/watchdog/lantiq_wdt.c | 7 ++--- >>> drivers/watchdog/loongson1_wdt.c | 5 +--- >>> drivers/watchdog/lpc18xx_wdt.c | 5 +--- >>> drivers/watchdog/m54xx_wdt.c | 6 ++-- >>> drivers/watchdog/machzwd.c | 11 +-- >>> drivers/watchdog/max63xx_wdt.c | 5 +--- >>> drivers/watchdog/max77620_wdt.c| 5 +--- >>> drivers/watchdog/mei_wdt.c | 12 ++-- >>> drivers/watchdog/mena21_wdt.c | 4 +-- >>> drivers/watchdog/menf21bmc_wdt.c
Re: [PATCH] watchdog: add SPDX identifiers for watchdog subsystem
s/watchdog/nv_tco.h | 10 +-- > drivers/watchdog/octeon-wdt-main.c | 11 +-- > drivers/watchdog/octeon-wdt-nmi.S | 5 +--- > drivers/watchdog/of_xilinx_wdt.c | 8 ++--- > drivers/watchdog/omap_wdt.c| 1 + > drivers/watchdog/omap_wdt.h| 21 + > drivers/watchdog/orion_wdt.c | 5 +--- > drivers/watchdog/pc87413_wdt.c | 10 +-- > drivers/watchdog/pcwd.c| 1 + > drivers/watchdog/pcwd_pci.c| 10 +-- > drivers/watchdog/pcwd_usb.c| 10 +-- > drivers/watchdog/pic32-dmt.c | 5 +--- > drivers/watchdog/pic32-wdt.c | 6 +--- > drivers/watchdog/pika_wdt.c| 1 + > drivers/watchdog/pnx4008_wdt.c | 7 ++--- > drivers/watchdog/pnx833x_wdt.c | 6 +--- > drivers/watchdog/pretimeout_noop.c | 7 + > drivers/watchdog/pretimeout_panic.c| 7 + > drivers/watchdog/qcom-wdt.c| 14 ++--- > drivers/watchdog/renesas_wdt.c | 4 +-- > drivers/watchdog/retu_wdt.c| 10 +-- > drivers/watchdog/riowd.c | 1 + > drivers/watchdog/rn5t618_wdt.c | 8 + > drivers/watchdog/rt2880_wdt.c | 5 +--- > drivers/watchdog/rtd119x_wdt.c | 2 +- > drivers/watchdog/rza_wdt.c | 5 +--- > drivers/watchdog/s3c2410_wdt.c | 11 +-- > drivers/watchdog/sa1100_wdt.c | 11 +-- > drivers/watchdog/sama5d4_wdt.c | 3 +- > drivers/watchdog/sb_wdog.c | 5 +--- > drivers/watchdog/sbc60xxwdt.c | 10 +-- > drivers/watchdog/sbc7240_wdt.c | 12 ++-- > drivers/watchdog/sbc8360.c | 10 +-- > drivers/watchdog/sbc_epx_c3.c | 6 +--- > drivers/watchdog/sbc_fitpc2_wdt.c | 7 ++--- > drivers/watchdog/sbsa_gwdt.c | 10 +-- > drivers/watchdog/sc1200wdt.c | 10 +-- > drivers/watchdog/sc520_wdt.c | 10 +-- > drivers/watchdog/sch311x_wdt.c | 10 +-- > drivers/watchdog/scx200_wdt.c | 10 ++- > drivers/watchdog/shwdt.c | 6 +--- > drivers/watchdog/sirfsoc_wdt.c | 5 ++-- > drivers/watchdog/smsc37b787_wdt.c | 10 +-- > drivers/watchdog/softdog.c | 10 +-- > drivers/watchdog/sp5100_tco.c | 6 +--- > drivers/watchdog/sp805_wdt.c | 5 +--- > drivers/watchdog/sprd_wdt.c| 10 +-- > drivers/watchdog/st_lpc_wdt.c | 6 +--- > drivers/watchdog/stmp3xxx_rtc_wdt.c| 5 +--- > drivers/watchdog/sun4v_wdt.c | 6 +--- > drivers/watchdog/sunxi_wdt.c | 6 +--- > drivers/watchdog/tangox_wdt.c | 6 +--- > drivers/watchdog/tegra_wdt.c | 10 +-- > drivers/watchdog/ts4800_wdt.c | 5 +--- > drivers/watchdog/ts72xx_wdt.c | 7 ++--- > drivers/watchdog/twl4030_wdt.c | 15 +- > drivers/watchdog/txx9wdt.c | 9 ++ > drivers/watchdog/uniphier_wdt.c| 10 +-- > drivers/watchdog/ux500_wdt.c | 5 ++-- > drivers/watchdog/via_wdt.c | 4 +-- > drivers/watchdog/w83627hf_wdt.c| 10 +-- > drivers/watchdog/w83877f_wdt.c | 10 +-- > drivers/watchdog/w83977f_wdt.c | 9 +- > drivers/watchdog/wafer5823wdt.c| 11 +-- > drivers/watchdog/watchdog_core.c | 10 +-- > drivers/watchdog/watchdog_core.h | 10 +-- > drivers/watchdog/watchdog_dev.c| 10 +-- > drivers/watchdog/watchdog_pretimeout.c | 6 +--- > drivers/watchdog/wd501p.h | 1 + > drivers/watchdog/wdat_wdt.c| 5 +--- > drivers/watchdog/wdrtas.c | 15 +- > drivers/watchdog/wdt.c | 11 +-- > drivers/watchdog/wdt285.c | 7 + > drivers/watchdog/wdt977.c | 8 + > drivers/watchdog/wdt_pci.c | 11 +-- > drivers/watchdog/wm831x_wdt.c | 5 +--- > drivers/watchdog/wm8350_wdt.c | 5 +--- > drivers/watchdog/xen_wdt.c | 6 +--- > drivers/watchdog/ziirave_wdt.c | 11 +-- > drivers/watchdog/zx2967_wdt.c | 3 +- > 162 files changed, 195 insertions(+), 1059 deletions(-) > [..] > diff --git a/drivers/watchdog/meson_gxbb_wdt.c > b/drivers/watchdog/meson_gxbb_wdt.c > index 69a5a57f1446..500463c3e040 100644 > --- a/drivers/watchdog/meson_gxbb_wdt.c > +++ b/drivers/watchdog/meson_gxbb_wdt.c > @@ -1,57 +1,4 @@ > -/* > - * This file is provided under a dual BSD/GPLv2 license. When using or > - * redistributing this file, you may do so under either license. > - * > - * GPL LIC
Re: [PATCH] mtd: nand: Rename nand.h into rawnand.h
On 08/04/2017 05:29 PM, Boris Brezillon wrote: > We are planning to share more code between different NAND based > devices (SPI NAND, OneNAND and raw NANDs), but before doing that > we need to move the existing include/linux/mtd/nand.h file into > include/linux/mtd/rawnand.h so we can later create a nand.h header > containing all common structure and function prototypes. > > Signed-off-by: Boris Brezillon > Signed-off-by: Peter Pan > Cc: Jonathan Corbet > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Sebastian Hesselbarth > Cc: Gregory Clement > Cc: Hartley Sweeten > Cc: Alexander Sverdlin > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Fabio Estevam > Cc: Imre Kaloz > Cc: Krzysztof Halasa > Cc: Eric Miao > Cc: Haojian Zhuang > Cc: Aaro Koskinen > Cc: Tony Lindgren > Cc: Alexander Clouter > Cc: Daniel Mack > Cc: Robert Jarzmik > Cc: Marek Vasut > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: Simtec Linux Team > Cc: Steven Miao > Cc: Mikael Starvik > Cc: Jesper Nilsson > Cc: Ralf Baechle > Cc: Yoshinori Sato > Cc: Rich Felker > Cc: Wenyou Yang > Cc: Josh Wu > Cc: Kamal Dasu > Cc: Masahiro Yamada > Cc: Han Xu > Cc: Harvey Hunt > Cc: Vladimir Zapolskiy > Cc: Sylvain Lemieux > Cc: Matthias Brugger > Cc: Wan ZongShun > Cc: Neil Armstrong > Cc: Ezequiel Garcia > Cc: Maxim Levitsky > Cc: Marc Gonzalez > Cc: Stefan Agner > Cc: Greg Kroah-Hartman > Cc: Mauro Carvalho Chehab > Cc: linux-...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-o...@vger.kernel.org > Cc: linux-samsung-...@vger.kernel.org > Cc: adi-buildroot-de...@lists.sourceforge.net > Cc: linux-cris-ker...@axis.com > Cc: linux-m...@linux-mips.org > Cc: linux...@vger.kernel.org > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: linux-media...@lists.infradead.org > Cc: linux-ox...@lists.tuxfamily.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: de...@driverdev.osuosl.org > --- > Hi All, > > Sorry for the huge Cc list, but I'd like to collect as much acks as > possible for this patch which is actually part of a bigger series [1]. > > Note that there's nothing complicated here, it's just a mechanical > s/nand\.h/rawnand\.h/ replacement, but it impacts several architectures, > the doc and staging directories. > > Regards, > > Boris > > [1]https://lwn.net/Articles/723694/ > --- > Documentation/driver-api/mtdnand.rst| 8 > MAINTAINERS | 2 +- > arch/arm/mach-davinci/board-da850-evm.c | 2 +- > arch/arm/mach-davinci/board-dm355-evm.c | 2 +- > arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- > arch/arm/mach-davinci/board-dm365-evm.c | 2 +- > arch/arm/mach-davinci/board-dm644x-evm.c| 2 +- > arch/arm/mach-davinci/board-dm646x-evm.c| 2 +- > arch/arm/mach-davinci/board-sffsdr.c| 2 +- > arch/arm/mach-dove/dove-db-setup.c | 2 +- > arch/arm/mach-ep93xx/snappercl15.c | 2 +- > arch/arm/mach-ep93xx/ts72xx.c | 2 +- > arch/arm/mach-imx/mach-qong.c | 2 +- > arch/arm/mach-ixp4xx/ixdp425-setup.c| 2 +- > arch/arm/mach-mmp/aspenite.c| 2 +- > arch/arm/mach-omap1/board-fsample.c | 2 +- > arch/arm/mach-omap1/board-h2.c | 2 +- > arch/arm/mach-omap1/board-h3.c | 2 +- > arch/arm/mach-omap1/board-nand.c| 2 +- > arch/arm/mach-omap1/board-perseus2.c| 2 +- > arch/arm/mach-orion5x/db88f5281-setup.c | 2 +- > arch/arm/mach-orion5x/kurobox_pro-setup.c | 2 +- > arch/arm/mach-orion5x/ts209-setup.c | 2 +- > arch/arm/mach-orion5x/ts78xx-setup.c| 2 +- > arch/arm/mach-pxa/balloon3.c| 2 +- > arch/arm/mach-pxa/em-x270.c | 2 +- > arch/arm/mach-pxa/eseries.c | 2 +- > arch/arm/mach-pxa/palmtx.c | 2 +- > arch/arm/mach-pxa/tosa.c| 2 +- > arch/arm/mach-s3c24xx/common-smdk.c | 2 +- > arch/arm/mach-s3c24xx/mach-anubis.c | 2 +- > arch/arm/mach-s3c24xx/mach-at2440evb.c | 2 +- > arch/arm/mach-s3c24xx/mach-bast.c | 2 +- > arch/arm/mach-s3c24xx/mach-gta02.c | 2 +- > arch/arm/mach-s3c24xx/mach-jive.c | 2 +- > arch/arm/mach-s3c24xx/mach-mini2440.c | 2 +- > arch/arm/mach-s3c24xx/mach-osiris.c | 2 +- > arch/arm/mach-s3c24xx/mach-qt2410.c | 2 +- > arch/arm/mach-s3c24xx/mach-r
