Re: [PATCH 08/11] irqchip/gic: Configure SGIs as standard interrupts

[dann frazier]

On Tue, Apr 20, 2021 at 02:37:10PM -0600, dann frazier wrote:
> On Tue, May 19, 2020 at 05:17:52PM +0100, Marc Zyngier wrote:
> > Change the way we deal with GIC SGIs by turning them into proper
> > IRQs, and calling into the arch code to register the interrupt range
> > instead of a callback.
> > 
> > Signed-off-by: Marc Zyngier 
> 
> hey Marc,
> 
>   I bisected a boot failure on our Gigabyte R120-T33 systems (ThunderX
> CN88XX) down to this commit, but only when running in ACPI mode. See below:
> 
> 
> EFI stub: Booting Linux Kernel...
> EFI stub: EFI_RNG_PROTOCOL unavailable, KASLR will be disabled
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> [0.00] Booting Linux on physical CPU 0x00 [0x431f0a11]
> [0.00] Linux version 5.11.0-13-generic (buildd@bos02-arm64-067) (gcc 
> (Ubuntu 10.2.1-23ubuntu1) 10.2.1 20210312, GNU ld (GNU Binutils for Ubuntu) 
> 2.36.1) #14-Ubuntu SMP Fri Mar 19 16:57:35 UTC 2021 (Ubuntu 
> 5.11.0-13.14-generic 5.11.7)

Sorry, realized I posted a log from an Ubuntu kernel. Here's an
upstream one:

EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[0.00] Booting Linux on physical CPU 0x00 [0x431f0a11]
[0.00] Linux version 5.12.0-rc8 (ubuntu@seidel) (gcc (Ubuntu 
10.3.0-1ubuntu1) 10.3.0, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #19 SMP Tue 
Apr 20 21:09:04 UTC 2021
[0.00] Machine model: Cavium ThunderX CN88XX board
[0.00] efi: EFI v2.40 by American Megatrends
[0.00] efi: ESRT=0xffce0ff18 SMBIOS 3.0=0xfffb ACPI 2.0=0xffec6 
MEMRESERVE=0xffc889d98 
[0.00] esrt: Reserving ESRT space from 0x000ffce0ff18 to 
0x000ffce0ff50.
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000FFEC6 24 (v02 ALASKA)
[0.00] ACPI: XSDT 0x000FFEC60028 8C (v01 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: FACP 0x000FFEC600B8 000114 (v06 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: DSDT 0x000FFEC601D0 00220B (v02 CAVIUM THUNDERX 
0001 INTL 20130517)
[0.00] ACPI: SPMI 0x000FFEC623E0 41 (v05 ALASKA A M I
 AMI. )
[0.00] ACPI: FIDT 0x000FFEC62428 9C (v01 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: APIC 0x000FFEC624C8 000F68 (v03 CAVIUM THUNDERX 
0001 INTL 20150619)
[0.00] ACPI: DBG2 0x000FFEC63430 67 (v01 CAVIUM CN88XDBG 
 INTL 20150619)
[0.00] ACPI: GTDT 0x000FFEC63498 E0 (v02 CAVIUM THUNDERX 
0001 INTL 20150619)
[0.00] ACPI: IORT 0x000FFEC63578 0013D4 (v01 CAVIUM THUNDERX 
0001 INTL 20150619)
[0.00] ACPI: MCFG 0x000FFEC64950 6C (v01 CAVIUM THUNDERX 
0001 INTL 20150619)
[0.00] ACPI: SSDT 0x000FFEC649C0 00089C (v02 CAVIUM NETWORK  
0001 INTL 20150619)
[0.00] ACPI: OEM1 0x000FFEC65260 0001E8 (v02 CAVIUM THUNDERX 
0001 INTL 20150619)
[0.00] ACPI: SLIT 0x000FFEC65448 30 (v01 CAVIUM TEMPLATE 
0001 INTL 20150619)
[0.00] ACPI: SPCR 0x000FFEC65478 50 (v02 A M I  APTIO V  
01072009 AMI. 0005000B)
[0.00] ACPI: BGRT 0x000FFEC654C8 38 (v01 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: SPCR: console: pl011,mmio32,0x87e02400,115200
[0.00] efi_bgrt: Ignoring BGRT: Incorrect BMP magic number 0x3707 
(expected 0x4d42)
[0.00] NUMA: Failed to initialise from firmware
[0.00] NUMA: Faking a node at [mem 
0x0050-0x000fff0f]
[0.00] NUMA: NODE_DATA [mem 0xff677c480-0xff6780fff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x0050-0x]
[0.00]   DMA32empty
[0.00]   Normal   [mem 0x0001-0x000fff0f]
[0.00]   Device   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0050-0x00df]
[0.00]   node   0: [mem 0x00e0-0x0fff]
[0.00]   node   0: [mem 0x1000-0x102f]
[0.00]   node   0: [mem 0x1030-0xfff9]
[0.00]   node   0: [mem 0xfffa-0x]
[0.00]   node   0: [mem 0x0001-0x000fee6a]
[0.00]   node   0: [mem 0x000fee6b-0x000fee6c]
[0.00]   node   0: [mem 0x000fee6d-0x000ffac2]
[0.00]   node   0: [mem 0x000ffac3-0x000ffb0a]
[0.00]   node   0: [mem 0x000ffb0b-0x000ffc8b]
[0.00]   node   0: [mem 0x00

Re: [PATCH 08/11] irqchip/gic: Configure SGIs as standard interrupts

[dann frazier]

On Tue, May 19, 2020 at 05:17:52PM +0100, Marc Zyngier wrote:
> Change the way we deal with GIC SGIs by turning them into proper
> IRQs, and calling into the arch code to register the interrupt range
> instead of a callback.
> 
> Signed-off-by: Marc Zyngier 

hey Marc,

  I bisected a boot failure on our Gigabyte R120-T33 systems (ThunderX
CN88XX) down to this commit, but only when running in ACPI mode. See below:


EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, KASLR will be disabled
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[0.00] Booting Linux on physical CPU 0x00 [0x431f0a11]
[0.00] Linux version 5.11.0-13-generic (buildd@bos02-arm64-067) (gcc 
(Ubuntu 10.2.1-23ubuntu1) 10.2.1 20210312, GNU ld (GNU Binutils for Ubuntu) 
2.36.1) #14-Ubuntu SMP Fri Mar 19 16:57:35 UTC 2021 (Ubuntu 
5.11.0-13.14-generic 5.11.7)
[0.00] Machine model: Cavium ThunderX CN88XX board
[0.00] efi: EFI v2.40 by American Megatrends
[0.00] efi: ESRT=0xffce0ff18 SMBIOS 3.0=0xfffb ACPI 2.0=0xffc87 
MEMRESERVE=0xffa9b8e98 
[0.00] secureboot: Secure boot disabled
[0.00] esrt: Reserving ESRT space from 0x000ffce0ff18 to 
0x000ffce0ff50.
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000FFC87 24 (v02 ALASKA)
[0.00] ACPI: XSDT 0x000FFC870028 8C (v01 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: FACP 0x000FFC8700B8 000114 (v06 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: DSDT 0x000FFC8701D0 00220B (v02 CAVIUM THUNDERX 
0001 INTL 20130517)
[0.00] ACPI: SPMI 0x000FFC8723E0 41 (v05 ALASKA A M I
 AMI. )
[0.00] ACPI: FIDT 0x000FFC872428 9C (v01 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: APIC 0x000FFC8724C8 000F68 (v03 CAVIUM THUNDERX 
0001 INTL 20150619)
[0.00] ACPI: DBG2 0x000FFC873430 67 (v01 CAVIUM CN88XDBG 
 INTL 20150619)
[0.00] ACPI: GTDT 0x000FFC873498 E0 (v02 CAVIUM THUNDERX 
0001 INTL 20150619)
[0.00] ACPI: IORT 0x000FFC873578 0013D4 (v01 CAVIUM THUNDERX 
0001 INTL 20150619)
[0.00] ACPI: MCFG 0x000FFC874950 6C (v01 CAVIUM THUNDERX 
0001 INTL 20150619)
[0.00] ACPI: SSDT 0x000FFC8749C0 00089C (v02 CAVIUM NETWORK  
0001 INTL 20150619)
[0.00] ACPI: OEM1 0x000FFC875260 0001E8 (v02 CAVIUM THUNDERX 
0001 INTL 20150619)
[0.00] ACPI: SLIT 0x000FFC875448 30 (v01 CAVIUM TEMPLATE 
0001 INTL 20150619)
[0.00] ACPI: SPCR 0x000FFC875478 50 (v02 A M I  APTIO V  
01072009 AMI. 0005000B)
[0.00] ACPI: BGRT 0x000FFC8754C8 38 (v01 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: SPCR: console: pl011,mmio32,0x87e02400,115200
[0.00] efi_bgrt: Ignoring BGRT: Incorrect BMP magic number 0x3707 
(expected 0x4d42)
[0.00] ACPI: NUMA: Failed to initialise from firmware
[0.00] NUMA: Faking a node at [mem 
0x0050-0x000fff0f]
[0.00] NUMA: NODE_DATA [mem 0xff67d40c0-0xff67d8fff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x0050-0x]
[0.00]   DMA32empty
[0.00]   Normal   [mem 0x0001-0x000fff0f]
[0.00]   Device   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0050-0x00df]
[0.00]   node   0: [mem 0x00e0-0x0fff]
[0.00]   node   0: [mem 0x1000-0x102f]
[0.00]   node   0: [mem 0x1030-0xfff9]
[0.00]   node   0: [mem 0xfffa-0x]
[0.00]   node   0: [mem 0x0001-0x000fee69]
[0.00]   node   0: [mem 0x000fee6a-0x000fee6b]
[0.00]   node   0: [mem 0x000fee6c-0x000ffa98]
[0.00]   node   0: [mem 0x000ffa99-0x000ffa9a]
[0.00]   node   0: [mem 0x000ffa9b-0x000ffac1]
[0.00]   node   0: [mem 0x000ffac2-0x000ffb09]
[0.00]   node   0: [mem 0x000ffb0a-0x000ffc8a]
[0.00]   node   0: [mem 0x000ffc8b-0x000ffc90]
[0.00]   node   0: [mem 0x000ffc91-0x000ffca2]
[0.00]   node   0: [mem 0x000ffca3-0x000ffca3]
[0.00]   node   0: [mem 0x000ffca4-0x000ffcdb]
[0.00]   node   0: [mem 0x000ffcdc-0x000ffd12]
[0.00]   node   0: [mem 0x000ffd13-0x000ffecb]
[0.00]   node   0: [mem 0x000ffecc-0x000ffed1]
[0.00]   node   0: [mem 

Re: [PATCH] PCI: xgene: fix a mistake about cfg address

[dann frazier]

On Sun, Mar 28, 2021 at 10:41:18PM +0800, Dejin Zheng wrote:
> It has a wrong modification to the xgene driver by the commit
> e2dcd20b1645a. it use devm_platform_ioremap_resource_byname() to
> simplify codes and remove the res variable, But the following code
> needs to use this res variable, So after this commit, the port->cfg_addr
> will get a wrong address. Now, revert it.
> 
> Fixes: e2dcd20b1645a ("PCI: controller: Convert to 
> devm_platform_ioremap_resource_byname()")
> Reported-by: dann.fraz...@canonical.com
> Signed-off-by: Dejin Zheng 

Tested-by: dann frazier 

Thanks!

  -dann

> ---
>  drivers/pci/controller/pci-xgene.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/pci-xgene.c 
> b/drivers/pci/controller/pci-xgene.c
> index 2afdc865253e..7f503dd4ff81 100644
> --- a/drivers/pci/controller/pci-xgene.c
> +++ b/drivers/pci/controller/pci-xgene.c
> @@ -354,7 +354,8 @@ static int xgene_pcie_map_reg(struct xgene_pcie_port 
> *port,
>   if (IS_ERR(port->csr_base))
>   return PTR_ERR(port->csr_base);
>  
> - port->cfg_base = devm_platform_ioremap_resource_byname(pdev, "cfg");
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
> + port->cfg_base = devm_ioremap_resource(dev, res);
>   if (IS_ERR(port->cfg_base))
>   return PTR_ERR(port->cfg_base);
>   port->cfg_addr = res->start;

Re: [PATCH v2] PCI: controller: convert to devm_platform_ioremap_resource_byname()

[dann frazier]

On Wed, Jun 03, 2020 at 01:16:01AM +0800, Dejin Zheng wrote:
> Use devm_platform_ioremap_resource_byname() to simplify codes.
> it contains platform_get_resource_byname() and devm_ioremap_resource().
> 
> Signed-off-by: Dejin Zheng 
> ---
> v1 -> v2:
>   - Discard changes to the file drivers/pci/controller/pcie-xilinx-nwl.c
> Due to my mistakes, my patch will modify pcie-xilinx-nwl.c,
> but it still need to use the res variable, but
> devm_platform_ioremap_resource_byname() funtion can't assign a
> value to the variable res. kbuild test robot report it. Thanks
> very much for kbuild test robot .
> 
>  drivers/pci/controller/cadence/pcie-cadence-ep.c   | 3 +--
>  drivers/pci/controller/cadence/pcie-cadence-host.c | 3 +--
>  drivers/pci/controller/pci-tegra.c | 8 +++-
>  drivers/pci/controller/pci-xgene.c | 3 +--
>  drivers/pci/controller/pcie-altera-msi.c   | 3 +--
>  drivers/pci/controller/pcie-altera.c   | 9 +++--
>  drivers/pci/controller/pcie-mediatek.c | 4 +---
>  drivers/pci/controller/pcie-rockchip.c | 5 ++---
>  8 files changed, 13 insertions(+), 25 deletions(-)
> 

hey,
  I found that recent kernels fail to initialize PCI devices on our HP
m400 Moonshot cartridges, which are based on the X-Gene SoC. I
bisected the issue down to this commit. I found that just reverting
this hunk in pci-xgene.c is enough to get v5.12 rcs booting again:

> diff --git a/drivers/pci/controller/pci-xgene.c 
> b/drivers/pci/controller/pci-xgene.c
> index d1efa8ffbae1..1431a18eb02c 100644
> --- a/drivers/pci/controller/pci-xgene.c
> +++ b/drivers/pci/controller/pci-xgene.c
> @@ -355,8 +355,7 @@ static int xgene_pcie_map_reg(struct xgene_pcie_port 
> *port,
>   if (IS_ERR(port->csr_base))
>   return PTR_ERR(port->csr_base);
>  
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
> - port->cfg_base = devm_ioremap_resource(dev, res);
> + port->cfg_base = devm_platform_ioremap_resource_byname(pdev, "cfg");
>   if (IS_ERR(port->cfg_base))
>   return PTR_ERR(port->cfg_base);
>   port->cfg_addr = res->start;


In case it helps, here's the PCI initialization portion of dmesg when
it fails:

[0.756359] xgene-pcie 1f50.pcie: host bridge /soc/pcie@1f50 ranges:
[0.756372] xgene-pcie 1f50.pcie:   No bus range found for 
/soc/pcie@1f50, using [bus 00-ff]
[0.756387] xgene-pcie 1f50.pcie:  MEM 0xa13000..0xa1afff -> 
0x003000
[0.756404] xgene-pcie 1f50.pcie:   IB MEM 0x40..0x7f -> 
0x40
[0.756459] xgene-pcie 1f50.pcie: (rc) x8 gen-2 link up
[0.756525] xgene-pcie 1f50.pcie: PCI host bridge to bus :00
[0.756532] pci_bus :00: root bus resource [bus 00-ff]
[0.756538] pci_bus :00: root bus resource [mem 
0xa13000-0xa1afff] (bus address [0x3000-0xafff])


and here's what it looks like when it works:

[0.756793] xgene-pcie 1f50.pcie: host bridge /soc/pcie@1f50 ranges:
[0.756807] xgene-pcie 1f50.pcie:   No bus range found for 
/soc/pcie@1f50, using [bus 00-ff]
[0.756822] xgene-pcie 1f50.pcie:  MEM 0xa13000..0xa1afff -> 
0x003000
[0.756838] xgene-pcie 1f50.pcie:   IB MEM 0x40..0x7f -> 
0x40
[0.756892] xgene-pcie 1f50.pcie: (rc) x8 gen-2 link up
[0.756962] xgene-pcie 1f50.pcie: PCI host bridge to bus :00
[0.756968] pci_bus :00: root bus resource [bus 00-ff]
[0.756974] pci_bus :00: root bus resource [mem 
0xa13000-0xa1afff] (bus address [0x3000-0xafff])
[0.757006] pci :00:00.0: [10e8:e004] type 01 class 0x060400
[0.757014] pci_bus :00: 2-byte config write to :00:00.0 offset 0x4 
may corrupt adjacent RW1C bits
[0.757022] pci_bus :00: 2-byte config write to :00:00.0 offset 0x4 
may corrupt adjacent RW1C bits
[0.757032] pci_bus :00: 2-byte config write to :00:00.0 offset 0x4 
may corrupt adjacent RW1C bits
[0.757039] pci_bus :00: 2-byte config write to :00:00.0 offset 0x4 
may corrupt adjacent RW1C bits
[0.757046] pci_bus :00: 2-byte config write to :00:00.0 offset 0x4 
may corrupt adjacent RW1C bits
[0.757052] pci_bus :00: 2-byte config write to :00:00.0 offset 0x4 
may corrupt adjacent RW1C bits
[0.757059] pci_bus :00: 2-byte config write to :00:00.0 offset 0x4 
may corrupt adjacent RW1C bits
[0.757068] pci_bus :00: 2-byte config write to :00:00.0 offset 0x4 
may corrupt adjacent RW1C bits
[0.757094] pci_bus :00: 2-byte config write to :00:00.0 offset 0x3e 
may corrupt adjacent RW1C bits
[0.757143] pci :00:00.0: supports D1 D2
[0.757589] pci_bus :00: 2-byte config write to :00:00.0 offset 0x3e 
may corrupt adjacent RW1C bits
[0.757968] pci :01:00.0: [15b3:1007] 

Re: [PATCH 4.4 17/70] crypto: arm64/sha - avoid non-standard inline asm tricks

[dann frazier]

On Mon, Nov 23, 2020 at 01:49:07PM -0700, dann frazier wrote:
> On Mon, Nov 26, 2018 at 11:50:32AM +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> fyi, I bisected a regression down to this commit. This apparently
> causes an ADR_PREL_PG_HI21 relocation to be added to the sha{1,2}_ce
> modules. Back in 4.4 ADR_PREL_PG_HI21 relocations were forbidden if
> built with CONFIG_ARM64_ERRATUM_843419=y, so now the sha{1,2}_ce modules
> fail to load:
> 
> [   37.866250] module sha1_ce: unsupported RELA relocation: 275
> 
> Looks like it should be an issue for 4.14.y as well, but I haven't yet
> tested it.

This regression appears to be limited to 4.4.y. I didn't find it when
testing 4.9.y, and a 2nd bisection determined that it is because
4.9.y+ also contains a backport of commit 41c066f ("arm64: assembler:
make adr_l work in modules under KASLR"). That was pulled from 4.4.y
because it caused a build failure:

  https://www.spinics.net/lists/stable/msg179709.html

Shall I submit a revert of this patch for 4.4.y, or is it worth trying
to get a backport of 41c066f to work?

  -dann
  
> > From: Ard Biesheuvel 
> > 
> > commit f4857f4c2ee9aa4e2aacac1a845352b00197fb57 upstream.
> > 
> > Replace the inline asm which exports struct offsets as ELF symbols
> > with proper const variables exposing the same values. This works
> > around an issue with Clang which does not interpret the "i" (or "I")
> > constraints in the same way as GCC.
> > 
> > Signed-off-by: Ard Biesheuvel 
> > Tested-by: Matthias Kaehlcke 
> > Signed-off-by: Herbert Xu 
> > Signed-off-by: Nathan Chancellor 
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> >  arch/arm64/crypto/sha1-ce-core.S |6 --
> >  arch/arm64/crypto/sha1-ce-glue.c |   11 +++
> >  arch/arm64/crypto/sha2-ce-core.S |6 --
> >  arch/arm64/crypto/sha2-ce-glue.c |   13 +
> >  4 files changed, 16 insertions(+), 20 deletions(-)
> > 
> > --- a/arch/arm64/crypto/sha1-ce-core.S
> > +++ b/arch/arm64/crypto/sha1-ce-core.S
> > @@ -82,7 +82,8 @@ ENTRY(sha1_ce_transform)
> > ldr dgb, [x0, #16]
> >  
> > /* load sha1_ce_state::finalize */
> > -   ldr w4, [x0, #:lo12:sha1_ce_offsetof_finalize]
> > +   ldr_l   w4, sha1_ce_offsetof_finalize, x4
> > +   ldr w4, [x0, x4]
> >  
> > /* load input */
> >  0: ld1 {v8.4s-v11.4s}, [x1], #64
> > @@ -132,7 +133,8 @@ CPU_LE( rev32   v11.16b, v11.16b)
> >  * the padding is handled by the C code in that case.
> >  */
> > cbz x4, 3f
> > -   ldr x4, [x0, #:lo12:sha1_ce_offsetof_count]
> > +   ldr_l   w4, sha1_ce_offsetof_count, x4
> > +   ldr x4, [x0, x4]
> > moviv9.2d, #0
> > mov x8, #0x8000
> > moviv10.2d, #0
> > --- a/arch/arm64/crypto/sha1-ce-glue.c
> > +++ b/arch/arm64/crypto/sha1-ce-glue.c
> > @@ -17,9 +17,6 @@
> >  #include 
> >  #include 
> >  
> > -#define ASM_EXPORT(sym, val) \
> > -   asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> > -
> >  MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
> >  MODULE_AUTHOR("Ard Biesheuvel ");
> >  MODULE_LICENSE("GPL v2");
> > @@ -32,6 +29,9 @@ struct sha1_ce_state {
> >  asmlinkage void sha1_ce_transform(struct sha1_ce_state *sst, u8 const *src,
> >   int blocks);
> >  
> > +const u32 sha1_ce_offsetof_count = offsetof(struct sha1_ce_state, 
> > sst.count);
> > +const u32 sha1_ce_offsetof_finalize = offsetof(struct sha1_ce_state, 
> > finalize);
> > +
> >  static int sha1_ce_update(struct shash_desc *desc, const u8 *data,
> >   unsigned int len)
> >  {
> > @@ -52,11 +52,6 @@ static int sha1_ce_finup(struct shash_de
> > struct sha1_ce_state *sctx = shash_desc_ctx(desc);
> > bool finalize = !sctx->sst.count && !(len % SHA1_BLOCK_SIZE);
> >  
> > -   ASM_EXPORT(sha1_ce_offsetof_count,
> > -  offsetof(struct sha1_ce_state, sst.count));
> > -   ASM_EXPORT(sha1_ce_offsetof_finalize,
> > -  offsetof(struct sha1_ce_state, finalize));
> > -
> > /*
> >  * Allow the asm code to perform the finalization if there is no
> >  * partial data and the input is a round multiple of the block size.
> > ---

Re: [PATCH 4.4 17/70] crypto: arm64/sha - avoid non-standard inline asm tricks

[dann frazier]

On Mon, Nov 26, 2018 at 11:50:32AM +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.

fyi, I bisected a regression down to this commit. This apparently
causes an ADR_PREL_PG_HI21 relocation to be added to the sha{1,2}_ce
modules. Back in 4.4 ADR_PREL_PG_HI21 relocations were forbidden if
built with CONFIG_ARM64_ERRATUM_843419=y, so now the sha{1,2}_ce modules
fail to load:

[   37.866250] module sha1_ce: unsupported RELA relocation: 275

Looks like it should be an issue for 4.14.y as well, but I haven't yet
tested it.

  -dann

> From: Ard Biesheuvel 
> 
> commit f4857f4c2ee9aa4e2aacac1a845352b00197fb57 upstream.
> 
> Replace the inline asm which exports struct offsets as ELF symbols
> with proper const variables exposing the same values. This works
> around an issue with Clang which does not interpret the "i" (or "I")
> constraints in the same way as GCC.
> 
> Signed-off-by: Ard Biesheuvel 
> Tested-by: Matthias Kaehlcke 
> Signed-off-by: Herbert Xu 
> Signed-off-by: Nathan Chancellor 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  arch/arm64/crypto/sha1-ce-core.S |6 --
>  arch/arm64/crypto/sha1-ce-glue.c |   11 +++
>  arch/arm64/crypto/sha2-ce-core.S |6 --
>  arch/arm64/crypto/sha2-ce-glue.c |   13 +
>  4 files changed, 16 insertions(+), 20 deletions(-)
> 
> --- a/arch/arm64/crypto/sha1-ce-core.S
> +++ b/arch/arm64/crypto/sha1-ce-core.S
> @@ -82,7 +82,8 @@ ENTRY(sha1_ce_transform)
>   ldr dgb, [x0, #16]
>  
>   /* load sha1_ce_state::finalize */
> - ldr w4, [x0, #:lo12:sha1_ce_offsetof_finalize]
> + ldr_l   w4, sha1_ce_offsetof_finalize, x4
> + ldr w4, [x0, x4]
>  
>   /* load input */
>  0:   ld1 {v8.4s-v11.4s}, [x1], #64
> @@ -132,7 +133,8 @@ CPU_LE(   rev32   v11.16b, v11.16b)
>* the padding is handled by the C code in that case.
>*/
>   cbz x4, 3f
> - ldr x4, [x0, #:lo12:sha1_ce_offsetof_count]
> + ldr_l   w4, sha1_ce_offsetof_count, x4
> + ldr x4, [x0, x4]
>   moviv9.2d, #0
>   mov x8, #0x8000
>   moviv10.2d, #0
> --- a/arch/arm64/crypto/sha1-ce-glue.c
> +++ b/arch/arm64/crypto/sha1-ce-glue.c
> @@ -17,9 +17,6 @@
>  #include 
>  #include 
>  
> -#define ASM_EXPORT(sym, val) \
> - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> -
>  MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
>  MODULE_AUTHOR("Ard Biesheuvel ");
>  MODULE_LICENSE("GPL v2");
> @@ -32,6 +29,9 @@ struct sha1_ce_state {
>  asmlinkage void sha1_ce_transform(struct sha1_ce_state *sst, u8 const *src,
> int blocks);
>  
> +const u32 sha1_ce_offsetof_count = offsetof(struct sha1_ce_state, sst.count);
> +const u32 sha1_ce_offsetof_finalize = offsetof(struct sha1_ce_state, 
> finalize);
> +
>  static int sha1_ce_update(struct shash_desc *desc, const u8 *data,
> unsigned int len)
>  {
> @@ -52,11 +52,6 @@ static int sha1_ce_finup(struct shash_de
>   struct sha1_ce_state *sctx = shash_desc_ctx(desc);
>   bool finalize = !sctx->sst.count && !(len % SHA1_BLOCK_SIZE);
>  
> - ASM_EXPORT(sha1_ce_offsetof_count,
> -offsetof(struct sha1_ce_state, sst.count));
> - ASM_EXPORT(sha1_ce_offsetof_finalize,
> -offsetof(struct sha1_ce_state, finalize));
> -
>   /*
>* Allow the asm code to perform the finalization if there is no
>* partial data and the input is a round multiple of the block size.
> --- a/arch/arm64/crypto/sha2-ce-core.S
> +++ b/arch/arm64/crypto/sha2-ce-core.S
> @@ -88,7 +88,8 @@ ENTRY(sha2_ce_transform)
>   ld1 {dgav.4s, dgbv.4s}, [x0]
>  
>   /* load sha256_ce_state::finalize */
> - ldr w4, [x0, #:lo12:sha256_ce_offsetof_finalize]
> + ldr_l   w4, sha256_ce_offsetof_finalize, x4
> + ldr w4, [x0, x4]
>  
>   /* load input */
>  0:   ld1 {v16.4s-v19.4s}, [x1], #64
> @@ -136,7 +137,8 @@ CPU_LE(   rev32   v19.16b, v19.16b)
>* the padding is handled by the C code in that case.
>*/
>   cbz x4, 3f
> - ldr x4, [x0, #:lo12:sha256_ce_offsetof_count]
> + ldr_l   w4, sha256_ce_offsetof_count, x4
> + ldr x4, [x0, x4]
>   moviv17.2d, #0
>   mov x8, #0x8000
>   moviv18.2d, #0
> --- a/arch/arm64/crypto/sha2-ce-glue.c
> +++ b/arch/arm64/crypto/sha2-ce-glue.c
> @@ -17,9 +17,6 @@
>  #include 
>  #include 
>  
> -#define ASM_EXPORT(sym, val) \
> - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> -
>  MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto 
> Extensions");
>  MODULE_AUTHOR("Ard Biesheuvel ");
>  MODULE_LICENSE("GPL v2");
> @@ -32,6 

5.9-rc7 oops in nvkm_udevice_info() w/ GA100

[dann frazier]

hey,
  I'm seeing an Oops when nouveau loads (see below). I've verified
that this is because both device->chip and device->name are NULL prior
to the strncpy()s at the end of nvkm_udevice_info(). Bisect shows that
this started happening after:

commit 24d5ff40a732633dceab68c6559ba723784f4a68
Author: Karol Herbst 
Date: Tue Apr 28 18:54:02 2020 +0200

drm/nouveau/device: rework mmio mapping code to get rid of second map

Fixes warnings on GPUs with smaller a smaller mmio region like vGPUs.

Signed-off-by: Karol Herbst 
Signed-off-by: Ben Skeggs 

[ 213.131657] nouveau :07:00.0: unknown chipset (17a1)
[ 213.138547] nouveau :07:00.0: unknown chipset (17a1)
[ 213.144938] BUG: kernel NULL pointer dereference, address: 
[ 213.152704] #PF: supervisor read access in kernel mode
[ 213.158433] #PF: error_code(0x) - not-present page
[ 213.164162] PGD 0 P4D 0
[ 213.166985] Oops:  [#1] SMP NOPTI
[ 213.171068] CPU: 32 PID: 206 Comm: kworker/32:0 Not tainted 5.9.0-rc7+ #1
[ 213.178639] Hardware name: NVIDIA DGXA100
920-23687-2530-000/DGXA100, BIOS 0.25 06/30/2020
[ 213.187866] Workqueue: events work_for_cpu_fn
[ 213.192761] RIP: 0010:nvkm_udevice_mthd+0x1ed/0x7d0 [nouveau]
[ 213.199170] Code: 10 49 89 47 08 4d 85 c9 74 10 48 85 c0 74 0b 41 8b
51 70 48 29 d0 49 89 47 10 49 8b 86 c0 00 00 00 49 8d 7f 18 ba 10 00
00 00 <48> 8b 30 e8 6b 91 89 c0 49 8b 76 28 49 8d 7f 28 ba 40 00 00 00
e8
[ 213.220121] RSP: 0018:ae0619d47b48 EFLAGS: 00010246
[ 213.225948] RAX:  RBX: 9cefab819580 RCX: 00c6
[ 213.233907] RDX: 0010 RSI:  RDI: 9cef988f0578
[ 213.241864] RBP: ae0619d47b80 R08:  R09: 
[ 213.249813] R10: 0088 R11: 01320122 R12: 
[ 213.257762] R13: 0068 R14: 9cef6107c400 R15: 9cef988f0560
[ 213.265721] FS: () GS:9cefce00()
knlGS:
[ 213.274747] CS: 0010 DS:  ES:  CR0: 80050033
[ 213.281153] CR2:  CR3: 007f3019c000 CR4: 00350ee0
[ 213.289104] Call Trace:
[ 213.291854] ? nvkm_object_insert+0x6f/0x80 [nouveau]
[ 213.297509] nvkm_object_mthd+0x1a/0x30 [nouveau]
[ 213.302773] nvkm_ioctl_mthd+0x65/0x70 [nouveau]
[ 213.307940] nvkm_ioctl+0xf0/0x190 [nouveau]
[ 213.312735] nvkm_client_ioctl+0x12/0x20 [nouveau]
[ 213.318097] nvif_object_ioctl+0x4f/0x60 [nouveau]
[ 213.323460] nvif_object_mthd+0x9f/0x150 [nouveau]
[ 213.328822] ? nvif_object_ctor+0x14b/0x1d0 [nouveau]
[ 213.334473] nvif_device_ctor+0x61/0x70 [nouveau]
[ 213.339749] nouveau_cli_init+0x1a3/0x460 [nouveau]
[ 213.345215] ? nouveau_drm_device_init+0x3e/0x780 [nouveau]
[ 213.351454] nouveau_drm_device_init+0x77/0x780 [nouveau]
[ 213.357479] ? pci_read_config_word+0x27/0x40
[ 213.362337] ? pci_enable_device_flags+0x14f/0x170
[ 213.367705] nouveau_drm_probe+0x132/0x1f0 [nouveau]
[ 213.373241] local_pci_probe+0x48/0x80
[ 213.377419] work_for_cpu_fn+0x1a/0x30
[ 213.381598] process_one_work+0x1e8/0x3b0
[ 213.386068] worker_thread+0x53/0x420
[ 213.390149] kthread+0x12f/0x150
[ 213.393745] ? process_one_work+0x3b0/0x3b0
[ 213.398406] ? __kthread_bind_mask+0x70/0x70
[ 213.403169] ret_from_fork+0x22/0x30
[ 213.407153] Modules linked in: nouveau(+) mxm_wmi wmi video
nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua
amd64_edac_mod edac_mce_amd amd_energy kvm_amd kvm rapl efi_pstore
ipmi_ssif input_leds cdc_ether usbnet mii ccp k10temp acpi_ipmi
ipmi_si ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel ip_tables
x_tables autofs4 btrfs blake2b_generic raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor
raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib ses enclosure
hid_generic usbhid uas hid usb_storage ib_uverbs ib_core
crct10dif_pclmul crc32_pclmul ast ghash_clmulni_intel drm_vram_helper
aesni_intel drm_ttm_helper crypto_simd ttm cryptd drm_kms_helper
glue_helper syscopyarea sysfillrect sysimgblt mlx5_core fb_sys_fops
pci_hyperv_intf igb cec mpt3sas dca rc_core raid_class nvme tls
i2c_algo_bit scsi_transport_sas drm mlxfw xhci_pci nvme_core
xhci_pci_renesas i2c_piix4
[ 213.497060] CR2: 
[ 213.500755] ---[ end trace eed3a19f1f25ca74 ]---

Re: [for-next][PATCH 09/18] tracing: Move pipe reference to trace array instead of current_tracer

[dann frazier]

On Fri, Jul 31, 2020 at 3:16 PM Steven Rostedt  wrote:
>
> On Fri, 31 Jul 2020 13:33:45 -0600
> dann frazier  wrote:
>
> > > This is marked as "Fixes" but is more of a clean up than a true fix.
> > > Backport if you want, but its not critical.
> >
> > Thanks Steven! In case it helps backport consideration, I wanted to
> > note that this addresses an issue we've seen with users trying to
> > change current_tracer when they happen to have rasdaemon
> > installed. rasdaemon uses the trace_pipe interface at runtime, which
> > therefore blocks changing the current tracer. But of course, unless
> > you know about rasdaemon internals, it isn't exactly an obvious
> > failure mode.
>
> Ah, then this should probably be backported.
>
> When I push to Linus (during the next merge window) and it gets into
> Linus's tree. Feel free to send sta...@vger.kernel.org the sha1 of this
> commit, and ask for it to be backported for the above stated reason.

Will do.

 -dann

Re: [for-next][PATCH 09/18] tracing: Move pipe reference to trace array instead of current_tracer

[dann frazier]

On Thu, Jul 02, 2020 at 05:58:21PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> If a process has the trace_pipe open on a trace_array, the current tracer
> for that trace array should not be changed. This was original enforced by a
> global lock, but when instances were introduced, it was moved to the
> current_trace. But this structure is shared by all instances, and a
> trace_pipe is for a single instance. There's no reason that a process that
> has trace_pipe open on one instance should prevent another instance from
> changing its current tracer. Move the reference counter to the trace_array
> instead.
> 
> This is marked as "Fixes" but is more of a clean up than a true fix.
> Backport if you want, but its not critical.

Thanks Steven! In case it helps backport consideration, I wanted to
note that this addresses an issue we've seen with users trying to
change current_tracer when they happen to have rasdaemon
installed. rasdaemon uses the trace_pipe interface at runtime, which
therefore blocks changing the current tracer. But of course, unless
you know about rasdaemon internals, it isn't exactly an obvious
failure mode.

  -dann

> Fixes: cf6ab6d9143b1 ("tracing: Add ref count to tracer for when they are 
> being read by pipe")
> Signed-off-by: Steven Rostedt (VMware) 
> ---
>  kernel/trace/trace.c | 12 ++--
>  kernel/trace/trace.h |  2 +-
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8241d1448d70..64c5b8146cca 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -5891,7 +5891,7 @@ int tracing_set_tracer(struct trace_array *tr, const 
> char *buf)
>   }
>  
>   /* If trace pipe files are being read, we can't change the tracer */
> - if (tr->current_trace->ref) {
> + if (tr->trace_ref) {
>   ret = -EBUSY;
>   goto out;
>   }
> @@ -6107,7 +6107,7 @@ static int tracing_open_pipe(struct inode *inode, 
> struct file *filp)
>  
>   nonseekable_open(inode, filp);
>  
> - tr->current_trace->ref++;
> + tr->trace_ref++;
>  out:
>   mutex_unlock(_types_lock);
>   return ret;
> @@ -6126,7 +6126,7 @@ static int tracing_release_pipe(struct inode *inode, 
> struct file *file)
>  
>   mutex_lock(_types_lock);
>  
> - tr->current_trace->ref--;
> + tr->trace_ref--;
>  
>   if (iter->trace->pipe_close)
>   iter->trace->pipe_close(iter);
> @@ -7428,7 +7428,7 @@ static int tracing_buffers_open(struct inode *inode, 
> struct file *filp)
>  
>   filp->private_data = info;
>  
> - tr->current_trace->ref++;
> + tr->trace_ref++;
>  
>   mutex_unlock(_types_lock);
>  
> @@ -7529,7 +7529,7 @@ static int tracing_buffers_release(struct inode *inode, 
> struct file *file)
>  
>   mutex_lock(_types_lock);
>  
> - iter->tr->current_trace->ref--;
> + iter->tr->trace_ref--;
>  
>   __trace_array_put(iter->tr);
>  
> @@ -8737,7 +8737,7 @@ static int __remove_instance(struct trace_array *tr)
>   int i;
>  
>   /* Reference counter for a newly created trace array = 1. */
> - if (tr->ref > 1 || (tr->current_trace && tr->current_trace->ref))
> + if (tr->ref > 1 || (tr->current_trace && tr->trace_ref))
>   return -EBUSY;
>  
>   list_del(>list);
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 13db4000af3f..f21607f87189 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -356,6 +356,7 @@ struct trace_array {
>   struct trace_event_file *trace_marker_file;
>   cpumask_var_t   tracing_cpumask; /* only trace on set CPUs */
>   int ref;
> + int trace_ref;
>  #ifdef CONFIG_FUNCTION_TRACER
>   struct ftrace_ops   *ops;
>   struct trace_pid_list   __rcu *function_pids;
> @@ -547,7 +548,6 @@ struct tracer {
>   struct tracer   *next;
>   struct tracer_flags *flags;
>   int enabled;
> - int ref;
>   boolprint_max;
>   boolallow_instances;
>  #ifdef CONFIG_TRACER_MAX_TRACE

Re: [PATCH net-next] hinic: fix a bug in set rx mode

[dann frazier]

On Mon, May 27, 2019 at 10:10:05PM +, Xue Chaojing wrote:
> in set_rx_mode, __dev_mc_sync and netdev_for_each_mc_addr will
> repeatedly set the multicast mac address. so we delete this loop.

fyi, I'm told this fixes the following Oops (in case it makes sense to
queue it for stable):

[ 642.914581] Internal error: Oops: 9605 [#1] SMP
[ 642.919444] Modules linked in: hinic(-) 8021q garp mrp stp llc ses enclosure 
sg nls_utf8 isofs vfat fat loop ipmi_ssif crc32_ce crct10dif_ce ghash_c e 
sha2_ce sha256_arm64 sha1_ce sbsa_gwdt hns_roce_hw_v2 hns_roce ib_core ipmi_si 
ipmi_devintf ipmi_msghandler xfs libcrc32c marvell hibmc_drm drm_kms_h elper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm qla2xxx ixgbe drm mpt3sas 
nvme_fc hns3 hisi_sas_v3_hw igb nvme_fabrics hisi_sas_main hclge mdio 
scsi_transport_fc nvme libsas hnae3 raid_class nvme_core scsi_transport_sas 
i2c_algo_bit gpio_dwapb gpio_generic dm_mirror dm_region_hash dm_log dm_mo d 
[last unloaded: hinic]
[ 642.974177] CPU: 4 PID: 5339 Comm: kworker/u256:1 Kdump: loaded Not tainted 
4.18.0-74.el8.aarch64 #1
[ 642.983293] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 
2280-A CS V2.16.01 03/16/2019
[ 642.992591] Workqueue: hinic_dev set_rx_mode [hinic]
[ 642.997542] pstate: 00c9 (nzcv daif +PAN +UAO)
[ 643.002320] pc : add_mac_addr+0xa4/0x100 [hinic]
[ 643.006924] lr : set_rx_mode+0x88/0xc0 [hinic]
[ 643.011353] sp : 3228fd40
[ 643.014653] x29: 3228fd40 x28: 
[ 643.019952] x27: b955c362ff38 x26: 27ccd2cc3110
[ 643.025250] x25:  x24: b955025c6b08
[ 643.030547] x23: b955025c6000 x22: 0010
[ 643.035845] x21: 27cc56040488 x20: b955025c6ac0
[ 643.041142] x19:  x18: 0010
[ 643.046440] x17: b7135830 x16: 27ccd2259bb8
[ 643.051737] x15:  x14: 2030302031302039
[ 643.057035] x13: 33203d2072646461 x12: 2063616d20746573
[ 643.062332] x11: 203a296465726574 x10: 0d10
[ 643.067630] x9 : 3228f9f0 x8 : b95501756170
[ 643.072927] x7 : 198c000940300814 x6 : 3228fd08
[ 643.078225] x5 :  x4 : 
[ 643.083523] x3 :  x2 : 0001
[ 643.088820] x1 : 0010 x0 : 00e3
[ 643.094118] Process kworker/u256:1 (pid: 5339, stack limit = 
0x23b4f182)
[ 643.101498] Call trace:
[ 643.103932] add_mac_addr+0xa4/0x100 [hinic]
[ 643.108189] set_rx_mode+0x88/0xc0 [hinic]
[ 643.112272] process_one_work+0x1ac/0x3e0
[ 643.116268] worker_thread+0x44/0x448
[ 643.119916] kthread+0x130/0x138
[ 643.123130] ret_from_fork+0x10/0x18
[ 643.126692] Code: a9425bf5 a94363f7 a8c47bfd d65f03c0 (394016c7)
[ 643.132828] SMP: stopping secondary CPUs
[ 643.139859] Starting crashdump kernel...
[ 643.143771] Bye!

  -dann

> Signed-off-by: Xue Chaojing 
> ---
>  drivers/net/ethernet/huawei/hinic/hinic_main.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c 
> b/drivers/net/ethernet/huawei/hinic/hinic_main.c
> index e64bc664f687..cfd3f4232cac 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
> @@ -724,7 +724,6 @@ static void set_rx_mode(struct work_struct *work)
>  {
>   struct hinic_rx_mode_work *rx_mode_work = work_to_rx_mode_work(work);
>   struct hinic_dev *nic_dev = rx_mode_work_to_nic_dev(rx_mode_work);
> - struct netdev_hw_addr *ha;
>  
>   netif_info(nic_dev, drv, nic_dev->netdev, "set rx mode work\n");
>  
> @@ -732,9 +731,6 @@ static void set_rx_mode(struct work_struct *work)
>  
>   __dev_uc_sync(nic_dev->netdev, add_mac_addr, remove_mac_addr);
>   __dev_mc_sync(nic_dev->netdev, add_mac_addr, remove_mac_addr);
> -
> - netdev_for_each_mc_addr(ha, nic_dev->netdev)
> - add_mac_addr(nic_dev->netdev, ha->addr);
>  }
>  
>  static void hinic_set_rx_mode(struct net_device *netdev)

Re: [PATCH] ixgbe: Avoid NULL pointer dereference with VF on non-IPsec hw

[dann frazier]

hey David, Jeff - is it possible to get this queued up as a fix for 5.2?

 -dann
 
On Wed, May 22, 2019 at 05:22:58PM -0600, dann frazier wrote:
> An ipsec structure will not be allocated if the hardware does not support
> offload. Fixes the following Oops:
> 
> [  191.045452] Unable to handle kernel NULL pointer dereference at virtual 
> address 
> [  191.054232] Mem abort info:
> [  191.057014]   ESR = 0x9604
> [  191.060057]   Exception class = DABT (current EL), IL = 32 bits
> [  191.065963]   SET = 0, FnV = 0
> [  191.069004]   EA = 0, S1PTW = 0
> [  191.072132] Data abort info:
> [  191.074999]   ISV = 0, ISS = 0x0004
> [  191.078822]   CM = 0, WnR = 0
> [  191.081780] user pgtable: 4k pages, 48-bit VAs, pgdp = 43d9e467
> [  191.088382] [] pgd=
> [  191.093252] Internal error: Oops: 9604 [#1] SMP
> [  191.098119] Modules linked in: vhost_net vhost tap vfio_pci vfio_virqfd 
> vfio_iommu_type1 vfio xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat 
> nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 
> ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter devlink 
> ebtables ip6table_filter ip6_tables iptable_filter bpfilter ipmi_ssif 
> nls_iso8859_1 input_leds joydev ipmi_si hns_roce_hw_v2 ipmi_devintf hns_roce 
> ipmi_msghandler cppc_cpufreq sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core 
> iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables 
> autofs4 ses enclosure btrfs zstd_compress raid10 raid456 async_raid6_recov 
> async_memcpy async_pq async_xor async_tx xor hid_generic usbhid hid raid6_pq 
> libcrc32c raid1 raid0 multipath linear ixgbevf hibmc_drm ttm
> [  191.168607]  drm_kms_helper aes_ce_blk aes_ce_cipher syscopyarea 
> crct10dif_ce sysfillrect ghash_ce qla2xxx sysimgblt sha2_ce sha256_arm64 
> hisi_sas_v3_hw fb_sys_fops sha1_ce uas nvme_fc mpt3sas ixgbe drm 
> hisi_sas_main nvme_fabrics usb_storage hclge scsi_transport_fc ahci libsas 
> hnae3 raid_class libahci xfrm_algo scsi_transport_sas mdio aes_neon_bs 
> aes_neon_blk crypto_simd cryptd aes_arm64
> [  191.202952] CPU: 94 PID: 0 Comm: swapper/94 Not tainted 4.19.0-rc1+ #11
> [  191.209553] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - 
> V1.20.01 04/26/2019
> [  191.218064] pstate: 20400089 (nzCv daIf +PAN -UAO)
> [  191.222873] pc : ixgbe_ipsec_vf_clear+0x60/0xd0 [ixgbe]
> [  191.228093] lr : ixgbe_msg_task+0x2d0/0x1088 [ixgbe]
> [  191.233044] sp : 09b3bcd0
> [  191.236346] x29: 09b3bcd0 x28: 
> [  191.241647] x27: 09628000 x26: 
> [  191.246946] x25: 803f652d7600 x24: 0004
> [  191.252246] x23: 803f6a718900 x22: 
> [  191.257546] x21:  x20: 
> [  191.262845] x19:  x18: 
> [  191.268144] x17:  x16: 
> [  191.273443] x15:  x14: 00010026
> [  191.278742] x13: 00010025 x12: 8a5f7fbe0df0
> [  191.284042] x11: 0001000b x10: 0040
> [  191.289341] x9 : 1100 x8 : 803f6a824fd8
> [  191.294640] x7 : 803f6a825098 x6 : 0001
> [  191.299939] x5 : 00f0ffc0 x4 : 
> [  191.305238] x3 : 28c0 x2 : 803f652d7600
> [  191.310538] x1 :  x0 : 00f205f0
> [  191.315838] Process swapper/94 (pid: 0, stack limit = 0xaddfed5a)
> [  191.322613] Call trace:
> [  191.325055]  ixgbe_ipsec_vf_clear+0x60/0xd0 [ixgbe]
> [  191.329927]  ixgbe_msg_task+0x2d0/0x1088 [ixgbe]
> [  191.334536]  ixgbe_msix_other+0x274/0x330 [ixgbe]
> [  191.339233]  __handle_irq_event_percpu+0x78/0x270
> [  191.343924]  handle_irq_event_percpu+0x40/0x98
> [  191.348355]  handle_irq_event+0x50/0xa8
> [  191.352180]  handle_fasteoi_irq+0xbc/0x148
> [  191.356263]  generic_handle_irq+0x34/0x50
> [  191.360259]  __handle_domain_irq+0x68/0xc0
> [  191.364343]  gic_handle_irq+0x84/0x180
> [  191.368079]  el1_irq+0xe8/0x180
> [  191.371208]  arch_cpu_idle+0x30/0x1a8
> [  191.374860]  do_idle+0x1dc/0x2a0
> [  191.378077]  cpu_startup_entry+0x2c/0x30
> [  191.381988]  secondary_start_kernel+0x150/0x1e0
> [  191.386506] Code: 6b15003f 54000320 f1404a9f 5460 (79400260)
> 
> Fixes: eda0333ac2930 ("ixgbe: add VF IPsec management")
> Signed-off-by: dann frazier 
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c 
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> index ff85ce5791a36..31629fc7e820f 100644
> --- a/drivers/net/etherne

[PATCH] ixgbe: Avoid NULL pointer dereference with VF on non-IPsec hw

[dann frazier]

An ipsec structure will not be allocated if the hardware does not support
offload. Fixes the following Oops:

[  191.045452] Unable to handle kernel NULL pointer dereference at virtual 
address 
[  191.054232] Mem abort info:
[  191.057014]   ESR = 0x9604
[  191.060057]   Exception class = DABT (current EL), IL = 32 bits
[  191.065963]   SET = 0, FnV = 0
[  191.069004]   EA = 0, S1PTW = 0
[  191.072132] Data abort info:
[  191.074999]   ISV = 0, ISS = 0x0004
[  191.078822]   CM = 0, WnR = 0
[  191.081780] user pgtable: 4k pages, 48-bit VAs, pgdp = 43d9e467
[  191.088382] [] pgd=
[  191.093252] Internal error: Oops: 9604 [#1] SMP
[  191.098119] Modules linked in: vhost_net vhost tap vfio_pci vfio_virqfd 
vfio_iommu_type1 vfio xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat 
nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 
ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter devlink 
ebtables ip6table_filter ip6_tables iptable_filter bpfilter ipmi_ssif 
nls_iso8859_1 input_leds joydev ipmi_si hns_roce_hw_v2 ipmi_devintf hns_roce 
ipmi_msghandler cppc_cpufreq sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core 
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 
ses enclosure btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy 
async_pq async_xor async_tx xor hid_generic usbhid hid raid6_pq libcrc32c raid1 
raid0 multipath linear ixgbevf hibmc_drm ttm
[  191.168607]  drm_kms_helper aes_ce_blk aes_ce_cipher syscopyarea 
crct10dif_ce sysfillrect ghash_ce qla2xxx sysimgblt sha2_ce sha256_arm64 
hisi_sas_v3_hw fb_sys_fops sha1_ce uas nvme_fc mpt3sas ixgbe drm hisi_sas_main 
nvme_fabrics usb_storage hclge scsi_transport_fc ahci libsas hnae3 raid_class 
libahci xfrm_algo scsi_transport_sas mdio aes_neon_bs aes_neon_blk crypto_simd 
cryptd aes_arm64
[  191.202952] CPU: 94 PID: 0 Comm: swapper/94 Not tainted 4.19.0-rc1+ #11
[  191.209553] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - 
V1.20.01 04/26/2019
[  191.218064] pstate: 20400089 (nzCv daIf +PAN -UAO)
[  191.222873] pc : ixgbe_ipsec_vf_clear+0x60/0xd0 [ixgbe]
[  191.228093] lr : ixgbe_msg_task+0x2d0/0x1088 [ixgbe]
[  191.233044] sp : 09b3bcd0
[  191.236346] x29: 09b3bcd0 x28: 
[  191.241647] x27: 09628000 x26: 
[  191.246946] x25: 803f652d7600 x24: 0004
[  191.252246] x23: 803f6a718900 x22: 
[  191.257546] x21:  x20: 
[  191.262845] x19:  x18: 
[  191.268144] x17:  x16: 
[  191.273443] x15:  x14: 00010026
[  191.278742] x13: 00010025 x12: 8a5f7fbe0df0
[  191.284042] x11: 0001000b x10: 0040
[  191.289341] x9 : 1100 x8 : 803f6a824fd8
[  191.294640] x7 : 803f6a825098 x6 : 0001
[  191.299939] x5 : 00f0ffc0 x4 : 
[  191.305238] x3 : 28c0 x2 : 803f652d7600
[  191.310538] x1 :  x0 : 00f205f0
[  191.315838] Process swapper/94 (pid: 0, stack limit = 0xaddfed5a)
[  191.322613] Call trace:
[  191.325055]  ixgbe_ipsec_vf_clear+0x60/0xd0 [ixgbe]
[  191.329927]  ixgbe_msg_task+0x2d0/0x1088 [ixgbe]
[  191.334536]  ixgbe_msix_other+0x274/0x330 [ixgbe]
[  191.339233]  __handle_irq_event_percpu+0x78/0x270
[  191.343924]  handle_irq_event_percpu+0x40/0x98
[  191.348355]  handle_irq_event+0x50/0xa8
[  191.352180]  handle_fasteoi_irq+0xbc/0x148
[  191.356263]  generic_handle_irq+0x34/0x50
[  191.360259]  __handle_domain_irq+0x68/0xc0
[  191.364343]  gic_handle_irq+0x84/0x180
[  191.368079]  el1_irq+0xe8/0x180
[  191.371208]  arch_cpu_idle+0x30/0x1a8
[  191.374860]  do_idle+0x1dc/0x2a0
[  191.378077]  cpu_startup_entry+0x2c/0x30
[  191.381988]  secondary_start_kernel+0x150/0x1e0
[  191.386506] Code: 6b15003f 54000320 f1404a9f 5460 (79400260)

Fixes: eda0333ac2930 ("ixgbe: add VF IPsec management")
Signed-off-by: dann frazier 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index ff85ce5791a36..31629fc7e820f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -842,6 +842,9 @@ void ixgbe_ipsec_vf_clear(struct ixgbe_adapter *adapter, 
u32 vf)
struct ixgbe_ipsec *ipsec = adapter->ipsec;
int i;
 
+   if (!ipsec)
+   return;
+
/* search rx sa table */
for (i = 0; i < IXGBE_IPSEC_MAX_SA_COUNT && ipsec->num_rx_sa; i++) {
if (!ipsec->rx_tbl[i].used)
-- 
2.20.1

Re: [PATCH] scsi: libsas: Fix rphy phy_identifier for PHYs with end devices attached

[dann frazier]

On Fri, Feb 15, 2019 at 12:37:57AM +0800, John Garry wrote:
> The sysfs phy_identifier attribute for a sas_end_device comes
> from the rphy phy_identifier value.
> 
> Currently this is not being set for rphys with an end device attached,
> so we see incorrect symlinks from systemd disk/by-path:
> 
> root@localhost:~# ls -l /dev/disk/by-path/
> total 0
> lrwxrwxrwx 1 root root  9 Feb 13 12:26 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0 -> ../../sdb
> lrwxrwxrwx 1 root root 10 Feb 13 12:26 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0-part1 -> ../../sdb1
> lrwxrwxrwx 1 root root 10 Feb 13 12:26 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0-part2 -> ../../sdb2
> lrwxrwxrwx 1 root root 10 Feb 13 12:26 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy0-lun-0-part3 -> ../../sdc3
> 
> Indeed, each sas_end_device phy_identifier value is 0:
> 
> root@localhost:/# more sys/class/sas_device/end_device-0\:0\:2/phy_identifier
> 0
> root@localhost:/# more sys/class/sas_device/end_device-0\:0\:10/phy_identifier
> 0
> 
> This patch fixes the discovery code to set the phy_identifier.
> With this, we now get proper symlinks:
> 
> root@localhost:~# ls -l /dev/disk/by-path/
> total 0
> lrwxrwxrwx 1 root root  9 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy10-lun-0 -> ../../sdg
> lrwxrwxrwx 1 root root  9 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy11-lun-0 -> ../../sdh
> lrwxrwxrwx 1 root root  9 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy2-lun-0 -> ../../sda
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy2-lun-0-part1 -> ../../sda1
> lrwxrwxrwx 1 root root  9 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy3-lun-0 -> ../../sdb
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy3-lun-0-part1 -> ../../sdb1
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy3-lun-0-part2 -> ../../sdb2
> lrwxrwxrwx 1 root root  9 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy4-lun-0 -> ../../sdc
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy4-lun-0-part1 -> ../../sdc1
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy4-lun-0-part2 -> ../../sdc2
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy4-lun-0-part3 -> ../../sdc3
> lrwxrwxrwx 1 root root  9 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy5-lun-0 -> ../../sdd
> lrwxrwxrwx 1 root root  9 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy7-lun-0 -> ../../sde
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy7-lun-0-part1 -> ../../sde1
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy7-lun-0-part2 -> ../../sde2
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy7-lun-0-part3 -> ../../sde3
> lrwxrwxrwx 1 root root  9 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy8-lun-0 -> ../../sdf
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy8-lun-0-part1 -> ../../sdf1
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy8-lun-0-part2 -> ../../sdf2
> lrwxrwxrwx 1 root root 10 Feb 13 11:53 
> platform-HISI0162:01-sas-exp0x500e004aaa1f-phy8-lun-0-part3 -> ../../sdf3
> 
> Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
> Reported-by: dann frazier 

Thanks John. Solves the problem for me as well.

Tested-by: dann frazier 

  -dann

> Signed-off-by: John Garry 
> 
> diff --git a/drivers/scsi/libsas/sas_expander.c 
> b/drivers/scsi/libsas/sas_expander.c
> index 17eb4185f29d..f21c93bbb35c 100644
> --- a/drivers/scsi/libsas/sas_expander.c
> +++ b/drivers/scsi/libsas/sas_expander.c
> @@ -828,6 +828,7 @@ static struct domain_device *sas_ex_discover_end_dev(
>   rphy = sas_end_device_alloc(phy->port);
>   if (!rphy)
>   goto out_free;
> + rphy->identify.phy_identifier = phy_id;
>  
>   child->rphy = rphy;
>   get_device(>dev);
> @@ -854,6 +855,7 @@ static struct domain_device *sas_ex_discover_end_dev(
>  
>   child->rphy = rphy;
>   get_device(>dev);
> + rphy->identify.phy_identifier = phy_id;
>   sas_fill_in_rphy(child, rphy);
>  
>   list_add_tail(>disco_list_node, 
> >port->disco_list);

Re: [PATCH net-next] net: hns3: Config NIC port speed same as that of optical module

[dann frazier]

On Wed, Jan 02, 2019 at 08:45:36PM +0800, lipeng (Y) wrote:
> 
> 
> On 2019/1/1 9:22, dann frazier wrote:
> > On Mon, Nov 26, 2018 at 06:43:00PM +, Salil Mehta wrote:
> > > From: Peng Li 
> > > 
> > > Port 0/1 of HiP08 supports 10G and 25G. This patch adds a
> > > change to configure NIC port speed same as that of  optical
> > > module(SFP/QFSP). Driver gets the optical module speed and
> > > sets NIC port speed accordingly.
> > Hi,
> > 
> > I'm getting the following errors in dmesg about every 1s on a D06:
> > 
> > [  766.761823] hns3 :bd:00.0: get sfp speed failed -5
> > [  767.785823] hns3 :bd:00.0: get sfp speed failed -5
> > [  768.809820] hns3 :bd:00.0: get sfp speed failed -5
> > [  769.833818] hns3 :bd:00.0: get sfp speed failed -5
> > 
> > Reverting this patch fixes the issue.
> > 
> >   -dann
> Hi,dann,
> 
> Thanks for your test and report.
> 
> This patch needs to match new fireware verison ,
> And  it  does some work to  be Compatible with older versions.

I did upgrade to the latest available firmware (20181213-b20), but the
problem persisted. Maybe the necessary firmware is not yet released?

> Can you show me more information？
> can you  use "ethtool -i ethx" to get the fireware version ,
> and shows me  some other message about hns3?

Sure: 

$ sudo ethtool -i enp125s0f2
driver: hns3
version: 4.20.0+ SMP mod_unload aarch64
firmware-version: 0xb0311019
expansion-rom-version: 
bus-info: :7d:00.2
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

  -dann

Re: [PATCH net-next] net: hns3: Config NIC port speed same as that of optical module

[dann frazier]

On Mon, Nov 26, 2018 at 06:43:00PM +, Salil Mehta wrote:
> From: Peng Li 
> 
> Port 0/1 of HiP08 supports 10G and 25G. This patch adds a
> change to configure NIC port speed same as that of  optical
> module(SFP/QFSP). Driver gets the optical module speed and
> sets NIC port speed accordingly.

Hi,

I'm getting the following errors in dmesg about every 1s on a D06:

[  766.761823] hns3 :bd:00.0: get sfp speed failed -5
[  767.785823] hns3 :bd:00.0: get sfp speed failed -5
[  768.809820] hns3 :bd:00.0: get sfp speed failed -5
[  769.833818] hns3 :bd:00.0: get sfp speed failed -5

Reverting this patch fixes the issue.

 -dann

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Sat, Jul 14, 2018 at 5:21 AM dann frazier  wrote:
>
> On Thu, Jul 12, 2018 at 5:08 PM Theodore Y. Ts'o  wrote:
> >
> > >
> > > Review console log and on each run I have filesystem rebuild. The problem
> > > is that mke2fs I am using is 1.44.3-rc2. I am now reseting the environment
> > > and re-test.
> > >
> >
> > Could it be that you saw the error in ext4_validate_block_bitmap()?
>
> Looks like it. From Ike's report:
>
> # grep EXT4 d05-4-ipmi.log
> [ 26.215587] EXT4-fs (sdb2): mounted filesystem with ordered data
> mode. Opts: (null)
> [ 29.844105] EXT4-fs (sdb2): re-mounted. Opts: errors=remount-ro
> [ 3586.211348] EXT4-fs error (device sda2):
> ext4_validate_block_bitmap:383: comm stress-ng: bg 4705: bad block
> bitmap checksum
> [ 8254.776992] EXT4-fs error (device sda2):
> ext4_validate_block_bitmap:383: comm stress-ng: bg 4193: bad block
> bitmap checksum
>
> I've ran my test case for several days w/ just the inode bitmap fix
> and haven't been able to reproduce it - but perhaps that's just the
> nature of the chdir test.

hey Ted,

Turns out the stress-ng 'mknod' test and - less reliably - the
'dentry' test can tickle the "bad block bitmap checksum" bug pretty
easily. stress-ng wasn't *detecting* the error, but Colin has just
released a new version that does. We've been running with your updated
patch on 3 machines for several iterations, and have not seen another
occurrence.

  -dann

> > The patch which I sent Dann only fixed the problem for inode bitmaps;
> > I noticed today that we need to fix it for block allocation bitmaps as
> > well.
>
> I've also now ran several iterations w/ the block bitmap fix as well,
> and still no problems, so:
>
> Tested-by: dann frazier 
>
> > commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef
> > Author: Theodore Ts'o 
> > Date:   Thu Jul 12 19:08:05 2018 -0400
> >
> > ext4: check for allocation block validity with block group locked
> >
> > With commit 044e6e3d74a3: "ext4: don't update checksum of new
> > initialized bitmaps" the buffer valid bit will get set without
> > actually setting up the checksum for the allocation bitmap, since the
> > checksum will get calculated once we actually allocate an inode or
> > block.
> >
> > If we are doing this, then we need to (re-)check the verified bit
> > after we take the block group lock.  Otherwise, we could race with
> > another process reading and verifying the bitmap, which would then
> > complain about the checksum being invalid.
> >
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137
> >
> > Signed-off-by: Theodore Ts'o 
> > Cc: sta...@kernel.org
>
> Would it also make sense to add the following?
>
> Fixes: 044e6e3d74a3 ("ext4: don't update checksum of new initialized bitmaps")
>
>   -dann
>
> > diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> > index e68cefe08261..aa52d87985aa 100644
> > --- a/fs/ext4/balloc.c
> > +++ b/fs/ext4/balloc.c
> > @@ -368,6 +368,8 @@ static int ext4_validate_block_bitmap(struct 
> > super_block *sb,
> > return -EFSCORRUPTED;
> >
> > ext4_lock_group(sb, block_group);
> > +   if (buffer_verified(bh))
> > +   goto verified;
> > if (unlikely(!ext4_block_bitmap_csum_verify(sb, block_group,
> > desc, bh))) {
> > ext4_unlock_group(sb, block_group);
> > @@ -386,6 +388,7 @@ static int ext4_validate_block_bitmap(struct 
> > super_block *sb,
> > return -EFSCORRUPTED;
> > }
> > set_buffer_verified(bh);
> > +verified:
> > ext4_unlock_group(sb, block_group);
> > return 0;
> >  }
> > diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> > index fb83750c1a14..e9d8e2667ab5 100644
> > --- a/fs/ext4/ialloc.c
> > +++ b/fs/ext4/ialloc.c
> > @@ -90,6 +90,8 @@ static int ext4_validate_inode_bitmap(struct super_block 
> > *sb,
> > return -EFSCORRUPTED;
> >
> > ext4_lock_group(sb, block_group);
> > +   if (buffer_verified(bh))
> > +   goto verified;
> > blk = ext4_inode_bitmap(sb, desc);
> > if (!ext4_inode_bitmap_csum_verify(sb, block_group, desc, bh,
> >EXT4_INODES_PER_GROUP(sb) / 8)) {
> > @@ -101,6 +103,7 @@ static int ext4_validate_inode_bitmap(struct 
> > super_block *sb,
> > return -EFSBADCRC;
> > }
> > set_buffer_verified(bh);
> > +verified:
> > ext4_unlock_group(sb, block_group);
> > return 0;
> >  }

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Sat, Jul 14, 2018 at 5:21 AM dann frazier  wrote:
>
> On Thu, Jul 12, 2018 at 5:08 PM Theodore Y. Ts'o  wrote:
> >
> > >
> > > Review console log and on each run I have filesystem rebuild. The problem
> > > is that mke2fs I am using is 1.44.3-rc2. I am now reseting the environment
> > > and re-test.
> > >
> >
> > Could it be that you saw the error in ext4_validate_block_bitmap()?
>
> Looks like it. From Ike's report:
>
> # grep EXT4 d05-4-ipmi.log
> [ 26.215587] EXT4-fs (sdb2): mounted filesystem with ordered data
> mode. Opts: (null)
> [ 29.844105] EXT4-fs (sdb2): re-mounted. Opts: errors=remount-ro
> [ 3586.211348] EXT4-fs error (device sda2):
> ext4_validate_block_bitmap:383: comm stress-ng: bg 4705: bad block
> bitmap checksum
> [ 8254.776992] EXT4-fs error (device sda2):
> ext4_validate_block_bitmap:383: comm stress-ng: bg 4193: bad block
> bitmap checksum
>
> I've ran my test case for several days w/ just the inode bitmap fix
> and haven't been able to reproduce it - but perhaps that's just the
> nature of the chdir test.

hey Ted,

Turns out the stress-ng 'mknod' test and - less reliably - the
'dentry' test can tickle the "bad block bitmap checksum" bug pretty
easily. stress-ng wasn't *detecting* the error, but Colin has just
released a new version that does. We've been running with your updated
patch on 3 machines for several iterations, and have not seen another
occurrence.

  -dann

> > The patch which I sent Dann only fixed the problem for inode bitmaps;
> > I noticed today that we need to fix it for block allocation bitmaps as
> > well.
>
> I've also now ran several iterations w/ the block bitmap fix as well,
> and still no problems, so:
>
> Tested-by: dann frazier 
>
> > commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef
> > Author: Theodore Ts'o 
> > Date:   Thu Jul 12 19:08:05 2018 -0400
> >
> > ext4: check for allocation block validity with block group locked
> >
> > With commit 044e6e3d74a3: "ext4: don't update checksum of new
> > initialized bitmaps" the buffer valid bit will get set without
> > actually setting up the checksum for the allocation bitmap, since the
> > checksum will get calculated once we actually allocate an inode or
> > block.
> >
> > If we are doing this, then we need to (re-)check the verified bit
> > after we take the block group lock.  Otherwise, we could race with
> > another process reading and verifying the bitmap, which would then
> > complain about the checksum being invalid.
> >
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137
> >
> > Signed-off-by: Theodore Ts'o 
> > Cc: sta...@kernel.org
>
> Would it also make sense to add the following?
>
> Fixes: 044e6e3d74a3 ("ext4: don't update checksum of new initialized bitmaps")
>
>   -dann
>
> > diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> > index e68cefe08261..aa52d87985aa 100644
> > --- a/fs/ext4/balloc.c
> > +++ b/fs/ext4/balloc.c
> > @@ -368,6 +368,8 @@ static int ext4_validate_block_bitmap(struct 
> > super_block *sb,
> > return -EFSCORRUPTED;
> >
> > ext4_lock_group(sb, block_group);
> > +   if (buffer_verified(bh))
> > +   goto verified;
> > if (unlikely(!ext4_block_bitmap_csum_verify(sb, block_group,
> > desc, bh))) {
> > ext4_unlock_group(sb, block_group);
> > @@ -386,6 +388,7 @@ static int ext4_validate_block_bitmap(struct 
> > super_block *sb,
> > return -EFSCORRUPTED;
> > }
> > set_buffer_verified(bh);
> > +verified:
> > ext4_unlock_group(sb, block_group);
> > return 0;
> >  }
> > diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> > index fb83750c1a14..e9d8e2667ab5 100644
> > --- a/fs/ext4/ialloc.c
> > +++ b/fs/ext4/ialloc.c
> > @@ -90,6 +90,8 @@ static int ext4_validate_inode_bitmap(struct super_block 
> > *sb,
> > return -EFSCORRUPTED;
> >
> > ext4_lock_group(sb, block_group);
> > +   if (buffer_verified(bh))
> > +   goto verified;
> > blk = ext4_inode_bitmap(sb, desc);
> > if (!ext4_inode_bitmap_csum_verify(sb, block_group, desc, bh,
> >EXT4_INODES_PER_GROUP(sb) / 8)) {
> > @@ -101,6 +103,7 @@ static int ext4_validate_inode_bitmap(struct 
> > super_block *sb,
> > return -EFSBADCRC;
> > }
> > set_buffer_verified(bh);
> > +verified:
> > ext4_unlock_group(sb, block_group);
> > return 0;
> >  }

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Thu, Jul 12, 2018 at 5:08 PM Theodore Y. Ts'o  wrote:
>
> >
> > Review console log and on each run I have filesystem rebuild. The problem
> > is that mke2fs I am using is 1.44.3-rc2. I am now reseting the environment
> > and re-test.
> >
>
> Could it be that you saw the error in ext4_validate_block_bitmap()?

Looks like it. From Ike's report:

# grep EXT4 d05-4-ipmi.log
[ 26.215587] EXT4-fs (sdb2): mounted filesystem with ordered data
mode. Opts: (null)
[ 29.844105] EXT4-fs (sdb2): re-mounted. Opts: errors=remount-ro
[ 3586.211348] EXT4-fs error (device sda2):
ext4_validate_block_bitmap:383: comm stress-ng: bg 4705: bad block
bitmap checksum
[ 8254.776992] EXT4-fs error (device sda2):
ext4_validate_block_bitmap:383: comm stress-ng: bg 4193: bad block
bitmap checksum

I've ran my test case for several days w/ just the inode bitmap fix
and haven't been able to reproduce it - but perhaps that's just the
nature of the chdir test.

> The patch which I sent Dann only fixed the problem for inode bitmaps;
> I noticed today that we need to fix it for block allocation bitmaps as
> well.

I've also now ran several iterations w/ the block bitmap fix as well,
and still no problems, so:

Tested-by: dann frazier 

> commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef
> Author: Theodore Ts'o 
> Date:   Thu Jul 12 19:08:05 2018 -0400
>
> ext4: check for allocation block validity with block group locked
>
> With commit 044e6e3d74a3: "ext4: don't update checksum of new
> initialized bitmaps" the buffer valid bit will get set without
> actually setting up the checksum for the allocation bitmap, since the
> checksum will get calculated once we actually allocate an inode or
> block.
>
> If we are doing this, then we need to (re-)check the verified bit
> after we take the block group lock.  Otherwise, we could race with
> another process reading and verifying the bitmap, which would then
> complain about the checksum being invalid.
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137
>
> Signed-off-by: Theodore Ts'o 
> Cc: sta...@kernel.org

Would it also make sense to add the following?

Fixes: 044e6e3d74a3 ("ext4: don't update checksum of new initialized bitmaps")

  -dann

> diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> index e68cefe08261..aa52d87985aa 100644
> --- a/fs/ext4/balloc.c
> +++ b/fs/ext4/balloc.c
> @@ -368,6 +368,8 @@ static int ext4_validate_block_bitmap(struct super_block 
> *sb,
> return -EFSCORRUPTED;
>
> ext4_lock_group(sb, block_group);
> +   if (buffer_verified(bh))
> +   goto verified;
> if (unlikely(!ext4_block_bitmap_csum_verify(sb, block_group,
> desc, bh))) {
> ext4_unlock_group(sb, block_group);
> @@ -386,6 +388,7 @@ static int ext4_validate_block_bitmap(struct super_block 
> *sb,
> return -EFSCORRUPTED;
> }
> set_buffer_verified(bh);
> +verified:
> ext4_unlock_group(sb, block_group);
> return 0;
>  }
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index fb83750c1a14..e9d8e2667ab5 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -90,6 +90,8 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
> return -EFSCORRUPTED;
>
> ext4_lock_group(sb, block_group);
> +   if (buffer_verified(bh))
> +   goto verified;
> blk = ext4_inode_bitmap(sb, desc);
> if (!ext4_inode_bitmap_csum_verify(sb, block_group, desc, bh,
>EXT4_INODES_PER_GROUP(sb) / 8)) {
> @@ -101,6 +103,7 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
> return -EFSBADCRC;
> }
> set_buffer_verified(bh);
> +verified:
> ext4_unlock_group(sb, block_group);
> return 0;
>  }

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Thu, Jul 12, 2018 at 5:08 PM Theodore Y. Ts'o  wrote:
>
> >
> > Review console log and on each run I have filesystem rebuild. The problem
> > is that mke2fs I am using is 1.44.3-rc2. I am now reseting the environment
> > and re-test.
> >
>
> Could it be that you saw the error in ext4_validate_block_bitmap()?

Looks like it. From Ike's report:

# grep EXT4 d05-4-ipmi.log
[ 26.215587] EXT4-fs (sdb2): mounted filesystem with ordered data
mode. Opts: (null)
[ 29.844105] EXT4-fs (sdb2): re-mounted. Opts: errors=remount-ro
[ 3586.211348] EXT4-fs error (device sda2):
ext4_validate_block_bitmap:383: comm stress-ng: bg 4705: bad block
bitmap checksum
[ 8254.776992] EXT4-fs error (device sda2):
ext4_validate_block_bitmap:383: comm stress-ng: bg 4193: bad block
bitmap checksum

I've ran my test case for several days w/ just the inode bitmap fix
and haven't been able to reproduce it - but perhaps that's just the
nature of the chdir test.

> The patch which I sent Dann only fixed the problem for inode bitmaps;
> I noticed today that we need to fix it for block allocation bitmaps as
> well.

I've also now ran several iterations w/ the block bitmap fix as well,
and still no problems, so:

Tested-by: dann frazier 

> commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef
> Author: Theodore Ts'o 
> Date:   Thu Jul 12 19:08:05 2018 -0400
>
> ext4: check for allocation block validity with block group locked
>
> With commit 044e6e3d74a3: "ext4: don't update checksum of new
> initialized bitmaps" the buffer valid bit will get set without
> actually setting up the checksum for the allocation bitmap, since the
> checksum will get calculated once we actually allocate an inode or
> block.
>
> If we are doing this, then we need to (re-)check the verified bit
> after we take the block group lock.  Otherwise, we could race with
> another process reading and verifying the bitmap, which would then
> complain about the checksum being invalid.
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137
>
> Signed-off-by: Theodore Ts'o 
> Cc: sta...@kernel.org

Would it also make sense to add the following?

Fixes: 044e6e3d74a3 ("ext4: don't update checksum of new initialized bitmaps")

  -dann

> diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> index e68cefe08261..aa52d87985aa 100644
> --- a/fs/ext4/balloc.c
> +++ b/fs/ext4/balloc.c
> @@ -368,6 +368,8 @@ static int ext4_validate_block_bitmap(struct super_block 
> *sb,
> return -EFSCORRUPTED;
>
> ext4_lock_group(sb, block_group);
> +   if (buffer_verified(bh))
> +   goto verified;
> if (unlikely(!ext4_block_bitmap_csum_verify(sb, block_group,
> desc, bh))) {
> ext4_unlock_group(sb, block_group);
> @@ -386,6 +388,7 @@ static int ext4_validate_block_bitmap(struct super_block 
> *sb,
> return -EFSCORRUPTED;
> }
> set_buffer_verified(bh);
> +verified:
> ext4_unlock_group(sb, block_group);
> return 0;
>  }
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index fb83750c1a14..e9d8e2667ab5 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -90,6 +90,8 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
> return -EFSCORRUPTED;
>
> ext4_lock_group(sb, block_group);
> +   if (buffer_verified(bh))
> +   goto verified;
> blk = ext4_inode_bitmap(sb, desc);
> if (!ext4_inode_bitmap_csum_verify(sb, block_group, desc, bh,
>EXT4_INODES_PER_GROUP(sb) / 8)) {
> @@ -101,6 +103,7 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
> return -EFSBADCRC;
> }
> set_buffer_verified(bh);
> +verified:
> ext4_unlock_group(sb, block_group);
> return 0;
>  }

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Tue, Jul 10, 2018 at 10:51:43AM -0600, dann frazier wrote:
> On Sat, Jul 07, 2018 at 12:10:18AM -0400, Theodore Y. Ts'o wrote:
> > On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote:
> > > Hi,
> > >   We're seeing a regression triggered by the stress-ng[*] "chdir" test
> > > that I've bisected to:
> > > 
> > > 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps
> > > 
> > > So far we've only seen failures on servers based on HiSilicon's family
> > > of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these systems it is
> > > very reproducible.
> > 
> > Thanks for the report.  Can you verify whether or not this patch fixes
> > things for you?
> 
> hey Ted,
>   Sorry for the delayed response - was afk for a long weekend.
> Your patch does seem to fix the issue for me - after applying the
> patch, I was able to survive 20 iterations (and counting), where
> previously it would always fail the first time.
> 
> However, I've received a conflicting report from a colleague who
> appears to still be seeing errors. I'll get back to you ASAP once I am
> able to (in-?)validate that observation.

OK - I believe I found an explanation for my colleague's continued
test failures after applying the patch. The filesystem being used may
have already been corrupted from a previous run, and the test w/ your
patch just tripped over it. Details are here starting in comment #9 if
you'd like to look them over:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137

  -dann

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Tue, Jul 10, 2018 at 10:51:43AM -0600, dann frazier wrote:
> On Sat, Jul 07, 2018 at 12:10:18AM -0400, Theodore Y. Ts'o wrote:
> > On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote:
> > > Hi,
> > >   We're seeing a regression triggered by the stress-ng[*] "chdir" test
> > > that I've bisected to:
> > > 
> > > 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps
> > > 
> > > So far we've only seen failures on servers based on HiSilicon's family
> > > of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these systems it is
> > > very reproducible.
> > 
> > Thanks for the report.  Can you verify whether or not this patch fixes
> > things for you?
> 
> hey Ted,
>   Sorry for the delayed response - was afk for a long weekend.
> Your patch does seem to fix the issue for me - after applying the
> patch, I was able to survive 20 iterations (and counting), where
> previously it would always fail the first time.
> 
> However, I've received a conflicting report from a colleague who
> appears to still be seeing errors. I'll get back to you ASAP once I am
> able to (in-?)validate that observation.

OK - I believe I found an explanation for my colleague's continued
test failures after applying the patch. The filesystem being used may
have already been corrupted from a previous run, and the test w/ your
patch just tripped over it. Details are here starting in comment #9 if
you'd like to look them over:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137

  -dann

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Sat, Jul 07, 2018 at 12:10:18AM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote:
> > Hi,
> >   We're seeing a regression triggered by the stress-ng[*] "chdir" test
> > that I've bisected to:
> > 
> > 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps
> > 
> > So far we've only seen failures on servers based on HiSilicon's family
> > of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these systems it is
> > very reproducible.
> 
> Thanks for the report.  Can you verify whether or not this patch fixes
> things for you?

hey Ted,
  Sorry for the delayed response - was afk for a long weekend.
Your patch does seem to fix the issue for me - after applying the
patch, I was able to survive 20 iterations (and counting), where
previously it would always fail the first time.

However, I've received a conflicting report from a colleague who
appears to still be seeing errors. I'll get back to you ASAP once I am
able to (in-?)validate that observation.

  -dann

>   - Ted
> 
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index da6c10c1e37a..1cfb74bc4dca 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -90,6 +90,8 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
>   return -EFSCORRUPTED;
>  
>   ext4_lock_group(sb, block_group);
> + if (buffer_verified(bh))
> + goto verified;
>   blk = ext4_inode_bitmap(sb, desc);
>   if (!ext4_inode_bitmap_csum_verify(sb, block_group, desc, bh,
>  EXT4_INODES_PER_GROUP(sb) / 8)) {
> @@ -101,6 +103,7 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
>   return -EFSBADCRC;
>   }
>   set_buffer_verified(bh);
> +verified:
>   ext4_unlock_group(sb, block_group);
>   return 0;
>  }

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Sat, Jul 07, 2018 at 12:10:18AM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote:
> > Hi,
> >   We're seeing a regression triggered by the stress-ng[*] "chdir" test
> > that I've bisected to:
> > 
> > 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps
> > 
> > So far we've only seen failures on servers based on HiSilicon's family
> > of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these systems it is
> > very reproducible.
> 
> Thanks for the report.  Can you verify whether or not this patch fixes
> things for you?

hey Ted,
  Sorry for the delayed response - was afk for a long weekend.
Your patch does seem to fix the issue for me - after applying the
patch, I was able to survive 20 iterations (and counting), where
previously it would always fail the first time.

However, I've received a conflicting report from a colleague who
appears to still be seeing errors. I'll get back to you ASAP once I am
able to (in-?)validate that observation.

  -dann

>   - Ted
> 
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index da6c10c1e37a..1cfb74bc4dca 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -90,6 +90,8 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
>   return -EFSCORRUPTED;
>  
>   ext4_lock_group(sb, block_group);
> + if (buffer_verified(bh))
> + goto verified;
>   blk = ext4_inode_bitmap(sb, desc);
>   if (!ext4_inode_bitmap_csum_verify(sb, block_group, desc, bh,
>  EXT4_INODES_PER_GROUP(sb) / 8)) {
> @@ -101,6 +103,7 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
>   return -EFSBADCRC;
>   }
>   set_buffer_verified(bh);
> +verified:
>   ext4_unlock_group(sb, block_group);
>   return 0;
>  }

[Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

Hi,
  We're seeing a regression triggered by the stress-ng[*] "chdir" test
that I've bisected to:

044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps

So far we've only seen failures on servers based on HiSilicon's family
of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these systems it is
very reproducible.

= Test Case =
#!/bin/sh
umount /tmp/mnt || /bin/true
mkdir -p /tmp/mnt
mkfs.ext4 -F /dev/sda1
mount /dev/sda1 /tmp/mnt
# Running directly under /tmp/mnt doesn't trigger the issue, we need
# this subdirectory for some reason
dir="/tmp/mnt/tmp/disk_stress_ng_f70f0f26-b332-4c48-9e07-67c529770e3d"
mkdir -p "$dir"
stress-ng --aggressive --verify --timeout 240 --temp-path "$dir" \
  --chdir 0 --hdd-opts dsync --readahead-bytes 16M -k

= Result =
[70586.263840] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[70586.637085] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:98: comm 
stress-ng: Corrupt inode bitmap - block_group = 43936, inode_bitmap = 1439694864
[70602.296551] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:98: comm 
stress-ng: Corrupt inode bitmap - block_group = 48896, inode_bitmap = 1602224144
[70602.409291] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:98: comm 
stress-ng: Corrupt inode bitmap - block_group = 48928, inode_bitmap = 1603272720

Full dmesg:
  
http://people.canonical.com/~dannf/d05-stress-ng/d05-sas-chdir-4.18.0-rc3+.dmesg

[*] http://kernel.ubuntu.com/~cking/stress-ng/

[Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

Hi,
  We're seeing a regression triggered by the stress-ng[*] "chdir" test
that I've bisected to:

044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps

So far we've only seen failures on servers based on HiSilicon's family
of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these systems it is
very reproducible.

= Test Case =
#!/bin/sh
umount /tmp/mnt || /bin/true
mkdir -p /tmp/mnt
mkfs.ext4 -F /dev/sda1
mount /dev/sda1 /tmp/mnt
# Running directly under /tmp/mnt doesn't trigger the issue, we need
# this subdirectory for some reason
dir="/tmp/mnt/tmp/disk_stress_ng_f70f0f26-b332-4c48-9e07-67c529770e3d"
mkdir -p "$dir"
stress-ng --aggressive --verify --timeout 240 --temp-path "$dir" \
  --chdir 0 --hdd-opts dsync --readahead-bytes 16M -k

= Result =
[70586.263840] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[70586.637085] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:98: comm 
stress-ng: Corrupt inode bitmap - block_group = 43936, inode_bitmap = 1439694864
[70602.296551] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:98: comm 
stress-ng: Corrupt inode bitmap - block_group = 48896, inode_bitmap = 1602224144
[70602.409291] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:98: comm 
stress-ng: Corrupt inode bitmap - block_group = 48928, inode_bitmap = 1603272720

Full dmesg:
  
http://people.canonical.com/~dannf/d05-stress-ng/d05-sas-chdir-4.18.0-rc3+.dmesg

[*] http://kernel.ubuntu.com/~cking/stress-ng/

[PATCH] net: hns: Avoid action name truncation

[dann frazier]

When longer interface names are used, the action names exposed in
/proc/interrupts and /proc/irq/* maybe truncated. For example, when
using the predictable name algorithm in systemd on a HiSilicon D05,
I see:

  ubuntu@d05-3:~$  grep enahisic2i0-tx /proc/interrupts | sed 's/.* //'
  enahisic2i0-tx0
  enahisic2i0-tx1
  [...]
  enahisic2i0-tx8
  enahisic2i0-tx9
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1

Increase the max ring name length to allow for an interface name
of IFNAMSIZE. After this change, I now see:

  $ grep enahisic2i0-tx /proc/interrupts | sed 's/.* //'
  enahisic2i0-tx0
  enahisic2i0-tx1
  enahisic2i0-tx2
  [...]
  enahisic2i0-tx8
  enahisic2i0-tx9
  enahisic2i0-tx10
  enahisic2i0-tx11
  enahisic2i0-tx12
  enahisic2i0-tx13
  enahisic2i0-tx14
  enahisic2i0-tx15

Signed-off-by: dann frazier <dann.fraz...@canonical.com>
---
 drivers/net/ethernet/hisilicon/hns/hnae.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index 3e62692af011..fa5b30f547f6 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -87,7 +87,7 @@ do { \
 
 #define HNAE_AE_REGISTER 0x1
 
-#define RCB_RING_NAME_LEN 16
+#define RCB_RING_NAME_LEN (IFNAMSIZ + 4)
 
 #define HNAE_LOWEST_LATENCY_COAL_PARAM 30
 #define HNAE_LOW_LATENCY_COAL_PARAM80
-- 
2.17.0

[PATCH] net: hns: Avoid action name truncation

[dann frazier]

When longer interface names are used, the action names exposed in
/proc/interrupts and /proc/irq/* maybe truncated. For example, when
using the predictable name algorithm in systemd on a HiSilicon D05,
I see:

  ubuntu@d05-3:~$  grep enahisic2i0-tx /proc/interrupts | sed 's/.* //'
  enahisic2i0-tx0
  enahisic2i0-tx1
  [...]
  enahisic2i0-tx8
  enahisic2i0-tx9
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1

Increase the max ring name length to allow for an interface name
of IFNAMSIZE. After this change, I now see:

  $ grep enahisic2i0-tx /proc/interrupts | sed 's/.* //'
  enahisic2i0-tx0
  enahisic2i0-tx1
  enahisic2i0-tx2
  [...]
  enahisic2i0-tx8
  enahisic2i0-tx9
  enahisic2i0-tx10
  enahisic2i0-tx11
  enahisic2i0-tx12
  enahisic2i0-tx13
  enahisic2i0-tx14
  enahisic2i0-tx15

Signed-off-by: dann frazier 
---
 drivers/net/ethernet/hisilicon/hns/hnae.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index 3e62692af011..fa5b30f547f6 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -87,7 +87,7 @@ do { \
 
 #define HNAE_AE_REGISTER 0x1
 
-#define RCB_RING_NAME_LEN 16
+#define RCB_RING_NAME_LEN (IFNAMSIZ + 4)
 
 #define HNAE_LOWEST_LATENCY_COAL_PARAM 30
 #define HNAE_LOW_LATENCY_COAL_PARAM80
-- 
2.17.0

Re: [PATCH 1/4] i2c: xlp9xx: return ENXIO on slave address NACK

[dann frazier]

On Tue, Jan 30, 2018 at 7:28 AM, George Cherian
<gcher...@caviumnetworks.com> wrote:
> Gentle Ping on this series.

I've been using these on a few Cavium Sabre boards, which previously
had an unusable system interface (/dev/ipmi) due to timeouts or just
enumerations failures. So, fwiw:

Tested-by: dann frazier <dann.fraz...@canonical.com>

 -dann

> On 01/18/2018 11:09 AM, George Cherian wrote:
>>
>> From: Dmitry Bazhenov <dmitry.bazhe...@auriga.com>
>>
>> Fix the driver violation of the common practice to return
>> ENXIO error on a slave address NACK.
>>
>> Signed-off-by: Dmitry Bazhenov <dmitry.bazhe...@auriga.com>
>> Signed-off-by: George Cherian <george.cher...@cavium.com>
>> ---
>>   drivers/i2c/busses/i2c-xlp9xx.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-xlp9xx.c
>> b/drivers/i2c/busses/i2c-xlp9xx.c
>> index b970bf8..6d78cdc 100644
>> --- a/drivers/i2c/busses/i2c-xlp9xx.c
>> +++ b/drivers/i2c/busses/i2c-xlp9xx.c
>> @@ -324,7 +324,8 @@ static int xlp9xx_i2c_xfer_msg(struct xlp9xx_i2c_dev
>> *priv, struct i2c_msg *msg,
>> dev_dbg(priv->dev, "transfer error %x!\n", priv->msg_err);
>> if (priv->msg_err & XLP9XX_I2C_INTEN_BUSERR)
>> xlp9xx_i2c_init(priv);
>> -   return -EIO;
>> +   return (priv->msg_err & XLP9XX_I2C_INTEN_NACKADDR) ?
>> +   -ENXIO : -EIO;
>> }
>> if (timeleft == 0) {
>>
>
> Regards
> -George

Re: [PATCH 1/4] i2c: xlp9xx: return ENXIO on slave address NACK

[dann frazier]

On Tue, Jan 30, 2018 at 7:28 AM, George Cherian
 wrote:
> Gentle Ping on this series.

I've been using these on a few Cavium Sabre boards, which previously
had an unusable system interface (/dev/ipmi) due to timeouts or just
enumerations failures. So, fwiw:

Tested-by: dann frazier 

 -dann

> On 01/18/2018 11:09 AM, George Cherian wrote:
>>
>> From: Dmitry Bazhenov 
>>
>> Fix the driver violation of the common practice to return
>> ENXIO error on a slave address NACK.
>>
>> Signed-off-by: Dmitry Bazhenov 
>> Signed-off-by: George Cherian 
>> ---
>>   drivers/i2c/busses/i2c-xlp9xx.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-xlp9xx.c
>> b/drivers/i2c/busses/i2c-xlp9xx.c
>> index b970bf8..6d78cdc 100644
>> --- a/drivers/i2c/busses/i2c-xlp9xx.c
>> +++ b/drivers/i2c/busses/i2c-xlp9xx.c
>> @@ -324,7 +324,8 @@ static int xlp9xx_i2c_xfer_msg(struct xlp9xx_i2c_dev
>> *priv, struct i2c_msg *msg,
>> dev_dbg(priv->dev, "transfer error %x!\n", priv->msg_err);
>> if (priv->msg_err & XLP9XX_I2C_INTEN_BUSERR)
>> xlp9xx_i2c_init(priv);
>> -   return -EIO;
>> +   return (priv->msg_err & XLP9XX_I2C_INTEN_NACKADDR) ?
>> +   -ENXIO : -EIO;
>> }
>> if (timeleft == 0) {
>>
>
> Regards
> -George

Re: [PATCH v14 0/9] LPC: legacy ISA I/O support

[dann frazier]

  MAINTAINERS|   7 +
>  drivers/acpi/pci_root.c|   8 +-
>  drivers/acpi/scan.c|  14 +
>  drivers/bus/Kconfig|   8 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 646 
> +
>  drivers/of/address.c   |  96 ++-
>  drivers/pci/pci.c  |  95 +--
>  include/asm-generic/io.h   |   4 +-
>  include/linux/logic_pio.h  | 131 +
>  include/linux/pci.h|   3 +-
>  lib/Kconfig|  15 +
>  lib/Makefile   |   2 +
>  lib/logic_pio.c| 285 +
>  15 files changed, 1250 insertions(+), 98 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c

Tested this version on a D05 board, no problems. So, for the series:

Tested-by: dann frazier <dann.fraz...@canonical.com>

Re: [PATCH v14 0/9] LPC: legacy ISA I/O support

[dann frazier]

  MAINTAINERS|   7 +
>  drivers/acpi/pci_root.c|   8 +-
>  drivers/acpi/scan.c|  14 +
>  drivers/bus/Kconfig|   8 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 646 
> +
>  drivers/of/address.c   |  96 ++-
>  drivers/pci/pci.c  |  95 +--
>  include/asm-generic/io.h   |   4 +-
>  include/linux/logic_pio.h  | 131 +
>  include/linux/pci.h|   3 +-
>  lib/Kconfig|  15 +
>  lib/Makefile   |   2 +
>  lib/logic_pio.c| 285 +
>  15 files changed, 1250 insertions(+), 98 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c

Tested this version on a D05 board, no problems. So, for the series:

Tested-by: dann frazier 

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Wed, Feb 14, 2018 at 8:42 AM, John Garry <john.ga...@huawei.com> wrote:
> On 13/02/2018 22:57, dann frazier wrote:
>>
>> On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote:
>>>
>>> From: Zhichang Yuan <yuanzhich...@hisilicon.com>
>>>
>>> After introducing the new generic I/O space management in logic pio, the
>>> original PCI MMIO relevant helpers need to be updated based on the new
>>> interfaces.
>>> This patch adapts the corresponding code to match the changes introduced
>>> by logic pio.
>>>
>>> Signed-off-by: Zhichang Yuan <yuanzhich...@hisilicon.com>
>>> Signed-off-by: Gabriele Paoloni <gabriele.paol...@huawei.com>
>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>#earlier draft
>>> Acked-by: Bjorn Helgaas <bhelg...@google.com>
>>
>>
>> I saw that Bjorn Acked this back in v6, but it seems like the code in
>> pci.c was reworked a bit for v7 onwards and I didn't see a follow-up
>> review (apologies if I just missed it). In which case, maybe his Ack
>> should have the "#earlier draft" tag as well?
>>
>
> Hi Dann,
>
> I see Bjorn acked again later on in the series, here:
> https://lkml.org/lkml/2017/5/26/612

Yep, you're right, sorry for missing that :)

>
>>> ---
>>>  drivers/pci/pci.c| 95
>>> +---
>>>  include/asm-generic/io.h |  2 +-
>>>  2 files changed, 18 insertions(+), 79 deletions(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index 07290a3..8aa5c54 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -22,6 +22,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -3440,17 +3441,6 @@ int pci_request_regions_exclusive(struct pci_dev
>>> *pdev, const char *res_name)
>>>  }
>>>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>>>
>>> -#ifdef PCI_IOBASE
>>> -struct io_range {
>>> -   struct list_head list;
>>> -   phys_addr_t start;
>>> -   resource_size_t size;
>>> -};
>>> -
>>> -static LIST_HEAD(io_range_list);
>>> -static DEFINE_SPINLOCK(io_range_lock);
>>> -#endif
>>> -
>>>  /*
>>>   * Record the PCI IO range (expressed as CPU physical address + size).
>>>   * Return a negative value if an error has occured, zero otherwise
>>> @@ -3458,51 +3448,28 @@ struct io_range {
>>>  int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t
>>> addr,
>>> resource_size_t size)
>>>  {
>>> -   int err = 0;
>>> -
>>> +   int ret = 0;
>>>  #ifdef PCI_IOBASE
>>> -   struct io_range *range;
>>> -   resource_size_t allocated_size = 0;
>>> -
>>> -   /* check if the range hasn't been previously recorded */
>>> -   spin_lock(_range_lock);
>>> -   list_for_each_entry(range, _range_list, list) {
>>> -   if (addr >= range->start && addr + size <= range->start +
>>> size) {
>>> -   /* range already registered, bail out */
>>> -   goto end_register;
>>> -   }
>>> -   allocated_size += range->size;
>>> -   }
>>> +   struct logic_pio_hwaddr *range;
>>>
>>> -   /* range not registed yet, check for available space */
>>> -   if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
>>> -   /* if it's too big check if 64K space can be reserved */
>>> -   if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
>>> -   err = -E2BIG;
>>> -   goto end_register;
>>> -   }
>>> -
>>> -   size = SZ_64K;
>>> -   pr_warn("Requested IO range too big, new size set to
>>> 64K\n");
>>> -   }
>>> +   if (!size || addr + size < addr)
>>> +   return -EINVAL;
>>>
>>> -   /* add the range to the list */
>>> range = kzalloc(sizeof(*range), GFP_ATOMIC);
>>> -   if (!range) {
>>> -   err = -ENOMEM;
>>> -   goto end_register;
>>> -   }
>>> +   if (!range)
>>

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Wed, Feb 14, 2018 at 8:42 AM, John Garry  wrote:
> On 13/02/2018 22:57, dann frazier wrote:
>>
>> On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote:
>>>
>>> From: Zhichang Yuan 
>>>
>>> After introducing the new generic I/O space management in logic pio, the
>>> original PCI MMIO relevant helpers need to be updated based on the new
>>> interfaces.
>>> This patch adapts the corresponding code to match the changes introduced
>>> by logic pio.
>>>
>>> Signed-off-by: Zhichang Yuan 
>>> Signed-off-by: Gabriele Paoloni 
>>> Signed-off-by: Arnd Bergmann #earlier draft
>>> Acked-by: Bjorn Helgaas 
>>
>>
>> I saw that Bjorn Acked this back in v6, but it seems like the code in
>> pci.c was reworked a bit for v7 onwards and I didn't see a follow-up
>> review (apologies if I just missed it). In which case, maybe his Ack
>> should have the "#earlier draft" tag as well?
>>
>
> Hi Dann,
>
> I see Bjorn acked again later on in the series, here:
> https://lkml.org/lkml/2017/5/26/612

Yep, you're right, sorry for missing that :)

>
>>> ---
>>>  drivers/pci/pci.c| 95
>>> +---
>>>  include/asm-generic/io.h |  2 +-
>>>  2 files changed, 18 insertions(+), 79 deletions(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index 07290a3..8aa5c54 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -22,6 +22,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -3440,17 +3441,6 @@ int pci_request_regions_exclusive(struct pci_dev
>>> *pdev, const char *res_name)
>>>  }
>>>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>>>
>>> -#ifdef PCI_IOBASE
>>> -struct io_range {
>>> -   struct list_head list;
>>> -   phys_addr_t start;
>>> -   resource_size_t size;
>>> -};
>>> -
>>> -static LIST_HEAD(io_range_list);
>>> -static DEFINE_SPINLOCK(io_range_lock);
>>> -#endif
>>> -
>>>  /*
>>>   * Record the PCI IO range (expressed as CPU physical address + size).
>>>   * Return a negative value if an error has occured, zero otherwise
>>> @@ -3458,51 +3448,28 @@ struct io_range {
>>>  int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t
>>> addr,
>>> resource_size_t size)
>>>  {
>>> -   int err = 0;
>>> -
>>> +   int ret = 0;
>>>  #ifdef PCI_IOBASE
>>> -   struct io_range *range;
>>> -   resource_size_t allocated_size = 0;
>>> -
>>> -   /* check if the range hasn't been previously recorded */
>>> -   spin_lock(_range_lock);
>>> -   list_for_each_entry(range, _range_list, list) {
>>> -   if (addr >= range->start && addr + size <= range->start +
>>> size) {
>>> -   /* range already registered, bail out */
>>> -   goto end_register;
>>> -   }
>>> -   allocated_size += range->size;
>>> -   }
>>> +   struct logic_pio_hwaddr *range;
>>>
>>> -   /* range not registed yet, check for available space */
>>> -   if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
>>> -   /* if it's too big check if 64K space can be reserved */
>>> -   if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
>>> -   err = -E2BIG;
>>> -   goto end_register;
>>> -   }
>>> -
>>> -   size = SZ_64K;
>>> -   pr_warn("Requested IO range too big, new size set to
>>> 64K\n");
>>> -   }
>>> +   if (!size || addr + size < addr)
>>> +   return -EINVAL;
>>>
>>> -   /* add the range to the list */
>>> range = kzalloc(sizeof(*range), GFP_ATOMIC);
>>> -   if (!range) {
>>> -   err = -ENOMEM;
>>> -   goto end_register;
>>> -   }
>>> +   if (!range)
>>> +   return -ENOMEM;
>>>
>>> -   range->start = addr;
>>> +   range->fwnode = fwnode;
>>> range->size =

Re: [PATCH v13 1/9] LIB: Introduce a generic PIO mapping method

[dann frazier]

On Wed, Feb 14, 2018 at 01:45:25AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and
> pci_pio_to_address()"), a new I/O space management was supported. With
> that driver, the I/O ranges configured for PCI/PCIe hosts on some
> architectures can be mapped to logical PIO, converted easily between
> CPU address and the corresponding logicial PIO. Based on this, PCI
> I/O devices can be accessed in a memory read/write way through the
> unified in/out accessors.
> 
> But on some archs/platforms, there are bus hosts which access I/O
> peripherals with host-local I/O port addresses rather than memory
> addresses after memory-mapped.
> 
> To support those devices, a more generic I/O mapping method is introduced
> here. Through this patch, both the CPU addresses and the host-local port
> can be mapped into the logical PIO space with different logical/fake PIOs.
> After this, all the I/O accesses to either PCI MMIO devices or host-local
> I/O peripherals can be unified into the existing I/O accessors defined in
> asm-generic/io.h and be redirected to the right device-specific hooks
> based on the input logical PIO.
> 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: John Garry 
> ---
>  include/asm-generic/io.h  |   2 +
>  include/linux/logic_pio.h | 131 ++
>  lib/Kconfig   |  15 +++
>  lib/Makefile  |   2 +
>  lib/logic_pio.c   | 272 
> ++
>  5 files changed, 422 insertions(+)
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c
> 
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index b4531e3..b7996a79 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -351,6 +351,8 @@ static inline void writesq(volatile void __iomem *addr, 
> const void *buffer,
>  #define IO_SPACE_LIMIT 0x
>  #endif
>  
> +#include 
> +
>  /*
>   * {in,out}{b,w,l}() access little endian I/O. {in,out}{b,w,l}_p() can be
>   * implemented on hardware that needs an additional delay for I/O accesses to
> diff --git a/include/linux/logic_pio.h b/include/linux/logic_pio.h
> new file mode 100644
> index 000..b3322fd
> --- /dev/null
> +++ b/include/linux/logic_pio.h
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Gabriele Paoloni 
> + * Author: Zhichang Yuan 
> + *
> + */
> +
> +#ifndef __LINUX_LOGIC_PIO_H__
> +#define __LINUX_LOGIC_PIO_H__
> +
> +#ifdef __KERNEL__
> +
> +#include 
> +
> +#define PIO_INDIRECT 0x01UL /* indirect IO flag */
> +#define PIO_CPU_MMIO 0x00UL /* memory mapped io flag */
> +
> +struct logic_pio_hwaddr {
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + resource_size_t hw_start;
> + resource_size_t io_start;
> + resource_size_t size; /* range size populated */
> + unsigned long flags;
> +
> + void *devpara;  /* private parameter of the host device */
> + struct hostio_ops *ops; /* ops operating on this node */
> +};
> +
> +struct hostio_ops {
> + u32 (*pfin)(void *devobj, unsigned long ptaddr, size_t dlen);
> + void (*pfout)(void *devobj, unsigned long ptaddr, u32 outval,
> + size_t dlen);
> + u32 (*pfins)(void *devobj, unsigned long ptaddr, void *inbuf,
> + size_t dlen, unsigned int count);
> + void (*pfouts)(void *devobj, unsigned long ptaddr,
> + const void *outbuf, size_t dlen, unsigned int count);
> +};
> +
> +#ifdef CONFIG_INDIRECT_PIO
> +u8 logic_inb(unsigned long addr);
> +void logic_outb(u8 value, unsigned long addr);
> +void logic_outw(u16 value, unsigned long addr);
> +void logic_outl(u32 value, unsigned long addr);
> +u16 logic_inw(unsigned long addr);
> +u32 logic_inl(unsigned long addr);
> +void logic_outb(u8 value, unsigned long addr);
> +void logic_outw(u16 value, unsigned long addr);
> +void logic_outl(u32 value, unsigned long addr);
> +void logic_insb(unsigned long addr, void *buffer, unsigned int count);
> +void logic_insl(unsigned long addr, void *buffer, unsigned int count);
> +void logic_insw(unsigned long addr, void *buffer, unsigned int count);
> +void logic_outsb(unsigned long addr, const void *buffer, unsigned int count);
> +void logic_outsw(unsigned long addr, const void *buffer, unsigned int count);
> +void logic_outsl(unsigned long addr, const void *buffer, unsigned int count);
> +
> +#ifndef inb
> +#define inb logic_inb
> +#endif
> +
> +#ifndef inw
> +#define inw logic_inw
> +#endif
> +
> +#ifndef inl
> +#define inl logic_inl
> +#endif
> +
> +#ifndef outb
> +#define outb logic_outb
> +#endif
> +
> +#ifndef outw
> +#define 

Re: [PATCH v13 1/9] LIB: Introduce a generic PIO mapping method

[dann frazier]

On Wed, Feb 14, 2018 at 01:45:25AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and
> pci_pio_to_address()"), a new I/O space management was supported. With
> that driver, the I/O ranges configured for PCI/PCIe hosts on some
> architectures can be mapped to logical PIO, converted easily between
> CPU address and the corresponding logicial PIO. Based on this, PCI
> I/O devices can be accessed in a memory read/write way through the
> unified in/out accessors.
> 
> But on some archs/platforms, there are bus hosts which access I/O
> peripherals with host-local I/O port addresses rather than memory
> addresses after memory-mapped.
> 
> To support those devices, a more generic I/O mapping method is introduced
> here. Through this patch, both the CPU addresses and the host-local port
> can be mapped into the logical PIO space with different logical/fake PIOs.
> After this, all the I/O accesses to either PCI MMIO devices or host-local
> I/O peripherals can be unified into the existing I/O accessors defined in
> asm-generic/io.h and be redirected to the right device-specific hooks
> based on the input logical PIO.
> 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: John Garry 
> ---
>  include/asm-generic/io.h  |   2 +
>  include/linux/logic_pio.h | 131 ++
>  lib/Kconfig   |  15 +++
>  lib/Makefile  |   2 +
>  lib/logic_pio.c   | 272 
> ++
>  5 files changed, 422 insertions(+)
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c
> 
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index b4531e3..b7996a79 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -351,6 +351,8 @@ static inline void writesq(volatile void __iomem *addr, 
> const void *buffer,
>  #define IO_SPACE_LIMIT 0x
>  #endif
>  
> +#include 
> +
>  /*
>   * {in,out}{b,w,l}() access little endian I/O. {in,out}{b,w,l}_p() can be
>   * implemented on hardware that needs an additional delay for I/O accesses to
> diff --git a/include/linux/logic_pio.h b/include/linux/logic_pio.h
> new file mode 100644
> index 000..b3322fd
> --- /dev/null
> +++ b/include/linux/logic_pio.h
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Gabriele Paoloni 
> + * Author: Zhichang Yuan 
> + *
> + */
> +
> +#ifndef __LINUX_LOGIC_PIO_H__
> +#define __LINUX_LOGIC_PIO_H__
> +
> +#ifdef __KERNEL__
> +
> +#include 
> +
> +#define PIO_INDIRECT 0x01UL /* indirect IO flag */
> +#define PIO_CPU_MMIO 0x00UL /* memory mapped io flag */
> +
> +struct logic_pio_hwaddr {
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + resource_size_t hw_start;
> + resource_size_t io_start;
> + resource_size_t size; /* range size populated */
> + unsigned long flags;
> +
> + void *devpara;  /* private parameter of the host device */
> + struct hostio_ops *ops; /* ops operating on this node */
> +};
> +
> +struct hostio_ops {
> + u32 (*pfin)(void *devobj, unsigned long ptaddr, size_t dlen);
> + void (*pfout)(void *devobj, unsigned long ptaddr, u32 outval,
> + size_t dlen);
> + u32 (*pfins)(void *devobj, unsigned long ptaddr, void *inbuf,
> + size_t dlen, unsigned int count);
> + void (*pfouts)(void *devobj, unsigned long ptaddr,
> + const void *outbuf, size_t dlen, unsigned int count);
> +};
> +
> +#ifdef CONFIG_INDIRECT_PIO
> +u8 logic_inb(unsigned long addr);
> +void logic_outb(u8 value, unsigned long addr);
> +void logic_outw(u16 value, unsigned long addr);
> +void logic_outl(u32 value, unsigned long addr);
> +u16 logic_inw(unsigned long addr);
> +u32 logic_inl(unsigned long addr);
> +void logic_outb(u8 value, unsigned long addr);
> +void logic_outw(u16 value, unsigned long addr);
> +void logic_outl(u32 value, unsigned long addr);
> +void logic_insb(unsigned long addr, void *buffer, unsigned int count);
> +void logic_insl(unsigned long addr, void *buffer, unsigned int count);
> +void logic_insw(unsigned long addr, void *buffer, unsigned int count);
> +void logic_outsb(unsigned long addr, const void *buffer, unsigned int count);
> +void logic_outsw(unsigned long addr, const void *buffer, unsigned int count);
> +void logic_outsl(unsigned long addr, const void *buffer, unsigned int count);
> +
> +#ifndef inb
> +#define inb logic_inb
> +#endif
> +
> +#ifndef inw
> +#define inw logic_inw
> +#endif
> +
> +#ifndef inl
> +#define inl logic_inl
> +#endif
> +
> +#ifndef outb
> +#define outb logic_outb
> +#endif
> +
> +#ifndef outw
> +#define outw logic_outw
> +#endif
> +
> +#ifndef outl
> +#define outl logic_outl
> +#endif
> +
> +#ifndef insb
> +#define insb logic_insb
> +#endif
> +
> +#ifndef insw
> 

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> After introducing the new generic I/O space management in logic pio, the
> original PCI MMIO relevant helpers need to be updated based on the new
> interfaces.
> This patch adapts the corresponding code to match the changes introduced
> by logic pio.
> 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: Arnd Bergmann #earlier draft
> Acked-by: Bjorn Helgaas 

I saw that Bjorn Acked this back in v6, but it seems like the code in
pci.c was reworked a bit for v7 onwards and I didn't see a follow-up
review (apologies if I just missed it). In which case, maybe his Ack
should have the "#earlier draft" tag as well?

> ---
>  drivers/pci/pci.c| 95 
> +---
>  include/asm-generic/io.h |  2 +-
>  2 files changed, 18 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 07290a3..8aa5c54 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3440,17 +3441,6 @@ int pci_request_regions_exclusive(struct pci_dev 
> *pdev, const char *res_name)
>  }
>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>  
> -#ifdef PCI_IOBASE
> -struct io_range {
> - struct list_head list;
> - phys_addr_t start;
> - resource_size_t size;
> -};
> -
> -static LIST_HEAD(io_range_list);
> -static DEFINE_SPINLOCK(io_range_lock);
> -#endif
> -
>  /*
>   * Record the PCI IO range (expressed as CPU physical address + size).
>   * Return a negative value if an error has occured, zero otherwise
> @@ -3458,51 +3448,28 @@ struct io_range {
>  int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
>   resource_size_t size)
>  {
> - int err = 0;
> -
> + int ret = 0;
>  #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> - /* check if the range hasn't been previously recorded */
> - spin_lock(_range_lock);
> - list_for_each_entry(range, _range_list, list) {
> - if (addr >= range->start && addr + size <= range->start + size) 
> {
> - /* range already registered, bail out */
> - goto end_register;
> - }
> - allocated_size += range->size;
> - }
> + struct logic_pio_hwaddr *range;
>  
> - /* range not registed yet, check for available space */
> - if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> - /* if it's too big check if 64K space can be reserved */
> - if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
> - err = -E2BIG;
> - goto end_register;
> - }
> -
> - size = SZ_64K;
> - pr_warn("Requested IO range too big, new size set to 64K\n");
> - }
> + if (!size || addr + size < addr)
> + return -EINVAL;
>  
> - /* add the range to the list */
>   range = kzalloc(sizeof(*range), GFP_ATOMIC);
> - if (!range) {
> - err = -ENOMEM;
> - goto end_register;
> - }
> + if (!range)
> + return -ENOMEM;
>  
> - range->start = addr;
> + range->fwnode = fwnode;
>   range->size = size;
> + range->hw_start = addr;
> + range->flags = PIO_CPU_MMIO;
>  
> - list_add_tail(>list, _range_list);
> -
> -end_register:
> - spin_unlock(_range_lock);
> + ret = logic_pio_register_range(range);
> + if (ret)
> + kfree(range);
>  #endif
>  
> - return err;
> + return ret;
>  }
>  
>  phys_addr_t pci_pio_to_address(unsigned long pio)
> @@ -3510,21 +3477,10 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>   phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
>  
>  #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> - if (pio > IO_SPACE_LIMIT)
> + if (pio >= MMIO_UPPER_LIMIT)
>   return address;
>  
> - spin_lock(_range_lock);
> - list_for_each_entry(range, _range_list, list) {
> - if (pio >= allocated_size && pio < allocated_size + 
> range->size) {
> - address = range->start + pio - allocated_size;
> - break;
> - }
> - allocated_size += range->size;
> - }
> - spin_unlock(_range_lock);
> + address = logic_pio_to_hwaddr(pio);
>  #endif
>  
>   return address;
> @@ -3533,25 +3489,8 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>  unsigned long __weak pci_address_to_pio(phys_addr_t address)
>  {
>  #ifdef PCI_IOBASE
> - struct io_range *res;
> - resource_size_t offset = 0;
> - unsigned long addr = -1;
> -
> - 

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> After introducing the new generic I/O space management in logic pio, the
> original PCI MMIO relevant helpers need to be updated based on the new
> interfaces.
> This patch adapts the corresponding code to match the changes introduced
> by logic pio.
> 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: Arnd Bergmann #earlier draft
> Acked-by: Bjorn Helgaas 

I saw that Bjorn Acked this back in v6, but it seems like the code in
pci.c was reworked a bit for v7 onwards and I didn't see a follow-up
review (apologies if I just missed it). In which case, maybe his Ack
should have the "#earlier draft" tag as well?

> ---
>  drivers/pci/pci.c| 95 
> +---
>  include/asm-generic/io.h |  2 +-
>  2 files changed, 18 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 07290a3..8aa5c54 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3440,17 +3441,6 @@ int pci_request_regions_exclusive(struct pci_dev 
> *pdev, const char *res_name)
>  }
>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>  
> -#ifdef PCI_IOBASE
> -struct io_range {
> - struct list_head list;
> - phys_addr_t start;
> - resource_size_t size;
> -};
> -
> -static LIST_HEAD(io_range_list);
> -static DEFINE_SPINLOCK(io_range_lock);
> -#endif
> -
>  /*
>   * Record the PCI IO range (expressed as CPU physical address + size).
>   * Return a negative value if an error has occured, zero otherwise
> @@ -3458,51 +3448,28 @@ struct io_range {
>  int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
>   resource_size_t size)
>  {
> - int err = 0;
> -
> + int ret = 0;
>  #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> - /* check if the range hasn't been previously recorded */
> - spin_lock(_range_lock);
> - list_for_each_entry(range, _range_list, list) {
> - if (addr >= range->start && addr + size <= range->start + size) 
> {
> - /* range already registered, bail out */
> - goto end_register;
> - }
> - allocated_size += range->size;
> - }
> + struct logic_pio_hwaddr *range;
>  
> - /* range not registed yet, check for available space */
> - if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> - /* if it's too big check if 64K space can be reserved */
> - if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
> - err = -E2BIG;
> - goto end_register;
> - }
> -
> - size = SZ_64K;
> - pr_warn("Requested IO range too big, new size set to 64K\n");
> - }
> + if (!size || addr + size < addr)
> + return -EINVAL;
>  
> - /* add the range to the list */
>   range = kzalloc(sizeof(*range), GFP_ATOMIC);
> - if (!range) {
> - err = -ENOMEM;
> - goto end_register;
> - }
> + if (!range)
> + return -ENOMEM;
>  
> - range->start = addr;
> + range->fwnode = fwnode;
>   range->size = size;
> + range->hw_start = addr;
> + range->flags = PIO_CPU_MMIO;
>  
> - list_add_tail(>list, _range_list);
> -
> -end_register:
> - spin_unlock(_range_lock);
> + ret = logic_pio_register_range(range);
> + if (ret)
> + kfree(range);
>  #endif
>  
> - return err;
> + return ret;
>  }
>  
>  phys_addr_t pci_pio_to_address(unsigned long pio)
> @@ -3510,21 +3477,10 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>   phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
>  
>  #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> - if (pio > IO_SPACE_LIMIT)
> + if (pio >= MMIO_UPPER_LIMIT)
>   return address;
>  
> - spin_lock(_range_lock);
> - list_for_each_entry(range, _range_list, list) {
> - if (pio >= allocated_size && pio < allocated_size + 
> range->size) {
> - address = range->start + pio - allocated_size;
> - break;
> - }
> - allocated_size += range->size;
> - }
> - spin_unlock(_range_lock);
> + address = logic_pio_to_hwaddr(pio);
>  #endif
>  
>   return address;
> @@ -3533,25 +3489,8 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>  unsigned long __weak pci_address_to_pio(phys_addr_t address)
>  {
>  #ifdef PCI_IOBASE
> - struct io_range *res;
> - resource_size_t offset = 0;
> - unsigned long addr = -1;
> -
> - spin_lock(_range_lock);
> - list_for_each_entry(res, _range_list, list) {
> - if (address >= res->start && 

Re: [PATCH v12 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

[dann frazier]

On Wed, Jan 24, 2018 at 12:36:22AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
> I/O port addresses. This patch implements the LPC host controller driver
> which perform the I/O operations on the underlying hardware.
> We don't want to touch those existing peripherals' driver, such as ipmi-bt.
> So this driver applies the indirect-IO introduced in the previous patch
> after registering an indirect-IO node to the indirect-IO devices list which
> will be searched in the I/O accessors to retrieve the host-local I/O port.
> 
> The driver config is set as a bool instead of a trisate. The reason
> here is that, by the very nature of the driver providing a logical
> PIO range, it does not make sense to have this driver as a loadable
> module. Another more specific reason is that the Huawei D03 board
> which includes hip06 SoC requires the LPC bus for UART console, so
> should be built in.
> 
> Signed-off-by: Zou Rongrong 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Rob Herring  #dts part
> ---
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  drivers/bus/Kconfig|   8 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 526 
> +
>  4 files changed, 568 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 000..213181f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,33 @@
> +Hisilicon Hip06 low-pin-count device
> +  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
> +  provides I/O access to some legacy ISA devices.
> +  Hip06 is based on arm64 architecture where there is no I/O space. So, the
> +  I/O ports here are not cpu addresses, and there is no 'ranges' property in
> +  LPC device node.
> +
> +Required properties:
> +- compatible:  value should be as follows:
> + (a) "hisilicon,hip06-lpc"
> + (b) "hisilicon,hip07-lpc"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the LPC register set is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to 
> the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b {
> + compatible = "hisilicon,hip06-lpc";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + };
> +};
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 57e011d..91debe4 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -65,6 +65,14 @@ config BRCMSTB_GISB_ARB
> arbiter. This driver provides timeout and target abort error handling
> and internal bus master decoding.
>  
> +config HISILICON_LPC
> + bool "Support for ISA I/O space on Hisilicon hip06/7"
> + depends on (ARM64 && (ARCH_HISI || COMPILE_TEST))
> + select INDIRECT_PIO
> + help
> +   Driver needed for some legacy ISA devices attached to Low-Pin-Count
> +   on Hisilicon hip06/7 SoC.
> +
>  config IMX_WEIM
>   bool "Freescale EIM DRIVER"
>   depends on ARCH_MXC
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index 9bcd0bf..abc7a42 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
>  obj-$(CONFIG_ARM_CCN)+= arm-ccn.o
>  
>  obj-$(CONFIG_BRCMSTB_GISB_ARB)   += brcmstb_gisb.o
> +obj-$(CONFIG_HISILICON_LPC)  += hisi_lpc.o
>  obj-$(CONFIG_IMX_WEIM)   += imx-weim.o
>  obj-$(CONFIG_MIPS_CDMM)  += mips_cdmm.o
>  obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> new file mode 100644
> index 000..4ce089a
> --- /dev/null
> +++ b/drivers/bus/hisi_lpc.c
> @@ -0,0 +1,526 @@
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + * Author: Zou Rongrong 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the 

Re: [PATCH v12 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

[dann frazier]

On Wed, Jan 24, 2018 at 12:36:22AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
> I/O port addresses. This patch implements the LPC host controller driver
> which perform the I/O operations on the underlying hardware.
> We don't want to touch those existing peripherals' driver, such as ipmi-bt.
> So this driver applies the indirect-IO introduced in the previous patch
> after registering an indirect-IO node to the indirect-IO devices list which
> will be searched in the I/O accessors to retrieve the host-local I/O port.
> 
> The driver config is set as a bool instead of a trisate. The reason
> here is that, by the very nature of the driver providing a logical
> PIO range, it does not make sense to have this driver as a loadable
> module. Another more specific reason is that the Huawei D03 board
> which includes hip06 SoC requires the LPC bus for UART console, so
> should be built in.
> 
> Signed-off-by: Zou Rongrong 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Rob Herring  #dts part
> ---
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  drivers/bus/Kconfig|   8 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 526 
> +
>  4 files changed, 568 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 000..213181f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,33 @@
> +Hisilicon Hip06 low-pin-count device
> +  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
> +  provides I/O access to some legacy ISA devices.
> +  Hip06 is based on arm64 architecture where there is no I/O space. So, the
> +  I/O ports here are not cpu addresses, and there is no 'ranges' property in
> +  LPC device node.
> +
> +Required properties:
> +- compatible:  value should be as follows:
> + (a) "hisilicon,hip06-lpc"
> + (b) "hisilicon,hip07-lpc"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the LPC register set is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to 
> the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b {
> + compatible = "hisilicon,hip06-lpc";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + };
> +};
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 57e011d..91debe4 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -65,6 +65,14 @@ config BRCMSTB_GISB_ARB
> arbiter. This driver provides timeout and target abort error handling
> and internal bus master decoding.
>  
> +config HISILICON_LPC
> + bool "Support for ISA I/O space on Hisilicon hip06/7"
> + depends on (ARM64 && (ARCH_HISI || COMPILE_TEST))
> + select INDIRECT_PIO
> + help
> +   Driver needed for some legacy ISA devices attached to Low-Pin-Count
> +   on Hisilicon hip06/7 SoC.
> +
>  config IMX_WEIM
>   bool "Freescale EIM DRIVER"
>   depends on ARCH_MXC
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index 9bcd0bf..abc7a42 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
>  obj-$(CONFIG_ARM_CCN)+= arm-ccn.o
>  
>  obj-$(CONFIG_BRCMSTB_GISB_ARB)   += brcmstb_gisb.o
> +obj-$(CONFIG_HISILICON_LPC)  += hisi_lpc.o
>  obj-$(CONFIG_IMX_WEIM)   += imx-weim.o
>  obj-$(CONFIG_MIPS_CDMM)  += mips_cdmm.o
>  obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> new file mode 100644
> index 000..4ce089a
> --- /dev/null
> +++ b/drivers/bus/hisi_lpc.c
> @@ -0,0 +1,526 @@
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + * Author: Zou Rongrong 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * 

Re: [PATCH v12 0/9] LPC: legacy ISA I/O support

[dann frazier]

On Tue, Jan 23, 2018 at 9:36 AM, John Garry <john.ga...@huawei.com> wrote:
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.
> ---
> | LPC host|
> | |
> ---
>  |
> _V___LPC
>   |   |
>   V   V
>  
>  |  BT(ipmi)|
>  
>
> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a specific
> LPC driver is needed to make LPC host generate the standard LPC I/O cycles 
> with
> the target peripherals'I/O port addresses. But on curent arm64 world, there is
> no real I/O accesses. All the I/O operations through in/out accessors are 
> based
> on MMIO ranges; on Hip06/Hip07 LPC the I/O accesses are performed through 
> driver
> specific accessors rather than MMIO.
> To solve this issue and keep the relevant existing peripherals' drivers 
> untouched,
> this patchset:
>- introduces a generic I/O space management framework, LIBIO, to support 
> I/O
>  operations on host controllers operating either on MMIO buses or on buses
>  requiring specific driver I/O accessors;
>- redefines the in/out accessors to provide a unified interface for both 
> MMIO
>  and driver specific I/O operations. Using LIBIO, th call of in/out() from
>  the host children drivers, such as ipmi-si, will be redirected to the
>  corresponding device-specific I/O hooks to perform the I/O accesses.
>
> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals 
> can
> be supported without any changes on the existing ipmi-si driver.
>
> The whole patchset has been tested on Hip07 D05 board both using DTB and ACPI.

fyi, tested successfully here as well on a D05:

Tested-by: dann frazier <dann.fraz...@canonical.com>

 -dann

> Differences to v11:
> - fixed build errors for i386, m68k, and tile
> - added a comment in LPC driver commit log why we set
>the kernel config as bool
> - some tidying logic_pio code
>
> Differences to v10:
> - dropped CONFIG_LOGIC_PIO. Reason is that CONFIG_PCI
>   depends on this, and CONFIG_PCI is a per-arch CONFIG.
>   So we would require all arch's kconfig to select this.
> - Addressed Dann Frazier's comments on LPC driver, and
>   sopme other cleanup
> - Moved logic_pio.h to be included in generic asm io.h
> - Fixed ACPI indirect IO host setup to handle >1 child
> - Relocated ACPI indirect IO host setup code to
>   drivers/acpi
> - Rebased to linux next-20180118
>
> Changes from v9:
>   - patch 2 has been split into 3 patches according to Bjorn comments on
> v9 thread
>   - patch 1 has been reworked accordign to Bjorn comments on v9
>   - now logic_pio_trans_hwaddr() has a sanity check to make sure the resource
> size fits into the assigned range
>   - in patch 5 the MFD framework has been used to probe the LPC children
> according to the suggestion from Mika Westerberg
>   - Maintaner has changed to Huawei Linuxarm mailing list
>
> Changes from v8:
>   - Simplified LIB IO framewrok
>   - Moved INDIRECT PIO ACPI framework under acpi/arm64
>   - Renamed occurrences of "lib io" and "indirect io" to "lib pio" and
> "indirect pio" to keep the patchset nomenclature consistent
>   - Removed Alignment reuqirements
>   - Moved LPC specific code out of ACPI common framework
>   - Now PIO indirect HW ranges can overlap
>   - Changed HiSilicon LPC driver maintainer (Gabriele Paoloni now) and split
> maintaner file modifications in a separate commit
>   - Removed the commit with the DT nodes support for hip06 and hip07 (to be
> pushed separately)
>   - Added a checking on ioport_map() not to break that function as Arnd points
> out in V7 review thread;
>   - fixed the compile issues on alpha, m68k;
>
> Changes from V7:
>   - Based on Arnd's comment, rename the LIBIO as LOGIC_PIO;
>   - Improved the mapping process in LOGIC_PIO to gain better efficiency when
> redirecting the I/O accesses to right device driver;
>   - To reduce the impact on PCI MMIO to a minimum, add a new
> CONFIG_INDIRECT_PIO for indirect-IO hosts/devices;
>   - Added a new ACPI handler for indirect-IO hosts/devices;
>   - Fixed the compile issues on V6;
>
> Changes from V6:
>   - According to the comments from Bjorn

Re: [PATCH v12 0/9] LPC: legacy ISA I/O support

[dann frazier]

On Tue, Jan 23, 2018 at 9:36 AM, John Garry  wrote:
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.
> ---
> | LPC host|
> | |
> ---
>  |
> _V___LPC
>   |   |
>   V   V
>  
>  |  BT(ipmi)|
>  
>
> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a specific
> LPC driver is needed to make LPC host generate the standard LPC I/O cycles 
> with
> the target peripherals'I/O port addresses. But on curent arm64 world, there is
> no real I/O accesses. All the I/O operations through in/out accessors are 
> based
> on MMIO ranges; on Hip06/Hip07 LPC the I/O accesses are performed through 
> driver
> specific accessors rather than MMIO.
> To solve this issue and keep the relevant existing peripherals' drivers 
> untouched,
> this patchset:
>- introduces a generic I/O space management framework, LIBIO, to support 
> I/O
>  operations on host controllers operating either on MMIO buses or on buses
>  requiring specific driver I/O accessors;
>- redefines the in/out accessors to provide a unified interface for both 
> MMIO
>  and driver specific I/O operations. Using LIBIO, th call of in/out() from
>  the host children drivers, such as ipmi-si, will be redirected to the
>  corresponding device-specific I/O hooks to perform the I/O accesses.
>
> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals 
> can
> be supported without any changes on the existing ipmi-si driver.
>
> The whole patchset has been tested on Hip07 D05 board both using DTB and ACPI.

fyi, tested successfully here as well on a D05:

Tested-by: dann frazier 

 -dann

> Differences to v11:
> - fixed build errors for i386, m68k, and tile
> - added a comment in LPC driver commit log why we set
>the kernel config as bool
> - some tidying logic_pio code
>
> Differences to v10:
> - dropped CONFIG_LOGIC_PIO. Reason is that CONFIG_PCI
>   depends on this, and CONFIG_PCI is a per-arch CONFIG.
>   So we would require all arch's kconfig to select this.
> - Addressed Dann Frazier's comments on LPC driver, and
>   sopme other cleanup
> - Moved logic_pio.h to be included in generic asm io.h
> - Fixed ACPI indirect IO host setup to handle >1 child
> - Relocated ACPI indirect IO host setup code to
>   drivers/acpi
> - Rebased to linux next-20180118
>
> Changes from v9:
>   - patch 2 has been split into 3 patches according to Bjorn comments on
> v9 thread
>   - patch 1 has been reworked accordign to Bjorn comments on v9
>   - now logic_pio_trans_hwaddr() has a sanity check to make sure the resource
> size fits into the assigned range
>   - in patch 5 the MFD framework has been used to probe the LPC children
> according to the suggestion from Mika Westerberg
>   - Maintaner has changed to Huawei Linuxarm mailing list
>
> Changes from v8:
>   - Simplified LIB IO framewrok
>   - Moved INDIRECT PIO ACPI framework under acpi/arm64
>   - Renamed occurrences of "lib io" and "indirect io" to "lib pio" and
> "indirect pio" to keep the patchset nomenclature consistent
>   - Removed Alignment reuqirements
>   - Moved LPC specific code out of ACPI common framework
>   - Now PIO indirect HW ranges can overlap
>   - Changed HiSilicon LPC driver maintainer (Gabriele Paoloni now) and split
> maintaner file modifications in a separate commit
>   - Removed the commit with the DT nodes support for hip06 and hip07 (to be
> pushed separately)
>   - Added a checking on ioport_map() not to break that function as Arnd points
> out in V7 review thread;
>   - fixed the compile issues on alpha, m68k;
>
> Changes from V7:
>   - Based on Arnd's comment, rename the LIBIO as LOGIC_PIO;
>   - Improved the mapping process in LOGIC_PIO to gain better efficiency when
> redirecting the I/O accesses to right device driver;
>   - To reduce the impact on PCI MMIO to a minimum, add a new
> CONFIG_INDIRECT_PIO for indirect-IO hosts/devices;
>   - Added a new ACPI handler for indirect-IO hosts/devices;
>   - Fixed the compile issues on V6;
>
> Changes from V6:
>   - According to the comments from Bjorn and Alex, merge PCI IO and 
> indirect-IO
> into

Re: [PATCH v10 0/9] LPC: legacy ISA I/O support

[dann frazier]

On Fri, Oct 27, 2017 at 10:11 AM, Gabriele Paoloni
<gabriele.paol...@huawei.com> wrote:
> From: gabriele paoloni <gabriele.paol...@huawei.com>
>
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.

fwiw, I tested this on one of our D05 boards and verified that the
IPMI SI worked fine.

Tested-by: dann frazier <dann.fraz...@canonical.com>

Re: [PATCH v10 0/9] LPC: legacy ISA I/O support

[dann frazier]

On Fri, Oct 27, 2017 at 10:11 AM, Gabriele Paoloni
 wrote:
> From: gabriele paoloni 
>
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.

fwiw, I tested this on one of our D05 boards and verified that the
IPMI SI worked fine.

Tested-by: dann frazier 

Re: [PATCH v10 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

[dann frazier]

On Fri, Oct 27, 2017 at 05:11:24PM +0100, Gabriele Paoloni wrote:
> From: "zhichang.yuan" 
> 
> The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
> I/O port addresses. This patch implements the LPC host controller driver
> which perform the I/O operations on the underlying hardware.
> We don't want to touch those existing peripherals' driver, such as ipmi-bt.
> So this driver applies the indirect-IO introduced in the previous patch
> after registering an indirect-IO node to the indirect-IO devices list which
> will be searched in the I/O accessors to retrieve the host-local I/O port.
> 
> Signed-off-by: Zou Rongrong 
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Rob Herring  #dts part
> ---
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  drivers/bus/Kconfig|   9 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 526 
> +
>  4 files changed, 569 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 000..213181f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,33 @@
> +Hisilicon Hip06 low-pin-count device
> +  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
> +  provides I/O access to some legacy ISA devices.
> +  Hip06 is based on arm64 architecture where there is no I/O space. So, the
> +  I/O ports here are not cpu addresses, and there is no 'ranges' property in
> +  LPC device node.
> +
> +Required properties:
> +- compatible:  value should be as follows:
> + (a) "hisilicon,hip06-lpc"
> + (b) "hisilicon,hip07-lpc"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the LPC register set is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to 
> the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b {
> + compatible = "hisilicon,hip06-lpc";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + };
> +};
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 2408ea3..358eed3 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -64,6 +64,15 @@ config BRCMSTB_GISB_ARB
> arbiter. This driver provides timeout and target abort error handling
> and internal bus master decoding.
>  
> +config HISILICON_LPC
> + bool "Support for ISA I/O space on Hisilicon Hip0X"
> + depends on (ARM64 && (ARCH_HISI || COMPILE_TEST))
> + select LOGIC_PIO
> + select INDIRECT_PIO
> + help
> +   Driver needed for some legacy ISA devices attached to Low-Pin-Count
> +   on Hisilicon Hip0X SoC.
> +
>  config IMX_WEIM
>   bool "Freescale EIM DRIVER"
>   depends on ARCH_MXC
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index cc6364b..28e3862 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
>  obj-$(CONFIG_ARM_CCN)+= arm-ccn.o
>  
>  obj-$(CONFIG_BRCMSTB_GISB_ARB)   += brcmstb_gisb.o
> +obj-$(CONFIG_HISILICON_LPC)  += hisi_lpc.o
>  obj-$(CONFIG_IMX_WEIM)   += imx-weim.o
>  obj-$(CONFIG_MIPS_CDMM)  += mips_cdmm.o
>  obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> new file mode 100644
> index 000..c885483
> --- /dev/null
> +++ b/drivers/bus/hisi_lpc.c
> @@ -0,0 +1,526 @@
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + * Author: Zou Rongrong 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU 

Re: [PATCH v10 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

[dann frazier]

On Fri, Oct 27, 2017 at 05:11:24PM +0100, Gabriele Paoloni wrote:
> From: "zhichang.yuan" 
> 
> The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
> I/O port addresses. This patch implements the LPC host controller driver
> which perform the I/O operations on the underlying hardware.
> We don't want to touch those existing peripherals' driver, such as ipmi-bt.
> So this driver applies the indirect-IO introduced in the previous patch
> after registering an indirect-IO node to the indirect-IO devices list which
> will be searched in the I/O accessors to retrieve the host-local I/O port.
> 
> Signed-off-by: Zou Rongrong 
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Rob Herring  #dts part
> ---
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  drivers/bus/Kconfig|   9 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 526 
> +
>  4 files changed, 569 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 000..213181f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,33 @@
> +Hisilicon Hip06 low-pin-count device
> +  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
> +  provides I/O access to some legacy ISA devices.
> +  Hip06 is based on arm64 architecture where there is no I/O space. So, the
> +  I/O ports here are not cpu addresses, and there is no 'ranges' property in
> +  LPC device node.
> +
> +Required properties:
> +- compatible:  value should be as follows:
> + (a) "hisilicon,hip06-lpc"
> + (b) "hisilicon,hip07-lpc"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the LPC register set is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to 
> the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b {
> + compatible = "hisilicon,hip06-lpc";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + };
> +};
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 2408ea3..358eed3 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -64,6 +64,15 @@ config BRCMSTB_GISB_ARB
> arbiter. This driver provides timeout and target abort error handling
> and internal bus master decoding.
>  
> +config HISILICON_LPC
> + bool "Support for ISA I/O space on Hisilicon Hip0X"
> + depends on (ARM64 && (ARCH_HISI || COMPILE_TEST))
> + select LOGIC_PIO
> + select INDIRECT_PIO
> + help
> +   Driver needed for some legacy ISA devices attached to Low-Pin-Count
> +   on Hisilicon Hip0X SoC.
> +
>  config IMX_WEIM
>   bool "Freescale EIM DRIVER"
>   depends on ARCH_MXC
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index cc6364b..28e3862 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
>  obj-$(CONFIG_ARM_CCN)+= arm-ccn.o
>  
>  obj-$(CONFIG_BRCMSTB_GISB_ARB)   += brcmstb_gisb.o
> +obj-$(CONFIG_HISILICON_LPC)  += hisi_lpc.o
>  obj-$(CONFIG_IMX_WEIM)   += imx-weim.o
>  obj-$(CONFIG_MIPS_CDMM)  += mips_cdmm.o
>  obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> new file mode 100644
> index 000..c885483
> --- /dev/null
> +++ b/drivers/bus/hisi_lpc.c
> @@ -0,0 +1,526 @@
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + * Author: Zou Rongrong 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

On Mon, Oct 23, 2017 at 3:08 PM, Bart Van Assche <bart.vanass...@wdc.com> wrote:
> On Mon, 2017-10-23 at 09:41 -0600, dann frazier wrote:
>> (gdb) list *(sg_io+0x120)
>> 0x084e71a8 is in sg_io (./include/linux/uaccess.h:113).
>> 108   static inline unsigned long
>> 109   _copy_from_user(void *to, const void __user *from, unsigned long n)
>> 110   {
>> 111   unsigned long res = n;
>> 112   might_fault();
>> 113   if (likely(access_ok(VERIFY_READ, from, n))) {
>> 114   kasan_check_write(to, n);
>> 115   res = raw_copy_from_user(to, from, n);
>> 116   }
>> 117   if (unlikely(res))
>
> Hello Dann,
>
> Would it be possible to check whether the patch below is sufficient to fix 
> this?

hey Bart,
 Yes, it does appear to be sufficient:

ubuntu@ubuntu:~$ sudo dmesg -c > /dev/null
ubuntu@ubuntu:~$ sudo dmraid -r -c
ERROR: isw: seeking device "/dev/vda" to 18446744073708843520
ERROR: sil: seeking device "/dev/vda" to 18446744073709401600
no raid disks
ubuntu@ubuntu:~$ dmesg
ubuntu@ubuntu:~$

  -dann

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

On Mon, Oct 23, 2017 at 3:08 PM, Bart Van Assche  wrote:
> On Mon, 2017-10-23 at 09:41 -0600, dann frazier wrote:
>> (gdb) list *(sg_io+0x120)
>> 0x084e71a8 is in sg_io (./include/linux/uaccess.h:113).
>> 108   static inline unsigned long
>> 109   _copy_from_user(void *to, const void __user *from, unsigned long n)
>> 110   {
>> 111   unsigned long res = n;
>> 112   might_fault();
>> 113   if (likely(access_ok(VERIFY_READ, from, n))) {
>> 114   kasan_check_write(to, n);
>> 115   res = raw_copy_from_user(to, from, n);
>> 116   }
>> 117   if (unlikely(res))
>
> Hello Dann,
>
> Would it be possible to check whether the patch below is sufficient to fix 
> this?

hey Bart,
 Yes, it does appear to be sufficient:

ubuntu@ubuntu:~$ sudo dmesg -c > /dev/null
ubuntu@ubuntu:~$ sudo dmraid -r -c
ERROR: isw: seeking device "/dev/vda" to 18446744073708843520
ERROR: sil: seeking device "/dev/vda" to 18446744073709401600
no raid disks
ubuntu@ubuntu:~$ dmesg
ubuntu@ubuntu:~$

  -dann

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

On Fri, Oct 20, 2017 at 11:30:55PM +, Bart Van Assche wrote:
> On Fri, 2017-10-20 at 16:54 -0600, dann frazier wrote:
> > hey,
> >   I'm seeing a regression when executing 'dmraid -r -c' in an arm64
> > QEMU guest, which I've bisected to the following commit:
> > 
> >   ca18d6f7 "block: Make most scsi_req_init() calls implicit"
> > 
> > I haven't yet had time to try and debug it yet, but wanted to get
> > the report out there before the weekend. Here's the crash:
> > 
> > [  138.519885] usercopy: kernel memory overwrite attempt detected to
> >(null) () (6 bytes)
> > [  138.521562] kernel BUG at mm/usercopy.c:72!
> > [  138.522294] Internal error: Oops - BUG: 0 [#1] SMP
> > [  138.523105] Modules linked in: nls_utf8 isofs nls_iso8859_1 qemu_fw_cfg 
> > ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi 
> > scsi_transport_iscsi ip_tables
> > x_tables autofs4 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 
> > async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
> > libcrc32c raid1 raid0
> > multipath linear aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce 
> > sha2_ce sha256_arm64 sha1_ce virtio_net virtio_blk aes_neon_bs aes_neon_blk 
> > crypto_simd cryptd
> > aes_arm64
> > [  138.531307] CPU: 62 PID: 2271 Comm: dmraid Not tainted 4.14.0-rc5+ #20
> > [  138.532512] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 
> > 02/06/2015
> > [  138.533796] task: 8003cba2e900 task.stack: 110e8000
> > [  138.534887] PC is at __check_object_size+0x114/0x200
> > [  138.535800] LR is at __check_object_size+0x114/0x200
> > [  138.536711] pc : [] lr : [] pstate: 
> > 00400145
> > [  138.538073] sp : 110ebb00
> > [  138.538682] x29: 110ebb00 x28:  
> > [  138.539658] x27: d88e1110 x26: 8003e8d3d800 
> > [  138.540633] x25: 0802001d x24: 8003e1131920 
> > [  138.541621] x23: 0006 x22: 0006 
> > [  138.542596] x21:  x20: 0006 
> > [  138.543571] x19:  x18:  
> > [  138.544548] x17: 83380ce0 x16: 082dd3b0 
> > [  138.545525] x15: 093c8c08 x14: 6c756e2820202020 
> > [  138.546511] x13: 202020202020206f x12: 7420646574636574 
> > [  138.547489] x11: 093c9658 x10: 086ae800 
> > [  138.548466] x9 : 7265766f2079726f x8 : 0017 
> > [  138.549445] x7 : 6c756e3c2820296c x6 : 8003eeb51c28 
> > [  138.550434] x5 : 8003eeb51c28 x4 :  
> > [  138.551411] x3 : 8003eeb59ec8 x2 : d4a0cd0f45236000 
> > [  138.552388] x1 :  x0 : 0059 
> > [  138.553364] Process dmraid (pid: 2271, stack limit = 0x110e8000)
> > [  138.554593] Call trace:
> > [  138.555043] Exception stack(0x110eb9c0 to 0x110ebb00)
> > [  138.556214] b9c0: 0059  d4a0cd0f45236000 
> > 8003eeb59ec8
> > [  138.557653] b9e0:  8003eeb51c28 8003eeb51c28 
> > 6c756e3c2820296c
> > [  138.559082] ba00: 0017 7265766f2079726f 086ae800 
> > 093c9658
> > [  138.560510] ba20: 7420646574636574 202020202020206f 6c756e2820202020 
> > 093c8c08
> > [  138.561950] ba40: 082dd3b0 83380ce0  
> > 
> > [  138.563379] ba60: 0006  0006 
> > 0006
> > [  138.564805] ba80: 8003e1131920 0802001d 8003e8d3d800 
> > d88e1110
> > [  138.566238] baa0:  110ebb00 082c0e5c 
> > 110ebb00
> > [  138.567666] bac0: 082c0e5c 00400145 08e25a80 
> > 
> > [  138.569090] bae0: 0001 0006 110ebb00 
> > 082c0e5c
> > [  138.570523] [] __check_object_size+0x114/0x200
> > [  138.571628] [] sg_io+0x120/0x438
> > [  138.572507] [] scsi_cmd_ioctl+0x594/0x728
> > [  138.573531] [] scsi_cmd_blk_ioctl+0x50/0x60
> > [  138.574594] [] virtblk_ioctl+0x60/0x80 [virtio_blk]
> > [  138.575769] [] blkdev_ioctl+0x5e4/0xb50
> > [  138.576756] [] block_ioctl+0x50/0x68
> > [  138.577698] [] do_vfs_ioctl+0xc4/0x940
> > [  138.578671] [] SyS_ioctl+0x8c/0xa8
> > [  138.579581] Exception stack(0x110ebec0 to 0x110ec000)
> > [  138.580752] bec0: 0005 2285 d88e10b8 
> > 0006
> > [  138.582199] bee0: 

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

On Fri, Oct 20, 2017 at 11:30:55PM +, Bart Van Assche wrote:
> On Fri, 2017-10-20 at 16:54 -0600, dann frazier wrote:
> > hey,
> >   I'm seeing a regression when executing 'dmraid -r -c' in an arm64
> > QEMU guest, which I've bisected to the following commit:
> > 
> >   ca18d6f7 "block: Make most scsi_req_init() calls implicit"
> > 
> > I haven't yet had time to try and debug it yet, but wanted to get
> > the report out there before the weekend. Here's the crash:
> > 
> > [  138.519885] usercopy: kernel memory overwrite attempt detected to
> >(null) () (6 bytes)
> > [  138.521562] kernel BUG at mm/usercopy.c:72!
> > [  138.522294] Internal error: Oops - BUG: 0 [#1] SMP
> > [  138.523105] Modules linked in: nls_utf8 isofs nls_iso8859_1 qemu_fw_cfg 
> > ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi 
> > scsi_transport_iscsi ip_tables
> > x_tables autofs4 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 
> > async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
> > libcrc32c raid1 raid0
> > multipath linear aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce 
> > sha2_ce sha256_arm64 sha1_ce virtio_net virtio_blk aes_neon_bs aes_neon_blk 
> > crypto_simd cryptd
> > aes_arm64
> > [  138.531307] CPU: 62 PID: 2271 Comm: dmraid Not tainted 4.14.0-rc5+ #20
> > [  138.532512] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 
> > 02/06/2015
> > [  138.533796] task: 8003cba2e900 task.stack: 110e8000
> > [  138.534887] PC is at __check_object_size+0x114/0x200
> > [  138.535800] LR is at __check_object_size+0x114/0x200
> > [  138.536711] pc : [] lr : [] pstate: 
> > 00400145
> > [  138.538073] sp : 110ebb00
> > [  138.538682] x29: 110ebb00 x28:  
> > [  138.539658] x27: d88e1110 x26: 8003e8d3d800 
> > [  138.540633] x25: 0802001d x24: 8003e1131920 
> > [  138.541621] x23: 0006 x22: 0006 
> > [  138.542596] x21:  x20: 0006 
> > [  138.543571] x19:  x18:  
> > [  138.544548] x17: 83380ce0 x16: 082dd3b0 
> > [  138.545525] x15: 093c8c08 x14: 6c756e2820202020 
> > [  138.546511] x13: 202020202020206f x12: 7420646574636574 
> > [  138.547489] x11: 093c9658 x10: 086ae800 
> > [  138.548466] x9 : 7265766f2079726f x8 : 0017 
> > [  138.549445] x7 : 6c756e3c2820296c x6 : 8003eeb51c28 
> > [  138.550434] x5 : 8003eeb51c28 x4 :  
> > [  138.551411] x3 : 8003eeb59ec8 x2 : d4a0cd0f45236000 
> > [  138.552388] x1 :  x0 : 0059 
> > [  138.553364] Process dmraid (pid: 2271, stack limit = 0x110e8000)
> > [  138.554593] Call trace:
> > [  138.555043] Exception stack(0x110eb9c0 to 0x110ebb00)
> > [  138.556214] b9c0: 0059  d4a0cd0f45236000 
> > 8003eeb59ec8
> > [  138.557653] b9e0:  8003eeb51c28 8003eeb51c28 
> > 6c756e3c2820296c
> > [  138.559082] ba00: 0017 7265766f2079726f 086ae800 
> > 093c9658
> > [  138.560510] ba20: 7420646574636574 202020202020206f 6c756e2820202020 
> > 093c8c08
> > [  138.561950] ba40: 082dd3b0 83380ce0  
> > 
> > [  138.563379] ba60: 0006  0006 
> > 0006
> > [  138.564805] ba80: 8003e1131920 0802001d 8003e8d3d800 
> > d88e1110
> > [  138.566238] baa0:  110ebb00 082c0e5c 
> > 110ebb00
> > [  138.567666] bac0: 082c0e5c 00400145 08e25a80 
> > 
> > [  138.569090] bae0: 0001 0006 110ebb00 
> > 082c0e5c
> > [  138.570523] [] __check_object_size+0x114/0x200
> > [  138.571628] [] sg_io+0x120/0x438
> > [  138.572507] [] scsi_cmd_ioctl+0x594/0x728
> > [  138.573531] [] scsi_cmd_blk_ioctl+0x50/0x60
> > [  138.574594] [] virtblk_ioctl+0x60/0x80 [virtio_blk]
> > [  138.575769] [] blkdev_ioctl+0x5e4/0xb50
> > [  138.576756] [] block_ioctl+0x50/0x68
> > [  138.577698] [] do_vfs_ioctl+0xc4/0x940
> > [  138.578671] [] SyS_ioctl+0x8c/0xa8
> > [  138.579581] Exception stack(0x110ebec0 to 0x110ec000)
> > [  138.580752] bec0: 0005 2285 d88e10b8 
> > 0006
> > [  138.582199] bee0: 

[bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

hey,
  I'm seeing a regression when executing 'dmraid -r -c' in an arm64
QEMU guest, which I've bisected to the following commit:

  ca18d6f7 "block: Make most scsi_req_init() calls implicit"

I haven't yet had time to try and debug it yet, but wanted to get
the report out there before the weekend. Here's the crash:

[  138.519885] usercopy: kernel memory overwrite attempt detected to   
(null) () (6 bytes)
[  138.521562] kernel BUG at mm/usercopy.c:72!
[  138.522294] Internal error: Oops - BUG: 0 [#1] SMP
[  138.523105] Modules linked in: nls_utf8 isofs nls_iso8859_1 qemu_fw_cfg 
ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_decompress 
zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq 
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 
aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha256_arm64 
sha1_ce virtio_net virtio_blk aes_neon_bs aes_neon_blk crypto_simd cryptd 
aes_arm64
[  138.531307] CPU: 62 PID: 2271 Comm: dmraid Not tainted 4.14.0-rc5+ #20
[  138.532512] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[  138.533796] task: 8003cba2e900 task.stack: 110e8000
[  138.534887] PC is at __check_object_size+0x114/0x200
[  138.535800] LR is at __check_object_size+0x114/0x200
[  138.536711] pc : [] lr : [] pstate: 
00400145
[  138.538073] sp : 110ebb00
[  138.538682] x29: 110ebb00 x28:  
[  138.539658] x27: d88e1110 x26: 8003e8d3d800 
[  138.540633] x25: 0802001d x24: 8003e1131920 
[  138.541621] x23: 0006 x22: 0006 
[  138.542596] x21:  x20: 0006 
[  138.543571] x19:  x18:  
[  138.544548] x17: 83380ce0 x16: 082dd3b0 
[  138.545525] x15: 093c8c08 x14: 6c756e2820202020 
[  138.546511] x13: 202020202020206f x12: 7420646574636574 
[  138.547489] x11: 093c9658 x10: 086ae800 
[  138.548466] x9 : 7265766f2079726f x8 : 0017 
[  138.549445] x7 : 6c756e3c2820296c x6 : 8003eeb51c28 
[  138.550434] x5 : 8003eeb51c28 x4 :  
[  138.551411] x3 : 8003eeb59ec8 x2 : d4a0cd0f45236000 
[  138.552388] x1 :  x0 : 0059 
[  138.553364] Process dmraid (pid: 2271, stack limit = 0x110e8000)
[  138.554593] Call trace:
[  138.555043] Exception stack(0x110eb9c0 to 0x110ebb00)
[  138.556214] b9c0: 0059  d4a0cd0f45236000 
8003eeb59ec8
[  138.557653] b9e0:  8003eeb51c28 8003eeb51c28 
6c756e3c2820296c
[  138.559082] ba00: 0017 7265766f2079726f 086ae800 
093c9658
[  138.560510] ba20: 7420646574636574 202020202020206f 6c756e2820202020 
093c8c08
[  138.561950] ba40: 082dd3b0 83380ce0  

[  138.563379] ba60: 0006  0006 
0006
[  138.564805] ba80: 8003e1131920 0802001d 8003e8d3d800 
d88e1110
[  138.566238] baa0:  110ebb00 082c0e5c 
110ebb00
[  138.567666] bac0: 082c0e5c 00400145 08e25a80 

[  138.569090] bae0: 0001 0006 110ebb00 
082c0e5c
[  138.570523] [] __check_object_size+0x114/0x200
[  138.571628] [] sg_io+0x120/0x438
[  138.572507] [] scsi_cmd_ioctl+0x594/0x728
[  138.573531] [] scsi_cmd_blk_ioctl+0x50/0x60
[  138.574594] [] virtblk_ioctl+0x60/0x80 [virtio_blk]
[  138.575769] [] blkdev_ioctl+0x5e4/0xb50
[  138.576756] [] block_ioctl+0x50/0x68
[  138.577698] [] do_vfs_ioctl+0xc4/0x940
[  138.578671] [] SyS_ioctl+0x8c/0xa8
[  138.579581] Exception stack(0x110ebec0 to 0x110ec000)
[  138.580752] bec0: 0005 2285 d88e10b8 
0006
[  138.582199] bee0:  0004 83416648 
0050
[  138.583623] bf00: 001d 0003 0012 
0011
[  138.585050] bf20: 83409000 00ff 8309dc70 
0531
[  138.586490] bf40: 8344a360 83380ce0 00dc 
83478948
[  138.587918] bf60: 0004 17ee7f90 0005 
17ede920
[  138.589346] bf80: 17ee7f60 0003 83416648 
17ee7f60
[  138.590785] bfa0: d88e1218 d88e1090 834166dc 
d88e1090
[  138.592215] bfc0: 83380cec 8000 0005 
001d
[  138.593649] bfe0:    

[  138.595091] [] el0_svc_naked+0x24/0x28
[  138.596071] Code: aa1403e5 aa1303e3 9119a0c0 97f9d96d (d421) 
[  138.597193] ---[ end trace b7eecd0b21001177 ]---

Here's the ioctl as 

[bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

hey,
  I'm seeing a regression when executing 'dmraid -r -c' in an arm64
QEMU guest, which I've bisected to the following commit:

  ca18d6f7 "block: Make most scsi_req_init() calls implicit"

I haven't yet had time to try and debug it yet, but wanted to get
the report out there before the weekend. Here's the crash:

[  138.519885] usercopy: kernel memory overwrite attempt detected to   
(null) () (6 bytes)
[  138.521562] kernel BUG at mm/usercopy.c:72!
[  138.522294] Internal error: Oops - BUG: 0 [#1] SMP
[  138.523105] Modules linked in: nls_utf8 isofs nls_iso8859_1 qemu_fw_cfg 
ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_decompress 
zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq 
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 
aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha256_arm64 
sha1_ce virtio_net virtio_blk aes_neon_bs aes_neon_blk crypto_simd cryptd 
aes_arm64
[  138.531307] CPU: 62 PID: 2271 Comm: dmraid Not tainted 4.14.0-rc5+ #20
[  138.532512] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[  138.533796] task: 8003cba2e900 task.stack: 110e8000
[  138.534887] PC is at __check_object_size+0x114/0x200
[  138.535800] LR is at __check_object_size+0x114/0x200
[  138.536711] pc : [] lr : [] pstate: 
00400145
[  138.538073] sp : 110ebb00
[  138.538682] x29: 110ebb00 x28:  
[  138.539658] x27: d88e1110 x26: 8003e8d3d800 
[  138.540633] x25: 0802001d x24: 8003e1131920 
[  138.541621] x23: 0006 x22: 0006 
[  138.542596] x21:  x20: 0006 
[  138.543571] x19:  x18:  
[  138.544548] x17: 83380ce0 x16: 082dd3b0 
[  138.545525] x15: 093c8c08 x14: 6c756e2820202020 
[  138.546511] x13: 202020202020206f x12: 7420646574636574 
[  138.547489] x11: 093c9658 x10: 086ae800 
[  138.548466] x9 : 7265766f2079726f x8 : 0017 
[  138.549445] x7 : 6c756e3c2820296c x6 : 8003eeb51c28 
[  138.550434] x5 : 8003eeb51c28 x4 :  
[  138.551411] x3 : 8003eeb59ec8 x2 : d4a0cd0f45236000 
[  138.552388] x1 :  x0 : 0059 
[  138.553364] Process dmraid (pid: 2271, stack limit = 0x110e8000)
[  138.554593] Call trace:
[  138.555043] Exception stack(0x110eb9c0 to 0x110ebb00)
[  138.556214] b9c0: 0059  d4a0cd0f45236000 
8003eeb59ec8
[  138.557653] b9e0:  8003eeb51c28 8003eeb51c28 
6c756e3c2820296c
[  138.559082] ba00: 0017 7265766f2079726f 086ae800 
093c9658
[  138.560510] ba20: 7420646574636574 202020202020206f 6c756e2820202020 
093c8c08
[  138.561950] ba40: 082dd3b0 83380ce0  

[  138.563379] ba60: 0006  0006 
0006
[  138.564805] ba80: 8003e1131920 0802001d 8003e8d3d800 
d88e1110
[  138.566238] baa0:  110ebb00 082c0e5c 
110ebb00
[  138.567666] bac0: 082c0e5c 00400145 08e25a80 

[  138.569090] bae0: 0001 0006 110ebb00 
082c0e5c
[  138.570523] [] __check_object_size+0x114/0x200
[  138.571628] [] sg_io+0x120/0x438
[  138.572507] [] scsi_cmd_ioctl+0x594/0x728
[  138.573531] [] scsi_cmd_blk_ioctl+0x50/0x60
[  138.574594] [] virtblk_ioctl+0x60/0x80 [virtio_blk]
[  138.575769] [] blkdev_ioctl+0x5e4/0xb50
[  138.576756] [] block_ioctl+0x50/0x68
[  138.577698] [] do_vfs_ioctl+0xc4/0x940
[  138.578671] [] SyS_ioctl+0x8c/0xa8
[  138.579581] Exception stack(0x110ebec0 to 0x110ec000)
[  138.580752] bec0: 0005 2285 d88e10b8 
0006
[  138.582199] bee0:  0004 83416648 
0050
[  138.583623] bf00: 001d 0003 0012 
0011
[  138.585050] bf20: 83409000 00ff 8309dc70 
0531
[  138.586490] bf40: 8344a360 83380ce0 00dc 
83478948
[  138.587918] bf60: 0004 17ee7f90 0005 
17ede920
[  138.589346] bf80: 17ee7f60 0003 83416648 
17ee7f60
[  138.590785] bfa0: d88e1218 d88e1090 834166dc 
d88e1090
[  138.592215] bfc0: 83380cec 8000 0005 
001d
[  138.593649] bfe0:    

[  138.595091] [] el0_svc_naked+0x24/0x28
[  138.596071] Code: aa1403e5 aa1303e3 9119a0c0 97f9d96d (d421) 
[  138.597193] ---[ end trace b7eecd0b21001177 ]---

Here's the ioctl as 

Re: [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO

[dann frazier]

On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan
 wrote:
> On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O
> with some special host-local I/O ports known on x86. To access the I/O
> peripherals, an indirect-IO mechanism is introduced to mapped the host-local
> I/O to system logical/fake PIO similar the PCI MMIO on architectures where no
> separate I/O space exists. Just as PCI MMIO, the host I/O range should be
> registered before probing the downstream devices and set up the I/O mapping.
> But current ACPI bus probing doesn't support these indirect-IO hosts/devices.
>
> This patch introdueces a new ACPI handler for this device category. Through 
> the
> handler attach callback, the indirect-IO hosts I/O registration is done and
> all peripherals' I/O resources are translated into logic/fake PIO before
> starting the enumeration.
>
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> ---
>  drivers/acpi/Makefile  |   1 +
>  drivers/acpi/acpi_indirectio.c | 344 
> +
>  drivers/acpi/internal.h|   5 +
>  drivers/acpi/scan.c|   1 +
>  4 files changed, 351 insertions(+)
>  create mode 100644 drivers/acpi/acpi_indirectio.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index a391bbc..10e5f2b 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
>  acpi-y += acpi_lpat.o
>  acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
>  acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
> +acpi-$(CONFIG_INDIRECT_PIO)+= acpi_indirectio.o
>
>  # These are (potentially) separate modules
>
> diff --git a/drivers/acpi/acpi_indirectio.c b/drivers/acpi/acpi_indirectio.c
> new file mode 100644
> index 000..c8c80b5
> --- /dev/null
> +++ b/drivers/acpi/acpi_indirectio.c
> @@ -0,0 +1,344 @@
> +/*
> + * ACPI support for indirect-IO bus.
> + *
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "internal.h"
> +
> +ACPI_MODULE_NAME("indirect IO");
> +
> +#define INDIRECT_IO_INFO(desc) ((unsigned long))
> +
> +struct lpc_private_data {
> +   resource_size_t io_size;
> +   resource_size_t io_start;
> +};
> +
> +struct indirectio_device_desc {
> +   void *pdata; /* device relevant info data */
> +   int (*pre_setup)(struct acpi_device *adev, void *pdata);
> +};
> +
> +static struct lpc_private_data lpc_data = {
> +   .io_size = LPC_BUS_IO_SIZE,
> +   .io_start = LPC_MIN_BUS_RANGE,
> +};
> +
> +static inline bool acpi_logicio_supported_resource(struct acpi_resource *res)
> +{
> +   switch (res->type) {
> +   case ACPI_RESOURCE_TYPE_ADDRESS32:
> +   case ACPI_RESOURCE_TYPE_ADDRESS64:
> +   return true;
> +   }
> +   return false;
> +}
> +
> +static acpi_status acpi_count_logiciores(struct acpi_resource *res,
> +  void *data)
> +{
> +   int *res_cnt = data;
> +
> +   if (acpi_logicio_supported_resource(res) &&
> +   !acpi_dev_filter_resource_type(res, IORESOURCE_IO))
> +   (*res_cnt)++;
> +
> +   return AE_OK;
> +}
> +
> +static acpi_status acpi_read_one_logiciores(struct acpi_resource *res,
> +   void *data)
> +{
> +   struct acpi_resource **resource = data;
> +
> +   if (acpi_logicio_supported_resource(res) &&
> +   !acpi_dev_filter_resource_type(res, IORESOURCE_IO)) {
> +   memcpy((*resource), res, sizeof(struct acpi_resource));
> +   (*resource)->length = sizeof(struct acpi_resource);
> +   (*resource)->type = res->type;
> +   (*resource)++;
> +   }
> +
> +   return AE_OK;
> +}
> +
> +static acpi_status
> +acpi_build_logiciores_template(struct acpi_device *adev,
> +   struct acpi_buffer *buffer)
> +{
> +   acpi_handle handle = adev->handle;
> +   struct acpi_resource *resource;
> +   acpi_status status;
> +   int res_cnt = 0;
> +
> +   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> +acpi_count_logiciores, _cnt);
> +   if (ACPI_FAILURE(status) || !res_cnt) {
> +   dev_err(>dev, "can't evaluate _CRS: %d\n", status);
> +   return -EINVAL;
> +   }
> +
> +   buffer->length = sizeof(struct acpi_resource) * (res_cnt + 1) + 1;
> +   buffer->pointer = kzalloc(buffer->length - 1, GFP_KERNEL);

(Seth Forshee noticed this issue, just passing it on)

Should this just 

Re: [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO

[dann frazier]

On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan
 wrote:
> On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O
> with some special host-local I/O ports known on x86. To access the I/O
> peripherals, an indirect-IO mechanism is introduced to mapped the host-local
> I/O to system logical/fake PIO similar the PCI MMIO on architectures where no
> separate I/O space exists. Just as PCI MMIO, the host I/O range should be
> registered before probing the downstream devices and set up the I/O mapping.
> But current ACPI bus probing doesn't support these indirect-IO hosts/devices.
>
> This patch introdueces a new ACPI handler for this device category. Through 
> the
> handler attach callback, the indirect-IO hosts I/O registration is done and
> all peripherals' I/O resources are translated into logic/fake PIO before
> starting the enumeration.
>
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> ---
>  drivers/acpi/Makefile  |   1 +
>  drivers/acpi/acpi_indirectio.c | 344 
> +
>  drivers/acpi/internal.h|   5 +
>  drivers/acpi/scan.c|   1 +
>  4 files changed, 351 insertions(+)
>  create mode 100644 drivers/acpi/acpi_indirectio.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index a391bbc..10e5f2b 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
>  acpi-y += acpi_lpat.o
>  acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
>  acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
> +acpi-$(CONFIG_INDIRECT_PIO)+= acpi_indirectio.o
>
>  # These are (potentially) separate modules
>
> diff --git a/drivers/acpi/acpi_indirectio.c b/drivers/acpi/acpi_indirectio.c
> new file mode 100644
> index 000..c8c80b5
> --- /dev/null
> +++ b/drivers/acpi/acpi_indirectio.c
> @@ -0,0 +1,344 @@
> +/*
> + * ACPI support for indirect-IO bus.
> + *
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "internal.h"
> +
> +ACPI_MODULE_NAME("indirect IO");
> +
> +#define INDIRECT_IO_INFO(desc) ((unsigned long))
> +
> +struct lpc_private_data {
> +   resource_size_t io_size;
> +   resource_size_t io_start;
> +};
> +
> +struct indirectio_device_desc {
> +   void *pdata; /* device relevant info data */
> +   int (*pre_setup)(struct acpi_device *adev, void *pdata);
> +};
> +
> +static struct lpc_private_data lpc_data = {
> +   .io_size = LPC_BUS_IO_SIZE,
> +   .io_start = LPC_MIN_BUS_RANGE,
> +};
> +
> +static inline bool acpi_logicio_supported_resource(struct acpi_resource *res)
> +{
> +   switch (res->type) {
> +   case ACPI_RESOURCE_TYPE_ADDRESS32:
> +   case ACPI_RESOURCE_TYPE_ADDRESS64:
> +   return true;
> +   }
> +   return false;
> +}
> +
> +static acpi_status acpi_count_logiciores(struct acpi_resource *res,
> +  void *data)
> +{
> +   int *res_cnt = data;
> +
> +   if (acpi_logicio_supported_resource(res) &&
> +   !acpi_dev_filter_resource_type(res, IORESOURCE_IO))
> +   (*res_cnt)++;
> +
> +   return AE_OK;
> +}
> +
> +static acpi_status acpi_read_one_logiciores(struct acpi_resource *res,
> +   void *data)
> +{
> +   struct acpi_resource **resource = data;
> +
> +   if (acpi_logicio_supported_resource(res) &&
> +   !acpi_dev_filter_resource_type(res, IORESOURCE_IO)) {
> +   memcpy((*resource), res, sizeof(struct acpi_resource));
> +   (*resource)->length = sizeof(struct acpi_resource);
> +   (*resource)->type = res->type;
> +   (*resource)++;
> +   }
> +
> +   return AE_OK;
> +}
> +
> +static acpi_status
> +acpi_build_logiciores_template(struct acpi_device *adev,
> +   struct acpi_buffer *buffer)
> +{
> +   acpi_handle handle = adev->handle;
> +   struct acpi_resource *resource;
> +   acpi_status status;
> +   int res_cnt = 0;
> +
> +   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> +acpi_count_logiciores, _cnt);
> +   if (ACPI_FAILURE(status) || !res_cnt) {
> +   dev_err(>dev, "can't evaluate _CRS: %d\n", status);
> +   return -EINVAL;
> +   }
> +
> +   buffer->length = sizeof(struct acpi_resource) * (res_cnt + 1) + 1;
> +   buffer->pointer = kzalloc(buffer->length - 1, GFP_KERNEL);

(Seth Forshee noticed this issue, just passing it on)

Should this just allocate the full buffer->length? That would keep the
length attribute accurate (possibly avoiding an off-by-1 error 

Re: [PATCH V8 0/7] LPC: legacy ISA I/O support

[dann frazier]

ycon;
>
> V7 thread here: https://lkml.org/lkml/2017/3/12/279
> v6 thread here: https://lkml.org/lkml/2017/1/24/25
> v5 thread here: https://lkml.org/lkml/2016/11/7/955
> v4 thread here: https://lkml.org/lkml/2016/10/20/149
> v3 thread here: https://lkml.org/lkml/2016/9/14/326
> v2 thread here: https://lkml.org/lkml/2016/9/7/356
> v1 thread here: https://lkml.org/lkml/2015/12/29/154
>
>
> Signed-off-by: Zhichang Yuan <yuanzhich...@hisilicon.com>
> zhichang.yuan (6):
>   LIBIO: Introduce a generic PIO mapping method
>   PCI: Apply the new generic I/O management on PCI IO hosts
>   OF: Add missing I/O range exception for indirect-IO devices
>   LPC: Support the device-tree LPC host on Hip06/Hip07
>   ACPI: Support the probing on the devices which apply indirect-IO
>   LPC: Add the ACPI LPC support
>
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  MAINTAINERS|   8 +
>  arch/arm64/boot/dts/hisilicon/hip06-d03.dts|   4 +
>  arch/arm64/boot/dts/hisilicon/hip06.dtsi   |  14 +
>  arch/arm64/boot/dts/hisilicon/hip07-d05.dts|   4 +
>  arch/arm64/boot/dts/hisilicon/hip07.dtsi   |  14 +
>  drivers/acpi/Makefile  |   1 +
>  drivers/acpi/acpi_indirectio.c | 344 +
>  drivers/acpi/internal.h|   5 +
>  drivers/acpi/pci_root.c|   8 +-
>  drivers/acpi/scan.c|   1 +
>  drivers/bus/Kconfig|   9 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 547 
> +
>  drivers/of/address.c   |  95 +++-
>  drivers/pci/pci.c  | 104 +---
>  include/asm-generic/io.h   |  50 ++
>  include/linux/logic_pio.h  | 174 +++
>  include/linux/pci.h|   3 +-
>  lib/Kconfig|  26 +
>  lib/Makefile   |   2 +
>  lib/logic_pio.c| 413 
>  22 files changed, 1758 insertions(+), 102 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/acpi/acpi_indirectio.c
>  create mode 100644 drivers/bus/hisi_lpc.c
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c

Booted up on a D05, was able to use the LPC-connected IPMI interface.

Tested-by: dann frazier <dann.fraz...@canonical.com>

Re: [PATCH V8 0/7] LPC: legacy ISA I/O support

[dann frazier]

s://lkml.org/lkml/2017/3/12/279
> v6 thread here: https://lkml.org/lkml/2017/1/24/25
> v5 thread here: https://lkml.org/lkml/2016/11/7/955
> v4 thread here: https://lkml.org/lkml/2016/10/20/149
> v3 thread here: https://lkml.org/lkml/2016/9/14/326
> v2 thread here: https://lkml.org/lkml/2016/9/7/356
> v1 thread here: https://lkml.org/lkml/2015/12/29/154
>
>
> Signed-off-by: Zhichang Yuan 
> zhichang.yuan (6):
>   LIBIO: Introduce a generic PIO mapping method
>   PCI: Apply the new generic I/O management on PCI IO hosts
>   OF: Add missing I/O range exception for indirect-IO devices
>   LPC: Support the device-tree LPC host on Hip06/Hip07
>   ACPI: Support the probing on the devices which apply indirect-IO
>   LPC: Add the ACPI LPC support
>
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  MAINTAINERS|   8 +
>  arch/arm64/boot/dts/hisilicon/hip06-d03.dts|   4 +
>  arch/arm64/boot/dts/hisilicon/hip06.dtsi   |  14 +
>  arch/arm64/boot/dts/hisilicon/hip07-d05.dts|   4 +
>  arch/arm64/boot/dts/hisilicon/hip07.dtsi   |  14 +
>  drivers/acpi/Makefile  |   1 +
>  drivers/acpi/acpi_indirectio.c | 344 +
>  drivers/acpi/internal.h|   5 +
>  drivers/acpi/pci_root.c|   8 +-
>  drivers/acpi/scan.c|   1 +
>  drivers/bus/Kconfig|   9 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 547 
> +
>  drivers/of/address.c   |  95 +++-
>  drivers/pci/pci.c  | 104 +---
>  include/asm-generic/io.h   |  50 ++
>  include/linux/logic_pio.h  | 174 +++
>  include/linux/pci.h|   3 +-
>  lib/Kconfig|  26 +
>  lib/Makefile   |   2 +
>  lib/logic_pio.c| 413 
>  22 files changed, 1758 insertions(+), 102 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/acpi/acpi_indirectio.c
>  create mode 100644 drivers/bus/hisi_lpc.c
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c

Booted up on a D05, was able to use the LPC-connected IPMI interface.

Tested-by: dann frazier 

Re: [PATCH V7 2/7] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Sun, Mar 12, 2017 at 8:42 PM, zhichang.yuan
 wrote:
> After introducing the new generic I/O space management(LIBIO), the original 
> PCI
> MMIO relevant helpers need to be updated based on the new interfaces defined 
> in
> LIBIO.
> This patch adapts the corresponding code to match the changes introduced by
> LIBIO.
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: Arnd Bergmann #earlier draft
> Acked-by: Bjorn Helgaas    #drivers/pci parts
> ---
>  drivers/acpi/pci_root.c |  8 +++--
>  drivers/of/address.c|  4 ++-
>  drivers/pci/pci.c   | 96 
> +++--
>  include/linux/pci.h |  3 +-
>  4 files changed, 30 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 919be0a..4d8cc24 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -730,7 +730,8 @@ static void acpi_pci_root_validate_resources(struct 
> device *dev,
> }
>  }
>
> -static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
> +static void acpi_pci_root_remap_iospace(struct fwnode_handle *fwnode,
> +   struct resource_entry *entry)
>  {
>  #ifdef PCI_IOBASE
> struct resource *res = entry->res;
> @@ -739,7 +740,7 @@ static void acpi_pci_root_remap_iospace(struct 
> resource_entry *entry)
> resource_size_t length = resource_size(res);
> unsigned long port;
>
> -   if (pci_register_io_range(cpu_addr, length))
> +   if (pci_register_io_range(fwnode, cpu_addr, length))
> goto err;
>
> port = pci_address_to_pio(cpu_addr);
> @@ -781,7 +782,8 @@ int acpi_pci_probe_root_resources(struct 
> acpi_pci_root_info *info)
> else {
> resource_list_for_each_entry_safe(entry, tmp, list) {
> if (entry->res->flags & IORESOURCE_IO)
> -   acpi_pci_root_remap_iospace(entry);
> +   acpi_pci_root_remap_iospace(>fwnode,
> +   entry);
>
> if (entry->res->flags & IORESOURCE_DISABLED)
> resource_list_destroy_entry(entry);
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..fb5d16a 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -2,6 +2,7 @@
>  #define pr_fmt(fmt)"OF: " fmt
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -323,7 +324,8 @@ int of_pci_range_to_resource(struct of_pci_range *range,
>
> if (res->flags & IORESOURCE_IO) {
> unsigned long port;
> -   err = pci_register_io_range(range->cpu_addr, range->size);
> +   err = pci_register_io_range(>fwnode, range->cpu_addr,
> +   range->size);
> if (err)
> goto invalid_range;
> port = pci_address_to_pio(range->cpu_addr);
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 7904d02..079319f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3238,65 +3238,37 @@ int pci_request_regions_exclusive(struct pci_dev 
> *pdev, const char *res_name)
>  }
>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>
> -#ifdef PCI_IOBASE
> -struct io_range {
> -   struct list_head list;
> -   phys_addr_t start;
> -   resource_size_t size;
> -};
> -
> -static LIST_HEAD(io_range_list);
> -static DEFINE_SPINLOCK(io_range_lock);
> -#endif
> -
>  /*
>   * Record the PCI IO range (expressed as CPU physical address + size).
>   * Return a negative value if an error has occured, zero otherwise
>   */
> -int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
> +   resource_size_t size)
>  {
> int err = 0;
>
>  #ifdef PCI_IOBASE
> -   struct io_range *range;
> -   resource_size_t allocated_size = 0;
> -
> -   /* check if the range hasn't been previously recorded */
> -   spin_lock(_range_lock);
> -   list_for_each_entry(range, _range_list, list) {
> -   if (addr >= range->start && addr + size <= range->start + 
> size) {
> -   /* range already registered, bail out */
> -   goto end_register;
> -   }
> -   allocated_size += range->size;
> -   }
> -
> -   /* range not registed yet, check for available space */
> -   if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> -   /* if it's too big check if 64K space can be reserved */
> -   if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
> -   err = -E2BIG;
> -   goto end_register;
> -   }
> + 

Re: [PATCH V7 2/7] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Sun, Mar 12, 2017 at 8:42 PM, zhichang.yuan
 wrote:
> After introducing the new generic I/O space management(LIBIO), the original 
> PCI
> MMIO relevant helpers need to be updated based on the new interfaces defined 
> in
> LIBIO.
> This patch adapts the corresponding code to match the changes introduced by
> LIBIO.
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: Arnd Bergmann #earlier draft
> Acked-by: Bjorn Helgaas#drivers/pci parts
> ---
>  drivers/acpi/pci_root.c |  8 +++--
>  drivers/of/address.c|  4 ++-
>  drivers/pci/pci.c   | 96 
> +++--
>  include/linux/pci.h |  3 +-
>  4 files changed, 30 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 919be0a..4d8cc24 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -730,7 +730,8 @@ static void acpi_pci_root_validate_resources(struct 
> device *dev,
> }
>  }
>
> -static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
> +static void acpi_pci_root_remap_iospace(struct fwnode_handle *fwnode,
> +   struct resource_entry *entry)
>  {
>  #ifdef PCI_IOBASE
> struct resource *res = entry->res;
> @@ -739,7 +740,7 @@ static void acpi_pci_root_remap_iospace(struct 
> resource_entry *entry)
> resource_size_t length = resource_size(res);
> unsigned long port;
>
> -   if (pci_register_io_range(cpu_addr, length))
> +   if (pci_register_io_range(fwnode, cpu_addr, length))
> goto err;
>
> port = pci_address_to_pio(cpu_addr);
> @@ -781,7 +782,8 @@ int acpi_pci_probe_root_resources(struct 
> acpi_pci_root_info *info)
> else {
> resource_list_for_each_entry_safe(entry, tmp, list) {
> if (entry->res->flags & IORESOURCE_IO)
> -   acpi_pci_root_remap_iospace(entry);
> +   acpi_pci_root_remap_iospace(>fwnode,
> +   entry);
>
> if (entry->res->flags & IORESOURCE_DISABLED)
> resource_list_destroy_entry(entry);
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..fb5d16a 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -2,6 +2,7 @@
>  #define pr_fmt(fmt)"OF: " fmt
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -323,7 +324,8 @@ int of_pci_range_to_resource(struct of_pci_range *range,
>
> if (res->flags & IORESOURCE_IO) {
> unsigned long port;
> -   err = pci_register_io_range(range->cpu_addr, range->size);
> +   err = pci_register_io_range(>fwnode, range->cpu_addr,
> +   range->size);
> if (err)
> goto invalid_range;
> port = pci_address_to_pio(range->cpu_addr);
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 7904d02..079319f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3238,65 +3238,37 @@ int pci_request_regions_exclusive(struct pci_dev 
> *pdev, const char *res_name)
>  }
>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>
> -#ifdef PCI_IOBASE
> -struct io_range {
> -   struct list_head list;
> -   phys_addr_t start;
> -   resource_size_t size;
> -};
> -
> -static LIST_HEAD(io_range_list);
> -static DEFINE_SPINLOCK(io_range_lock);
> -#endif
> -
>  /*
>   * Record the PCI IO range (expressed as CPU physical address + size).
>   * Return a negative value if an error has occured, zero otherwise
>   */
> -int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
> +   resource_size_t size)
>  {
> int err = 0;
>
>  #ifdef PCI_IOBASE
> -   struct io_range *range;
> -   resource_size_t allocated_size = 0;
> -
> -   /* check if the range hasn't been previously recorded */
> -   spin_lock(_range_lock);
> -   list_for_each_entry(range, _range_list, list) {
> -   if (addr >= range->start && addr + size <= range->start + 
> size) {
> -   /* range already registered, bail out */
> -   goto end_register;
> -   }
> -   allocated_size += range->size;
> -   }
> -
> -   /* range not registed yet, check for available space */
> -   if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> -   /* if it's too big check if 64K space can be reserved */
> -   if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
> -   err = -E2BIG;
> -   goto end_register;
> -   }
> +   struct libio_range *range, *tmprange;
>
> -   size = SZ_64K;
> -   pr_warn("Requested IO 

Re: [PATCH v2 06/18] arm64: arch_timer: Add infrastructure for multiple erratum detection methods

[dann frazier]

On Mon, Mar 20, 2017 at 11:48 AM, Marc Zyngier  wrote:
> We're currently stuck with DT when it comes to handling errata, which
> is pretty restrictive. In order to make things more flexible, let's
> introduce an infrastructure that could support alternative discovery
> methods. No change in functionality.
>
> Reviewed-by: Hanjun Guo 
> Signed-off-by: Marc Zyngier 
> ---
>  arch/arm64/include/asm/arch_timer.h  |  7 +++-
>  drivers/clocksource/arm_arch_timer.c | 80 
> +++-
>  2 files changed, 75 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/include/asm/arch_timer.h 
> b/arch/arm64/include/asm/arch_timer.h
> index b4b34004a21e..5cd964e90d11 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -37,9 +37,14 @@ extern struct static_key_false arch_timer_read_ool_enabled;
>  #define needs_unstable_timer_counter_workaround()  false
>  #endif
>
> +enum arch_timer_erratum_match_type {
> +   ate_match_dt,
> +};
>
>  struct arch_timer_erratum_workaround {
> -   const char *id; /* Indicate the Erratum ID */
> +   enum arch_timer_erratum_match_type match_type;
> +   const void *id;
> +   const char *desc;
> u32 (*read_cntp_tval_el0)(void);
> u32 (*read_cntv_tval_el0)(void);
> u64 (*read_cntvct_el0)(void);
> diff --git a/drivers/clocksource/arm_arch_timer.c 
> b/drivers/clocksource/arm_arch_timer.c
> index 7a8a4117f123..6a0f0e161a0f 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -182,7 +182,9 @@ EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
>  static const struct arch_timer_erratum_workaround ool_workarounds[] = {
>  #ifdef CONFIG_FSL_ERRATUM_A008585
> {
> +   .match_type = ate_match_dt,
> .id = "fsl,erratum-a008585",
> +   .desc = "Freescale erratum a005858",
> .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
> .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
> .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
> @@ -190,13 +192,78 @@ static const struct arch_timer_erratum_workaround 
> ool_workarounds[] = {
>  #endif
>  #ifdef CONFIG_HISILICON_ERRATUM_161010101
> {
> +   .match_type = ate_match_dt,
> .id = "hisilicon,erratum-161010101",
> +   .desc = "HiSilicon erratum 161010101",
> .read_cntp_tval_el0 = hisi_161010101_read_cntp_tval_el0,
> .read_cntv_tval_el0 = hisi_161010101_read_cntv_tval_el0,
> .read_cntvct_el0 = hisi_161010101_read_cntvct_el0,
> },
>  #endif
>  };
> +
> +typedef bool (*ate_match_fn_t)(const struct arch_timer_erratum_workaround *,
> +  const void *);
> +
> +static
> +bool arch_timer_check_dt_erratum(const struct arch_timer_erratum_workaround 
> *wa,
> +const void *arg)
> +{
> +   const struct device_node *np = arg;
> +
> +   return of_property_read_bool(np, wa->id);
> +}
> +
> +static const struct arch_timer_erratum_workaround *
> +arch_timer_iterate_errata(enum arch_timer_erratum_match_type type,
> + ate_match_fn_t match_fn,
> + void *arg)
> +{
> +   int i;
> +
> +   for (i = 0; i < ARRAY_SIZE(ool_workarounds); i++) {
> +   if (ool_workarounds[i].match_type != type)
> +   continue;
> +
> +   if (match_fn(_workarounds[i], arg))
> +   return _workarounds[i];
> +   }
> +
> +   return NULL;
> +}
> +
> +static
> +void arch_timer_enable_workaround(const struct arch_timer_erratum_workaround 
> *wa)
> +{
> +   timer_unstable_counter_workaround = wa;
> +   static_branch_enable(_timer_read_ool_enabled);
> +}
> +
> +static void arch_timer_check_ool_workaround(enum 
> arch_timer_erratum_match_type type,
> +   void *arg)
> +{
> +   const struct arch_timer_erratum_workaround *wa;
> +   ate_match_fn_t match_fn = NULL;
> +
> +   if (static_branch_unlikely(_timer_read_ool_enabled))
> +   return;
> +
> +   switch (type) {
> +   case ate_match_dt:
> +   match_fn = arch_timer_check_dt_erratum;
> +   break;

hey Marc,
   Would it make sense to have a default case here that warns &
returns? That wouldn't get hit by this series as-is, but might avoid a
NULL callback in the future.

  -dann

> +   }
> +
> +   wa = arch_timer_iterate_errata(type, match_fn, arg);
> +   if (!wa)
> +   return;
> +
> +   arch_timer_enable_workaround(wa);
> +   pr_info("Enabling global workaround for %s\n", wa->desc);
> +}
> +
> +#else
> +#define arch_timer_check_ool_workaround(t,a)   do { } while(0)
>  #endif /* 

Re: [PATCH v2 06/18] arm64: arch_timer: Add infrastructure for multiple erratum detection methods

[dann frazier]

On Mon, Mar 20, 2017 at 11:48 AM, Marc Zyngier  wrote:
> We're currently stuck with DT when it comes to handling errata, which
> is pretty restrictive. In order to make things more flexible, let's
> introduce an infrastructure that could support alternative discovery
> methods. No change in functionality.
>
> Reviewed-by: Hanjun Guo 
> Signed-off-by: Marc Zyngier 
> ---
>  arch/arm64/include/asm/arch_timer.h  |  7 +++-
>  drivers/clocksource/arm_arch_timer.c | 80 
> +++-
>  2 files changed, 75 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/include/asm/arch_timer.h 
> b/arch/arm64/include/asm/arch_timer.h
> index b4b34004a21e..5cd964e90d11 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -37,9 +37,14 @@ extern struct static_key_false arch_timer_read_ool_enabled;
>  #define needs_unstable_timer_counter_workaround()  false
>  #endif
>
> +enum arch_timer_erratum_match_type {
> +   ate_match_dt,
> +};
>
>  struct arch_timer_erratum_workaround {
> -   const char *id; /* Indicate the Erratum ID */
> +   enum arch_timer_erratum_match_type match_type;
> +   const void *id;
> +   const char *desc;
> u32 (*read_cntp_tval_el0)(void);
> u32 (*read_cntv_tval_el0)(void);
> u64 (*read_cntvct_el0)(void);
> diff --git a/drivers/clocksource/arm_arch_timer.c 
> b/drivers/clocksource/arm_arch_timer.c
> index 7a8a4117f123..6a0f0e161a0f 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -182,7 +182,9 @@ EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
>  static const struct arch_timer_erratum_workaround ool_workarounds[] = {
>  #ifdef CONFIG_FSL_ERRATUM_A008585
> {
> +   .match_type = ate_match_dt,
> .id = "fsl,erratum-a008585",
> +   .desc = "Freescale erratum a005858",
> .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
> .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
> .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
> @@ -190,13 +192,78 @@ static const struct arch_timer_erratum_workaround 
> ool_workarounds[] = {
>  #endif
>  #ifdef CONFIG_HISILICON_ERRATUM_161010101
> {
> +   .match_type = ate_match_dt,
> .id = "hisilicon,erratum-161010101",
> +   .desc = "HiSilicon erratum 161010101",
> .read_cntp_tval_el0 = hisi_161010101_read_cntp_tval_el0,
> .read_cntv_tval_el0 = hisi_161010101_read_cntv_tval_el0,
> .read_cntvct_el0 = hisi_161010101_read_cntvct_el0,
> },
>  #endif
>  };
> +
> +typedef bool (*ate_match_fn_t)(const struct arch_timer_erratum_workaround *,
> +  const void *);
> +
> +static
> +bool arch_timer_check_dt_erratum(const struct arch_timer_erratum_workaround 
> *wa,
> +const void *arg)
> +{
> +   const struct device_node *np = arg;
> +
> +   return of_property_read_bool(np, wa->id);
> +}
> +
> +static const struct arch_timer_erratum_workaround *
> +arch_timer_iterate_errata(enum arch_timer_erratum_match_type type,
> + ate_match_fn_t match_fn,
> + void *arg)
> +{
> +   int i;
> +
> +   for (i = 0; i < ARRAY_SIZE(ool_workarounds); i++) {
> +   if (ool_workarounds[i].match_type != type)
> +   continue;
> +
> +   if (match_fn(_workarounds[i], arg))
> +   return _workarounds[i];
> +   }
> +
> +   return NULL;
> +}
> +
> +static
> +void arch_timer_enable_workaround(const struct arch_timer_erratum_workaround 
> *wa)
> +{
> +   timer_unstable_counter_workaround = wa;
> +   static_branch_enable(_timer_read_ool_enabled);
> +}
> +
> +static void arch_timer_check_ool_workaround(enum 
> arch_timer_erratum_match_type type,
> +   void *arg)
> +{
> +   const struct arch_timer_erratum_workaround *wa;
> +   ate_match_fn_t match_fn = NULL;
> +
> +   if (static_branch_unlikely(_timer_read_ool_enabled))
> +   return;
> +
> +   switch (type) {
> +   case ate_match_dt:
> +   match_fn = arch_timer_check_dt_erratum;
> +   break;

hey Marc,
   Would it make sense to have a default case here that warns &
returns? That wouldn't get hit by this series as-is, but might avoid a
NULL callback in the future.

  -dann

> +   }
> +
> +   wa = arch_timer_iterate_errata(type, match_fn, arg);
> +   if (!wa)
> +   return;
> +
> +   arch_timer_enable_workaround(wa);
> +   pr_info("Enabling global workaround for %s\n", wa->desc);
> +}
> +
> +#else
> +#define arch_timer_check_ool_workaround(t,a)   do { } while(0)
>  #endif /* CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND */
>
>  static __always_inline
> @@ -960,17 +1027,8 @@ static 

Re: [PATCH 00/17] clocksource/arch_timer: Errara workaround infrastructure rework

[dann frazier]

On Mon, Mar 6, 2017 at 4:26 AM, Marc Zyngier <marc.zyng...@arm.com> wrote:
> It has recently become obvious that a number of arm64 systems have
> been blessed with a set of timers that are slightly less than perfect,
> and require a bit of hand-holding. We already have a bunch of
> errata-specific code to deal with this, but as we're adding more
> potential detection methods (DT, ACPI, capability), things are getting
> a bit out of hands.
>
> Instead of adding more ad-hoc fixes to an already difficult code base,
> let's give ourselves a bit of an infrastructure that can deal with
> this and hide most of the uggliness behind frendly accessors.
>
> The series is structured as such:
>
> - The first half of the series rework the existing workarounds,
>   allowing errata to be matched using a given detection method
>
> - Another patch allows a workaround to affect a subset of the CPUs,
>   and not the whole system
>
> - Another set of patches allow the virtual counter to be trapped when
>   accessed from userspace (something that affects the current set of
>   broken platform, and that is not worked around yet)
>
> - We then work around a Cortex-A73 erratum, whose counter can return a
>   wrong value if read while crossing a 32bit boundary
>
> - Finally, we add some ACPI-specific workarounds for HiSilicon
>   platforms that have the HISILICON_ERRATUM_161010101 defect.
>
> Note that so far, we only deal with arm64. Once the infrastructure is
> agreed upon, we can look at generalizing it (to some extent) to 32bit
> ARM (typical use case would be a 32bit guest running on an affected
> host).

Thanks Marc. Worked on our HiSilicon board:

[0.00] arm_arch_timer: Enabling global workaround for
HiSilicon erratum 161010101
[0.00] arm_arch_timer: CPU0: Trapping CNTVCT access
[0.00] arm_arch_timer: Architected cp15 timer(s) running at
50.00MHz (phys).
[0.266571] arm_arch_timer: CPU1: Trapping CNTVCT access
[0.270108] arm_arch_timer: CPU2: Trapping CNTVCT access
[...]

Tested-by: dann frazier <dann.fraz...@canonical.com>

  -dann

Re: [PATCH 00/17] clocksource/arch_timer: Errara workaround infrastructure rework

[dann frazier]

On Mon, Mar 6, 2017 at 4:26 AM, Marc Zyngier  wrote:
> It has recently become obvious that a number of arm64 systems have
> been blessed with a set of timers that are slightly less than perfect,
> and require a bit of hand-holding. We already have a bunch of
> errata-specific code to deal with this, but as we're adding more
> potential detection methods (DT, ACPI, capability), things are getting
> a bit out of hands.
>
> Instead of adding more ad-hoc fixes to an already difficult code base,
> let's give ourselves a bit of an infrastructure that can deal with
> this and hide most of the uggliness behind frendly accessors.
>
> The series is structured as such:
>
> - The first half of the series rework the existing workarounds,
>   allowing errata to be matched using a given detection method
>
> - Another patch allows a workaround to affect a subset of the CPUs,
>   and not the whole system
>
> - Another set of patches allow the virtual counter to be trapped when
>   accessed from userspace (something that affects the current set of
>   broken platform, and that is not worked around yet)
>
> - We then work around a Cortex-A73 erratum, whose counter can return a
>   wrong value if read while crossing a 32bit boundary
>
> - Finally, we add some ACPI-specific workarounds for HiSilicon
>   platforms that have the HISILICON_ERRATUM_161010101 defect.
>
> Note that so far, we only deal with arm64. Once the infrastructure is
> agreed upon, we can look at generalizing it (to some extent) to 32bit
> ARM (typical use case would be a 32bit guest running on an affected
> host).

Thanks Marc. Worked on our HiSilicon board:

[0.00] arm_arch_timer: Enabling global workaround for
HiSilicon erratum 161010101
[0.00] arm_arch_timer: CPU0: Trapping CNTVCT access
[0.00] arm_arch_timer: Architected cp15 timer(s) running at
50.00MHz (phys).
[0.266571] arm_arch_timer: CPU1: Trapping CNTVCT access
[0.270108] arm_arch_timer: CPU2: Trapping CNTVCT access
[...]

Tested-by: dann frazier 

  -dann

[PATCH] arm64: Disallow combination of ARCH_XGENE and 16K page size

[dann frazier]

16K page size is an optional feature of the architecture, and is not
supported by the X-Gene SoC family.

Signed-off-by: dann frazier 
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..b241290 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -133,6 +133,7 @@ config ARCH_VEXPRESS
 
 config ARCH_XGENE
bool "AppliedMicro X-Gene SOC Family"
+   depends on !ARM64_16K_PAGES
help
  This enables support for AppliedMicro X-Gene SOC Family
 
-- 
2.7.0

[PATCH] arm64: Disallow combination of ARCH_XGENE and 16K page size

[dann frazier]

16K page size is an optional feature of the architecture, and is not
supported by the X-Gene SoC family.

Signed-off-by: dann frazier <dann.fraz...@canonical.com>
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..b241290 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -133,6 +133,7 @@ config ARCH_VEXPRESS
 
 config ARCH_XGENE
bool "AppliedMicro X-Gene SOC Family"
+   depends on !ARM64_16K_PAGES
help
  This enables support for AppliedMicro X-Gene SOC Family
 
-- 
2.7.0

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

[Dann Frazier]

On Tue, Jun 9, 2015 at 9:31 AM, Dann Frazier  wrote:
> On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen  wrote:
>> Hi Dann,
>>
>> On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier  
>> wrote:
>>> On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen  wrote:
>>>> This patch adds syscon poweroff device node to support poweroff feature
>>>> on APM X-Gene Mustang platform
>>>
>>> hey Tai,
>>>  The reboot changes work just fine for me, but poweroff does not:
>>>
>>> [  OK  ] Reached target Final Step.
>>>  Starting Power-Off...
>>> reboot: Power down
>>> Unable to poweroff system
>>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x
>>>
>>> CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: GW   4.1.0-rc7+ #1
>>> Hardware name: APM X-Gene Mustang board (DT)
>>> Call trace:
>>> [] dump_backtrace+0x0/0x11c
>>> [] show_stack+0x10/0x1c
>>> [] dump_stack+0x88/0xc8
>>> [] panic+0xe0/0x220
>>> [] do_exit+0x990/0x994
>>> [] SyS_reboot+0x14c/0x208
>>> ---[ end Kernel panic - not syncing: Attempted to kill init! 
>>> exitcode=0x
>>>
>>>   -dann
>>>
>>
>> Thanks for testing my patches.
>> On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
>> It requires a firmware update to support power off feature.
>> May I ask what firmware version you're running on?
>
> Sure, 1.15.12.

Tai worked with me offline. For reference, this requires an updated
SlimPro firmware in addition to the u-boot update. Verified it works
for me after the update, so:

Tested-by: dann frazier 

>   -dann
>
>> Tai
>>
>>
>>>> Signed-off-by: Tai Nguyen 
>>>> ---
>>>>  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
>>>>  1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts 
>>>> b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>> index 83578e7..910d561 100644
>>>> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>>> @@ -23,6 +23,18 @@
>>>> device_type = "memory";
>>>> reg = < 0x1 0x 0x0 0x8000 >; /* Updated by 
>>>> bootloader */
>>>> };
>>>> +
>>>> +   poweroff_mbox: poweroff_mbox@10548000 {
>>>> +   compatible = "syscon";
>>>> +   reg = <0x0 0x10548000 0x0 0x30>;
>>>> +   };
>>>> +
>>>> +   poweroff: poweroff@10548010 {
>>>> +   compatible = "syscon-poweroff";
>>>> +   regmap = <_mbox>;
>>>> +   offset = <0x10>;
>>>> +   mask = <0x1>;
>>>> +   };
>>>>  };
>>>>
>>>>   {
>>>> --
>>>> 1.7.9.5
>>>>
>>>>
>>>> ___
>>>> linux-arm-kernel mailing list
>>>> linux-arm-ker...@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>> --
>> Tai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

[Dann Frazier]

On Tue, Jun 9, 2015 at 9:31 AM, Dann Frazier dann.fraz...@canonical.com wrote:
 On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen ttngu...@apm.com wrote:
 Hi Dann,

 On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier dann.fraz...@canonical.com 
 wrote:
 On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote:
 This patch adds syscon poweroff device node to support poweroff feature
 on APM X-Gene Mustang platform

 hey Tai,
  The reboot changes work just fine for me, but poweroff does not:

 [  OK  ] Reached target Final Step.
  Starting Power-Off...
 reboot: Power down
 Unable to poweroff system
 Kernel panic - not syncing: Attempted to kill init! exitcode=0x

 CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: GW   4.1.0-rc7+ #1
 Hardware name: APM X-Gene Mustang board (DT)
 Call trace:
 [ffc8990c] dump_backtrace+0x0/0x11c
 [ffc89a38] show_stack+0x10/0x1c
 [ffc0005b447c] dump_stack+0x88/0xc8
 [ffc0005b3374] panic+0xe0/0x220
 [ffcb5f24] do_exit+0x990/0x994
 [ffcd06bc] SyS_reboot+0x14c/0x208
 ---[ end Kernel panic - not syncing: Attempted to kill init! 
 exitcode=0x

   -dann


 Thanks for testing my patches.
 On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
 It requires a firmware update to support power off feature.
 May I ask what firmware version you're running on?

 Sure, 1.15.12.

Tai worked with me offline. For reference, this requires an updated
SlimPro firmware in addition to the u-boot update. Verified it works
for me after the update, so:

Tested-by: dann frazier dann.fraz...@canoncial.com

   -dann

 Tai


 Signed-off-by: Tai Nguyen ttngu...@apm.com
 ---
  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
  1 file changed, 12 insertions(+)

 diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts 
 b/arch/arm64/boot/dts/apm/apm-mustang.dts
 index 83578e7..910d561 100644
 --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
 +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
 @@ -23,6 +23,18 @@
 device_type = memory;
 reg =  0x1 0x 0x0 0x8000 ; /* Updated by 
 bootloader */
 };
 +
 +   poweroff_mbox: poweroff_mbox@10548000 {
 +   compatible = syscon;
 +   reg = 0x0 0x10548000 0x0 0x30;
 +   };
 +
 +   poweroff: poweroff@10548010 {
 +   compatible = syscon-poweroff;
 +   regmap = poweroff_mbox;
 +   offset = 0x10;
 +   mask = 0x1;
 +   };
  };

  pcie0clk {
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



 --
 Tai
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2 RESEND] power: reset: Add syscon reboot device node for APM X-Gene platform

[Dann Frazier]

On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen  wrote:
> This patch adds syscon reboot device node to support reboot feature on APM 
> X-Gene platform

Tested-by: dann frazier 

> Signed-off-by: Feng Kan  
> Signed-off-by: Tai Nguyen 
> ---
>  arch/arm64/boot/dts/apm/apm-storm.dtsi |   12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
> b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> index c8d3e0e..16efcf7 100644
> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> @@ -710,5 +710,17 @@
> dma-coherent;
> clocks = < 0>;
> };
> +
> +   scu: system-clk-controller@1700 {
> +   compatible = "apm,xgene-scu","syscon";
> +   reg = <0x0 0x1700 0x0 0x400>;
> +   };
> +
> +   reboot: reboot@1714 {
> +   compatible = "syscon-reboot";
> +   regmap = <>;
> +   offset = <0x14>;
> +   mask = <0x1>;
> +   };
> };
>  };
> --
> 1.7.9.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

[Dann Frazier]

On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen  wrote:
> Hi Dann,
>
> On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier  
> wrote:
>> On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen  wrote:
>>> This patch adds syscon poweroff device node to support poweroff feature
>>> on APM X-Gene Mustang platform
>>
>> hey Tai,
>>  The reboot changes work just fine for me, but poweroff does not:
>>
>> [  OK  ] Reached target Final Step.
>>  Starting Power-Off...
>> reboot: Power down
>> Unable to poweroff system
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x
>>
>> CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: GW   4.1.0-rc7+ #1
>> Hardware name: APM X-Gene Mustang board (DT)
>> Call trace:
>> [] dump_backtrace+0x0/0x11c
>> [] show_stack+0x10/0x1c
>> [] dump_stack+0x88/0xc8
>> [] panic+0xe0/0x220
>> [] do_exit+0x990/0x994
>> [] SyS_reboot+0x14c/0x208
>> ---[ end Kernel panic - not syncing: Attempted to kill init! 
>> exitcode=0x
>>
>>   -dann
>>
>
> Thanks for testing my patches.
> On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
> It requires a firmware update to support power off feature.
> May I ask what firmware version you're running on?

Sure, 1.15.12.

  -dann

> Tai
>
>
>>> Signed-off-by: Tai Nguyen 
>>> ---
>>>  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts 
>>> b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>> index 83578e7..910d561 100644
>>> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
>>> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
>>> @@ -23,6 +23,18 @@
>>> device_type = "memory";
>>> reg = < 0x1 0x 0x0 0x8000 >; /* Updated by 
>>> bootloader */
>>> };
>>> +
>>> +   poweroff_mbox: poweroff_mbox@10548000 {
>>> +   compatible = "syscon";
>>> +   reg = <0x0 0x10548000 0x0 0x30>;
>>> +   };
>>> +
>>> +   poweroff: poweroff@10548010 {
>>> +   compatible = "syscon-poweroff";
>>> +   regmap = <_mbox>;
>>> +   offset = <0x10>;
>>> +   mask = <0x1>;
>>> +   };
>>>  };
>>>
>>>   {
>>> --
>>> 1.7.9.5
>>>
>>>
>>> ___
>>> linux-arm-kernel mailing list
>>> linux-arm-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Tai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

[Dann Frazier]

On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen ttngu...@apm.com wrote:
 Hi Dann,

 On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier dann.fraz...@canonical.com 
 wrote:
 On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote:
 This patch adds syscon poweroff device node to support poweroff feature
 on APM X-Gene Mustang platform

 hey Tai,
  The reboot changes work just fine for me, but poweroff does not:

 [  OK  ] Reached target Final Step.
  Starting Power-Off...
 reboot: Power down
 Unable to poweroff system
 Kernel panic - not syncing: Attempted to kill init! exitcode=0x

 CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: GW   4.1.0-rc7+ #1
 Hardware name: APM X-Gene Mustang board (DT)
 Call trace:
 [ffc8990c] dump_backtrace+0x0/0x11c
 [ffc89a38] show_stack+0x10/0x1c
 [ffc0005b447c] dump_stack+0x88/0xc8
 [ffc0005b3374] panic+0xe0/0x220
 [ffcb5f24] do_exit+0x990/0x994
 [ffcd06bc] SyS_reboot+0x14c/0x208
 ---[ end Kernel panic - not syncing: Attempted to kill init! 
 exitcode=0x

   -dann


 Thanks for testing my patches.
 On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
 It requires a firmware update to support power off feature.
 May I ask what firmware version you're running on?

Sure, 1.15.12.

  -dann

 Tai


 Signed-off-by: Tai Nguyen ttngu...@apm.com
 ---
  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
  1 file changed, 12 insertions(+)

 diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts 
 b/arch/arm64/boot/dts/apm/apm-mustang.dts
 index 83578e7..910d561 100644
 --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
 +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
 @@ -23,6 +23,18 @@
 device_type = memory;
 reg =  0x1 0x 0x0 0x8000 ; /* Updated by 
 bootloader */
 };
 +
 +   poweroff_mbox: poweroff_mbox@10548000 {
 +   compatible = syscon;
 +   reg = 0x0 0x10548000 0x0 0x30;
 +   };
 +
 +   poweroff: poweroff@10548010 {
 +   compatible = syscon-poweroff;
 +   regmap = poweroff_mbox;
 +   offset = 0x10;
 +   mask = 0x1;
 +   };
  };

  pcie0clk {
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



 --
 Tai
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2 RESEND] power: reset: Add syscon reboot device node for APM X-Gene platform

[Dann Frazier]

On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote:
 This patch adds syscon reboot device node to support reboot feature on APM 
 X-Gene platform

Tested-by: dann frazier dann.fraz...@canonical.com

 Signed-off-by: Feng Kan  f...@apm.com
 Signed-off-by: Tai Nguyen ttngu...@apm.com
 ---
  arch/arm64/boot/dts/apm/apm-storm.dtsi |   12 
  1 file changed, 12 insertions(+)

 diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
 b/arch/arm64/boot/dts/apm/apm-storm.dtsi
 index c8d3e0e..16efcf7 100644
 --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
 +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
 @@ -710,5 +710,17 @@
 dma-coherent;
 clocks = dmaclk 0;
 };
 +
 +   scu: system-clk-controller@1700 {
 +   compatible = apm,xgene-scu,syscon;
 +   reg = 0x0 0x1700 0x0 0x400;
 +   };
 +
 +   reboot: reboot@1714 {
 +   compatible = syscon-reboot;
 +   regmap = scu;
 +   offset = 0x14;
 +   mask = 0x1;
 +   };
 };
  };
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

[Dann Frazier]

On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen  wrote:
> This patch adds syscon poweroff device node to support poweroff feature
> on APM X-Gene Mustang platform

hey Tai,
 The reboot changes work just fine for me, but poweroff does not:

[  OK  ] Reached target Final Step.
 Starting Power-Off...
reboot: Power down
Unable to poweroff system
Kernel panic - not syncing: Attempted to kill init! exitcode=0x

CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: GW   4.1.0-rc7+ #1
Hardware name: APM X-Gene Mustang board (DT)
Call trace:
[] dump_backtrace+0x0/0x11c
[] show_stack+0x10/0x1c
[] dump_stack+0x88/0xc8
[] panic+0xe0/0x220
[] do_exit+0x990/0x994
[] SyS_reboot+0x14c/0x208
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x

  -dann

> Signed-off-by: Tai Nguyen 
> ---
>  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts 
> b/arch/arm64/boot/dts/apm/apm-mustang.dts
> index 83578e7..910d561 100644
> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
> @@ -23,6 +23,18 @@
> device_type = "memory";
> reg = < 0x1 0x 0x0 0x8000 >; /* Updated by 
> bootloader */
> };
> +
> +   poweroff_mbox: poweroff_mbox@10548000 {
> +   compatible = "syscon";
> +   reg = <0x0 0x10548000 0x0 0x30>;
> +   };
> +
> +   poweroff: poweroff@10548010 {
> +   compatible = "syscon-poweroff";
> +   regmap = <_mbox>;
> +   offset = <0x10>;
> +   mask = <0x1>;
> +   };
>  };
>
>   {
> --
> 1.7.9.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

[Dann Frazier]

On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote:
 This patch adds syscon poweroff device node to support poweroff feature
 on APM X-Gene Mustang platform

hey Tai,
 The reboot changes work just fine for me, but poweroff does not:

[  OK  ] Reached target Final Step.
 Starting Power-Off...
reboot: Power down
Unable to poweroff system
Kernel panic - not syncing: Attempted to kill init! exitcode=0x

CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: GW   4.1.0-rc7+ #1
Hardware name: APM X-Gene Mustang board (DT)
Call trace:
[ffc8990c] dump_backtrace+0x0/0x11c
[ffc89a38] show_stack+0x10/0x1c
[ffc0005b447c] dump_stack+0x88/0xc8
[ffc0005b3374] panic+0xe0/0x220
[ffcb5f24] do_exit+0x990/0x994
[ffcd06bc] SyS_reboot+0x14c/0x208
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x

  -dann

 Signed-off-by: Tai Nguyen ttngu...@apm.com
 ---
  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
  1 file changed, 12 insertions(+)

 diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts 
 b/arch/arm64/boot/dts/apm/apm-mustang.dts
 index 83578e7..910d561 100644
 --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
 +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
 @@ -23,6 +23,18 @@
 device_type = memory;
 reg =  0x1 0x 0x0 0x8000 ; /* Updated by 
 bootloader */
 };
 +
 +   poweroff_mbox: poweroff_mbox@10548000 {
 +   compatible = syscon;
 +   reg = 0x0 0x10548000 0x0 0x30;
 +   };
 +
 +   poweroff: poweroff@10548010 {
 +   compatible = syscon-poweroff;
 +   regmap = poweroff_mbox;
 +   offset = 0x10;
 +   mask = 0x1;
 +   };
  };

  pcie0clk {
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] tools: testing: selftests: mq_perf_tests: Fix infinite loop on ARM

[dann frazier]

We can't use a char type to check for a negative return value since char
isn't guaranteed to be signed. Indeed, the char type tends to be unsigned on
ARM.

Signed-off-by: dann frazier 
---
 tools/testing/selftests/mqueue/mq_perf_tests.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/testing/selftests/mqueue/mq_perf_tests.c 
b/tools/testing/selftests/mqueue/mq_perf_tests.c
index 94dae65..8519e9e 100644
--- a/tools/testing/selftests/mqueue/mq_perf_tests.c
+++ b/tools/testing/selftests/mqueue/mq_perf_tests.c
@@ -536,10 +536,9 @@ int main(int argc, char *argv[])
 {
struct mq_attr attr;
char *option, *next_option;
-   int i, cpu;
+   int i, cpu, rc;
struct sigaction sa;
poptContext popt_context;
-   char rc;
void *retval;
 
main_thread = pthread_self();
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] tools: testing: selftests: mq_perf_tests: Fix infinite loop on ARM

[dann frazier]

We can't use a char type to check for a negative return value since char
isn't guaranteed to be signed. Indeed, the char type tends to be unsigned on
ARM.

Signed-off-by: dann frazier dann.fraz...@canonical.com
---
 tools/testing/selftests/mqueue/mq_perf_tests.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/testing/selftests/mqueue/mq_perf_tests.c 
b/tools/testing/selftests/mqueue/mq_perf_tests.c
index 94dae65..8519e9e 100644
--- a/tools/testing/selftests/mqueue/mq_perf_tests.c
+++ b/tools/testing/selftests/mqueue/mq_perf_tests.c
@@ -536,10 +536,9 @@ int main(int argc, char *argv[])
 {
struct mq_attr attr;
char *option, *next_option;
-   int i, cpu;
+   int i, cpu, rc;
struct sigaction sa;
poptContext popt_context;
-   char rc;
void *retval;
 
main_thread = pthread_self();
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 4/4] drivers: net: Add APM X-Gene SoC ethernet driver support.

[Dann Frazier]

On Fri, Jun 20, 2014 at 5:18 PM, Iyappan Subramanian
 wrote:
> This patch adds network driver for APM X-Gene SoC ethernet.
>
> Signed-off-by: Iyappan Subramanian 
> Signed-off-by: Ravi Patel 
> Signed-off-by: Keyur Chudgar 
> ---
>  drivers/net/ethernet/Kconfig   |   1 +
>  drivers/net/ethernet/Makefile  |   1 +
>  drivers/net/ethernet/apm/Kconfig   |   1 +
>  drivers/net/ethernet/apm/Makefile  |   5 +
>  drivers/net/ethernet/apm/xgene/Kconfig |   9 +
>  drivers/net/ethernet/apm/xgene/Makefile|   6 +
>  .../net/ethernet/apm/xgene/xgene_enet_ethtool.c| 125 +++
>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 848 +++
>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 394 +
>  drivers/net/ethernet/apm/xgene/xgene_enet_main.c   | 939 
> +
>  drivers/net/ethernet/apm/xgene/xgene_enet_main.h   | 109 +++
>  11 files changed, 2438 insertions(+)
>  create mode 100644 drivers/net/ethernet/apm/Kconfig
>  create mode 100644 drivers/net/ethernet/apm/Makefile
>  create mode 100644 drivers/net/ethernet/apm/xgene/Kconfig
>  create mode 100644 drivers/net/ethernet/apm/xgene/Makefile
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.c
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.h
[...]
> +static struct xgene_enet_desc_ring *xgene_enet_create_desc_ring(
> +   struct net_device *ndev, u32 ring_num,
> +   enum xgene_enet_ring_cfgsize cfgsize, u32 ring_id)
> +{
> +   struct xgene_enet_desc_ring *ring;
> +   struct xgene_enet_pdata *pdata = netdev_priv(ndev);
> +   struct device *dev = >pdev->dev;
> +   u32 size;
> +
> +   ring = devm_kzalloc(dev, sizeof(struct xgene_enet_desc_ring),
> +   GFP_KERNEL);
> +   if (!ring)
> +   return NULL;
> +
> +   ring->ndev = ndev;
> +   ring->num = ring_num;
> +   ring->cfgsize = cfgsize;
> +   ring->id = ring_id;
> +
> +   size = xgene_enet_get_ring_size(dev, cfgsize);
> +   ring->desc_addr = dma_zalloc_coherent(dev, size, >dma,
> + GFP_KERNEL);

Iyappan,
When testing this driver on a 3.16-rc2 base, I'm finding that
desc_addr gets assigned to NULL here, which results in an oops later
on (see below).

I wasn't seeing this before (3.15 base), so I'm guessing something
changed upstream, or in my config, to change this behavior. But it
does illuminate a place where we could maybe use some better error
handling (also see below).

> +   if (!ring->desc_addr)
> +   goto err;
> +   ring->size = size;
> +
> +   ring->cmd_base = pdata->ring_cmd_addr + (ring->num << 6);
> +   ring->cmd = ring->cmd_base + INC_DEC_CMD_ADDR;
> +   pdata->rm = RM3;
> +   ring = xgene_enet_setup_ring(ring);
> +   netdev_dbg(ndev, "ring info: num=%d  size=%d  id=%d  slots=%d\n",
> +  ring->num, ring->size, ring->id, ring->slots);
> +
> +   return ring;
> +err:
> +   dma_free_coherent(dev, size, ring->desc_addr, ring->dma);
> +   devm_kfree(dev, ring);
> +
> +   return NULL;
> +}
> +
> +static u16 xgene_enet_get_ring_id(enum xgene_ring_owner owner, u8 bufnum)
> +{
> +   return (owner << 6) | (bufnum & GENMASK(5, 0));
> +}
> +
> +static int xgene_enet_create_desc_rings(struct net_device *ndev)
> +{
> +   struct xgene_enet_pdata *pdata = netdev_priv(ndev);
> +   struct device *dev = >pdev->dev;
> +   struct xgene_enet_desc_ring *rx_ring, *tx_ring, *cp_ring;
> +   struct xgene_enet_desc_ring *buf_pool = NULL;
> +   u8 cpu_bufnum = 0, eth_bufnum = 0;
> +   u8 bp_bufnum = 0x20;
> +   u16 ring_id, ring_num = 0;
> +   int ret;
> +
> +   /* allocate rx descriptor ring */
> +   ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
> +   rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
> + RING_CFGSIZE_16KB, ring_id);
> +   if (IS_ERR_OR_NULL(rx_ring)) {
> +   ret = PTR_ERR(rx_ring);
> +   goto err;
> +   }

Here we test for IS_ERR_OR_NULL. In the oops I'm hitting, rx_ring is
NULL here - but PTR_ERR() apparently returns 0 in that case. So this
function ends up returning no error.

> +   /* allocate buffer pool for receiving packets */
> +   ring_id = xgene_enet_get_ring_id(RING_OWNER_ETH0, bp_bufnum++);
> +   buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
> +  RING_CFGSIZE_2KB, ring_id);
> +   if (IS_ERR_OR_NULL(buf_pool)) {
> +   ret = PTR_ERR(buf_pool);
> +   goto 

Re: [PATCH v8 4/4] drivers: net: Add APM X-Gene SoC ethernet driver support.

[Dann Frazier]

On Fri, Jun 20, 2014 at 5:18 PM, Iyappan Subramanian
isubraman...@apm.com wrote:
 This patch adds network driver for APM X-Gene SoC ethernet.

 Signed-off-by: Iyappan Subramanian isubraman...@apm.com
 Signed-off-by: Ravi Patel rapa...@apm.com
 Signed-off-by: Keyur Chudgar kchud...@apm.com
 ---
  drivers/net/ethernet/Kconfig   |   1 +
  drivers/net/ethernet/Makefile  |   1 +
  drivers/net/ethernet/apm/Kconfig   |   1 +
  drivers/net/ethernet/apm/Makefile  |   5 +
  drivers/net/ethernet/apm/xgene/Kconfig |   9 +
  drivers/net/ethernet/apm/xgene/Makefile|   6 +
  .../net/ethernet/apm/xgene/xgene_enet_ethtool.c| 125 +++
  drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 848 +++
  drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 394 +
  drivers/net/ethernet/apm/xgene/xgene_enet_main.c   | 939 
 +
  drivers/net/ethernet/apm/xgene/xgene_enet_main.h   | 109 +++
  11 files changed, 2438 insertions(+)
  create mode 100644 drivers/net/ethernet/apm/Kconfig
  create mode 100644 drivers/net/ethernet/apm/Makefile
  create mode 100644 drivers/net/ethernet/apm/xgene/Kconfig
  create mode 100644 drivers/net/ethernet/apm/xgene/Makefile
  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c
  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.c
  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.h
[...]
 +static struct xgene_enet_desc_ring *xgene_enet_create_desc_ring(
 +   struct net_device *ndev, u32 ring_num,
 +   enum xgene_enet_ring_cfgsize cfgsize, u32 ring_id)
 +{
 +   struct xgene_enet_desc_ring *ring;
 +   struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 +   struct device *dev = pdata-pdev-dev;
 +   u32 size;
 +
 +   ring = devm_kzalloc(dev, sizeof(struct xgene_enet_desc_ring),
 +   GFP_KERNEL);
 +   if (!ring)
 +   return NULL;
 +
 +   ring-ndev = ndev;
 +   ring-num = ring_num;
 +   ring-cfgsize = cfgsize;
 +   ring-id = ring_id;
 +
 +   size = xgene_enet_get_ring_size(dev, cfgsize);
 +   ring-desc_addr = dma_zalloc_coherent(dev, size, ring-dma,
 + GFP_KERNEL);

Iyappan,
When testing this driver on a 3.16-rc2 base, I'm finding that
desc_addr gets assigned to NULL here, which results in an oops later
on (see below).

I wasn't seeing this before (3.15 base), so I'm guessing something
changed upstream, or in my config, to change this behavior. But it
does illuminate a place where we could maybe use some better error
handling (also see below).

 +   if (!ring-desc_addr)
 +   goto err;
 +   ring-size = size;
 +
 +   ring-cmd_base = pdata-ring_cmd_addr + (ring-num  6);
 +   ring-cmd = ring-cmd_base + INC_DEC_CMD_ADDR;
 +   pdata-rm = RM3;
 +   ring = xgene_enet_setup_ring(ring);
 +   netdev_dbg(ndev, ring info: num=%d  size=%d  id=%d  slots=%d\n,
 +  ring-num, ring-size, ring-id, ring-slots);
 +
 +   return ring;
 +err:
 +   dma_free_coherent(dev, size, ring-desc_addr, ring-dma);
 +   devm_kfree(dev, ring);
 +
 +   return NULL;
 +}
 +
 +static u16 xgene_enet_get_ring_id(enum xgene_ring_owner owner, u8 bufnum)
 +{
 +   return (owner  6) | (bufnum  GENMASK(5, 0));
 +}
 +
 +static int xgene_enet_create_desc_rings(struct net_device *ndev)
 +{
 +   struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 +   struct device *dev = pdata-pdev-dev;
 +   struct xgene_enet_desc_ring *rx_ring, *tx_ring, *cp_ring;
 +   struct xgene_enet_desc_ring *buf_pool = NULL;
 +   u8 cpu_bufnum = 0, eth_bufnum = 0;
 +   u8 bp_bufnum = 0x20;
 +   u16 ring_id, ring_num = 0;
 +   int ret;
 +
 +   /* allocate rx descriptor ring */
 +   ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
 +   rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
 + RING_CFGSIZE_16KB, ring_id);
 +   if (IS_ERR_OR_NULL(rx_ring)) {
 +   ret = PTR_ERR(rx_ring);
 +   goto err;
 +   }

Here we test for IS_ERR_OR_NULL. In the oops I'm hitting, rx_ring is
NULL here - but PTR_ERR() apparently returns 0 in that case. So this
function ends up returning no error.

 +   /* allocate buffer pool for receiving packets */
 +   ring_id = xgene_enet_get_ring_id(RING_OWNER_ETH0, bp_bufnum++);
 +   buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
 +  RING_CFGSIZE_2KB, ring_id);
 +   if (IS_ERR_OR_NULL(buf_pool)) {
 +   ret = PTR_ERR(buf_pool);
 +   goto err;
 +   }
 +
 +   

lustre virtual block device doesn't build w/ CONFIG_ARM64_64K_PAGES=y

[dann frazier]

With current git, lustre fails to build with CONFIG_ARM64_64K_PAGES=y
and CONFIG_LUSTRE_LLITE_LLOOP=m:

make -f scripts/Makefile.build obj=drivers/staging/lustre/lustre/llite
  gcc -Wp,-MD,drivers/staging/lustre/lustre/llite/.lloop.o.d  -nostdinc 
-isystem /usr/lib/gcc/aarch64-linux-gnu/4.8/include -I./arch/arm64/include 
-Iarch/arm64/include/generated  -Iinclude -I./arch/arm64/include/uapi 
-Iarch/arm64/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi 
-include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef 
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
-Werror-implicit-function-declaration -Wno-format-security -mgeneral-regs-only 
-fno-delete-null-pointer-checks -O2 -Wframe-larger-than=1024 
-fno-stack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer 
-fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign 
-fno-strict-overflow -fconserve-stack -Werror=implicit-int 
-Werror=strict-prototypes -Idrivers/staging/lustre/include/ 
-Idrivers/staging/lustre/lustre/llite/../include  -DMODULE  
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(lloop)"  
-D"KBUILD_MODNAME=KBUILD_STR(llite_lloop)" -c -o 
drivers/staging/lustre/lustre/llite/.tmp_lloop.o 
drivers/staging/lustre/lustre/llite/lloop.c
drivers/staging/lustre/lustre/llite/lloop.c: In function ‘loop_set_fd’:
drivers/staging/lustre/lustre/llite/lloop.c:523:78: error: duplicate case value
  CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
  ^
drivers/staging/lustre/lustre/llite/lloop.c:523:18: error: previously used here
  CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
  ^
scripts/Makefile.build:257: recipe for target 
'drivers/staging/lustre/lustre/llite/lloop.o' failed
make[5]: *** [drivers/staging/lustre/lustre/llite/lloop.o] Error 1
scripts/Makefile.build:404: recipe for target 
'drivers/staging/lustre/lustre/llite' failed
make[4]: *** [drivers/staging/lustre/lustre/llite] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging/lustre/lustre' 
failed
make[3]: *** [drivers/staging/lustre/lustre] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging/lustre' failed
make[2]: *** [drivers/staging/lustre] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging' failed
make[1]: *** [drivers/staging] Error 2
Makefile:893: recipe for target 'drivers' failed
make: *** [drivers] Error 2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lustre virtual block device doesn't build w/ CONFIG_ARM64_64K_PAGES=y

[dann frazier]

With current git, lustre fails to build with CONFIG_ARM64_64K_PAGES=y
and CONFIG_LUSTRE_LLITE_LLOOP=m:

make -f scripts/Makefile.build obj=drivers/staging/lustre/lustre/llite
  gcc -Wp,-MD,drivers/staging/lustre/lustre/llite/.lloop.o.d  -nostdinc 
-isystem /usr/lib/gcc/aarch64-linux-gnu/4.8/include -I./arch/arm64/include 
-Iarch/arm64/include/generated  -Iinclude -I./arch/arm64/include/uapi 
-Iarch/arm64/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi 
-include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef 
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
-Werror-implicit-function-declaration -Wno-format-security -mgeneral-regs-only 
-fno-delete-null-pointer-checks -O2 -Wframe-larger-than=1024 
-fno-stack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer 
-fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign 
-fno-strict-overflow -fconserve-stack -Werror=implicit-int 
-Werror=strict-prototypes -Idrivers/staging/lustre/include/ 
-Idrivers/staging/lustre/lustre/llite/../include  -DMODULE  
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(lloop)  
-DKBUILD_MODNAME=KBUILD_STR(llite_lloop) -c -o 
drivers/staging/lustre/lustre/llite/.tmp_lloop.o 
drivers/staging/lustre/lustre/llite/lloop.c
drivers/staging/lustre/lustre/llite/lloop.c: In function ‘loop_set_fd’:
drivers/staging/lustre/lustre/llite/lloop.c:523:78: error: duplicate case value
  CLASSERT(PAGE_CACHE_SIZE  (1  (sizeof(unsigned short) * 8)));
  ^
drivers/staging/lustre/lustre/llite/lloop.c:523:18: error: previously used here
  CLASSERT(PAGE_CACHE_SIZE  (1  (sizeof(unsigned short) * 8)));
  ^
scripts/Makefile.build:257: recipe for target 
'drivers/staging/lustre/lustre/llite/lloop.o' failed
make[5]: *** [drivers/staging/lustre/lustre/llite/lloop.o] Error 1
scripts/Makefile.build:404: recipe for target 
'drivers/staging/lustre/lustre/llite' failed
make[4]: *** [drivers/staging/lustre/lustre/llite] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging/lustre/lustre' 
failed
make[3]: *** [drivers/staging/lustre/lustre] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging/lustre' failed
make[2]: *** [drivers/staging/lustre] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging' failed
make[1]: *** [drivers/staging] Error 2
Makefile:893: recipe for target 'drivers' failed
make: *** [drivers] Error 2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] serial: uart: add hw flow control support configuration

[Dann Frazier]

On Wed, Jun 11, 2014 at 2:53 PM, Murali Karicheri  wrote:
> On 5/28/2014 4:04 PM, Dann Frazier wrote:
>>
>> On Thu, May 1, 2014 at 1:04 PM, Murali Karicheri 
>> wrote:
>>>
>>> 8250 uart driver currently supports only software assisted hw flow
>>> control. The software assisted hw flow control maintains a hw_stopped
>>> flag in the tty structure to stop and start transmission and use modem
>>> status interrupt for the event to drive the handshake signals. This is
>>> not needed if hw has flow control capabilities. This patch adds a
>>> DT attribute for enabling hw flow control for a uart port. Also skip
>>> stop and start if this flag is present in flag field of the port
>>> structure.
>>
>> ubuntu@hwflow:~$ sudo stty -a --file /dev/ttyS0 |tr ' ' '\n' | grep
>> crtscts
>> crtscts
>> ubuntu@hwflow:~$ ls
>> /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
>> /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
>> ubuntu@hwflow:~$ python
>> Python 2.7.6 (default, Mar 22 2014, 22:58:30)
>> [GCC 4.8.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>
>>>>> UPF_HARDWARE_FLOW = 1 << 21
>>>>> if 0xB920 & UPF_HARDWARE_FLOW:
>>
>> ... print "OK"
>> ...
>> OK
>>
>> Hope that's a reasonable test case. Test fails when booted w/o
>> has-hw-flow-control attribute.
>>
>> Tested-by: dann frazier 
>
> What is the verdict? pass/fail? Ok/Not OK to merge?

Murali,

 It is working for me, and appears to already be Linus' tree.

  -dann

> Murali
>
>>> Signed-off-by: Murali Karicheri 
>>>
>>> CC: Rob Herring 
>>> CC: Pawel Moll 
>>> CC: Mark Rutland 
>>> CC: Ian Campbell 
>>> CC: Kumar Gala 
>>> CC: Randy Dunlap 
>>> CC: Greg Kroah-Hartman 
>>> CC: Jiri Slaby 
>>> CC: Santosh Shilimkar 
>>> ---
>>>   .../devicetree/bindings/serial/of-serial.txt   |1 +
>>>   drivers/tty/serial/8250/8250_core.c|6 --
>>>   drivers/tty/serial/of_serial.c |4 
>>>   drivers/tty/serial/serial_core.c   |   12 +---
>>>   4 files changed, 18 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
>>> b/Documentation/devicetree/bindings/serial/of-serial.txt
>>> index 1928a3e..7705477 100644
>>> --- a/Documentation/devicetree/bindings/serial/of-serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
>>> @@ -37,6 +37,7 @@ Optional properties:
>>>   - auto-flow-control: one way to enable automatic flow control support.
>>> The
>>> driver is allowed to detect support for the capability even without
>>> this
>>> property.
>>> +- has-hw-flow-control: the hardware has flow control capability.
>>>
>>>   Example:
>>>
>>> diff --git a/drivers/tty/serial/8250/8250_core.c
>>> b/drivers/tty/serial/8250/8250_core.c
>>> index 0e1bf88..b69aff2 100644
>>> --- a/drivers/tty/serial/8250/8250_core.c
>>> +++ b/drivers/tty/serial/8250/8250_core.c
>>> @@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port,
>>> struct ktermios *termios,
>>>   * the trigger, or the MCR RTS bit is cleared.  In the case
>>> where
>>>   * the remote UART is not using CTS auto flow control, we must
>>>   * have sufficient FIFO entries for the latency of the remote
>>> -* UART to respond.  IOW, at least 32 bytes of FIFO.
>>> +* UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
>>> +* AFE if hw flow control is supported
>>>   */
>>> -   if (up->capabilities & UART_CAP_AFE && port->fifosize >= 32) {
>>> +   if ((up->capabilities & UART_CAP_AFE && (port->fifosize >= 32))
>>> ||
>>> +   (port->flags & UPF_HARD_FLOW)) {
>>>  up->mcr &= ~UART_MCR_AFE;
>>>  if (termios->c_cflag & CRTSCTS)
>>>  up->mcr |= UART_MCR_AFE;
>>> diff --git a/drivers/tty/serial/of_serial.c
>>> b/drivers/tty/serial/of_serial.c
>>> index 9924660..77ec6a1 100644
>>> --- a/drivers/tty/serial/of_serial.c
>>> +++ b/drivers/tty/

Re: [PATCH v2] serial: uart: add hw flow control support configuration

[Dann Frazier]

On Wed, Jun 11, 2014 at 2:53 PM, Murali Karicheri m-kariche...@ti.com wrote:
 On 5/28/2014 4:04 PM, Dann Frazier wrote:

 On Thu, May 1, 2014 at 1:04 PM, Murali Karicheri m-kariche...@ti.com
 wrote:

 8250 uart driver currently supports only software assisted hw flow
 control. The software assisted hw flow control maintains a hw_stopped
 flag in the tty structure to stop and start transmission and use modem
 status interrupt for the event to drive the handshake signals. This is
 not needed if hw has flow control capabilities. This patch adds a
 DT attribute for enabling hw flow control for a uart port. Also skip
 stop and start if this flag is present in flag field of the port
 structure.

 ubuntu@hwflow:~$ sudo stty -a --file /dev/ttyS0 |tr ' ' '\n' | grep
 crtscts
 crtscts
 ubuntu@hwflow:~$ ls
 /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
 /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
 ubuntu@hwflow:~$ python
 Python 2.7.6 (default, Mar 22 2014, 22:58:30)
 [GCC 4.8.2] on linux2
 Type help, copyright, credits or license for more information.

 UPF_HARDWARE_FLOW = 1  21
 if 0xB920  UPF_HARDWARE_FLOW:

 ... print OK
 ...
 OK

 Hope that's a reasonable test case. Test fails when booted w/o
 has-hw-flow-control attribute.

 Tested-by: dann frazier dann.fraz...@canonical.com

 What is the verdict? pass/fail? Ok/Not OK to merge?

Murali,

 It is working for me, and appears to already be Linus' tree.

  -dann

 Murali

 Signed-off-by: Murali Karicheri m-kariche...@ti.com

 CC: Rob Herring robh...@kernel.org
 CC: Pawel Moll pawel.m...@arm.com
 CC: Mark Rutland mark.rutl...@arm.com
 CC: Ian Campbell ijc+devicet...@hellion.org.uk
 CC: Kumar Gala ga...@codeaurora.org
 CC: Randy Dunlap rdun...@infradead.org
 CC: Greg Kroah-Hartman gre...@linuxfoundation.org
 CC: Jiri Slaby jsl...@suse.cz
 CC: Santosh Shilimkar santosh.shilim...@ti.com
 ---
   .../devicetree/bindings/serial/of-serial.txt   |1 +
   drivers/tty/serial/8250/8250_core.c|6 --
   drivers/tty/serial/of_serial.c |4 
   drivers/tty/serial/serial_core.c   |   12 +---
   4 files changed, 18 insertions(+), 5 deletions(-)

 diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
 b/Documentation/devicetree/bindings/serial/of-serial.txt
 index 1928a3e..7705477 100644
 --- a/Documentation/devicetree/bindings/serial/of-serial.txt
 +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
 @@ -37,6 +37,7 @@ Optional properties:
   - auto-flow-control: one way to enable automatic flow control support.
 The
 driver is allowed to detect support for the capability even without
 this
 property.
 +- has-hw-flow-control: the hardware has flow control capability.

   Example:

 diff --git a/drivers/tty/serial/8250/8250_core.c
 b/drivers/tty/serial/8250/8250_core.c
 index 0e1bf88..b69aff2 100644
 --- a/drivers/tty/serial/8250/8250_core.c
 +++ b/drivers/tty/serial/8250/8250_core.c
 @@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port,
 struct ktermios *termios,
   * the trigger, or the MCR RTS bit is cleared.  In the case
 where
   * the remote UART is not using CTS auto flow control, we must
   * have sufficient FIFO entries for the latency of the remote
 -* UART to respond.  IOW, at least 32 bytes of FIFO.
 +* UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
 +* AFE if hw flow control is supported
   */
 -   if (up-capabilities  UART_CAP_AFE  port-fifosize = 32) {
 +   if ((up-capabilities  UART_CAP_AFE  (port-fifosize = 32))
 ||
 +   (port-flags  UPF_HARD_FLOW)) {
  up-mcr = ~UART_MCR_AFE;
  if (termios-c_cflag  CRTSCTS)
  up-mcr |= UART_MCR_AFE;
 diff --git a/drivers/tty/serial/of_serial.c
 b/drivers/tty/serial/of_serial.c
 index 9924660..77ec6a1 100644
 --- a/drivers/tty/serial/of_serial.c
 +++ b/drivers/tty/serial/of_serial.c
 @@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct
 platform_device *ofdev)
auto-flow-control))
  port8250.capabilities |= UART_CAP_AFE;

 +   if (of_property_read_bool(ofdev-dev.of_node,
 + has-hw-flow-control))
 +   port8250.port.flags |= UPF_HARD_FLOW;
 +
  ret = serial8250_register_8250_port(port8250);
  break;
  }
 diff --git a/drivers/tty/serial/serial_core.c
 b/drivers/tty/serial/serial_core.c
 index b68550d..851707a 100644
 --- a/drivers/tty/serial/serial_core.c
 +++ b/drivers/tty/serial/serial_core.c
 @@ -174,8 +174,12 @@ static int uart_port_startup(struct tty_struct *tty,
 struct uart_state *state,
  if (tty-termios.c_cflag  CBAUD)
  uart_set_mctrl(uport, TIOCM_RTS |
 TIOCM_DTR

Re: [PATCH v2] serial: uart: add hw flow control support configuration

[Dann Frazier]

On Thu, May 1, 2014 at 1:04 PM, Murali Karicheri  wrote:
> 8250 uart driver currently supports only software assisted hw flow
> control. The software assisted hw flow control maintains a hw_stopped
> flag in the tty structure to stop and start transmission and use modem
> status interrupt for the event to drive the handshake signals. This is
> not needed if hw has flow control capabilities. This patch adds a
> DT attribute for enabling hw flow control for a uart port. Also skip
> stop and start if this flag is present in flag field of the port
> structure.

ubuntu@hwflow:~$ sudo stty -a --file /dev/ttyS0 |tr ' ' '\n' | grep crtscts
crtscts
ubuntu@hwflow:~$ ls /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
/proc/device-tree/soc/serial@1c021000/has-hw-flow-control
ubuntu@hwflow:~$ python
Python 2.7.6 (default, Mar 22 2014, 22:58:30)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> UPF_HARDWARE_FLOW = 1 << 21
>>> if 0xB920 & UPF_HARDWARE_FLOW:
... print "OK"
...
OK

Hope that's a reasonable test case. Test fails when booted w/o
has-hw-flow-control attribute.

Tested-by: dann frazier 

>
> Signed-off-by: Murali Karicheri 
>
> CC: Rob Herring 
> CC: Pawel Moll 
> CC: Mark Rutland 
> CC: Ian Campbell 
> CC: Kumar Gala 
> CC: Randy Dunlap 
> CC: Greg Kroah-Hartman 
> CC: Jiri Slaby 
> CC: Santosh Shilimkar 
> ---
>  .../devicetree/bindings/serial/of-serial.txt   |1 +
>  drivers/tty/serial/8250/8250_core.c|6 --
>  drivers/tty/serial/of_serial.c |4 
>  drivers/tty/serial/serial_core.c   |   12 +---
>  4 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt 
> b/Documentation/devicetree/bindings/serial/of-serial.txt
> index 1928a3e..7705477 100644
> --- a/Documentation/devicetree/bindings/serial/of-serial.txt
> +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
> @@ -37,6 +37,7 @@ Optional properties:
>  - auto-flow-control: one way to enable automatic flow control support. The
>driver is allowed to detect support for the capability even without this
>property.
> +- has-hw-flow-control: the hardware has flow control capability.
>
>  Example:
>
> diff --git a/drivers/tty/serial/8250/8250_core.c 
> b/drivers/tty/serial/8250/8250_core.c
> index 0e1bf88..b69aff2 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, 
> struct ktermios *termios,
>  * the trigger, or the MCR RTS bit is cleared.  In the case where
>  * the remote UART is not using CTS auto flow control, we must
>  * have sufficient FIFO entries for the latency of the remote
> -* UART to respond.  IOW, at least 32 bytes of FIFO.
> +* UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
> +* AFE if hw flow control is supported
>  */
> -   if (up->capabilities & UART_CAP_AFE && port->fifosize >= 32) {
> +   if ((up->capabilities & UART_CAP_AFE && (port->fifosize >= 32)) ||
> +   (port->flags & UPF_HARD_FLOW)) {
> up->mcr &= ~UART_MCR_AFE;
> if (termios->c_cflag & CRTSCTS)
> up->mcr |= UART_MCR_AFE;
> diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
> index 9924660..77ec6a1 100644
> --- a/drivers/tty/serial/of_serial.c
> +++ b/drivers/tty/serial/of_serial.c
> @@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct 
> platform_device *ofdev)
>   "auto-flow-control"))
> port8250.capabilities |= UART_CAP_AFE;
>
> +   if (of_property_read_bool(ofdev->dev.of_node,
> + "has-hw-flow-control"))
> +   port8250.port.flags |= UPF_HARD_FLOW;
> +
> ret = serial8250_register_8250_port();
> break;
> }
> diff --git a/drivers/tty/serial/serial_core.c 
> b/drivers/tty/serial/serial_core.c
> index b68550d..851707a 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -174,8 +174,12 @@ static int uart_port_startup(struct tty_struct *tty, 
> struct uart_state *state,
> if (tty->termios.c_cflag & CBAUD)
> uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
> }
>

Re: [PATCH v2] serial: uart: add hw flow control support configuration

[Dann Frazier]

On Thu, May 1, 2014 at 1:04 PM, Murali Karicheri m-kariche...@ti.com wrote:
 8250 uart driver currently supports only software assisted hw flow
 control. The software assisted hw flow control maintains a hw_stopped
 flag in the tty structure to stop and start transmission and use modem
 status interrupt for the event to drive the handshake signals. This is
 not needed if hw has flow control capabilities. This patch adds a
 DT attribute for enabling hw flow control for a uart port. Also skip
 stop and start if this flag is present in flag field of the port
 structure.

ubuntu@hwflow:~$ sudo stty -a --file /dev/ttyS0 |tr ' ' '\n' | grep crtscts
crtscts
ubuntu@hwflow:~$ ls /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
/proc/device-tree/soc/serial@1c021000/has-hw-flow-control
ubuntu@hwflow:~$ python
Python 2.7.6 (default, Mar 22 2014, 22:58:30)
[GCC 4.8.2] on linux2
Type help, copyright, credits or license for more information.
 UPF_HARDWARE_FLOW = 1  21
 if 0xB920  UPF_HARDWARE_FLOW:
... print OK
...
OK

Hope that's a reasonable test case. Test fails when booted w/o
has-hw-flow-control attribute.

Tested-by: dann frazier dann.fraz...@canonical.com


 Signed-off-by: Murali Karicheri m-kariche...@ti.com

 CC: Rob Herring robh...@kernel.org
 CC: Pawel Moll pawel.m...@arm.com
 CC: Mark Rutland mark.rutl...@arm.com
 CC: Ian Campbell ijc+devicet...@hellion.org.uk
 CC: Kumar Gala ga...@codeaurora.org
 CC: Randy Dunlap rdun...@infradead.org
 CC: Greg Kroah-Hartman gre...@linuxfoundation.org
 CC: Jiri Slaby jsl...@suse.cz
 CC: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  .../devicetree/bindings/serial/of-serial.txt   |1 +
  drivers/tty/serial/8250/8250_core.c|6 --
  drivers/tty/serial/of_serial.c |4 
  drivers/tty/serial/serial_core.c   |   12 +---
  4 files changed, 18 insertions(+), 5 deletions(-)

 diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt 
 b/Documentation/devicetree/bindings/serial/of-serial.txt
 index 1928a3e..7705477 100644
 --- a/Documentation/devicetree/bindings/serial/of-serial.txt
 +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
 @@ -37,6 +37,7 @@ Optional properties:
  - auto-flow-control: one way to enable automatic flow control support. The
driver is allowed to detect support for the capability even without this
property.
 +- has-hw-flow-control: the hardware has flow control capability.

  Example:

 diff --git a/drivers/tty/serial/8250/8250_core.c 
 b/drivers/tty/serial/8250/8250_core.c
 index 0e1bf88..b69aff2 100644
 --- a/drivers/tty/serial/8250/8250_core.c
 +++ b/drivers/tty/serial/8250/8250_core.c
 @@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, 
 struct ktermios *termios,
  * the trigger, or the MCR RTS bit is cleared.  In the case where
  * the remote UART is not using CTS auto flow control, we must
  * have sufficient FIFO entries for the latency of the remote
 -* UART to respond.  IOW, at least 32 bytes of FIFO.
 +* UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
 +* AFE if hw flow control is supported
  */
 -   if (up-capabilities  UART_CAP_AFE  port-fifosize = 32) {
 +   if ((up-capabilities  UART_CAP_AFE  (port-fifosize = 32)) ||
 +   (port-flags  UPF_HARD_FLOW)) {
 up-mcr = ~UART_MCR_AFE;
 if (termios-c_cflag  CRTSCTS)
 up-mcr |= UART_MCR_AFE;
 diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
 index 9924660..77ec6a1 100644
 --- a/drivers/tty/serial/of_serial.c
 +++ b/drivers/tty/serial/of_serial.c
 @@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct 
 platform_device *ofdev)
   auto-flow-control))
 port8250.capabilities |= UART_CAP_AFE;

 +   if (of_property_read_bool(ofdev-dev.of_node,
 + has-hw-flow-control))
 +   port8250.port.flags |= UPF_HARD_FLOW;
 +
 ret = serial8250_register_8250_port(port8250);
 break;
 }
 diff --git a/drivers/tty/serial/serial_core.c 
 b/drivers/tty/serial/serial_core.c
 index b68550d..851707a 100644
 --- a/drivers/tty/serial/serial_core.c
 +++ b/drivers/tty/serial/serial_core.c
 @@ -174,8 +174,12 @@ static int uart_port_startup(struct tty_struct *tty, 
 struct uart_state *state,
 if (tty-termios.c_cflag  CBAUD)
 uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
 }
 -
 -   if (tty_port_cts_enabled(port)) {
 +   /*
 +* if hw support flow control without software intervention,
 +* then skip the below check
 +*/
 +   if (tty_port_cts_enabled(port) 
 +   !(uport-flags

Re: [RFC PATCH V3 0/4] APM X-Gene PCIe controller

[Dann Frazier]

On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar  wrote:
> This patch adds support for AppliedMicro X-Gene PCIe host controller. The
> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
> cards.
>
> X-Gene PCIe controller driver has depedency on the pcie arch support for
> arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel
> and approach for arch support is under discussion with arm64 maintainers.
> The reference patch can be found here --> https://lkml.org/lkml/2013/10/23/244

The reference patch looks corrupted (pcibios.c has no includes, etc),
would you mind reposting?

  -dann

> If someone wishes to test PCIe on X-Gene, arch support patch must be applied
> before the patches in this patch set.
>
> changes since V2:
> 1. redefined each PCI port in different PCI domain correctly.
> 2. removed setup_lane and setup_link functions from driver.
> 3. removed scan_bus wrapper and set_primary_bus hack.
> 4. added pci_ioremap_io for io resources.
>
> changes since V1:
> 1. added PCI domain support
> 2. reading cpu and pci addresses from device tree to configure regions.
> 3. got rid of unnecessary wrappers for readl and writel.
> 4. got rid of endpoint configuration code.
> 5. added 'dma-ranges' property support to read inbound region configuration.
> 6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
> 7. dropped 'clock-names' property from bindings
> 8. added comments whereever requested.
>
> Tanmay Inamdar (4):
>   pci: APM X-Gene PCIe controller driver
>   arm64: dts: APM X-Gene PCIe device tree nodes
>   dt-bindings: pci: xgene pcie device tree bindings
>   MAINTAINERS: entry for APM X-Gene PCIe host driver
>
>  .../devicetree/bindings/pci/xgene-pci.txt  |   52 ++
>  MAINTAINERS|7 +
>  arch/arm64/boot/dts/apm-mustang.dts|8 +
>  arch/arm64/boot/dts/apm-storm.dtsi |  155 
>  drivers/pci/host/Kconfig   |   10 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pci-xgene.c   |  784 
> 
>  7 files changed, 1017 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
>  create mode 100644 drivers/pci/host/pci-xgene.c
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH V3 0/4] APM X-Gene PCIe controller

[Dann Frazier]

On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar tinam...@apm.com wrote:
 This patch adds support for AppliedMicro X-Gene PCIe host controller. The
 driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
 cards.

 X-Gene PCIe controller driver has depedency on the pcie arch support for
 arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel
 and approach for arch support is under discussion with arm64 maintainers.
 The reference patch can be found here -- https://lkml.org/lkml/2013/10/23/244

The reference patch looks corrupted (pcibios.c has no includes, etc),
would you mind reposting?

  -dann

 If someone wishes to test PCIe on X-Gene, arch support patch must be applied
 before the patches in this patch set.

 changes since V2:
 1. redefined each PCI port in different PCI domain correctly.
 2. removed setup_lane and setup_link functions from driver.
 3. removed scan_bus wrapper and set_primary_bus hack.
 4. added pci_ioremap_io for io resources.

 changes since V1:
 1. added PCI domain support
 2. reading cpu and pci addresses from device tree to configure regions.
 3. got rid of unnecessary wrappers for readl and writel.
 4. got rid of endpoint configuration code.
 5. added 'dma-ranges' property support to read inbound region configuration.
 6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
 7. dropped 'clock-names' property from bindings
 8. added comments whereever requested.

 Tanmay Inamdar (4):
   pci: APM X-Gene PCIe controller driver
   arm64: dts: APM X-Gene PCIe device tree nodes
   dt-bindings: pci: xgene pcie device tree bindings
   MAINTAINERS: entry for APM X-Gene PCIe host driver

  .../devicetree/bindings/pci/xgene-pci.txt  |   52 ++
  MAINTAINERS|7 +
  arch/arm64/boot/dts/apm-mustang.dts|8 +
  arch/arm64/boot/dts/apm-storm.dtsi |  155 
  drivers/pci/host/Kconfig   |   10 +
  drivers/pci/host/Makefile  |1 +
  drivers/pci/host/pci-xgene.c   |  784 
 
  7 files changed, 1017 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
  create mode 100644 drivers/pci/host/pci-xgene.c

 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-pci in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.4.36.1 hangs.

[dann frazier]

On Tue, Feb 26, 2008 at 09:16:25AM +0100, Willy Tarreau wrote:
> On Mon, Feb 25, 2008 at 09:36:12PM -1000, Glen Nakamura wrote:
> > Aloha,
> > 
> > The "ext2_readdir() filp->f_pos fix" patch looks weird...
> > Perhaps the "filp->f_pos += le16_to_cpu(de->rec_len);" line should be
> > outside of the if statement like the indentation implies?
> 
> good catch! At least it's what is done in 2.6.

Yes, that certainly looks like a bug.

> > As it is, filp->f_pos gets corrupted if de->inode is ever zero...
> > This could possibly explain why I had a few strange directory
> > entries until I checked the filesystem with:
> > e2fsck -D -F -f /dev/{ext2 partition}
> > 
> > - glen
> > 
> > Here is an updated (untested) patch:
> 
> unfortunately, neither Dann nor me could reproduce the issue, so
> we'll wait for some victims^Wvolunteers to give it a try.

I'm now able to reliably reproduce it by creating/removing a chroot
(pbuilder create on a Debian system, though I'm sure a simpler test
exists). Correcting the le16_to_cpu placement as Glen described
fixes the issue for me.

> BTW, I notice that 2.6 also has one extra chunk that 2.4 does not
> have :
> 
> if (unlikely(need_revalidate)) {
> +   if (offset) {
> offset = ext2_validate_entry(kaddr, offset, 
> chunk_mask);
> +   filp->f_pos = (n< +   }
> +   filp->f_version = inode->i_version;
> need_revalidate = 0;
> }
> 
> I have no idea whether this part is needed, we'd better ask Theo or Al
> for some advices, as I'm not tempted by merging an uncertain patch when
> it comes to filesystems.

Looks like a test case may be available:
  
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2d7f2ea9c989853310c7f6e8be52cc090cc8e66b

-- 
dann frazier

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.4.36.1 hangs.

[dann frazier]

On Tue, Feb 26, 2008 at 09:16:25AM +0100, Willy Tarreau wrote:
 On Mon, Feb 25, 2008 at 09:36:12PM -1000, Glen Nakamura wrote:
  Aloha,
  
  The ext2_readdir() filp-f_pos fix patch looks weird...
  Perhaps the filp-f_pos += le16_to_cpu(de-rec_len); line should be
  outside of the if statement like the indentation implies?
 
 good catch! At least it's what is done in 2.6.

Yes, that certainly looks like a bug.

  As it is, filp-f_pos gets corrupted if de-inode is ever zero...
  This could possibly explain why I had a few strange directory
  entries until I checked the filesystem with:
  e2fsck -D -F -f /dev/{ext2 partition}
  
  - glen
  
  Here is an updated (untested) patch:
 
 unfortunately, neither Dann nor me could reproduce the issue, so
 we'll wait for some victims^Wvolunteers to give it a try.

I'm now able to reliably reproduce it by creating/removing a chroot
(pbuilder create on a Debian system, though I'm sure a simpler test
exists). Correcting the le16_to_cpu placement as Glen described
fixes the issue for me.

 BTW, I notice that 2.6 also has one extra chunk that 2.4 does not
 have :
 
 if (unlikely(need_revalidate)) {
 +   if (offset) {
 offset = ext2_validate_entry(kaddr, offset, 
 chunk_mask);
 +   filp-f_pos = (nPAGE_CACHE_SHIFT) + offset;
 +   }
 +   filp-f_version = inode-i_version;
 need_revalidate = 0;
 }
 
 I have no idea whether this part is needed, we'd better ask Theo or Al
 for some advices, as I'm not tempted by merging an uncertain patch when
 it comes to filesystems.

Looks like a test case may be available:
  
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2d7f2ea9c989853310c7f6e8be52cc090cc8e66b

-- 
dann frazier

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [POWERPC] CHRP: Fix possible NULL pointer dereference

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Cyrill Gorcunov.
(commit 9ac71d00398674aaec664f30559f0a21d963862f)

CVE-2007-6694 was assigned for this issue.
This backport has been compile-tested only.

Commit log from 2.6 follows.

This fixes a possible NULL pointer dereference inside of strncmp() if
of_get_property() fails.

Signed-off-by: dann frazier <[EMAIL PROTECTED]>

diff --git a/arch/ppc/platforms/chrp_setup.c b/arch/ppc/platforms/chrp_setup.c
index 0ffbbd2..28747db 100644
--- a/arch/ppc/platforms/chrp_setup.c
+++ b/arch/ppc/platforms/chrp_setup.c
@@ -121,7 +121,7 @@ chrp_show_cpuinfo(struct seq_file *m)
seq_printf(m, "machine\t\t: CHRP %s\n", model);
 
/* longtrail (goldengate) stuff */
-   if (!strncmp(model, "IBM,LongTrail", 13)) {
+   if (model && !strncmp(model, "IBM,LongTrail", 13)) {
/* VLSI VAS96011/12 `Golden Gate 2' */
/* Memory banks */
sdramen = (in_le32((unsigned *)(gg2_pci_config_base+
@@ -210,14 +210,20 @@ static void __init sio_fixup_irq(const char *name, u8 
device, u8 level,
 static void __init sio_init(void)
 {
struct device_node *root;
+   const char *model;
 
-   if ((root = find_path_device("/")) &&
-   !strncmp(get_property(root, "model", NULL), "IBM,LongTrail", 13)) {
+   root = find_path_device("/");
+   if (!root)
+   return;
+
+   model = get_property(root, "model", NULL);
+   if (model && !strncmp(model, "IBM,LongTrail", 13)) {
/* logical device 0 (KBC/Keyboard) */
sio_fixup_irq("keyboard", 0, 1, 2);
/* select logical device 1 (KBC/Mouse) */
sio_fixup_irq("mouse", 1, 12, 2);
}
+
 }
 
 
-- 
1.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [POWERPC] CHRP: Fix possible NULL pointer dereference

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Cyrill Gorcunov.
(commit 9ac71d00398674aaec664f30559f0a21d963862f)

CVE-2007-6694 was assigned for this issue.
This backport has been compile-tested only.

Commit log from 2.6 follows.

This fixes a possible NULL pointer dereference inside of strncmp() if
of_get_property() fails.

Signed-off-by: dann frazier [EMAIL PROTECTED]

diff --git a/arch/ppc/platforms/chrp_setup.c b/arch/ppc/platforms/chrp_setup.c
index 0ffbbd2..28747db 100644
--- a/arch/ppc/platforms/chrp_setup.c
+++ b/arch/ppc/platforms/chrp_setup.c
@@ -121,7 +121,7 @@ chrp_show_cpuinfo(struct seq_file *m)
seq_printf(m, machine\t\t: CHRP %s\n, model);
 
/* longtrail (goldengate) stuff */
-   if (!strncmp(model, IBM,LongTrail, 13)) {
+   if (model  !strncmp(model, IBM,LongTrail, 13)) {
/* VLSI VAS96011/12 `Golden Gate 2' */
/* Memory banks */
sdramen = (in_le32((unsigned *)(gg2_pci_config_base+
@@ -210,14 +210,20 @@ static void __init sio_fixup_irq(const char *name, u8 
device, u8 level,
 static void __init sio_init(void)
 {
struct device_node *root;
+   const char *model;
 
-   if ((root = find_path_device(/)) 
-   !strncmp(get_property(root, model, NULL), IBM,LongTrail, 13)) {
+   root = find_path_device(/);
+   if (!root)
+   return;
+
+   model = get_property(root, model, NULL);
+   if (model  !strncmp(model, IBM,LongTrail, 13)) {
/* logical device 0 (KBC/Keyboard) */
sio_fixup_irq(keyboard, 0, 1, 2);
/* select logical device 1 (KBC/Mouse) */
sio_fixup_irq(mouse, 1, 12, 2);
}
+
 }
 
 
-- 
1.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: USB: fix DoS in pwc USB video driver

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Oliver Neukum.
(commit 85237f202d46d55c1bffe0c5b1aa3ddc0f1dce4d)

CVE-2007-5093 was assigned for this issue.
This backport has been compile-tested only.

Commit log from 2.6 follows.

  the pwc driver has a disconnect method that waits for user space to
  close the device. This opens up an opportunity for a DoS attack,
  blocking the USB subsystem and making khubd's task busy wait in
  kernel space. This patch shifts freeing resources to close if an opened
  device is disconnected.

Signed-off-by: dann frazier <[EMAIL PROTECTED]>
---
 drivers/usb/pwc-if.c |   50 +-
 drivers/usb/pwc.h|1 +
 2 files changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/pwc-if.c b/drivers/usb/pwc-if.c
index e458515..a1c3989 100644
--- a/drivers/usb/pwc-if.c
+++ b/drivers/usb/pwc-if.c
@@ -1055,11 +1055,16 @@ static int pwc_video_open(struct video_device *vdev, 
int mode)
return 0;
 }
 
+static void pwc_cleanup(struct pwc_device *pdev)
+{
+   video_unregister_device(>vdev);
+}
+
 /* Note that all cleanup is done in the reverse order as in _open */
 static void pwc_video_close(struct video_device *vdev)
 {
struct pwc_device *pdev;
-   int i;
+   int i, hint;
 
Trace(TRACE_OPEN, ">> video_close called(vdev = 0x%p).\n", vdev);
 
@@ -1083,8 +1088,9 @@ static void pwc_video_close(struct video_device *vdev)
pwc_isoc_cleanup(pdev);
pwc_free_buffers(pdev);
 
+   lock_kernel();
/* Turn off LEDS and power down camera, but only when not unplugged */
-   if (pdev->error_status != EPIPE) {
+   if (!pdev->unplugged) {
if (pwc_set_leds(pdev, 0, 0) < 0)
Info("Failed to set LED on/off time.\n");
if (power_save) {
@@ -1092,9 +1098,18 @@ static void pwc_video_close(struct video_device *vdev)
if (i < 0) 
Err("Failed to power down camera (%d)\n", i);
}
+   pdev->vopen = 0;
+   Trace(TRACE_OPEN, "<< video_close()\n");
+   } else {
+   pwc_cleanup(pdev);
+   /* Free memory (don't set pdev to 0 just yet) */
+   kfree(pdev);
+   /* search device_hint[] table if we occupy a slot, by any 
chance */
+   for (hint = 0; hint < MAX_DEV_HINTS; hint++)
+   if (device_hint[hint].pdev == pdev)
+   device_hint[hint].pdev = NULL;
}
-   pdev->vopen = 0;
-   Trace(TRACE_OPEN, "<< video_close()\n");
+   unlock_kernel();
 }
 
 /*
@@ -1897,19 +1912,20 @@ static void usb_pwc_disconnect(struct usb_device *udev, 
void *ptr)
/* Alert waiting processes */
wake_up_interruptible(>frameq);
/* Wait until device is closed */
-   while (pdev->vopen)
-   schedule();
-   /* Device is now closed, so we can safely unregister it */
-   Trace(TRACE_PROBE, "Unregistering video device in disconnect().\n");
-   video_unregister_device(>vdev); 
-
-   /* Free memory (don't set pdev to 0 just yet) */
-   kfree(pdev);
-
-   /* search device_hint[] table if we occupy a slot, by any chance */
-   for (hint = 0; hint < MAX_DEV_HINTS; hint++)
-   if (device_hint[hint].pdev == pdev)
-   device_hint[hint].pdev = NULL;
+   if(pdev->vopen) {
+   pdev->unplugged = 1;
+   } else {
+   /* Device is closed, so we can safely unregister it */
+   Trace(TRACE_PROBE, "Unregistering video device in 
disconnect().\n");
+   pwc_cleanup(pdev);
+   /* Free memory (don't set pdev to 0 just yet) */
+   kfree(pdev);
+   
+   /* search device_hint[] table if we occupy a slot, by any 
chance */
+   for (hint = 0; hint < MAX_DEV_HINTS; hint++)
+   if (device_hint[hint].pdev == pdev)
+   device_hint[hint].pdev = NULL;
+   }
 
unlock_kernel();
 }
diff --git a/drivers/usb/pwc.h b/drivers/usb/pwc.h
index b020769..999daf2 100644
--- a/drivers/usb/pwc.h
+++ b/drivers/usb/pwc.h
@@ -141,6 +141,7 @@ struct pwc_device
char vsnapshot; /* snapshot mode */
char vsync; /* used by isoc handler */
char vmirror;   /* for ToUCaM series */
+   char unplugged;
 
/* The image acquisition requires 3 to 4 steps:
   1. data is gathered in short packets from the USB controller
-- 
1.5.3.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [PPPOE]: memory leak when socket is release()d before PPPIOCGCHAN has been called on it

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Florian Zumbiehl.
(commit 202a03acf9994076055df40ae093a5c5474ad0bd)

CVE-2007-2525 was assigned for this issue. It has been compile tested-only.

Commit log from 2.6 follows.

  below you find a patch that fixes a memory leak when a PPPoE socket is
  release()d after it has been connect()ed, but before the PPPIOCGCHAN ioctl
  ever has been called on it.

  This is somewhat of a security problem, too, since PPPoE sockets can be
  created by any user, so any user can easily allocate all the machine's
  RAM to non-swappable address space and thus DoS the system.

  Is there any specific reason for PPPoE sockets being available to any
  unprivileged process, BTW? After all, you need a packet socket for the
  discovery stage anyway, so it's unlikely that any unprivileged process
  will ever need to create a PPPoE socket, no? Allocating all session IDs
  for a known AC is a kind of DoS, too, after all - with Juniper ERXes,
  this is really easy, actually, since they don't ever assign session ids
  above 8000 ...

Signed-off-by: dann frazier <[EMAIL PROTECTED]>
---
 drivers/net/pppox.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/pppox.c b/drivers/net/pppox.c
index 7830e4d..4883c0f 100644
--- a/drivers/net/pppox.c
+++ b/drivers/net/pppox.c
@@ -67,7 +67,7 @@ void pppox_unbind_sock(struct sock *sk)
 {
/* Clear connection to ppp device, if attached. */
 
-   if (sk->state & (PPPOX_BOUND|PPPOX_ZOMBIE)) {
+   if (sk->state & (PPPOX_BOUND | PPPOX_CONNECTED | PPPOX_ZOMBIE)) {
ppp_unregister_channel(>protinfo.pppox->chan);
sk->state = PPPOX_DEAD;
}
-- 
1.5.3.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [PPPOE]: memory leak when socket is release()d before PPPIOCGCHAN has been called on it

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Florian Zumbiehl.
(commit 202a03acf9994076055df40ae093a5c5474ad0bd)

CVE-2007-2525 was assigned for this issue. It has been compile tested-only.

Commit log from 2.6 follows.

  below you find a patch that fixes a memory leak when a PPPoE socket is
  release()d after it has been connect()ed, but before the PPPIOCGCHAN ioctl
  ever has been called on it.

  This is somewhat of a security problem, too, since PPPoE sockets can be
  created by any user, so any user can easily allocate all the machine's
  RAM to non-swappable address space and thus DoS the system.

  Is there any specific reason for PPPoE sockets being available to any
  unprivileged process, BTW? After all, you need a packet socket for the
  discovery stage anyway, so it's unlikely that any unprivileged process
  will ever need to create a PPPoE socket, no? Allocating all session IDs
  for a known AC is a kind of DoS, too, after all - with Juniper ERXes,
  this is really easy, actually, since they don't ever assign session ids
  above 8000 ...

Signed-off-by: dann frazier [EMAIL PROTECTED]
---
 drivers/net/pppox.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/pppox.c b/drivers/net/pppox.c
index 7830e4d..4883c0f 100644
--- a/drivers/net/pppox.c
+++ b/drivers/net/pppox.c
@@ -67,7 +67,7 @@ void pppox_unbind_sock(struct sock *sk)
 {
/* Clear connection to ppp device, if attached. */
 
-   if (sk-state  (PPPOX_BOUND|PPPOX_ZOMBIE)) {
+   if (sk-state  (PPPOX_BOUND | PPPOX_CONNECTED | PPPOX_ZOMBIE)) {
ppp_unregister_channel(sk-protinfo.pppox-chan);
sk-state = PPPOX_DEAD;
}
-- 
1.5.3.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: USB: fix DoS in pwc USB video driver

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Oliver Neukum.
(commit 85237f202d46d55c1bffe0c5b1aa3ddc0f1dce4d)

CVE-2007-5093 was assigned for this issue.
This backport has been compile-tested only.

Commit log from 2.6 follows.

  the pwc driver has a disconnect method that waits for user space to
  close the device. This opens up an opportunity for a DoS attack,
  blocking the USB subsystem and making khubd's task busy wait in
  kernel space. This patch shifts freeing resources to close if an opened
  device is disconnected.

Signed-off-by: dann frazier [EMAIL PROTECTED]
---
 drivers/usb/pwc-if.c |   50 +-
 drivers/usb/pwc.h|1 +
 2 files changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/pwc-if.c b/drivers/usb/pwc-if.c
index e458515..a1c3989 100644
--- a/drivers/usb/pwc-if.c
+++ b/drivers/usb/pwc-if.c
@@ -1055,11 +1055,16 @@ static int pwc_video_open(struct video_device *vdev, 
int mode)
return 0;
 }
 
+static void pwc_cleanup(struct pwc_device *pdev)
+{
+   video_unregister_device(pdev-vdev);
+}
+
 /* Note that all cleanup is done in the reverse order as in _open */
 static void pwc_video_close(struct video_device *vdev)
 {
struct pwc_device *pdev;
-   int i;
+   int i, hint;
 
Trace(TRACE_OPEN,  video_close called(vdev = 0x%p).\n, vdev);
 
@@ -1083,8 +1088,9 @@ static void pwc_video_close(struct video_device *vdev)
pwc_isoc_cleanup(pdev);
pwc_free_buffers(pdev);
 
+   lock_kernel();
/* Turn off LEDS and power down camera, but only when not unplugged */
-   if (pdev-error_status != EPIPE) {
+   if (!pdev-unplugged) {
if (pwc_set_leds(pdev, 0, 0)  0)
Info(Failed to set LED on/off time.\n);
if (power_save) {
@@ -1092,9 +1098,18 @@ static void pwc_video_close(struct video_device *vdev)
if (i  0) 
Err(Failed to power down camera (%d)\n, i);
}
+   pdev-vopen = 0;
+   Trace(TRACE_OPEN,  video_close()\n);
+   } else {
+   pwc_cleanup(pdev);
+   /* Free memory (don't set pdev to 0 just yet) */
+   kfree(pdev);
+   /* search device_hint[] table if we occupy a slot, by any 
chance */
+   for (hint = 0; hint  MAX_DEV_HINTS; hint++)
+   if (device_hint[hint].pdev == pdev)
+   device_hint[hint].pdev = NULL;
}
-   pdev-vopen = 0;
-   Trace(TRACE_OPEN,  video_close()\n);
+   unlock_kernel();
 }
 
 /*
@@ -1897,19 +1912,20 @@ static void usb_pwc_disconnect(struct usb_device *udev, 
void *ptr)
/* Alert waiting processes */
wake_up_interruptible(pdev-frameq);
/* Wait until device is closed */
-   while (pdev-vopen)
-   schedule();
-   /* Device is now closed, so we can safely unregister it */
-   Trace(TRACE_PROBE, Unregistering video device in disconnect().\n);
-   video_unregister_device(pdev-vdev); 
-
-   /* Free memory (don't set pdev to 0 just yet) */
-   kfree(pdev);
-
-   /* search device_hint[] table if we occupy a slot, by any chance */
-   for (hint = 0; hint  MAX_DEV_HINTS; hint++)
-   if (device_hint[hint].pdev == pdev)
-   device_hint[hint].pdev = NULL;
+   if(pdev-vopen) {
+   pdev-unplugged = 1;
+   } else {
+   /* Device is closed, so we can safely unregister it */
+   Trace(TRACE_PROBE, Unregistering video device in 
disconnect().\n);
+   pwc_cleanup(pdev);
+   /* Free memory (don't set pdev to 0 just yet) */
+   kfree(pdev);
+   
+   /* search device_hint[] table if we occupy a slot, by any 
chance */
+   for (hint = 0; hint  MAX_DEV_HINTS; hint++)
+   if (device_hint[hint].pdev == pdev)
+   device_hint[hint].pdev = NULL;
+   }
 
unlock_kernel();
 }
diff --git a/drivers/usb/pwc.h b/drivers/usb/pwc.h
index b020769..999daf2 100644
--- a/drivers/usb/pwc.h
+++ b/drivers/usb/pwc.h
@@ -141,6 +141,7 @@ struct pwc_device
char vsnapshot; /* snapshot mode */
char vsync; /* used by isoc handler */
char vmirror;   /* for ToUCaM series */
+   char unplugged;
 
/* The image acquisition requires 3 to 4 steps:
   1. data is gathered in short packets from the USB controller
-- 
1.5.3.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [SCSI] aacraid: Fix security hole

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Alan Cox.
(commit 60395bb60e0b5e4e0808ac8eb07a92f6c9cdea1f)

It has been build-tested only (I don't have the hardware).
CVE-2007-4308 was assigned for this issue.

Commit log from 2.6 follows.

  On the SCSI layer ioctl path there is no implicit permissions check for
  ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
  however allows all sorts of very admin only things to be done so should
  check.
---
 drivers/scsi/aacraid/linit.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Signed-off-by: dann frazier <[EMAIL PROTECTED]>

diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 57d0a40..c6d7bdf 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -683,6 +683,8 @@ static int aac_cfg_release(struct inode * inode, struct 
file * file )
 static int aac_cfg_ioctl(struct inode * inode,  struct file * file, unsigned 
int cmd, unsigned long arg )
 {
struct aac_dev *dev = aac_devices[MINOR(inode->i_rdev)];
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
return aac_do_ioctl(dev, cmd, (void *)arg);
 }
 
-- 
1.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [SCSI] aacraid: Fix security hole

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Alan Cox.
(commit 60395bb60e0b5e4e0808ac8eb07a92f6c9cdea1f)

It has been build-tested only (I don't have the hardware).
CVE-2007-4308 was assigned for this issue.

Commit log from 2.6 follows.

  On the SCSI layer ioctl path there is no implicit permissions check for
  ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
  however allows all sorts of very admin only things to be done so should
  check.
---
 drivers/scsi/aacraid/linit.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Signed-off-by: dann frazier [EMAIL PROTECTED]

diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 57d0a40..c6d7bdf 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -683,6 +683,8 @@ static int aac_cfg_release(struct inode * inode, struct 
file * file )
 static int aac_cfg_ioctl(struct inode * inode,  struct file * file, unsigned 
int cmd, unsigned long arg )
 {
struct aac_dev *dev = aac_devices[MINOR(inode-i_rdev)];
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
return aac_do_ioctl(dev, cmd, (void *)arg);
 }
 
-- 
1.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

[dann frazier]

On Thu, Jan 24, 2008 at 03:06:58PM -0600, Eric Sandeen wrote:
> Willy Tarreau wrote:
> > Hi Dann,
> > 
> > On Wed, Jan 23, 2008 at 11:12:12PM -0700, dann frazier wrote:
> >> This is a 2.4 backport of a linux-2.6 change by Eric Sandeen
> >> (commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)
> >>
> >> CVE-2006-5753 was assigned for this issue.
> >>
> >> I've built and boot-tested this, but I'm not sure how to exercise
> >> these codepaths.
> > 
> > I have no idea either. Let's consider that if nobody on the list knows
> > how to do so, I'll merge it since you did not notice any regression.
> > 
> > Thanks,
> > Willy
> > 
> 
> Sorry... here you go.  Forgot to post this sooner.  I hit it with
> this on 2.6.x
> 
> #include 
> #include 
> #include 
> 
> static int return_EIO(void)
> {
> return -EIO;
> }
> 
> int main(int argc, char ** argv)
> {
>   ssize_t error;
>   ssize_t realerror = -EIO;
>   ssize_t (*fn_ptr)(void);
> 
>   fn_ptr = (void *)return_EIO;
> 
>   error = (ssize_t)fn_ptr();
>   printf("and... error is %ld, should be %ld\n", error, realerror);
>   return 0;
> }

Thanks Eric. Sounds like my comment about exercising these code paths
wasn't too clear - the comments with your patch do make the issue
clear, and this program demonstrates the void cast promotion issue
well. I'm just not sure of a good way to demonstrate that my backport
of this patch doesn't break anything for 2.4.

-- 
dann frazier

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

[dann frazier]

On Thu, Jan 24, 2008 at 03:06:58PM -0600, Eric Sandeen wrote:
 Willy Tarreau wrote:
  Hi Dann,
  
  On Wed, Jan 23, 2008 at 11:12:12PM -0700, dann frazier wrote:
  This is a 2.4 backport of a linux-2.6 change by Eric Sandeen
  (commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)
 
  CVE-2006-5753 was assigned for this issue.
 
  I've built and boot-tested this, but I'm not sure how to exercise
  these codepaths.
  
  I have no idea either. Let's consider that if nobody on the list knows
  how to do so, I'll merge it since you did not notice any regression.
  
  Thanks,
  Willy
  
 
 Sorry... here you go.  Forgot to post this sooner.  I hit it with
 this on 2.6.x
 
 #include stdio.h
 #include sys/types.h
 #include sys/errno.h
 
 static int return_EIO(void)
 {
 return -EIO;
 }
 
 int main(int argc, char ** argv)
 {
   ssize_t error;
   ssize_t realerror = -EIO;
   ssize_t (*fn_ptr)(void);
 
   fn_ptr = (void *)return_EIO;
 
   error = (ssize_t)fn_ptr();
   printf(and... error is %ld, should be %ld\n, error, realerror);
   return 0;
 }

Thanks Eric. Sounds like my comment about exercising these code paths
wasn't too clear - the comments with your patch do make the issue
clear, and this program demonstrates the void cast promotion issue
well. I'm just not sure of a good way to demonstrate that my backport
of this patch doesn't break anything for 2.4.

-- 
dann frazier

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Eric Sandeen
(commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)

CVE-2006-5753 was assigned for this issue.

I've built and boot-tested this, but I'm not sure how to exercise
these codepaths.

Commit log from 2.6 follows.

  CVE-2006-5753 is for a case where an inode can be marked bad, switching
  the ops to bad_inode_ops, which are all connected as:

  static int return_EIO(void)
  {
  return -EIO;
  }

  #define EIO_ERROR ((void *) (return_EIO))

  static struct inode_operations bad_inode_ops =
  {
  .create = bad_inode_create
  ...etc...

  The problem here is that the void cast causes return types to not be
  promoted, and for ops such as listxattr which expect more than 32 bits of
  return value, the 32-bit -EIO is interpreted as a large positive 64-bit
  number, i.e. 0xfffa instead of 0xfffa.

  This goes particularly badly when the return value is taken as a number of
  bytes to copy into, say, a user's buffer for example...

  I originally had coded up the fix by creating a return_EIO_ macro
  for each return type, like this:

  static int return_EIO_int(void)
  {
return -EIO;
  }
  #define EIO_ERROR_INT ((void *) (return_EIO_int))

  static struct inode_operations bad_inode_ops =
  {
.create = EIO_ERROR_INT,
  ...etc...

  but Al felt that it was probably better to create an EIO-returner for each
  actual op signature.  Since so few ops share a signature, I just went ahead
  & created an EIO function for each individual file & inode op that returns
  a value.

Signed-off-by: dann frazier <[EMAIL PROTECTED]>
---
 fs/bad_inode.c |  191 +++-
 1 files changed, 161 insertions(+), 30 deletions(-)

diff --git a/fs/bad_inode.c b/fs/bad_inode.c
index 850ba5e..b6b1d7d 100644
--- a/fs/bad_inode.c
+++ b/fs/bad_inode.c
@@ -9,6 +9,76 @@
 #include 
 #include 
 #include 
+#include 
+
+static loff_t bad_file_llseek(struct file *file, loff_t offset, int origin)
+{
+   return -EIO;
+}
+
+static ssize_t bad_file_read(struct file *filp, char __user *buf,
+   size_t size, loff_t *ppos)
+{
+return -EIO;
+}
+
+static ssize_t bad_file_write(struct file *filp, const char __user *buf,
+   size_t siz, loff_t *ppos)
+{
+return -EIO;
+}
+
+static int bad_file_readdir(struct file *filp, void *dirent, filldir_t filldir)
+{
+   return -EIO;
+}
+
+static unsigned int bad_file_poll(struct file *filp, poll_table *wait)
+{
+   return POLLERR;
+}
+
+static int bad_file_ioctl (struct inode *inode, struct file *filp,
+   unsigned int cmd, unsigned long arg)
+{
+   return -EIO;
+}
+
+static int bad_file_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   return -EIO;
+}
+
+static int bad_file_open(struct inode *inode, struct file *filp)
+{
+   return -EIO;
+}
+
+static int bad_file_flush(struct file *file)
+{
+   return -EIO;
+}
+
+static int bad_file_release(struct inode *inode, struct file *filp)
+{
+   return -EIO;
+}
+
+static int bad_file_fsync(struct file *file, struct dentry *dentry,
+   int datasync)
+{
+   return -EIO;
+}
+
+static int bad_file_fasync(int fd, struct file *filp, int on)
+{
+   return -EIO;
+}
+
+static int bad_file_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+   return -EIO;
+}
 
 /*
  * The follow_link operation is special: it must behave as a no-op
@@ -20,46 +90,107 @@ static int bad_follow_link(struct dentry *dent, struct 
nameidata *nd)
return vfs_follow_link(nd, ERR_PTR(-EIO));
 }
 
-static int return_EIO(void)
+static struct file_operations bad_file_ops =
+{
+   llseek: bad_file_llseek,
+   read:   bad_file_read,
+   write:  bad_file_write,
+   readdir:bad_file_readdir,
+   poll:   bad_file_poll,
+   ioctl:  bad_file_ioctl,
+   mmap:   bad_file_mmap,
+   open:   bad_file_open,
+   flush:  bad_file_flush,
+   release:bad_file_release,
+   fsync:  bad_file_fsync,
+   fasync: bad_file_fasync,
+   lock:   bad_file_lock,
+};
+
+static int bad_inode_create (struct inode *dir, struct dentry *dentry,
+   int mode)
 {
return -EIO;
 }
+  
+static struct dentry *bad_inode_lookup(struct inode *dir,
+   struct dentry *dentry)
+{
+   return ERR_PTR(-EIO);
+}
 
-#define EIO_ERROR ((void *) (return_EIO))
+static int bad_inode_link (struct dentry *old_dentry, struct inode *dir,
+   struct dentry *dentry)
+{
+   return -EIO;
+}
 
-static struct file_operations bad_file_ops =
+static int bad_inode_unlink(struct inode *dir, struct dentry *dentry)
 {
-   llseek: EIO_ERROR,
-   read:   EIO_ERROR,
-   write:  EIO_ERROR,
-   readdir:   

[PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Eric Sandeen
(commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)

CVE-2006-5753 was assigned for this issue.

I've built and boot-tested this, but I'm not sure how to exercise
these codepaths.

Commit log from 2.6 follows.

  CVE-2006-5753 is for a case where an inode can be marked bad, switching
  the ops to bad_inode_ops, which are all connected as:

  static int return_EIO(void)
  {
  return -EIO;
  }

  #define EIO_ERROR ((void *) (return_EIO))

  static struct inode_operations bad_inode_ops =
  {
  .create = bad_inode_create
  ...etc...

  The problem here is that the void cast causes return types to not be
  promoted, and for ops such as listxattr which expect more than 32 bits of
  return value, the 32-bit -EIO is interpreted as a large positive 64-bit
  number, i.e. 0xfffa instead of 0xfffa.

  This goes particularly badly when the return value is taken as a number of
  bytes to copy into, say, a user's buffer for example...

  I originally had coded up the fix by creating a return_EIO_TYPE macro
  for each return type, like this:

  static int return_EIO_int(void)
  {
return -EIO;
  }
  #define EIO_ERROR_INT ((void *) (return_EIO_int))

  static struct inode_operations bad_inode_ops =
  {
.create = EIO_ERROR_INT,
  ...etc...

  but Al felt that it was probably better to create an EIO-returner for each
  actual op signature.  Since so few ops share a signature, I just went ahead
   created an EIO function for each individual file  inode op that returns
  a value.

Signed-off-by: dann frazier [EMAIL PROTECTED]
---
 fs/bad_inode.c |  191 +++-
 1 files changed, 161 insertions(+), 30 deletions(-)

diff --git a/fs/bad_inode.c b/fs/bad_inode.c
index 850ba5e..b6b1d7d 100644
--- a/fs/bad_inode.c
+++ b/fs/bad_inode.c
@@ -9,6 +9,76 @@
 #include linux/fs.h
 #include linux/stat.h
 #include linux/sched.h
+#include linux/poll.h
+
+static loff_t bad_file_llseek(struct file *file, loff_t offset, int origin)
+{
+   return -EIO;
+}
+
+static ssize_t bad_file_read(struct file *filp, char __user *buf,
+   size_t size, loff_t *ppos)
+{
+return -EIO;
+}
+
+static ssize_t bad_file_write(struct file *filp, const char __user *buf,
+   size_t siz, loff_t *ppos)
+{
+return -EIO;
+}
+
+static int bad_file_readdir(struct file *filp, void *dirent, filldir_t filldir)
+{
+   return -EIO;
+}
+
+static unsigned int bad_file_poll(struct file *filp, poll_table *wait)
+{
+   return POLLERR;
+}
+
+static int bad_file_ioctl (struct inode *inode, struct file *filp,
+   unsigned int cmd, unsigned long arg)
+{
+   return -EIO;
+}
+
+static int bad_file_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   return -EIO;
+}
+
+static int bad_file_open(struct inode *inode, struct file *filp)
+{
+   return -EIO;
+}
+
+static int bad_file_flush(struct file *file)
+{
+   return -EIO;
+}
+
+static int bad_file_release(struct inode *inode, struct file *filp)
+{
+   return -EIO;
+}
+
+static int bad_file_fsync(struct file *file, struct dentry *dentry,
+   int datasync)
+{
+   return -EIO;
+}
+
+static int bad_file_fasync(int fd, struct file *filp, int on)
+{
+   return -EIO;
+}
+
+static int bad_file_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+   return -EIO;
+}
 
 /*
  * The follow_link operation is special: it must behave as a no-op
@@ -20,46 +90,107 @@ static int bad_follow_link(struct dentry *dent, struct 
nameidata *nd)
return vfs_follow_link(nd, ERR_PTR(-EIO));
 }
 
-static int return_EIO(void)
+static struct file_operations bad_file_ops =
+{
+   llseek: bad_file_llseek,
+   read:   bad_file_read,
+   write:  bad_file_write,
+   readdir:bad_file_readdir,
+   poll:   bad_file_poll,
+   ioctl:  bad_file_ioctl,
+   mmap:   bad_file_mmap,
+   open:   bad_file_open,
+   flush:  bad_file_flush,
+   release:bad_file_release,
+   fsync:  bad_file_fsync,
+   fasync: bad_file_fasync,
+   lock:   bad_file_lock,
+};
+
+static int bad_inode_create (struct inode *dir, struct dentry *dentry,
+   int mode)
 {
return -EIO;
 }
+  
+static struct dentry *bad_inode_lookup(struct inode *dir,
+   struct dentry *dentry)
+{
+   return ERR_PTR(-EIO);
+}
 
-#define EIO_ERROR ((void *) (return_EIO))
+static int bad_inode_link (struct dentry *old_dentry, struct inode *dir,
+   struct dentry *dentry)
+{
+   return -EIO;
+}
 
-static struct file_operations bad_file_ops =
+static int bad_inode_unlink(struct inode *dir, struct dentry *dentry)
 {
-   llseek: EIO_ERROR,
-   read:   EIO_ERROR,
-   write

Re: old buffer overflow in moxa driver

[dann frazier]

On Tue, May 01, 2007 at 04:29:27AM -0400, Andres Salomon wrote:
> Right; the lack of input checking is most definitely a bug.  It's no
> longer a security issue, as a CAP_SYS_RAWIO check was added at some
> point to the code path, but it's still a bug.

I hadn't noticed this, but yes - the CAP_SYS_RAWIO check was added in
2.6.16.

-- 
dann frazier | HP Open Source and Linux Organization
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: old buffer overflow in moxa driver

[dann frazier]

On Tue, May 01, 2007 at 04:29:27AM -0400, Andres Salomon wrote:
 Right; the lack of input checking is most definitely a bug.  It's no
 longer a security issue, as a CAP_SYS_RAWIO check was added at some
 point to the code path, but it's still a bug.

I hadn't noticed this, but yes - the CAP_SYS_RAWIO check was added in
2.6.16.

-- 
dann frazier | HP Open Source and Linux Organization
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

old buffer overflow in moxa driver

[dann frazier]

hey,
  I noticed that the moxa input checking security bug described by
CVE-2005-0504 appears to remain unfixed upstream.
 
The issue is described here:
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504

Debian has been shipping the following patch from Andres Salomon. I
tried contacting the listed maintainer a few months ago but received
no response.

I've tested that this still applies to and compiles against 2.6.21.

Signed-off-by: dann frazier <[EMAIL PROTECTED]>

diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c
index 7dbaee8..e0d35c2 100644
--- a/drivers/char/moxa.c
+++ b/drivers/char/moxa.c
@@ -1582,7 +1582,7 @@ copy:
 
if(copy_from_user(, argp, sizeof(struct dl_str)))
return -EFAULT;
-   if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS)
+   if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS || dltmp.len < 0)
return -EINVAL;
 
switch(cmd)
@@ -2529,6 +2529,8 @@ static int moxaloadbios(int cardno, unsigned char __user 
*tmp, int len)
void __iomem *baseAddr;
int i;
 
+   if(len < 0 || len > sizeof(moxaBuff))
+   return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
baseAddr = moxa_boards[cardno].basemem;
@@ -2576,7 +2578,7 @@ static int moxaload320b(int cardno, unsigned char __user 
*tmp, int len)
void __iomem *baseAddr;
int i;
 
-   if(len > sizeof(moxaBuff))
+   if(len < 0 || len > sizeof(moxaBuff))
return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
@@ -2596,6 +2598,8 @@ static int moxaloadcode(int cardno, unsigned char __user 
*tmp, int len)
void __iomem *baseAddr, *ofsAddr;
int retval, port, i;
 
+   if(len < 0 || len > sizeof(moxaBuff))
+   return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
baseAddr = moxa_boards[cardno].basemem;

-- 
dann frazier
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/