* [soc:at91/dt] BUILD SUCCESS 88d801aec6e971c15a0bfb4d46d02476dde9e8aa
From: kbuild test robot @ 2020-05-22 8:27 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git at91/dt
branch HEAD: 88d801aec6e971c15a0bfb4d46d02476dde9e8aa ARM: dts: at91: sama5d2_xplained: Add aliases for the dedicated I2C IPs
elapsed time: 5215m
configs tested: 208
configs skipped: 5
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sparc allyesconfig
mips allyesconfig
m68k allyesconfig
arm davinci_all_defconfig
sh r7780mp_defconfig
arm sunxi_defconfig
powerpc chrp32_defconfig
sh polaris_defconfig
sh microdev_defconfig
mips allnoconfig
arm exynos_defconfig
mips db1xxx_defconfig
c6x defconfig
arm64 alldefconfig
sh sh2007_defconfig
arc vdk_hs38_defconfig
sh se7751_defconfig
arm netwinder_defconfig
arm iop32x_defconfig
mips ath25_defconfig
powerpc linkstation_defconfig
csky allyesconfig
powerpc skiroot_defconfig
riscv rv32_defconfig
s390 defconfig
sh sdk7786_defconfig
arm u8500_defconfig
parisc generic-32bit_defconfig
sparc64 allyesconfig
mips lasat_defconfig
arm cm_x300_defconfig
powerpc64 defconfig
mips pic32mzda_defconfig
mips e55_defconfig
mips tb0287_defconfig
powerpc mgcoge_defconfig
um x86_64_defconfig
powerpc storcenter_defconfig
sh shmin_defconfig
powerpc tqm8xx_defconfig
arm shmobile_defconfig
arm stm32_defconfig
powerpc holly_defconfig
mips tb0226_defconfig
arm imx_v4_v5_defconfig
arm cns3420vb_defconfig
m68k amcore_defconfig
mips decstation_64_defconfig
arm mps2_defconfig
h8300 h8s-sim_defconfig
m68k m5208evb_defconfig
sh ecovec24_defconfig
sh se7721_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
arm sama5_defconfig
sh se7712_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a006-20200519
i386 randconfig-a005-20200519
i386 randconfig-a001-20200519
i386 randconfig-a003-20200519
i386 randconfig-a004-20200519
i386 randconfig-a002-20200519
i386 randconfig-a001-20200520
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a006-20200518
i386 randconfig-a005-20200518
i386 randconfig-a001-20200518
i386 randconfig-a003-20200518
i386 randconfig-a004-20200518
i386 randconfig-a002-20200518
x86_64 randconfig-a003-20200519
x86_64 randconfig-a005-20200519
x86_64 randconfig-a004-20200519
x86_64 randconfig-a006-20200519
x86_64 randconfig-a002-20200519
x86_64 randconfig-a001-20200519
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
x86_64 randconfig-a016-20200518
x86_64 randconfig-a012-20200518
x86_64 randconfig-a015-20200518
x86_64 randconfig-a013-20200518
x86_64 randconfig-a011-20200518
x86_64 randconfig-a014-20200518
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a012-20200519
i386 randconfig-a014-20200519
i386 randconfig-a016-20200519
i386 randconfig-a011-20200519
i386 randconfig-a015-20200519
i386 randconfig-a013-20200519
i386 randconfig-a012-20200518
i386 randconfig-a014-20200518
i386 randconfig-a016-20200518
i386 randconfig-a011-20200518
i386 randconfig-a015-20200518
i386 randconfig-a013-20200518
i386 randconfig-a013-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a014-20200521
i386 randconfig-a012-20200521
i386 randconfig-a016-20200521
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allyesconfig
um allmodconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:tegra/dt-bindings] BUILD SUCCESS 4e79691d050e6d06ee7fa09002c52dd1ce9ac6e6
From: kbuild test robot @ 2020-05-22 8:26 UTC (permalink / raw)
To: Thierry Reding; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tegra/dt-bindings
branch HEAD: 4e79691d050e6d06ee7fa09002c52dd1ce9ac6e6 dt-bindings: i2c: tegra: Document Tegra210 VI I2C
elapsed time: 13602m
configs tested: 168
configs skipped: 30
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sparc allyesconfig
m68k allyesconfig
mips allyesconfig
h8300 edosk2674_defconfig
mips decstation_defconfig
sh rsk7201_defconfig
m68k stmark2_defconfig
arm colibri_pxa300_defconfig
c6x evmc6457_defconfig
powerpc powernv_defconfig
mips decstation_r4k_defconfig
arm davinci_all_defconfig
arc axs101_defconfig
m68k mvme16x_defconfig
arc alldefconfig
arm zx_defconfig
m68k amcore_defconfig
powerpc pmac32_defconfig
arc axs103_defconfig
arm64 alldefconfig
arm vexpress_defconfig
m68k m5272c3_defconfig
s390 zfcpdump_defconfig
m68k m5249evb_defconfig
m68k sun3x_defconfig
sh se7619_defconfig
sh ecovec24-romimage_defconfig
arc hsdk_defconfig
arm iop32x_defconfig
riscv allnoconfig
arm shmobile_defconfig
powerpc gamecube_defconfig
sh se7343_defconfig
sh sh03_defconfig
riscv allyesconfig
arm lpc32xx_defconfig
sh titan_defconfig
arc tb10x_defconfig
powerpc wii_defconfig
s390 defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa defconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20200512
i386 randconfig-a005-20200512
i386 randconfig-a003-20200512
i386 randconfig-a001-20200512
i386 randconfig-a004-20200512
i386 randconfig-a002-20200512
i386 randconfig-a006-20200513
i386 randconfig-a005-20200513
i386 randconfig-a003-20200513
i386 randconfig-a001-20200513
i386 randconfig-a004-20200513
i386 randconfig-a002-20200513
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
x86_64 randconfig-a005-20200513
x86_64 randconfig-a003-20200513
x86_64 randconfig-a006-20200513
x86_64 randconfig-a004-20200513
x86_64 randconfig-a001-20200513
x86_64 randconfig-a002-20200513
x86_64 randconfig-a012-20200514
x86_64 randconfig-a016-20200514
x86_64 randconfig-a015-20200514
x86_64 randconfig-a013-20200514
x86_64 randconfig-a014-20200514
x86_64 randconfig-a011-20200514
x86_64 randconfig-a016-20200512
x86_64 randconfig-a012-20200512
x86_64 randconfig-a015-20200512
x86_64 randconfig-a013-20200512
x86_64 randconfig-a014-20200512
x86_64 randconfig-a011-20200512
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
i386 randconfig-a012-20200512
i386 randconfig-a016-20200512
i386 randconfig-a014-20200512
i386 randconfig-a011-20200512
i386 randconfig-a013-20200512
i386 randconfig-a015-20200512
i386 randconfig-a012-20200513
i386 randconfig-a016-20200513
i386 randconfig-a014-20200513
i386 randconfig-a011-20200513
i386 randconfig-a013-20200513
i386 randconfig-a015-20200513
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: linux-next: build warning after merge of the aspeed tree
From: Arnd Bergmann @ 2020-05-22 8:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: ARM, devicetree, Andrew Jeffery, Linux Kernel Mailing List,
Vijay Khemka, Linux Next Mailing List, Rob Herring, Joel Stanley,
Olof Johansson, Manikandan Elumalai, Devicetree Compiler,
David Gibson
In-Reply-To: <20200522101638.052bd0a2@canb.auug.org.au>
On Fri, May 22, 2020 at 2:16 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Wed, 20 May 2020 07:56:36 +0000 Joel Stanley <joel@jms.id.au> wrote:
> > On Mon, 11 May 2020 at 15:19, Rob Herring <robh+dt@kernel.org> wrote:
> > > On Wed, 6 May 2020 at 23:13, Joel Stanley <joel@jms.id.au> wrote:
> > > > > These are IPMB nodes with the SLAVE_ADDRESS bit set:
> > > > >
> > > > > +&i2c5 {
> > > > > + //Host3 IPMB bus
> > > > > + status = "okay";
> > > > > + multi-master;
> > > > > + ipmb5@10 {
> > > > > + compatible = "ipmb-dev";
> > > > > + reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
> > > > > + i2c-protocol;
> > > > > + };
> > > > >
> > > > > This is a correct entry, so dtc should not warn about it.
> > > >
> > > > I sent a patch for dtc here:
> > > > https://lore.kernel.org/lkml/20200508063904.60162-1-joel@jms.id.au/
> > >
> > > Patches for dtc need to be against upstream dtc. There's already a
> > > similar patch posted for it which I commented on and never saw a
> > > respin.
> >
> > Can I suggest some instructions in scsripts/dtc explaining that you
> > don't take patches in the kernel tree for this code?
> >
> > I've sent the patch so it applies to the dtc tree. It would be good to
> > see that change propagate over to -next as others have reported this
> > warning.
>
> These warnings now appear in the arm-soc tree.
Right, I also saw them earlier.
Joel, have you sent your patch to David Gibson for integration into
upstream dtc?
I don't know who sent the other patch, but as long as one of them
gets merged, I'd hope we can pull that into kernel as well.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: linux-next: Signed-off-by missing for commit in the arm-soc tree
From: Arnd Bergmann @ 2020-05-22 8:09 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Olof Johansson, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, ARM
In-Reply-To: <CAK7LNATU18vKsSV_pugSRw4e3bQBUAQ670ac34GbO2YNHXgLPw@mail.gmail.com>
On Fri, May 22, 2020 at 3:28 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Fri, May 22, 2020 at 7:24 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > Commit
> >
> > 82ab9b6705bd ("dt-bindings: arm: Add Akebi96 board support")
> >
> > is missing a Signed-off-by from its committer.
>
>
> Sorry, I missed to add it.
>
> Olof, Arnd,
> If you want me to resend the pull-request,
> please let me know.
> (but, probably it is too late, I guess...)
Yes, I think it's too late, I did a lot of merges yesterday and would
rather not rebase them.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: linux-next: manual merge of the devicetree tree with the arm-soc tree
From: Arnd Bergmann @ 2020-05-22 8:08 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Masami Hiramatsu, Linux Kernel Mailing List, Masahiro Yamada,
Linux Next Mailing List, Rob Herring, Olof Johansson, ARM
In-Reply-To: <20200522160313.09cb2b7e@canb.auug.org.au>
On Fri, May 22, 2020 at 8:03 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
> index 10a7f0752281,113f93b9ae55..000000000000
> --- a/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
> +++ b/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
> @@@ -51,9 -51,8 +51,9 @@@ properties
> - description: LD20 SoC boards
> items:
> - enum:
> - - socionext,uniphier-ld20-akebi96
> - - socionext,uniphier-ld20-global
> - - socionext,uniphier-ld20-ref
> ++ - socionext,uniphier-ld20-akebi96
> + - socionext,uniphier-ld20-global
> + - socionext,uniphier-ld20-ref
> - const: socionext,uniphier-ld20
> - description: PXs3 SoC boards
> items:
Ok, thanks! I think can let Linus handle this in the merge window.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64/acpi: NULL dereference reports from UBSAN at boot
From: Hanjun Guo @ 2020-05-22 8:07 UTC (permalink / raw)
To: Will Deacon, lorenzo.pieralisi
Cc: mark.rutland, rjw, linux-kernel, linux-arm-kernel
In-Reply-To: <20200521100952.GA5360@willie-the-truck>
Hi Will,
On 2020/5/21 18:09, Will Deacon wrote:
> Hi folks,
>
> I just tried booting the arm64 for-kernelci branch under QEMU (version
> 4.2.50 (v4.2.0-779-g4354edb6dcc7)) with UBSAN enabled, and I see a couple
> of NULL pointer dereferences reported at boot. I think they're both GIC
> related (log below). I don't see a panic with UBSAN disabled, so something's
> fishy here.
>
> Please can you take a look when you get a chance? I haven't had time to see
> if this is a regression or not, but I don't think it's particularly serious
> as I have all sorts of horrible stuff enabled in my .config, since I'm
> trying to chase down another bug:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/plain/arch/arm64/configs/fuzzing.config?h=fuzzing/arm64-kernelci-20200519&id=c149cf6a51aa4f72d53fc681c6661094e93ef660
>
> (on top of defconfig)
>
> CONFIG_FAIL_PAGE_ALLOC may be to blame.
I enabled UBSAN and CONFIG_FAIL_PAGE_ALLOC on top of defconfig,
testing against the for-kernelci branch on the D06 board, I
can see some UBSAN warnings from megaraid_sas driver [0], but not
from any other subsystem including ACPI, I will try all your
configs above to see if I can get more warnings.
Thanks
Hanjun
[0]:
[ 18.244272]
================================================================================
[ 18.252673] UBSAN: array-index-out-of-bounds in
drivers/scsi/megaraid/megaraid_sas_fp.c:104:32
[ 18.261244] index 1 is out of range for type 'MR_LD_SPAN_MAP [1]'
[ 18.267313] CPU: 0 PID: 656 Comm: kworker/0:1 Not tainted
5.7.0-rc6-1-14703-gf4582661223d-dirty #20
[ 18.276314] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS
2280-V2 CS V3.B210.01 03/12/2020
[ 18.285151] Workqueue: events work_for_cpu_fn
[ 18.289488] Call trace:
[ 18.291925] dump_backtrace+0x0/0x248
[ 18.295572] show_stack+0x18/0x28
[ 18.298873] dump_stack+0xc0/0x10c
[ 18.302261] ubsan_epilogue+0x10/0x58
[ 18.305905] __ubsan_handle_out_of_bounds+0x8c/0xa8
[ 18.310763] mr_update_load_balance_params+0x118/0x120
[ 18.315877] MR_ValidateMapInfo+0x300/0xb00
[ 18.320040] megasas_get_map_info+0x134/0x1f8
[ 18.324377] megasas_init_adapter_fusion+0xba8/0x10a0
[ 18.329403] megasas_probe_one+0x6e0/0x1b70
[ 18.333569] local_pci_probe+0x40/0xb0
[ 18.337299] work_for_cpu_fn+0x1c/0x30
[ 18.341031] process_one_work+0x1f8/0x378
[ 18.345022] worker_thread+0x21c/0x4c0
[ 18.348753] kthread+0x150/0x158
[ 18.351967] ret_from_fork+0x10/0x18
[ 18.355529]
================================================================================
[ 18.592274]
================================================================================
[ 18.600672] UBSAN: array-index-out-of-bounds in
drivers/scsi/megaraid/megaraid_sas_fp.c:141:9
[ 18.609155] index 1 is out of range for type 'MR_LD_SPAN_MAP [1]'
[ 18.615221] CPU: 0 PID: 656 Comm: kworker/0:1 Not tainted
5.7.0-rc6-1-14703-gf4582661223d-dirty #20
[ 18.624222] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS
2280-V2 CS V3.B210.01 03/12/2020
[ 18.633050] Workqueue: events work_for_cpu_fn
[ 18.637387] Call trace:
[ 18.639822] dump_backtrace+0x0/0x248
[ 18.643467] show_stack+0x18/0x28
[ 18.646767] dump_stack+0xc0/0x10c
[ 18.650152] ubsan_epilogue+0x10/0x58
[ 18.653796] __ubsan_handle_out_of_bounds+0x8c/0xa8
[ 18.658652] MR_GetLDTgtId+0x58/0x60
[ 18.662211] megasas_sync_map_info+0xd0/0x1c0
[ 18.666547] megasas_init_adapter_fusion+0xd60/0x10a0
[ 18.671574] megasas_probe_one+0x6e0/0x1b70
[ 18.675736] local_pci_probe+0x40/0xb0
[ 18.679466] work_for_cpu_fn+0x1c/0x30
[ 18.683197] process_one_work+0x1f8/0x378
[ 18.687188] worker_thread+0x21c/0x4c0
[ 18.690920] kthread+0x150/0x158
[ 18.694123] ret_from_fork+0x10/0x18
[ 18.697683]
================================================================================
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 06/11] net: ethernet: mtk-eth-mac: new driver
From: Arnd Bergmann @ 2020-05-22 7:49 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Edwin Peer, DTML, Stephane Le Provost, Bartosz Golaszewski,
Pedro Tsai, Sean Wang, linux-kernel@vger.kernel.org, Mark Lee,
Fabien Parent, Rob Herring, moderated list:ARM/Mediatek SoC...,
Andrew Perepech, John Crispin, Matthias Brugger, Jakub Kicinski,
Networking, David S . Miller, Linux ARM, Heiner Kallweit
In-Reply-To: <CAMRc=MfVkbDSfEV71SD57dpYthdx5epD0FOvjRx8qQGT+SgsTQ@mail.gmail.com>
On Fri, May 22, 2020 at 9:44 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> śr., 20 maj 2020 o 23:23 Arnd Bergmann <arnd@arndb.de> napisał(a):
> > On Wed, May 20, 2020 at 7:35 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > śr., 20 maj 2020 o 16:37 Arnd Bergmann <arnd@arndb.de> napisał(a):
> > > My thinking was this: if I mask the relevant interrupt (TX/RX
> > > complete) and ack it right away, the status bit will be asserted on
> > > the next packet received/sent but the process won't get interrupted
> > > and when I unmask it, it will fire right away and I won't have to
> > > recheck the status register. I noticed that if I ack it at the end of
> > > napi poll callback, I end up missing certain TX complete interrupts
> > > and end up seeing a lot of retransmissions even if I reread the status
> > > register. I'm not yet sure where this race happens.
> >
> > Right, I see. If you just ack at the end of the poll function, you need
> > to check the rings again to ensure you did not miss an interrupt
> > between checking observing both rings to be empty and the irq-ack.
> >
> > I suspect it's still cheaper to check the two rings with an uncached
> > read from memory than to to do the read-modify-write on the mmio,
> > but you'd have to measure that to be sure.
> >
>
> Unfortunately the PHY on the board I have is 100Mbps which is the
> limiting factor in benchmarking this driver. :(
>
> If you're fine with this - I'd like to fix the minor issues you
> pointed out and stick with the current approach for now. We can always
> fix the implementation in the future once a board with a Gigabit PHY
> is out. Most ethernet drivers don't use such fine-grained interrupt
> control anyway. I expect the performance differences to be miniscule
> really.
Ok, fair enough. The BQL limiting is the part that matters the most
for performance on slow lines (preventing long latencies from
buffer bloat), and you have that now.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 06/11] net: ethernet: mtk-eth-mac: new driver
From: Bartosz Golaszewski @ 2020-05-22 7:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Edwin Peer, DTML, Stephane Le Provost, Bartosz Golaszewski,
Pedro Tsai, Sean Wang, linux-kernel@vger.kernel.org, Mark Lee,
Fabien Parent, Rob Herring, moderated list:ARM/Mediatek SoC...,
Andrew Perepech, John Crispin, Matthias Brugger, Jakub Kicinski,
Networking, David S . Miller, Linux ARM, Heiner Kallweit
In-Reply-To: <CAK8P3a1nhPj6kRhwyXzDK3BGbh66XG6Fmp44QuM1NhFPPBTtPQ@mail.gmail.com>
śr., 20 maj 2020 o 23:23 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> On Wed, May 20, 2020 at 7:35 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > śr., 20 maj 2020 o 16:37 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> > > I just noticed how the naming of NET_MEDIATEK_MAC and NET_MEDIATEK_SOC
> > > for two different drivers doing the same thing is really confusing.
> > >
> > > Maybe someone can come up with a better name, such as one
> > > based on the soc it first showed up in.
> > >
> >
> > This has been discussed under one of the previous submissions.
> > MediaTek wants to use this IP on future designs as well and it's
> > already used on multiple SoCs so they want the name to be generic. I
> > also argued that this is a driver strongly tied to a specific
> > platform(s) so if someone wants to compile it - they probably know
> > what they're doing.
> >
> > That being said: I verified with MediaTek and the name of the IP I can
> > use is "star" so they proposed "mtk-star-eth". I would personally
> > maybe go with "mtk-star-mac". How about those two?
>
> Both seem fine to me. If this was previously discussed, I don't want
> do further bike-shedding and I'd trust you to pick a sensible name
> based on the earlier discussions.
>
> > > + /* One of the counters reached 0x8000000 - update stats and
> > > > + * reset all counters.
> > > > + */
> > > > + if (unlikely(status & MTK_MAC_REG_INT_STS_MIB_CNT_TH)) {
> > > > + mtk_mac_intr_disable_stats(priv);
> > > > + schedule_work(&priv->stats_work);
> > > > + }
> > > > + befor
> > > > + mtk_mac_intr_ack_all(priv);
> > >
> > > The ack here needs to be dropped, otherwise you can get further
> > > interrupts before the bottom half has had a chance to run.
> > >
> >
> > My thinking was this: if I mask the relevant interrupt (TX/RX
> > complete) and ack it right away, the status bit will be asserted on
> > the next packet received/sent but the process won't get interrupted
> > and when I unmask it, it will fire right away and I won't have to
> > recheck the status register. I noticed that if I ack it at the end of
> > napi poll callback, I end up missing certain TX complete interrupts
> > and end up seeing a lot of retransmissions even if I reread the status
> > register. I'm not yet sure where this race happens.
>
> Right, I see. If you just ack at the end of the poll function, you need
> to check the rings again to ensure you did not miss an interrupt
> between checking observing both rings to be empty and the irq-ack.
>
> I suspect it's still cheaper to check the two rings with an uncached
> read from memory than to to do the read-modify-write on the mmio,
> but you'd have to measure that to be sure.
>
Unfortunately the PHY on the board I have is 100Mbps which is the
limiting factor in benchmarking this driver. :(
If you're fine with this - I'd like to fix the minor issues you
pointed out and stick with the current approach for now. We can always
fix the implementation in the future once a board with a Gigabit PHY
is out. Most ethernet drivers don't use such fine-grained interrupt
control anyway. I expect the performance differences to be miniscule
really.
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: mediatek: Add MT6397 Pin Controller
From: Lee Jones @ 2020-05-22 7:37 UTC (permalink / raw)
To: matthias.bgg
Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20200110145952.9720-1-matthias.bgg@kernel.org>
On Fri, 10 Jan 2020, matthias.bgg@kernel.org wrote:
> From: Matthias Brugger <matthias.bgg@gmail.com>
>
> The MT6397 mfd includes a pin controller. Add binding
> a description for it.
>
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
>
> ---
>
> Documentation/devicetree/bindings/mfd/mt6397.txt | 5 +++++
> 1 file changed, 5 insertions(+)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: mediatek: Add MT6397 Pin Controller
From: Lee Jones @ 2020-05-22 7:37 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mark Rutland, Rob Herring, devicetree, linux-kernel,
linux-mediatek, matthias.bgg, linux-arm-kernel
In-Reply-To: <ce3747e5-41db-a168-0602-37337d8530f2@gmail.com>
On Thu, 21 May 2020, Matthias Brugger wrote:
> Hi Lee,
>
> On 15/01/2020 16:19, Rob Herring wrote:
> > On Fri, 10 Jan 2020 15:59:51 +0100, matthias.bgg@kernel.org wrote:
> >> From: Matthias Brugger <matthias.bgg@gmail.com>
> >>
> >> The MT6397 mfd includes a pin controller. Add binding
> >> a description for it.
> >>
> >> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> >>
> >> ---
> >>
> >> Documentation/devicetree/bindings/mfd/mt6397.txt | 5 +++++
> >> 1 file changed, 5 insertions(+)
> >>
> >
> > Acked-by: Rob Herring <robh@kernel.org>
> >
>
> It looks like this fall through the cracks.
> Would you consider to queue it or do you have further comments?
There is a current issue where Rob and I are both taking patches.
Sometimes we both assume the other will take the patch.
Apologies.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/8] iio: core: wrap IIO device into an iio_dev_opaque object
From: Ardelean, Alexandru @ 2020-05-22 6:58 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Cc: alexandre.belloni@bootlin.com, alexandre.torgue@st.com,
ludovic.desroches@microchip.com, ak@it-klinger.de,
mcoquelin.stm32@gmail.com, eugen.hristev@microchip.com,
jic23@kernel.org
In-Reply-To: <20200514131710.84201-1-alexandru.ardelean@analog.com>
On Thu, 2020-05-14 at 16:17 +0300, Alexandru Ardelean wrote:
> This change starts to hide some internal fields of the IIO device into
> the framework.
>
> Because the iio_priv_to_dev() will be hidden some pre-work is done to
> try to remove it from some interrupt handlers.
> iio_priv_to_dev() will become a function call and won't be expandable
> into place (as-is now as an inline function).
>
I'll defer this series.
A cleanup of iio_priv_to_dev() doesn't look like a bit detour.
> Changelog v1 -> v2:
> - add pre-work patches that remove some calls to iio_priv_to_dev() from
> interrupt handlers
> - renamed iio_dev_priv -> iio_dev_opaque
> - moved the iio_dev_opaque to 'include/linux/iio/iio-opaque.h' this way
> it should be usable for debugging
> - the iio_priv() call, is still an inline function that returns an
> 'indio_dev->priv' reference; this field is added to 'struct iio_dev';
> the reference is computed in iio_device_alloc() and should be
> cacheline aligned
> - the to_iio_dev_opaque() container is in the
> 'include/linux/iio/iio-opaque.h' header; it's still implemented with
> some pointer arithmetic; one idea was to do it via an
> 'indio_dev->opaque' field; that may still be an optionif there are
> some opinions in that direction
>
> Alexandru Ardelean (8):
> iio: proximity: ping: pass reference to IIO device via call-stack
> iio: at91-sama5d2_adc: pass ref to IIO device via param for int
> function
> iio: at91_adc: pass ref to IIO device via param for int function
> iio: stm32-dfsdm-adc: pass iio device as arg for the interrupt handler
> iio: stm32-adc: pass iio device as arg for the interrupt handler
> iio: core: wrap IIO device into an iio_dev_opaque object
> iio: core: simplify alloc alignment code
> iio: core: move debugfs data on the private iio dev info
>
> drivers/iio/adc/at91-sama5d2_adc.c | 7 ++-
> drivers/iio/adc/at91_adc.c | 5 +-
> drivers/iio/adc/stm32-adc.c | 10 ++--
> drivers/iio/adc/stm32-dfsdm-adc.c | 6 +--
> drivers/iio/industrialio-core.c | 75 ++++++++++++++++++++----------
> drivers/iio/proximity/ping.c | 5 +-
> include/linux/iio/iio-opaque.h | 27 +++++++++++
> include/linux/iio/iio.h | 24 +++-------
> 8 files changed, 99 insertions(+), 60 deletions(-)
> create mode 100644 include/linux/iio/iio-opaque.h
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:mmp/fixes] BUILD SUCCESS 24cf6eef79a7e85cfd2ef9dea52f769c9192fc6e
From: kbuild test robot @ 2020-05-22 6:44 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mmp/fixes
branch HEAD: 24cf6eef79a7e85cfd2ef9dea52f769c9192fc6e ARM: dts: mmp3: Drop usb-nop-xceiv from HSIC phy
elapsed time: 529m
configs tested: 42
configs skipped: 94
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
sparc allyesconfig
mips allyesconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
i386 allnoconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
arc defconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:mvebu/dt] BUILD SUCCESS 1383d42cffa68c03d886ae846b3e3f6e3bbd784c
From: kbuild test robot @ 2020-05-22 6:44 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mvebu/dt
branch HEAD: 1383d42cffa68c03d886ae846b3e3f6e3bbd784c ARM: dts: kirkwood: ReadyNAS NV+v2: Add LCD panel
elapsed time: 6531m
configs tested: 239
configs skipped: 127
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sparc allyesconfig
mips allyesconfig
m68k allyesconfig
sh sh03_defconfig
arm vf610m4_defconfig
h8300 defconfig
mips cavium_octeon_defconfig
microblaze defconfig
powerpc64 alldefconfig
arm integrator_defconfig
arc nsimosci_hs_defconfig
s390 defconfig
um allnoconfig
sh secureedge5410_defconfig
sh apsh4ad0a_defconfig
powerpc allmodconfig
s390 debug_defconfig
sh ap325rxa_defconfig
c6x defconfig
h8300 h8300h-sim_defconfig
arm u300_defconfig
c6x evmc6457_defconfig
arm corgi_defconfig
mips cu1000-neo_defconfig
mips xway_defconfig
arm ixp4xx_defconfig
arm mps2_defconfig
arm davinci_all_defconfig
mips db1xxx_defconfig
arm64 alldefconfig
sh sh2007_defconfig
arm pleb_defconfig
h8300 alldefconfig
microblaze mmu_defconfig
powerpc ppc44x_defconfig
arm colibri_pxa300_defconfig
arm clps711x_defconfig
mips maltasmvp_eva_defconfig
arm magician_defconfig
sh allnoconfig
arc vdk_hs38_defconfig
sh se7751_defconfig
arm netwinder_defconfig
arm iop32x_defconfig
mips ath25_defconfig
mips malta_defconfig
arm assabet_defconfig
arm exynos_defconfig
m68k defconfig
arm h3600_defconfig
ia64 allnoconfig
mips loongson3_defconfig
sh sdk7786_defconfig
arm u8500_defconfig
parisc generic-32bit_defconfig
sparc64 allyesconfig
mips lasat_defconfig
mips tb0287_defconfig
powerpc mgcoge_defconfig
um x86_64_defconfig
powerpc storcenter_defconfig
sh shmin_defconfig
mips decstation_defconfig
mips lemote2f_defconfig
powerpc tqm8xx_defconfig
arm shmobile_defconfig
arm stm32_defconfig
powerpc holly_defconfig
mips tb0226_defconfig
h8300 h8s-sim_defconfig
m68k m5208evb_defconfig
sh ecovec24_defconfig
sh se7721_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
sh r7780mp_defconfig
arm sama5_defconfig
sh se7712_defconfig
m68k m5307c3_defconfig
mips nlm_xlr_defconfig
sh migor_defconfig
powerpc mpc512x_defconfig
nds32 defconfig
arm moxart_defconfig
um allyesconfig
mips rb532_defconfig
arm imote2_defconfig
i386 allnoconfig
i386 defconfig
i386 debian-10.3
i386 allyesconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allnoconfig
powerpc defconfig
x86_64 randconfig-a005-20200517
x86_64 randconfig-a003-20200517
x86_64 randconfig-a006-20200517
x86_64 randconfig-a004-20200517
x86_64 randconfig-a001-20200517
x86_64 randconfig-a002-20200517
i386 randconfig-a006-20200518
i386 randconfig-a005-20200518
i386 randconfig-a001-20200518
i386 randconfig-a003-20200518
i386 randconfig-a004-20200518
i386 randconfig-a002-20200518
i386 randconfig-a006-20200519
i386 randconfig-a005-20200519
i386 randconfig-a001-20200519
i386 randconfig-a003-20200519
i386 randconfig-a004-20200519
i386 randconfig-a002-20200519
i386 randconfig-a001-20200520
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a006-20200517
i386 randconfig-a005-20200517
i386 randconfig-a003-20200517
i386 randconfig-a001-20200517
i386 randconfig-a004-20200517
i386 randconfig-a002-20200517
x86_64 randconfig-a003-20200519
x86_64 randconfig-a005-20200519
x86_64 randconfig-a004-20200519
x86_64 randconfig-a006-20200519
x86_64 randconfig-a002-20200519
x86_64 randconfig-a001-20200519
x86_64 randconfig-a016-20200518
x86_64 randconfig-a012-20200518
x86_64 randconfig-a015-20200518
x86_64 randconfig-a013-20200518
x86_64 randconfig-a011-20200518
x86_64 randconfig-a014-20200518
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
i386 randconfig-a012-20200518
i386 randconfig-a014-20200518
i386 randconfig-a016-20200518
i386 randconfig-a011-20200518
i386 randconfig-a015-20200518
i386 randconfig-a013-20200518
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a012-20200519
i386 randconfig-a014-20200519
i386 randconfig-a016-20200519
i386 randconfig-a011-20200519
i386 randconfig-a015-20200519
i386 randconfig-a013-20200519
i386 randconfig-a013-20200521
i386 randconfig-a012-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a016-20200521
i386 randconfig-a014-20200521
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allmodconfig
um allmodconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:rockchip/dt32] BUILD SUCCESS 54b1a4e070330c3fba5becfb0b619bf360bc2657
From: kbuild test robot @ 2020-05-22 6:44 UTC (permalink / raw)
To: Heiko Stuebner; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git rockchip/dt32
branch HEAD: 54b1a4e070330c3fba5becfb0b619bf360bc2657 ARM: dts: rockchip: add rga node for rk322x
elapsed time: 4788m
configs tested: 191
configs skipped: 119
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sparc allyesconfig
mips allyesconfig
m68k allyesconfig
nds32 alldefconfig
powerpc chrp32_defconfig
m68k atari_defconfig
sh sdk7786_defconfig
arm vf610m4_defconfig
arm davinci_all_defconfig
sh r7780mp_defconfig
arm sunxi_defconfig
sh rsk7269_defconfig
parisc alldefconfig
sh apsh4a3a_defconfig
arc nsimosci_hs_smp_defconfig
arm prima2_defconfig
sh polaris_defconfig
sh microdev_defconfig
mips allnoconfig
arm exynos_defconfig
mips db1xxx_defconfig
c6x defconfig
arm64 alldefconfig
sh sh2007_defconfig
arm hackkit_defconfig
arc haps_hs_smp_defconfig
sh se7712_defconfig
arm badge4_defconfig
arm oxnas_v6_defconfig
arc vdk_hs38_defconfig
sh se7751_defconfig
arm netwinder_defconfig
arm iop32x_defconfig
mips ath25_defconfig
arm u8500_defconfig
parisc generic-32bit_defconfig
sparc64 allyesconfig
mips lasat_defconfig
mips tb0287_defconfig
powerpc mgcoge_defconfig
um x86_64_defconfig
powerpc storcenter_defconfig
sh shmin_defconfig
powerpc tqm8xx_defconfig
arm shmobile_defconfig
arm stm32_defconfig
powerpc holly_defconfig
mips tb0226_defconfig
h8300 h8s-sim_defconfig
m68k m5208evb_defconfig
sh ecovec24_defconfig
sh se7721_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
arm sama5_defconfig
parisc allnoconfig
mips maltaup_xpa_defconfig
sh lboxre2_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allmodconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a006-20200519
i386 randconfig-a005-20200519
i386 randconfig-a001-20200519
i386 randconfig-a003-20200519
i386 randconfig-a004-20200519
i386 randconfig-a002-20200519
i386 randconfig-a001-20200520
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a006-20200518
i386 randconfig-a005-20200518
i386 randconfig-a001-20200518
i386 randconfig-a003-20200518
i386 randconfig-a002-20200518
x86_64 randconfig-a003-20200519
x86_64 randconfig-a005-20200519
x86_64 randconfig-a004-20200519
x86_64 randconfig-a006-20200519
x86_64 randconfig-a002-20200519
x86_64 randconfig-a001-20200519
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a012-20200519
i386 randconfig-a014-20200519
i386 randconfig-a016-20200519
i386 randconfig-a011-20200519
i386 randconfig-a015-20200519
i386 randconfig-a013-20200519
i386 randconfig-a013-20200521
i386 randconfig-a012-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a016-20200521
i386 randconfig-a014-20200521
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 05/19] mtd: spi-nor: add support for DTR protocol
From: masonccyang @ 2020-05-22 6:30 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Alexandre Belloni, Vignesh Raghavendra, Tudor Ambarus, juliensu,
Richard Weinberger, Mark Brown, Sekhar Nori, linux-kernel,
linux-spi, Ludovic Desroches, Boris Brezillon, linux-mediatek,
Miquel Raynal, Matthias Brugger, linux-mtd, Pratyush Yadav,
linux-arm-kernel
In-Reply-To: <20200519142642.24131-6-p.yadav@ti.com>
Hi Pratyush,
> +/**
> + * spi_nor_spimem_setup_op() - Set up common properties of a spi-mem
op.
> + * @nor: pointer to a 'struct spi_nor'
> + * @op: pointer to the 'struct spi_mem_op' whose properties
> + * need to be initialized.
> + * @proto: the protocol from which the properties need to be set.
> + */
> +void spi_nor_spimem_setup_op(const struct spi_nor *nor,
> + struct spi_mem_op *op,
> + const enum spi_nor_protocol proto)
> +{
> + u8 ext;
> +
> + op->cmd.buswidth = spi_nor_get_protocol_inst_nbits(proto);
> +
> + if (op->addr.nbytes)
> + op->addr.buswidth = spi_nor_get_protocol_addr_nbits(proto);
> +
> + if (op->dummy.nbytes)
> + op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto);
> +
> + if (op->data.nbytes)
> + op->data.buswidth = spi_nor_get_protocol_data_nbits(proto);
> +
> + if (spi_nor_protocol_is_dtr(proto)) {
As mentioned before that I am also patching mx25* which supports 8S-8S-8S
and
8D-8D-8D mode.
please patch to spi_nor_protocol_is_8_8_8(proto) for 8S-8S-8S mode
support.
> + /*
> + * spi-mem supports mixed DTR modes, but right now we can only
> + * have all phases either DTR or STR. IOW, spi-mem can have
> + * something like 4S-4D-4D, but spi-nor can't. So, set all 4
> + * phases to either DTR or STR.
> + */
if (spi_nor_protocol_is_8D_8D_8D(proto) {
> + op->cmd.dtr = op->addr.dtr = op->dummy.dtr
> + = op->data.dtr = true;
> +
> + /* 2 bytes per clock cycle in DTR mode. */
> + op->dummy.nbytes *= 2;
}
> +
> + ext = spi_nor_get_cmd_ext(nor, op);
> + op->cmd.opcode = (op->cmd.opcode << 8) | ext;
> + op->cmd.nbytes = 2;
> + }
> +}
> +
thanks & best regards,
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1] usb: musb: dsps: set MUSB_DA8XX quirk for AM335x
From: Oleksij Rempel @ 2020-05-22 6:21 UTC (permalink / raw)
To: Bin Liu, Michael Grzeschik, linux-arm-kernel, linux-kernel,
Pengutronix Kernel Team, Greg Kroah-Hartman, linux-usb, russell,
fercerpav
In-Reply-To: <20200520145505.GC15845@iaqt7>
[-- Attachment #1.1: Type: text/plain, Size: 6454 bytes --]
On Wed, May 20, 2020 at 09:55:05AM -0500, Bin Liu wrote:
> On Wed, May 20, 2020 at 06:49:34AM +0200, Oleksij Rempel wrote:
> > On Tue, May 19, 2020 at 05:18:51PM -0500, Bin Liu wrote:
> > > Hi,
> > >
> > > On Fri, Mar 27, 2020 at 06:38:49AM +0100, Oleksij Rempel wrote:
> > > > Beagle Bone Black has different memory corruptions if kernel is
> > > > configured with USB_TI_CPPI41_DMA=y. This issue is reproducible with
> > > > ath9k-htc driver (ar9271 based wifi usb controller):
> > > >
> > > > root@AccessBox:~ iw dev wlan0 set monitor fcsfail otherbss
> > > > root@AccessBox:~ ip l s dev wlan0 up
> > > > kmemleak: Cannot insert 0xda577e40 into the object search tree (overlaps existing)
> > > > CPU: 0 PID: 176 Comm: ip Not tainted 5.5.0 #7
> > > > Hardware name: Generic AM33XX (Flattened Device Tree)
> > > > [<c0112c14>] (unwind_backtrace) from [<c010dc98>] (show_stack+0x18/0x1c)
> > > > [<c010dc98>] (show_stack) from [<c08c7c2c>] (dump_stack+0x84/0x98)
> > > > [<c08c7c2c>] (dump_stack) from [<c02c75a8>] (create_object+0x2f8/0x324)
> > > > [<c02c75a8>] (create_object) from [<c02b8928>] (kmem_cache_alloc+0x1a8/0x39c)
> > > > [<c02b8928>] (kmem_cache_alloc) from [<c072fb68>] (__alloc_skb+0x60/0x174)
> > > > [<c072fb68>] (__alloc_skb) from [<bf0c5c58>] (ath9k_wmi_cmd+0x50/0x184 [ath9k_htc])
> > > > [<bf0c5c58>] (ath9k_wmi_cmd [ath9k_htc]) from [<bf0cb410>] (ath9k_regwrite_multi+0x54/0x84 [ath9k_htc])
> > > > [<bf0cb410>] (ath9k_regwrite_multi [ath9k_htc]) from [<bf0cb7fc>] (ath9k_regwrite+0xf0/0xfc [ath9k_htc])
> > > > [<bf0cb7fc>] (ath9k_regwrite [ath9k_htc]) from [<bf1aca78>] (ar5008_hw_process_ini+0x280/0x6c0 [ath9k_hw])
> > > > [<bf1aca78>] (ar5008_hw_process_ini [ath9k_hw]) from [<bf1a66ac>] (ath9k_hw_reset+0x270/0x1458 [ath9k_hw])
> > > > [<bf1a66ac>] (ath9k_hw_reset [ath9k_hw]) from [<bf0c9588>] (ath9k_htc_start+0xb0/0x22c [ath9k_htc])
> > > > [<bf0c9588>] (ath9k_htc_start [ath9k_htc]) from [<bf0eb3c0>] (drv_start+0x4c/0x1e8 [mac80211])
> > > > [<bf0eb3c0>] (drv_start [mac80211]) from [<bf104a84>] (ieee80211_do_open+0x480/0x954 [mac80211])
> > > > [<bf104a84>] (ieee80211_do_open [mac80211]) from [<c075127c>] (__dev_open+0xdc/0x160)
> > > > [<c075127c>] (__dev_open) from [<c07516a8>] (__dev_change_flags+0x1a4/0x204)
> > > > [<c07516a8>] (__dev_change_flags) from [<c0751728>] (dev_change_flags+0x20/0x50)
> > > > [<c0751728>] (dev_change_flags) from [<c076971c>] (do_setlink+0x2ac/0x978)
> > > >
> > > > After applying this patch, the system is running in monitor mode without
> > > > noticeable issues.
> > > >
> > > > Suggested-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > > > ---
> > > > drivers/usb/musb/musb_dsps.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> > > > index 88923175f71e..c01f9e9e69f5 100644
> > > > --- a/drivers/usb/musb/musb_dsps.c
> > > > +++ b/drivers/usb/musb/musb_dsps.c
> > > > @@ -690,7 +690,7 @@ static void dsps_dma_controller_resume(struct dsps_glue *glue) {}
> > > > #endif /* CONFIG_USB_TI_CPPI41_DMA */
> > > >
> > > > static struct musb_platform_ops dsps_ops = {
> > > > - .quirks = MUSB_DMA_CPPI41 | MUSB_INDEXED_EP,
> > > > + .quirks = MUSB_DMA_CPPI41 | MUSB_INDEXED_EP | MUSB_DA8XX,
> > >
> > > The MUSB_DA8XX flag cannot be simply applied to MUSB_DSPS, at least the
> > > teardown and autoreq register offsets are different as show in
> > > cppi41_dma_controller_create().
> >
> > ok
> >
> > > Do you understand what exactly caused the issue?
> >
> > No.
> >
> > Disabling DMA support "solve" this issue as well.
> >
> > Beside, with DMA support, there remains one more crash with different symptoms.
> > I can workaround it by disabling CPU Freq governor, or setting it to performance.
> >
> > > The kernel trace above doesn't provide enuough information.
> >
> > Do you have any suggestions how to instrument the kernel to get needed
> > information? Or, should I try to capture USB traffic before the crash?
>
> First can you please try the following patch instead?
>
> diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
> index 7fbb8a307145..26c996f8b2bd 100644
> --- a/drivers/usb/musb/musb_cppi41.c
> +++ b/drivers/usb/musb/musb_cppi41.c
> @@ -614,7 +614,6 @@ static int cppi41_dma_channel_abort(struct dma_channel *channel)
> }
>
> /* DA8xx Advisory 2.3.27: wait 250 ms before to start the teardown */
> - if (musb->ops->quirks & MUSB_DA8XX)
> mdelay(250);
>
> tdbit = 1 << cppi41_channel->port_num;
The setup is running, it may take some time until it is reproduced.
Reproduce ability seems to depend on the traffic in the air. Since
currently most people are on vocation, there is not many things happen
on WiFi.
> >
> > If it helps, ath9k_htc is a usb wifi adapter. It generates a lot of
> > USB traffic on multiple endpoints. Bulk with data packets and Interrupt
> > with register accesses, LED blinking... etc.
>
> Do you have a link to the picture or description of the adapter? I'd like
> to see if I can buy the same to take a look.
It is AR9271 based adapter. Searching on ebay for this chip will give a
lot of adapters (even very suspicious .. promising 600!!! or 300!! Mbps,
actually it is 150 Mbps)
I would recommend ALFA AWUS036NHA or this one
https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-w-external-antenna-gnu-linux-tpe-n150usbl
This adapters provide access to the UART pins of the AR9271 chip, so you
will be able to talk to firmware.
Firmware source code is available here:
https://github.com/qca/open-ath9k-htc-firmware
The debian package for this firmware is build from source as well and in
the main repository (coll he?! :D)
If you do not wont to hack on firmware, then you can use the mini adapter:
https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 5/5] dt-bindings: arm: fsl: add different Protonic boards
From: Oleksij Rempel @ 2020-05-22 6:03 UTC (permalink / raw)
To: robh
Cc: Mark Rutland, devicetree, Fabio Estevam, Sascha Hauer,
linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo, linux-arm-kernel
In-Reply-To: <20200521200002.GA2800876@bogus>
[-- Attachment #1.1: Type: text/plain, Size: 1050 bytes --]
On Thu, May 21, 2020 at 02:00:02PM -0600, robh@kernel.org wrote:
> On Wed, 20 May 2020 17:41:16 +0200, Oleksij Rempel wrote:
> > Add Protonic PRTI6Q, WD2, RVT, VT7 boards.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > Documentation/devicetree/bindings/arm/fsl.yaml | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
>
>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
>
> If a tag was not added on purpose, please state why and what changed.
Sorry, there is no special reason. I just missed it.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* linux-next: manual merge of the devicetree tree with the arm-soc tree
From: Stephen Rothwell @ 2020-05-22 6:03 UTC (permalink / raw)
To: Rob Herring, Olof Johansson, Arnd Bergmann, ARM
Cc: Masahiro Yamada, Linux Next Mailing List,
Linux Kernel Mailing List, Masami Hiramatsu
[-- Attachment #1.1: Type: text/plain, Size: 1553 bytes --]
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
between commit:
82ab9b6705bd ("dt-bindings: arm: Add Akebi96 board support")
from the arm-soc tree and commit:
9f60a65bc5e6 ("dt-bindings: Clean-up schema indentation formatting")
from the devicetree tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
index 10a7f0752281,113f93b9ae55..000000000000
--- a/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
+++ b/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
@@@ -51,9 -51,8 +51,9 @@@ properties
- description: LD20 SoC boards
items:
- enum:
- - socionext,uniphier-ld20-akebi96
- - socionext,uniphier-ld20-global
- - socionext,uniphier-ld20-ref
++ - socionext,uniphier-ld20-akebi96
+ - socionext,uniphier-ld20-global
+ - socionext,uniphier-ld20-ref
- const: socionext,uniphier-ld20
- description: PXs3 SoC boards
items:
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH V4 1/4] media: v4l2-mem2mem: add v4l2_m2m_suspend, v4l2_m2m_resume
From: Jerry-ch Chen @ 2020-05-22 6:01 UTC (permalink / raw)
To: Tomasz Figa
Cc: devicetree, Sean.Cheng, laurent.pinchart+renesas, Rynn.Wu,
zwisler, srv_heupstream, Jerry-ch Chen, Hans Verkuil, jungo.lin,
sj.huang, yuzhao, linux-mediatek, pihsun, frederic.chen,
matthias.bgg, christie.yu, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200521171101.GA243874@chromium.org>
Hi Tomasz,
On Thu, 2020-05-21 at 17:11 +0000, Tomasz Figa wrote:
> Hi Jerry,
>
> On Wed, Dec 04, 2019 at 08:47:29PM +0800, Jerry-ch Chen wrote:
> > From: Pi-Hsun Shih <pihsun@chromium.org>
> >
> > Add two functions that can be used to stop new jobs from being queued /
> > continue running queued job. This can be used while a driver using m2m
> > helper is going to suspend / wake up from resume, and can ensure that
> > there's no job running in suspend process.
> >
> > BUG=b:143046833
> > TEST=build
> >
> > Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
> > Signed-off-by: Jerry-ch Chen <jerry-ch.chen@mediatek.corp-partner.google.com>
> > ---
> > drivers/media/v4l2-core/v4l2-mem2mem.c | 40 ++++++++++++++++++++++++++
> > include/media/v4l2-mem2mem.h | 22 ++++++++++++++
> > 2 files changed, 62 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c
> > index 5bbdec55b7d7..76ba203e0035 100644
> > --- a/drivers/media/v4l2-core/v4l2-mem2mem.c
> > +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
> > @@ -47,6 +47,10 @@ module_param(debug, bool, 0644);
> > #define TRANS_ABORT (1 << 2)
> >
> >
> > +/* The job queue is not running new jobs */
> > +#define QUEUE_PAUSED (1 << 0)
> > +
> > +
> > /* Offset base for buffers on the destination queue - used to distinguish
> > * between source and destination buffers when mmapping - they receive the same
> > * offsets but for different queues */
> > @@ -88,6 +92,7 @@ static const char * const m2m_entity_name[] = {
> > * @job_queue: instances queued to run
> > * @job_spinlock: protects job_queue
> > * @job_work: worker to run queued jobs.
> > + * @job_queue_flags: flags of the queue status, %QUEUE_PAUSED.
> > * @m2m_ops: driver callbacks
> > */
> > struct v4l2_m2m_dev {
> > @@ -105,6 +110,7 @@ struct v4l2_m2m_dev {
> > struct list_head job_queue;
> > spinlock_t job_spinlock;
> > struct work_struct job_work;
> > + unsigned long job_queue_flags;
> >
> > const struct v4l2_m2m_ops *m2m_ops;
> > };
> > @@ -267,6 +273,12 @@ static void v4l2_m2m_try_run(struct v4l2_m2m_dev *m2m_dev)
> > return;
> > }
> >
> > + if (m2m_dev->job_queue_flags & QUEUE_PAUSED) {
> > + spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags);
> > + dprintk("Running new jobs is paused\n");
> > + return;
> > + }
> > +
> > m2m_dev->curr_ctx = list_first_entry(&m2m_dev->job_queue,
> > struct v4l2_m2m_ctx, queue);
> > m2m_dev->curr_ctx->job_flags |= TRANS_RUNNING;
> > @@ -447,6 +459,34 @@ void v4l2_m2m_job_finish(struct v4l2_m2m_dev *m2m_dev,
> > }
> > EXPORT_SYMBOL(v4l2_m2m_job_finish);
> >
> > +void v4l2_m2m_suspend(struct v4l2_m2m_dev *m2m_dev)
> > +{
> > + unsigned long flags;
> > + struct v4l2_m2m_ctx *curr_ctx;
> > +
> > + spin_lock_irqsave(&m2m_dev->job_spinlock, flags);
> > + m2m_dev->job_queue_flags |= QUEUE_PAUSED;
> > + curr_ctx = m2m_dev->curr_ctx;
> > + spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags);
> > +
> > + if (curr_ctx)
> > + wait_event(curr_ctx->finished,
> > + !(curr_ctx->job_flags & TRANS_RUNNING));
> > +}
> > +EXPORT_SYMBOL(v4l2_m2m_suspend);
> > +
> > +void v4l2_m2m_resume(struct v4l2_m2m_dev *m2m_dev)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&m2m_dev->job_spinlock, flags);
> > + m2m_dev->job_queue_flags &= ~QUEUE_PAUSED;
> > + spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags);
> > +
> > + v4l2_m2m_try_run(m2m_dev);
> > +}
> > +EXPORT_SYMBOL(v4l2_m2m_resume);
> > +
> > int v4l2_m2m_reqbufs(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
> > struct v4l2_requestbuffers *reqbufs)
> > {
> > diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
> > index 5467264771ec..119a195da390 100644
> > --- a/include/media/v4l2-mem2mem.h
> > +++ b/include/media/v4l2-mem2mem.h
> > @@ -183,6 +183,28 @@ v4l2_m2m_buf_done(struct vb2_v4l2_buffer *buf, enum vb2_buffer_state state)
> > vb2_buffer_done(&buf->vb2_buf, state);
> > }
> >
> > +/**
> > + * v4l2_m2m_suspend() - stop new jobs from being run and wait for current job
> > + * to finish
> > + *
> > + * @m2m_dev: opaque pointer to the internal data to handle M2M context
> > + *
> > + * Called by a driver in the suspend hook. Stop new jobs from being run, and
> > + * wait for current running job to finish.
> > + */
> > +void v4l2_m2m_suspend(struct v4l2_m2m_dev *m2m_dev);
> > +
> > +/**
> > + * v4l2_m2m_resume() - resume job running and try to run a queued job
> > + *
> > + * @m2m_dev: opaque pointer to the internal data to handle M2M context
> > + *
> > + * Called by a driver in the resume hook. This reverts the operation of
> > + * v4l2_m2m_suspend() and allows job to be run. Also try to run a queued job if
> > + * there is any.
> > + */
> > +void v4l2_m2m_resume(struct v4l2_m2m_dev *m2m_dev);
> > +
> > /**
> > * v4l2_m2m_reqbufs() - multi-queue-aware REQBUFS multiplexer
> > *
> > --
> > 2.18.0
>
> Reviewed-by: Tomasz Figa <tfiga@chromium.org>
>
Ok, I've added it in the commit message.
Thanks and Best regards,
Jerry
> [Corrected Hans's email address.]
> Hans, does this look good to you?
>
> Best regards,
> Tomasz
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 24/26] arm64: mte: Introduce early param to disable MTE support
From: Patrick Daly @ 2020-05-22 5:57 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, Vladimir Murzin, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Peter Collingbourne, linux-mm, Vincenzo Frascino,
Will Deacon, Dave P Martin, linux-arm-kernel
In-Reply-To: <20200518172054.GL9862@gaia>
On Mon, May 18, 2020 at 06:20:55PM +0100, Catalin Marinas wrote:
> On Mon, May 18, 2020 at 12:31:03PM +0100, Will Deacon wrote:
> > On Mon, May 18, 2020 at 12:26:30PM +0100, Vladimir Murzin wrote:
> > > On 5/15/20 6:16 PM, Catalin Marinas wrote:
> > > > For performance analysis it may be desirable to disable MTE altogether
> > > > via an early param. Introduce arm64.mte_disable and, if true, filter out
> > > > the sanitised ID_AA64PFR1_EL1.MTE field to avoid exposing the HWCAP to
> > > > user.
> > > >
> > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > Cc: Will Deacon <will@kernel.org>
> > > > ---
> > > >
> > > > Notes:
> > > > New in v4.
> > > >
> > > > Documentation/admin-guide/kernel-parameters.txt | 4 ++++
> > > > arch/arm64/kernel/cpufeature.c | 11 +++++++++++
> > > > 2 files changed, 15 insertions(+)
> > > >
> > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > > index f2a93c8679e8..7436e7462b85 100644
> > > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > > @@ -373,6 +373,10 @@
> > > > arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
> > > > Format: <io>,<irq>,<nodeID>
> > > >
> > > > + arm64.mte_disable=
> > > > + [ARM64] Disable Linux support for the Memory
> > > > + Tagging Extension (both user and in-kernel).
> > > > +
> > >
> > > Should it really to take parameter (on/off/true/false)? It may lead to expectation
> > > that arm64.mte_disable=false should enable MT and, yes, double negatives make it
> > > look ugly, so if we do need parameter, can it be arm64.mte=on/off/true/false?
> >
> > I don't think "performance analysis" is a good justification for this
> > parameter tbh. We don't tend to add these options for other architectural
> > features, and I don't see why MTE is any different in this regard.
>
> There is an expectation of performance impact with MTE enabled,
> especially if it's running in synchronous mode. For the in-kernel MTE,
> we could add a parameter which sets sync vs async at boot time rather
> than a big disable knob. It won't affect user space however.
>
> The other 'justification' is if your hardware has weird unexpected
> behaviour but I'd like this handled via errata workarounds.
>
> I'll let the people who asked for this to chip in ;). I agree with you
> that we rarely add these (and I rejected a similar option a few weeks
> ago on the AMU patchset).
We've been looking into other ways this on/off behavior could be achieved.
The "arm,armv8.5-memtag" DT flag already provides what we want - meaning
that this flag could be removed if the system did not support MTE.
I did see your remark on "arm64: mte: Check the DT memory nodes for MTE support"
questioning whether it was the right approach - is this still the case?
--Patrick
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 12/12] bus: fsl-mc: Add ACPI support for fsl-mc
From: Makarand Pawagi @ 2020-05-22 5:32 UTC (permalink / raw)
To: Laurentiu Tudor, Lorenzo Pieralisi,
linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org, Sudeep Holla, Catalin Marinas,
Will Deacon, linux-pci@vger.kernel.org, Joerg Roedel, Hanjun Guo,
Rafael J. Wysocki, linux-acpi@vger.kernel.org,
iommu@lists.linux-foundation.org, Rob Herring, Marc Zyngier,
Diana Madalina Craciun (OSS), Bjorn Helgaas, Robin Murphy
In-Reply-To: <3045acd5-0bcf-40c1-e65f-0b740200b2e0@nxp.com>
Hi Lorenzo,
> -----Original Message-----
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> Sent: Thursday, May 21, 2020 8:33 PM
> To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; linux-arm-
> kernel@lists.infradead.org
> Cc: Diana Madalina Craciun (OSS) <diana.craciun@oss.nxp.com>; Makarand
> Pawagi <makarand.pawagi@nxp.com>; iommu@lists.linux-foundation.org;
> linux-acpi@vger.kernel.org; devicetree@vger.kernel.org; linux-
> pci@vger.kernel.org; Rob Herring <robh+dt@kernel.org>; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Joerg Roedel <joro@8bytes.org>; Hanjun Guo
> <guohanjun@huawei.com>; Bjorn Helgaas <bhelgaas@google.com>; Sudeep
> Holla <sudeep.holla@arm.com>; Robin Murphy <robin.murphy@arm.com>;
> Catalin Marinas <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>;
> Marc Zyngier <maz@kernel.org>
> Subject: Re: [PATCH 12/12] bus: fsl-mc: Add ACPI support for fsl-mc
>
> Hi Lorenzo,
>
> On 5/21/2020 4:00 PM, Lorenzo Pieralisi wrote:
> > From: Diana Craciun <diana.craciun@oss.nxp.com>
> >
> > Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
> > extract memory and other resources.
> >
> > Interrupt (GIC ITS) information is extracted from the MADT table by
> > drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
> >
> > IORT table is parsed to configure DMA.
> >
> > Signed-off-by: Makarand Pawagi <makarand.pawagi@nxp.com>
> > Signed-off-by: Diana Craciun <diana.craciun@oss.nxp.com>
> > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > ---
>
> The author of this patch should be Makarand. I think I accidentaly broke it when
> we exchanged the patches. Very sorry about it.
>
Will you be able to correct this or should I post another patch?
> ---
> Best Regards, Laurentiu
>
>
> > drivers/bus/fsl-mc/fsl-mc-bus.c | 73 +++++++++++++++-----
> > drivers/bus/fsl-mc/fsl-mc-msi.c | 37 +++++-----
> > drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 75
> > ++++++++++++++++++++-
> > 3 files changed, 150 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c
> > b/drivers/bus/fsl-mc/fsl-mc-bus.c index 824ff77bbe86..324d49d6df89
> > 100644
> > --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> > +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > @@ -18,6 +18,8 @@
> > #include <linux/bitops.h>
> > #include <linux/msi.h>
> > #include <linux/dma-mapping.h>
> > +#include <linux/acpi.h>
> > +#include <linux/iommu.h>
> >
> > #include "fsl-mc-private.h"
> >
> > @@ -38,6 +40,7 @@ struct fsl_mc {
> > struct fsl_mc_device *root_mc_bus_dev;
> > u8 num_translation_ranges;
> > struct fsl_mc_addr_translation_range *translation_ranges;
> > + void *fsl_mc_regs;
> > };
> >
> > /**
> > @@ -56,6 +59,10 @@ struct fsl_mc_addr_translation_range {
> > phys_addr_t start_phys_addr;
> > };
> >
> > +#define FSL_MC_FAPR 0x28
> > +#define MC_FAPR_PL BIT(18)
> > +#define MC_FAPR_BMT BIT(17)
> > +
> > /**
> > * fsl_mc_bus_match - device to driver matching callback
> > * @dev: the fsl-mc device to match against @@ -124,7 +131,10 @@
> > static int fsl_mc_dma_configure(struct device *dev)
> > while (dev_is_fsl_mc(dma_dev))
> > dma_dev = dma_dev->parent;
> >
> > - return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
> > + if (dev_of_node(dma_dev))
> > + return of_dma_configure_id(dev, dma_dev->of_node, 0,
> &input_id);
> > +
> > + return acpi_dma_configure_id(dev, DEV_DMA_COHERENT, &input_id);
> > }
> >
> > static ssize_t modalias_show(struct device *dev, struct
> > device_attribute *attr, @@ -865,8 +875,11 @@ static int
> fsl_mc_bus_probe(struct platform_device *pdev)
> > struct fsl_mc_io *mc_io = NULL;
> > int container_id;
> > phys_addr_t mc_portal_phys_addr;
> > - u32 mc_portal_size;
> > - struct resource res;
> > + u32 mc_portal_size, mc_stream_id;
> > + struct resource *plat_res;
> > +
> > + if (!iommu_present(&fsl_mc_bus_type))
> > + return -EPROBE_DEFER;
> >
> > mc = devm_kzalloc(&pdev->dev, sizeof(*mc), GFP_KERNEL);
> > if (!mc)
> > @@ -874,19 +887,33 @@ static int fsl_mc_bus_probe(struct
> > platform_device *pdev)
> >
> > platform_set_drvdata(pdev, mc);
> >
> > + plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > + mc->fsl_mc_regs = devm_ioremap_resource(&pdev->dev, plat_res);
> > + if (IS_ERR(mc->fsl_mc_regs))
> > + return PTR_ERR(mc->fsl_mc_regs);
> > +
> > + if (IS_ENABLED(CONFIG_ACPI) && !dev_of_node(&pdev->dev)) {
> > + mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR);
> > + /*
> > + * HW ORs the PL and BMT bit, places the result in bit 15 of
> > + * the StreamID and ORs in the ICID. Calculate it accordingly.
> > + */
> > + mc_stream_id = (mc_stream_id & 0xffff) |
> > + ((mc_stream_id & (MC_FAPR_PL |
> MC_FAPR_BMT)) ?
> > + 0x4000 : 0);
> > + error = acpi_dma_configure_id(&pdev->dev,
> DEV_DMA_COHERENT,
> > + &mc_stream_id);
> > + if (error)
> > + dev_warn(&pdev->dev, "failed to configure
> dma: %d.\n",
> > + error);
> > + }
> > +
> > /*
> > * Get physical address of MC portal for the root DPRC:
> > */
> > - error = of_address_to_resource(pdev->dev.of_node, 0, &res);
> > - if (error < 0) {
> > - dev_err(&pdev->dev,
> > - "of_address_to_resource() failed for %pOF\n",
> > - pdev->dev.of_node);
> > - return error;
> > - }
> > -
> > - mc_portal_phys_addr = res.start;
> > - mc_portal_size = resource_size(&res);
> > + plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + mc_portal_phys_addr = plat_res->start;
> > + mc_portal_size = resource_size(plat_res);
> > error = fsl_create_mc_io(&pdev->dev, mc_portal_phys_addr,
> > mc_portal_size, NULL,
> > FSL_MC_IO_ATOMIC_CONTEXT_PORTAL,
> &mc_io); @@ -903,11 +930,13 @@
> > static int fsl_mc_bus_probe(struct platform_device *pdev)
> > dev_info(&pdev->dev, "MC firmware version: %u.%u.%u\n",
> > mc_version.major, mc_version.minor, mc_version.revision);
> >
> > - error = get_mc_addr_translation_ranges(&pdev->dev,
> > - &mc->translation_ranges,
> > - &mc->num_translation_ranges);
> > - if (error < 0)
> > - goto error_cleanup_mc_io;
> > + if (dev_of_node(&pdev->dev)) {
> > + error = get_mc_addr_translation_ranges(&pdev->dev,
> > + &mc->translation_ranges,
> > + &mc-
> >num_translation_ranges);
> > + if (error < 0)
> > + goto error_cleanup_mc_io;
> > + }
> >
> > error = dprc_get_container_id(mc_io, 0, &container_id);
> > if (error < 0) {
> > @@ -934,6 +963,7 @@ static int fsl_mc_bus_probe(struct platform_device
> *pdev)
> > goto error_cleanup_mc_io;
> >
> > mc->root_mc_bus_dev = mc_bus_dev;
> > + mc_bus_dev->dev.fwnode = pdev->dev.fwnode;
> > return 0;
> >
> > error_cleanup_mc_io:
> > @@ -967,11 +997,18 @@ static const struct of_device_id
> > fsl_mc_bus_match_table[] = {
> >
> > MODULE_DEVICE_TABLE(of, fsl_mc_bus_match_table);
> >
> > +static const struct acpi_device_id fsl_mc_bus_acpi_match_table[] = {
> > + {"NXP0008", 0 },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(acpi, fsl_mc_bus_acpi_match_table);
> > +
> > static struct platform_driver fsl_mc_bus_driver = {
> > .driver = {
> > .name = "fsl_mc_bus",
> > .pm = NULL,
> > .of_match_table = fsl_mc_bus_match_table,
> > + .acpi_match_table = fsl_mc_bus_acpi_match_table,
> > },
> > .probe = fsl_mc_bus_probe,
> > .remove = fsl_mc_bus_remove,
> > diff --git a/drivers/bus/fsl-mc/fsl-mc-msi.c
> > b/drivers/bus/fsl-mc/fsl-mc-msi.c index e7bbff445a83..8edadf05cbb7
> > 100644
> > --- a/drivers/bus/fsl-mc/fsl-mc-msi.c
> > +++ b/drivers/bus/fsl-mc/fsl-mc-msi.c
> > @@ -13,6 +13,7 @@
> > #include <linux/irq.h>
> > #include <linux/irqdomain.h>
> > #include <linux/msi.h>
> > +#include <linux/acpi_iort.h>
> >
> > #include "fsl-mc-private.h"
> >
> > @@ -179,25 +180,31 @@ struct irq_domain
> > *fsl_mc_msi_create_irq_domain(struct fwnode_handle *fwnode,
> >
> > struct irq_domain *fsl_mc_find_msi_domain(struct device *dev) {
> > - struct irq_domain *msi_domain = NULL;
> > + struct device *root_dprc_dev;
> > + struct device *bus_dev;
> > + struct irq_domain *msi_domain;
> > struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
> >
> > - msi_domain = of_msi_map_get_device_domain(dev, mc_dev->icid,
> > + fsl_mc_get_root_dprc(dev, &root_dprc_dev);
> > + bus_dev = root_dprc_dev->parent;
> > +
> > + if (bus_dev->of_node) {
> > + msi_domain = of_msi_map_get_device_domain(dev,
> > + mc_dev->icid,
> > DOMAIN_BUS_FSL_MC_MSI);
> >
> > - /*
> > - * if the msi-map property is missing assume that all the
> > - * child containers inherit the domain from the parent
> > - */
> > - if (!msi_domain) {
> > - struct device *root_dprc_dev;
> > - struct device *bus_dev;
> > -
> > - fsl_mc_get_root_dprc(dev, &root_dprc_dev);
> > - bus_dev = root_dprc_dev->parent;
> > - msi_domain = of_msi_get_domain(bus_dev,
> > - bus_dev->of_node,
> > - DOMAIN_BUS_FSL_MC_MSI);
> > + /*
> > + * if the msi-map property is missing assume that all the
> > + * child containers inherit the domain from the parent
> > + */
> > + if (!msi_domain)
> > +
> > + msi_domain = of_msi_get_domain(bus_dev,
> > + bus_dev->of_node,
> > + DOMAIN_BUS_FSL_MC_MSI);
> > + } else {
> > + msi_domain = iort_get_device_domain(dev, mc_dev->icid,
> > +
> DOMAIN_BUS_FSL_MC_MSI);
> > }
> >
> > return msi_domain;
> > diff --git a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> > b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> > index a5c8d577e424..b8b948fb6b2d 100644
> > --- a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> > +++ b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> > @@ -7,6 +7,8 @@
> > *
> > */
> >
> > +#include <linux/acpi.h>
> > +#include <linux/acpi_iort.h>
> > #include <linux/of_device.h>
> > #include <linux/of_address.h>
> > #include <linux/irq.h>
> > @@ -30,7 +32,8 @@ static u32 fsl_mc_msi_domain_get_msi_id(struct
> irq_domain *domain,
> > u32 out_id;
> >
> > of_node = irq_domain_get_of_node(domain);
> > - out_id = of_msi_map_id(&mc_dev->dev, of_node, mc_dev->icid);
> > + out_id = of_node ? of_msi_map_id(&mc_dev->dev, of_node, mc_dev-
> >icid) :
> > + iort_msi_map_id(&mc_dev->dev, mc_dev->icid);
> >
> > return out_id;
> > }
> > @@ -79,7 +82,67 @@ static const struct of_device_id its_device_id[] = {
> > {},
> > };
> >
> > -static int __init its_fsl_mc_msi_init(void)
> > +static int __init its_fsl_mc_msi_init_one(struct fwnode_handle *handle,
> > + const char *name)
> > +{
> > + struct irq_domain *parent;
> > + struct irq_domain *mc_msi_domain;
> > +
> > + parent = irq_find_matching_fwnode(handle, DOMAIN_BUS_NEXUS);
> > + if (!parent || !msi_get_domain_info(parent)) {
> > + pr_err("%s: Unable to locate ITS domain\n", name);
> > + return -ENXIO;
> > + }
> > +
> > + mc_msi_domain = fsl_mc_msi_create_irq_domain(handle,
> > + &its_fsl_mc_msi_domain_info,
> > + parent);
> > + if (!mc_msi_domain)
> > + pr_err("ACPIF: unable to create fsl-mc domain\n");
> > +
> > + pr_info("fsl-mc MSI: domain created\n");
> > +
> > + return 0;
> > +}
> > +
> > +static int __init
> > +its_fsl_mc_msi_parse_madt(union acpi_subtable_headers *header,
> > + const unsigned long end)
> > +{
> > + struct acpi_madt_generic_translator *its_entry;
> > + struct fwnode_handle *dom_handle;
> > + const char *node_name;
> > + int err = -ENXIO;
> > +
> > + its_entry = (struct acpi_madt_generic_translator *)header;
> > + node_name = kasprintf(GFP_KERNEL, "ITS@0x%lx",
> > + (long)its_entry->base_address);
> > +
> > + dom_handle = iort_find_domain_token(its_entry->translation_id);
> > + if (!dom_handle) {
> > + pr_err("%s: Unable to locate ITS domain handle\n",
> node_name);
> > + goto out;
> > + }
> > +
> > + err = its_fsl_mc_msi_init_one(dom_handle, node_name);
> > + if (!err)
> > + pr_info("fsl-mc MSI: %s domain created\n", node_name);
> > +
> > +out:
> > + kfree(node_name);
> > + return err;
> > +}
> > +
> > +
> > +static int __init its_fsl_mc_acpi_msi_init(void) {
> > + acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> > + its_fsl_mc_msi_parse_madt, 0);
> > +
> > + return 0;
> > +}
> > +
> > +static int __init its_fsl_mc_of_msi_init(void)
> > {
> > struct device_node *np;
> > struct irq_domain *parent;
> > @@ -113,4 +176,12 @@ static int __init its_fsl_mc_msi_init(void)
> > return 0;
> > }
> >
> > +static int __init its_fsl_mc_msi_init(void) {
> > + its_fsl_mc_of_msi_init();
> > + its_fsl_mc_acpi_msi_init();
> > +
> > + return 0;
> > +}
> > +
> > early_initcall(its_fsl_mc_msi_init);
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v4,0/7] Add Mediatek thermal dirver and dtsi
From: Michael Kao @ 2020-05-22 4:07 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mark Rutland, devicetree, srv_heupstream, linux-pm,
Daniel Lezcano, linux-kernel, Eduardo Valentin, Rob Herring,
linux-mediatek, hsinyi, Zhang Rui, linux-arm-kernel
In-Reply-To: <7e205390-c7a7-b8c9-3ba2-344a04dc6696@gmail.com>
On Thu, 2020-05-21 at 14:51 +0200, Matthias Brugger wrote:
> Hi Michael,
>
> On 23/03/2020 13:15, Michael Kao wrote:
> > This patchset supports for MT8183 chip to mtk_thermal.c.
> > Add thermal zone of all the thermal sensor in SoC for
> > another get temperatrue. They don't need to thermal throttle.
> > And we bind coolers for thermal zone nodes of cpu_thermal.
> >
> > Rebase to kernel-5.6-rc1.
> >
> > Update content:
> >
> > [1/7]
> > - Squash thermal zone settings in the dtsi from [v3,5/8]
> > arm64: dts: mt8183: Increase polling frequency for CPU thermal zone
> >
> > - Remove the property of interrupts and mediatek,hw-reset-temp
> >
> > [2/7]
> > - Correct commit message
> >
> > [4/7]
> > - Change the target temperature to the 80C and change the commit message
> >
> > [6/7]
> > - Adjust newline alignment
> >
> > - Fix the judgement on the return value of registering thermal zone
> >
> > This patch series base on these patches [1].
> >
> > [v7,3/3] PM / AVS: SVS: Introduce SVS engine (https://patchwork.kernel.org/patch/11439829/)
> >
> > Matthias Kaehlcke (1):
> > arm64: dts: mt8183: Configure CPU cooling
> >
> > Michael Kao (6):
> > arm64: dts: mt8183: add thermal zone node
> > arm64: dts: mt8183: add dynamic power coefficients
> > arm64: dts: mt8183: Add #cooling-cells to CPU nodes
> > thermal: mediatek: mt8183: fix bank number settings
>
> Do I understand correctly that we need to fix the bank number before we can add
> the device tree changes. And that the last two patches are enhancements for the
> driver but needed to get a working version?
>
> Regards,
> Matthias
Hi Matthias,
There is one bank setting of mt8183 config.
If the device tree merged first. I worry that it will crash when the
thermal zone read temperature.
It will access the invalid index of bank.
So please add the patch "fix bank number settings "
first.222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222
>
> > thermal: mediatek: add another get_temp ops for thermal sensors
> > thermal: mediatek: use spinlock to protect PTPCORESEL
> >
> > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 156 +++++++++++++++++++++++
> > drivers/thermal/mtk_thermal.c | 88 +++++++++++--
> > 2 files changed, 231 insertions(+), 13 deletions(-)
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v4,0/7] Add Mediatek thermal dirver and dtsi
From: Michael Kao @ 2020-05-22 4:09 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mark Rutland, devicetree, srv_heupstream, linux-pm,
Daniel Lezcano, linux-kernel, Eduardo Valentin, Rob Herring,
linux-mediatek, hsinyi, Zhang Rui, linux-arm-kernel
In-Reply-To: <7e205390-c7a7-b8c9-3ba2-344a04dc6696@gmail.com>
On Thu, 2020-05-21 at 14:51 +0200, Matthias Brugger wrote:
> Hi Michael,
>
> On 23/03/2020 13:15, Michael Kao wrote:
> > This patchset supports for MT8183 chip to mtk_thermal.c.
> > Add thermal zone of all the thermal sensor in SoC for
> > another get temperatrue. They don't need to thermal throttle.
> > And we bind coolers for thermal zone nodes of cpu_thermal.
> >
> > Rebase to kernel-5.6-rc1.
> >
> > Update content:
> >
> > [1/7]
> > - Squash thermal zone settings in the dtsi from [v3,5/8]
> > arm64: dts: mt8183: Increase polling frequency for CPU thermal zone
> >
> > - Remove the property of interrupts and mediatek,hw-reset-temp
> >
> > [2/7]
> > - Correct commit message
> >
> > [4/7]
> > - Change the target temperature to the 80C and change the commit message
> >
> > [6/7]
> > - Adjust newline alignment
> >
> > - Fix the judgement on the return value of registering thermal zone
> >
> > This patch series base on these patches [1].
> >
> > [v7,3/3] PM / AVS: SVS: Introduce SVS engine (https://patchwork.kernel.org/patch/11439829/)
> >
> > Matthias Kaehlcke (1):
> > arm64: dts: mt8183: Configure CPU cooling
> >
> > Michael Kao (6):
> > arm64: dts: mt8183: add thermal zone node
> > arm64: dts: mt8183: add dynamic power coefficients
> > arm64: dts: mt8183: Add #cooling-cells to CPU nodes
> > thermal: mediatek: mt8183: fix bank number settings
>
> Do I understand correctly that we need to fix the bank number before we can add
> the device tree changes. And that the last two patches are enhancements for the
> driver but needed to get a working version?
>
> Regards,
> Matthias
>
Hi Matthias,
There is one bank setting of mt8183 config.
If the device tree merged first. I worry that it will crash when the
thermal zone read temperature.
It will access the invalid index of bank.
So please wait the patch "fix bank number settings " merged first.
Thanks!
/* MT8183 thermal sensor data */
static const int mt8183_bank_data[MT8183_NUM_SENSORS] = {
MT8183_TS1, MT8183_TS2, MT8183_TS3, MT8183_TS4, MT8183_TS5,
MT8183_TSABB
};
Best Regards,
Michael
> > thermal: mediatek: add another get_temp ops for thermal sensors
> > thermal: mediatek: use spinlock to protect PTPCORESEL
> >
> > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 156 +++++++++++++++++++++++
> > drivers/thermal/mtk_thermal.c | 88 +++++++++++--
> > 2 files changed, 231 insertions(+), 13 deletions(-)
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 0/3] arm64: Enable vmemmap mapping from device memory
From: Jia He @ 2020-05-22 3:58 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, Michal Hocko, Thomas Gleixner, David Hildenbrand,
Peter Zijlstra, Catalin Marinas, Dave Hansen, Paul Mackerras,
linux-ia64, linux-riscv, Will Deacon, jgg, aneesh.kumar, x86,
Matthew Wilcox (Oracle), Mike Rapoport, Kaly Xin, Ingo Molnar,
Benjamin Herrenschmidt, Fenghua Yu, rcampbell, Pavel Tatashin,
jglisse, Andy Lutomirski, Paul Walmsley, dan.j.williams,
linux-arm-kernel, Tony Luck, linuxppc-dev, linux-kernel,
Palmer Dabbelt, Michael Ellerman, Andrew Morton, robin.murphy,
Kirill A. Shutemov
In-Reply-To: <1585631387-18819-1-git-send-email-anshuman.khandual@arm.com>
Hi
On 2020/3/31 13:09, Anshuman Khandual wrote:
> This series enables vmemmap backing memory allocation from device memory
> ranges on arm64. But before that, it enables vmemmap_populate_basepages()
> and vmemmap_alloc_block_buf() to accommodate struct vmem_altmap based
> alocation requests.
I verified no obvious regression after this patch series.
Host: ThunderX2(armv8a server), kernel v5.4
qemu:v3.1, -M virt \
-object
memory-backend-file,id=mem1,share=on,mem-path=/tmp2/nvdimm.img,size=4G,align=2M \
-device nvdimm,id=nvdimm1,memdev=mem1,label-size=2M
Guest: kernel v5.7.0-rc5 with this patch series.
Tested case:
- 4K PAGESIZE, boot, mount w/ -o dax, mount w/o -o dax, basic io
- 64K PAGESIZE,boot, mount w/ -o dax, mount w/o -o dax, basic io
Not tested:
- 16K pagesize due to my hardware limiation(can't run 16K pgsz kernel)
- hot-add/remove nvdimm device from qemu due to no fully support on arm64 qemu yet
- Host nvdimm device hotplug
Hence from above result,
Tested-by: Jia He <justin.he@arm.com>
> This series applies after latest (v14) arm64 memory hot remove series
> (https://lkml.org/lkml/2020/3/3/1746) on Linux 5.6.
>
> Pending Question:
>
> altmap_alloc_block_buf() does not have any other remaining users in the
> tree after this change. Should it be converted into a static function and
> it's declaration be dropped from the header (include/linux/mm.h). Avoided
> doing so because I was not sure if there are any off-tree users or not.
>
> Changes in V3:
>
> - Dropped comment from free_hotplug_page_range() per Robin
> - Modified comment in unmap_hotplug_range() per Robin
> - Enabled altmap support in vmemmap_alloc_block_buf() per Robin
>
> Changes in V2: (https://lkml.org/lkml/2020/3/4/475)
>
> - Rebased on latest hot-remove series (v14) adding P4D page table support
>
> Changes in V1: (https://lkml.org/lkml/2020/1/23/12)
>
> - Added an WARN_ON() in unmap_hotplug_range() when altmap is
> provided without the page table backing memory being freed
>
> Changes in RFC V2: (https://lkml.org/lkml/2019/10/21/11)
>
> - Changed the commit message on 1/2 patch per Will
> - Changed the commit message on 2/2 patch as well
> - Rebased on arm64 memory hot remove series (v10)
>
> RFC V1: (https://lkml.org/lkml/2019/6/28/32)
>
> Cc: Catalin Marinas<catalin.marinas@arm.com>
> Cc: Will Deacon<will@kernel.org>
> Cc: Mark Rutland<mark.rutland@arm.com>
> Cc: Paul Walmsley<paul.walmsley@sifive.com>
> Cc: Palmer Dabbelt<palmer@dabbelt.com>
> Cc: Tony Luck<tony.luck@intel.com>
> Cc: Fenghua Yu<fenghua.yu@intel.com>
> Cc: Dave Hansen<dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski<luto@kernel.org>
> Cc: Peter Zijlstra<peterz@infradead.org>
> Cc: Thomas Gleixner<tglx@linutronix.de>
> Cc: Ingo Molnar<mingo@redhat.com>
> Cc: David Hildenbrand<david@redhat.com>
> Cc: Mike Rapoport<rppt@linux.ibm.com>
> Cc: Michal Hocko<mhocko@suse.com>
> Cc: "Matthew Wilcox (Oracle)"<willy@infradead.org>
> Cc: "Kirill A. Shutemov"<kirill.shutemov@linux.intel.com>
> Cc: Andrew Morton<akpm@linux-foundation.org>
> Cc: Dan Williams<dan.j.williams@intel.com>
> Cc: Pavel Tatashin<pasha.tatashin@soleen.com>
> Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> Cc: Paul Mackerras<paulus@samba.org>
> Cc: Michael Ellerman<mpe@ellerman.id.au>
> Cc:linux-arm-kernel@lists.infradead.org
> Cc:linux-ia64@vger.kernel.org
> Cc:linux-riscv@lists.infradead.org
> Cc:x86@kernel.org
> Cc:linuxppc-dev@lists.ozlabs.org
> Cc:linux-mm@kvack.org
> Cc:linux-kernel@vger.kernel.org
>
> Anshuman Khandual (3):
> mm/sparsemem: Enable vmem_altmap support in vmemmap_populate_basepages()
> mm/sparsemem: Enable vmem_altmap support in vmemmap_alloc_block_buf()
> arm64/mm: Enable vmem_altmap support for vmemmap mappings
>
> arch/arm64/mm/mmu.c | 59 ++++++++++++++++++++++++++-------------
> arch/ia64/mm/discontig.c | 2 +-
> arch/powerpc/mm/init_64.c | 10 +++----
> arch/riscv/mm/init.c | 2 +-
> arch/x86/mm/init_64.c | 12 ++++----
> include/linux/mm.h | 8 ++++--
> mm/sparse-vmemmap.c | 38 ++++++++++++++++++++-----
> 7 files changed, 87 insertions(+), 44 deletions(-)
>
--
---
Cheers,
Justin (Jia He)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] mt76: mt7915: Fix build error
From: YueHaibing @ 2020-05-22 3:45 UTC (permalink / raw)
To: nbd, lorenzo.bianconi83, ryder.lee, kvalo, davem, kuba,
matthias.bgg, shayne.chen, chih-min.chen, yf.luo, yiwei.chung
Cc: linux-wireless, netdev, YueHaibing, linux-kernel, linux-mediatek,
linux-arm-kernel
In file included from ./include/linux/firmware.h:6:0,
from drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:4:
In function ‘__mt7915_mcu_msg_send’,
inlined from ‘mt7915_mcu_send_message’ at drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:370:6:
./include/linux/compiler.h:396:38: error: call to ‘__compiletime_assert_545’ declared with attribute error: BUILD_BUG_ON failed: cmd == MCU_EXT_CMD_EFUSE_ACCESS && mcu_txd->set_query != MCU_Q_QUERY
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
./include/linux/compiler.h:377:4: note: in definition of macro ‘__compiletime_assert’
prefix ## suffix(); \
^~~~~~
./include/linux/compiler.h:396:2: note: in expansion of macro ‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:280:2: note: in expansion of macro ‘BUILD_BUG_ON’
BUILD_BUG_ON(cmd == MCU_EXT_CMD_EFUSE_ACCESS &&
^~~~~~~~~~~~
BUILD_BUG_ON is meaningless here, chang it to WARN_ON.
Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
index f00ad2b66761..99eeea42478f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
@@ -277,8 +277,8 @@ static int __mt7915_mcu_msg_send(struct mt7915_dev *dev, struct sk_buff *skb,
}
mcu_txd->s2d_index = MCU_S2D_H2N;
- BUILD_BUG_ON(cmd == MCU_EXT_CMD_EFUSE_ACCESS &&
- mcu_txd->set_query != MCU_Q_QUERY);
+ WARN_ON(cmd == MCU_EXT_CMD_EFUSE_ACCESS &&
+ mcu_txd->set_query != MCU_Q_QUERY);
exit:
if (wait_seq)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox