linux-next: Tree for Sep 26
Hi all, Changes since 20180925: Dropped trees: xarray, ida (temporarily) The pci tree gained a build failure for which I applied a patch. The vfio tree gained a conflict against the vfs tree. Non-merge commits (relative to Linus' tree): 5701 6126 files changed, 279602 insertions(+), 123599 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 288 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (a38523185b40 erge tag 'libnvdimm-fixes-4.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm) Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of Linus' tree) Merging kbuild-current/fixes (ef8c4ed9db80 kbuild: allow to use GCC toolchain not in Clang search path) Merging arc-current/for-curr (40660f1fcee8 ARC: build: Don't set CROSS_COMPILE in arch's Makefile) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (031e6e6b4e12 arm64: hugetlb: Avoid unnecessary clearing in huge_ptep_set_access_flags) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (c716a25b9b70 powerpc/pkeys: Fix reading of ibm, processor-storage-keys property) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (92ef12b32fea tipc: fix flow control accounting for implicit connect) Merging bpf/master (f4a518797b40 net: mvneta: fix the remaining Rx descriptor unmapping issues) Merging ipsec/master (32bf94fb5c2e xfrm: validate template mode) Merging netfilter/master (346fa83d1093 netfilter: conntrack: get rid of double sizeof) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (2823c8716c68 b43: fix DMA error related regression with proprietary firmware) Merging mac80211/master (c42055105785 mac80211: fix TX status reporting for ieee80211s) Merging rdma-fixes/for-rc (de5c95d0f518 RDMA/bnxt_re: Fix system crash during RDMA resource initialization) Merging sound-current/for-linus (b3a5402cbceb ALSA: hda: Fix the audio-component completion timeout) Merging sound-asoc-fixes/for-linus (6c96a58bb15b Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4) Merging regulator-fixes/for-linus (3564951ca82b Merge branch 'regulator-4.19' into regulator-linus) Merging spi-fixes/for-linus (1f6b3b2c1ff4 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (9024143e700f PCI: dwc: Fix scheduling while atomic issues) Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4) Merging tty.current/tty-linus (7e620984b625 serial: imx: restore handshaking irq for imx1) Merging usb.current/usb-linus (3e3b81965cbf usb: typec: mux: Take care of driver module reference counting) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of dwc2_check_core_endianness) Merging usb-serial-fixes/usb-linus (f5fad711c06e USB: serial: simple: add Motorola Tetra MTP6550 id) Merging usb-chipi
linux-next: Tree for Sep 26
Hi all, Changes since 20180925: Dropped trees: xarray, ida (temporarily) The pci tree gained a build failure for which I applied a patch. The vfio tree gained a conflict against the vfs tree. Non-merge commits (relative to Linus' tree): 5701 6126 files changed, 279602 insertions(+), 123599 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 288 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (a38523185b40 erge tag 'libnvdimm-fixes-4.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm) Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of Linus' tree) Merging kbuild-current/fixes (ef8c4ed9db80 kbuild: allow to use GCC toolchain not in Clang search path) Merging arc-current/for-curr (40660f1fcee8 ARC: build: Don't set CROSS_COMPILE in arch's Makefile) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (031e6e6b4e12 arm64: hugetlb: Avoid unnecessary clearing in huge_ptep_set_access_flags) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (c716a25b9b70 powerpc/pkeys: Fix reading of ibm, processor-storage-keys property) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (92ef12b32fea tipc: fix flow control accounting for implicit connect) Merging bpf/master (f4a518797b40 net: mvneta: fix the remaining Rx descriptor unmapping issues) Merging ipsec/master (32bf94fb5c2e xfrm: validate template mode) Merging netfilter/master (346fa83d1093 netfilter: conntrack: get rid of double sizeof) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (2823c8716c68 b43: fix DMA error related regression with proprietary firmware) Merging mac80211/master (c42055105785 mac80211: fix TX status reporting for ieee80211s) Merging rdma-fixes/for-rc (de5c95d0f518 RDMA/bnxt_re: Fix system crash during RDMA resource initialization) Merging sound-current/for-linus (b3a5402cbceb ALSA: hda: Fix the audio-component completion timeout) Merging sound-asoc-fixes/for-linus (6c96a58bb15b Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4) Merging regulator-fixes/for-linus (3564951ca82b Merge branch 'regulator-4.19' into regulator-linus) Merging spi-fixes/for-linus (1f6b3b2c1ff4 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (9024143e700f PCI: dwc: Fix scheduling while atomic issues) Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4) Merging tty.current/tty-linus (7e620984b625 serial: imx: restore handshaking irq for imx1) Merging usb.current/usb-linus (3e3b81965cbf usb: typec: mux: Take care of driver module reference counting) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of dwc2_check_core_endianness) Merging usb-serial-fixes/usb-linus (f5fad711c06e USB: serial: simple: add Motorola Tetra MTP6550 id) Merging usb-chipi
Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver
On Mon, Sep 17, 2018 at 7:58 PM Anup Patel wrote: > > On Mon, Sep 17, 2018 at 7:44 PM Christoph Hellwig wrote: > > > > On Mon, Sep 10, 2018 at 10:08:58PM +0530, Anup Patel wrote: > > > > They could in theory IFF someone actually get the use case through > > > > the riscv privileged spec working group. > > > > > > Their is no point in having each and every possible local interrupts > > > defined by RISC-V spec because some of these will be CPU > > > implementation specific in which case these local interrupts will > > > be described in platform specific DT passed to Linux. > > > > Again, to legally have implementation specific local interrupt types > > you'll first need to convice the spec to change the status for those > > fields from reserved to implementation specific. > > I agree, this needs to be first clarified in RISC-V spec. May be this is > a good topic for discussion in any upcoming RISC-V meetup. > > Until then anyone can try these patches from riscv_intc_v2 branch of > https://github.com/avpatel/linux > I released that CLIC is going to be available for both M-mode and S-mode. Software can choose to use HLIC or CLIC based on it's own preference. If we are going to support both HLIC and CLIC in Linux kernel for per-CPU local interrupts then we should definitely have irqdomain and irqchip for per-CPU local interrupts. The selection between HLIC and CLIC will be based on which driver gets probed via DT. Regards, Anup
Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver
On Mon, Sep 17, 2018 at 7:58 PM Anup Patel wrote: > > On Mon, Sep 17, 2018 at 7:44 PM Christoph Hellwig wrote: > > > > On Mon, Sep 10, 2018 at 10:08:58PM +0530, Anup Patel wrote: > > > > They could in theory IFF someone actually get the use case through > > > > the riscv privileged spec working group. > > > > > > Their is no point in having each and every possible local interrupts > > > defined by RISC-V spec because some of these will be CPU > > > implementation specific in which case these local interrupts will > > > be described in platform specific DT passed to Linux. > > > > Again, to legally have implementation specific local interrupt types > > you'll first need to convice the spec to change the status for those > > fields from reserved to implementation specific. > > I agree, this needs to be first clarified in RISC-V spec. May be this is > a good topic for discussion in any upcoming RISC-V meetup. > > Until then anyone can try these patches from riscv_intc_v2 branch of > https://github.com/avpatel/linux > I released that CLIC is going to be available for both M-mode and S-mode. Software can choose to use HLIC or CLIC based on it's own preference. If we are going to support both HLIC and CLIC in Linux kernel for per-CPU local interrupts then we should definitely have irqdomain and irqchip for per-CPU local interrupts. The selection between HLIC and CLIC will be based on which driver gets probed via DT. Regards, Anup
[PATCH] staging: rtl8723bs: Remove ACPI table declaration
Clang warns that the acpi_id declaration is not going to be emitted
in the final assembly:
drivers/staging/rtl8723bs/os_dep/sdio_intf.c:25:36: warning: variable
'acpi_ids' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static const struct acpi_device_id acpi_ids[] = {
^
1 warning generated.
This is because it's marked as static const and it is not used anywhere
in this file. Doing a git grep on this driver for 'acpi' shows that this
declaration has been unused since the driver's initial induction. Remove
it since it's not doing anything.
Link: https://github.com/ClangBuiltLinux/linux/issues/169
Signed-off-by: Nathan Chancellor
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index 6d02904de63f..d473f9bd08c3 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -22,13 +22,7 @@ static const struct sdio_device_id sdio_ids[] =
{ SDIO_DEVICE(0x024c, 0xb723), },
{ /* end: all zeroes */ },
};
-static const struct acpi_device_id acpi_ids[] = {
- {"OBDA8723", 0x},
- {}
-};
-
MODULE_DEVICE_TABLE(sdio, sdio_ids);
-MODULE_DEVICE_TABLE(acpi, acpi_ids);
static int rtw_drv_init(struct sdio_func *func, const struct sdio_device_id
*id);
static void rtw_dev_remove(struct sdio_func *func);
--
2.19.0
[PATCH] staging: rtl8723bs: Remove ACPI table declaration
Clang warns that the acpi_id declaration is not going to be emitted
in the final assembly:
drivers/staging/rtl8723bs/os_dep/sdio_intf.c:25:36: warning: variable
'acpi_ids' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static const struct acpi_device_id acpi_ids[] = {
^
1 warning generated.
This is because it's marked as static const and it is not used anywhere
in this file. Doing a git grep on this driver for 'acpi' shows that this
declaration has been unused since the driver's initial induction. Remove
it since it's not doing anything.
Link: https://github.com/ClangBuiltLinux/linux/issues/169
Signed-off-by: Nathan Chancellor
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index 6d02904de63f..d473f9bd08c3 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -22,13 +22,7 @@ static const struct sdio_device_id sdio_ids[] =
{ SDIO_DEVICE(0x024c, 0xb723), },
{ /* end: all zeroes */ },
};
-static const struct acpi_device_id acpi_ids[] = {
- {"OBDA8723", 0x},
- {}
-};
-
MODULE_DEVICE_TABLE(sdio, sdio_ids);
-MODULE_DEVICE_TABLE(acpi, acpi_ids);
static int rtw_drv_init(struct sdio_func *func, const struct sdio_device_id
*id);
static void rtw_dev_remove(struct sdio_func *func);
--
2.19.0
Re: [PATCH 4.14 000/173] 4.14.72-stable review
On Wed, Sep 26, 2018 at 12:01:53AM -0300, Rafael Tinoco wrote: > Greg, > > > > > This is the start of the stable review cycle for the 4.14.72 release. > > > > There are 173 patches in this series, all will be posted as a response > > > > to this one. If anyone has any issues with these being applied, please > > > > let me know. > > > > > > > > Responses should be made by Wed Sep 26 11:30:10 UTC 2018. > > > > Anything received after that time might be too late. > > > > > > > > The whole patch series can be found in one patch at: > > > > > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.72-rc1.gz > > > > or in the git tree and branch at: > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > > linux-4.14.y > > > > and the diffstat can be found below. > > > > > > -rc2 is out to resolve some reported problems: > > > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.72-rc2.gz > > > > -rc2 looks good. There is a problem on dragonboard during boot that was > > introduced in v4.14.71 that I didn't notice last week. We'll bisect it > > and report back later this week. dragonboard on the other branches (4.9, > > 4.18, mainline) looks fine. > > As Dan pointed out, during validation, we have bisected this issue on > a dragonboard 410c (can't find root device) to the following commit > for v4.14: > > [1ed3a9307230] rpmsg: core: add support to power domains for devices > > There is an on-going discussion on "[PATCH] rpmsg: core: add support > to power domains for devices" about this patch having other > dependencies and breaking something else on v4.14 as well. > > Do you think we could drop this patch, for now, in a possible -rc3 for > v4.14.72 ? Dragonboards aren't being tested, because of this, since > v4.14.70. Hopefully it isn't too late for this release =). I can't "drop" it as it is already in a released kernel, 4.14.71 and 4.18.9. I can revert it though, and will do so for the next round of releases after this one. thanks for the report. greg k-h
Re: [PATCH 4.14 000/173] 4.14.72-stable review
On Wed, Sep 26, 2018 at 12:01:53AM -0300, Rafael Tinoco wrote: > Greg, > > > > > This is the start of the stable review cycle for the 4.14.72 release. > > > > There are 173 patches in this series, all will be posted as a response > > > > to this one. If anyone has any issues with these being applied, please > > > > let me know. > > > > > > > > Responses should be made by Wed Sep 26 11:30:10 UTC 2018. > > > > Anything received after that time might be too late. > > > > > > > > The whole patch series can be found in one patch at: > > > > > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.72-rc1.gz > > > > or in the git tree and branch at: > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > > linux-4.14.y > > > > and the diffstat can be found below. > > > > > > -rc2 is out to resolve some reported problems: > > > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.72-rc2.gz > > > > -rc2 looks good. There is a problem on dragonboard during boot that was > > introduced in v4.14.71 that I didn't notice last week. We'll bisect it > > and report back later this week. dragonboard on the other branches (4.9, > > 4.18, mainline) looks fine. > > As Dan pointed out, during validation, we have bisected this issue on > a dragonboard 410c (can't find root device) to the following commit > for v4.14: > > [1ed3a9307230] rpmsg: core: add support to power domains for devices > > There is an on-going discussion on "[PATCH] rpmsg: core: add support > to power domains for devices" about this patch having other > dependencies and breaking something else on v4.14 as well. > > Do you think we could drop this patch, for now, in a possible -rc3 for > v4.14.72 ? Dragonboards aren't being tested, because of this, since > v4.14.70. Hopefully it isn't too late for this release =). I can't "drop" it as it is already in a released kernel, 4.14.71 and 4.18.9. I can revert it though, and will do so for the next round of releases after this one. thanks for the report. greg k-h
Re: [Resend PATCH 5/5] arm: dts: mt7623: add display subsystem related device nodes
Hi, Ryder:
On Wed, 2018-09-26 at 10:38 +0800, Ryder Lee wrote:
> On Wed, 2018-09-26 at 09:37 +0800, CK Hu wrote:
> > Hi, Ryder:
> >
> > On Wed, 2018-09-05 at 22:09 +0800, Ryder Lee wrote:
> > > Add display subsystem related device nodes for MT7623.
> > >
> > > Cc: CK Hu
> > > Signed-off-by: chunhui dai
> > > Signed-off-by: Bibby Hsieh
> > > Signed-off-by: Ryder Lee
> > > ---
> > > I forgot to sort nodes in my previous mail. Sorry for the inconvenience.
> > >
> > > This patch depends on the series: https://lkml.org/lkml/2018/9/5/223
> > >
> > > @Matthias,
> > > I know you're working on broken MMSYS - just want to ask whether it's
> > > possible
> > > to let the patch to go to your tree (if others are okay with it), and
> > > send a
> > > fixup one for MT7623 MMSYS later?
> > > ---
> > > arch/arm/boot/dts/mt7623.dtsi | 177
> > > ++
> > > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 83
> > > arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 83
> > > 3 files changed, 343 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> > > index d01bdee..fdf9078 100644
> > > --- a/arch/arm/boot/dts/mt7623.dtsi
> > > +++ b/arch/arm/boot/dts/mt7623.dtsi
> > > @@ -23,6 +23,11 @@
> > > #address-cells = <2>;
> > > #size-cells = <2>;
> > >
> > > + aliases {
> > > + rdma0 =
> > > + rdma1 =
> > > + };
> > > +
> > > cpu_opp_table: opp-table {
> > > compatible = "operating-points-v2";
> > > opp-shared;
> > > @@ -311,6 +316,25 @@
> > > clock-names = "spi", "wrap";
> > > };
> > >
> > > + mipi_tx0: mipi-dphy@1001 {
> > > + compatible = "mediatek,mt7623-mipi-tx",
> > > + "mediatek,mt2701-mipi-tx";
> > > + reg = <0 0x1001 0 0x90>;
> > > + clocks = <>;
> > > + clock-output-names = "mipi_tx0_pll";
> > > + #clock-cells = <0>;
> > > + #phy-cells = <0>;
> > > + };
> > > +
> > > + cec: cec@10012000 {
> > > + compatible = "mediatek,mt7623-cec",
> > > + "mediatek,mt8173-cec";
> > > + reg = <0 0x10012000 0 0xbc>;
> > > + interrupts = ;
> > > + clocks = < CLK_INFRA_CEC>;
> > > + status = "disabled";
> > > + };
> > > +
> > > cir: cir@10013000 {
> > > compatible = "mediatek,mt7623-cir";
> > > reg = <0 0x10013000 0 0x1000>;
> > > @@ -359,6 +383,18 @@
> > > #clock-cells = <1>;
> > > };
> > >
> > > + hdmi_phy: phy@10209100 {
> > > + compatible = "mediatek,mt7623-hdmi-phy",
> > > + "mediatek,mt2701-hdmi-phy";
> > > + reg = <0 0x10209100 0 0x24>;
> > > + clocks = < CLK_APMIXED_HDMI_REF>;
> > > + clock-names = "pll_ref";
> > > + clock-output-names = "hdmitx_dig_cts";
> > > + #clock-cells = <0>;
> > > + #phy-cells = <0>;
> > > + status = "disabled";
> > > + };
> > > +
> > > rng: rng@1020f000 {
> > > compatible = "mediatek,mt7623-rng";
> > > reg = <0 0x1020f000 0 0x1000>;
> > > @@ -558,6 +594,16 @@
> > > status = "disabled";
> > > };
> > >
> > > + hdmiddc0: i2c@11013000 {
> > > + compatible = "mediatek,mt7623-hdmi-ddc",
> > > + "mediatek,mt8173-hdmi-ddc";
> > > + interrupts = ;
> > > + reg = <0 0x11013000 0 0x1C>;
> > > + clocks = < CLK_PERI_I2C3>;
> > > + clock-names = "ddc-i2c";
> > > + status = "disabled";
> > > + };
> > > +
> > > nor_flash: spi@11014000 {
> > > compatible = "mediatek,mt7623-nor",
> > >"mediatek,mt8173-nor";
> > > @@ -732,6 +778,84 @@
> > > #clock-cells = <1>;
> > > };
> > >
> > > + display_components: dispsys@1400 {
> > > + compatible = "mediatek,mt7623-mmsys",
> >
> > Checkpatch warning:
> >
> > WARNING: DT compatible string "mediatek,mt7623-mmsys" appears
> > un-documented -- check ./Documentation/devicetree/bindings/
> > #101: FILE: arch/arm/boot/dts/mt7623.dtsi:782:
> > + compatible = "mediatek,mt7623-mmsys",
> >
> >
> > > + "mediatek,mt2701-mmsys";
> > > + reg = <0 0x1400 0 0x1000>;
> > > + power-domains = < MT2701_POWER_DOMAIN_DISP>;
> > > + };
> > > +
> > > + ovl@14007000 {
> > > + compatible = "mediatek,mt7623-disp-ovl",
> >
> > I think this is also un-documented, but I don't know why checkpatch does
> > not show any warning.
> >
> > Regards,
> > CK
> > > + "mediatek,mt2701-disp-ovl";
> > > + reg = <0 0x14007000 0 0x1000>;
> > > + interrupts = ;
> > > + clocks = < CLK_MM_DISP_OVL>;
> > > + iommus = < MT2701_M4U_PORT_DISP_OVL_0>;
> > > + mediatek,larb = <>;
> > > + };
> > > +
>
> I fallback to use the MT2701's compatible string here and there, but I
> could add a new one for MT7623.
>
>
[PATCH] platform/x86: mlx-platform: Properly use mlxplat_mlxcpld_msn201x_items
Clang warns that mlxplat_mlxcpld_msn201x_items is not going to be
emitted in the final assembly because it's only used in ARRAY_SIZE right
now, which is a compile time evaluation since the array's size is known.
drivers/platform/x86/mlx-platform.c:555:32: warning: variable
'mlxplat_mlxcpld_msn201x_items' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static struct mlxreg_core_item mlxplat_mlxcpld_msn201x_items[] = {
^
1 warning generated.
It appears this was a copy and paste mistake from when this item was
first added. Use the definition in mlxplat_mlxcpld_msn201x_data so that
Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/141
Fixes: a49a41482f61 ("platform/x86: mlx-platform: Add support for new msn201x
system type")
Signed-off-by: Nathan Chancellor
---
drivers/platform/x86/mlx-platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index d89936c93ba0..c2c3a1a19879 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -575,7 +575,7 @@ static struct mlxreg_core_item
mlxplat_mlxcpld_msn201x_items[] = {
static
struct mlxreg_core_hotplug_platform_data mlxplat_mlxcpld_msn201x_data = {
- .items = mlxplat_mlxcpld_msn21xx_items,
+ .items = mlxplat_mlxcpld_msn201x_items,
.counter = ARRAY_SIZE(mlxplat_mlxcpld_msn201x_items),
.cell = MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET,
.mask = MLXPLAT_CPLD_AGGR_MASK_DEF,
--
2.19.0
Re: [Resend PATCH 5/5] arm: dts: mt7623: add display subsystem related device nodes
Hi, Ryder:
On Wed, 2018-09-26 at 10:38 +0800, Ryder Lee wrote:
> On Wed, 2018-09-26 at 09:37 +0800, CK Hu wrote:
> > Hi, Ryder:
> >
> > On Wed, 2018-09-05 at 22:09 +0800, Ryder Lee wrote:
> > > Add display subsystem related device nodes for MT7623.
> > >
> > > Cc: CK Hu
> > > Signed-off-by: chunhui dai
> > > Signed-off-by: Bibby Hsieh
> > > Signed-off-by: Ryder Lee
> > > ---
> > > I forgot to sort nodes in my previous mail. Sorry for the inconvenience.
> > >
> > > This patch depends on the series: https://lkml.org/lkml/2018/9/5/223
> > >
> > > @Matthias,
> > > I know you're working on broken MMSYS - just want to ask whether it's
> > > possible
> > > to let the patch to go to your tree (if others are okay with it), and
> > > send a
> > > fixup one for MT7623 MMSYS later?
> > > ---
> > > arch/arm/boot/dts/mt7623.dtsi | 177
> > > ++
> > > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 83
> > > arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 83
> > > 3 files changed, 343 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> > > index d01bdee..fdf9078 100644
> > > --- a/arch/arm/boot/dts/mt7623.dtsi
> > > +++ b/arch/arm/boot/dts/mt7623.dtsi
> > > @@ -23,6 +23,11 @@
> > > #address-cells = <2>;
> > > #size-cells = <2>;
> > >
> > > + aliases {
> > > + rdma0 =
> > > + rdma1 =
> > > + };
> > > +
> > > cpu_opp_table: opp-table {
> > > compatible = "operating-points-v2";
> > > opp-shared;
> > > @@ -311,6 +316,25 @@
> > > clock-names = "spi", "wrap";
> > > };
> > >
> > > + mipi_tx0: mipi-dphy@1001 {
> > > + compatible = "mediatek,mt7623-mipi-tx",
> > > + "mediatek,mt2701-mipi-tx";
> > > + reg = <0 0x1001 0 0x90>;
> > > + clocks = <>;
> > > + clock-output-names = "mipi_tx0_pll";
> > > + #clock-cells = <0>;
> > > + #phy-cells = <0>;
> > > + };
> > > +
> > > + cec: cec@10012000 {
> > > + compatible = "mediatek,mt7623-cec",
> > > + "mediatek,mt8173-cec";
> > > + reg = <0 0x10012000 0 0xbc>;
> > > + interrupts = ;
> > > + clocks = < CLK_INFRA_CEC>;
> > > + status = "disabled";
> > > + };
> > > +
> > > cir: cir@10013000 {
> > > compatible = "mediatek,mt7623-cir";
> > > reg = <0 0x10013000 0 0x1000>;
> > > @@ -359,6 +383,18 @@
> > > #clock-cells = <1>;
> > > };
> > >
> > > + hdmi_phy: phy@10209100 {
> > > + compatible = "mediatek,mt7623-hdmi-phy",
> > > + "mediatek,mt2701-hdmi-phy";
> > > + reg = <0 0x10209100 0 0x24>;
> > > + clocks = < CLK_APMIXED_HDMI_REF>;
> > > + clock-names = "pll_ref";
> > > + clock-output-names = "hdmitx_dig_cts";
> > > + #clock-cells = <0>;
> > > + #phy-cells = <0>;
> > > + status = "disabled";
> > > + };
> > > +
> > > rng: rng@1020f000 {
> > > compatible = "mediatek,mt7623-rng";
> > > reg = <0 0x1020f000 0 0x1000>;
> > > @@ -558,6 +594,16 @@
> > > status = "disabled";
> > > };
> > >
> > > + hdmiddc0: i2c@11013000 {
> > > + compatible = "mediatek,mt7623-hdmi-ddc",
> > > + "mediatek,mt8173-hdmi-ddc";
> > > + interrupts = ;
> > > + reg = <0 0x11013000 0 0x1C>;
> > > + clocks = < CLK_PERI_I2C3>;
> > > + clock-names = "ddc-i2c";
> > > + status = "disabled";
> > > + };
> > > +
> > > nor_flash: spi@11014000 {
> > > compatible = "mediatek,mt7623-nor",
> > >"mediatek,mt8173-nor";
> > > @@ -732,6 +778,84 @@
> > > #clock-cells = <1>;
> > > };
> > >
> > > + display_components: dispsys@1400 {
> > > + compatible = "mediatek,mt7623-mmsys",
> >
> > Checkpatch warning:
> >
> > WARNING: DT compatible string "mediatek,mt7623-mmsys" appears
> > un-documented -- check ./Documentation/devicetree/bindings/
> > #101: FILE: arch/arm/boot/dts/mt7623.dtsi:782:
> > + compatible = "mediatek,mt7623-mmsys",
> >
> >
> > > + "mediatek,mt2701-mmsys";
> > > + reg = <0 0x1400 0 0x1000>;
> > > + power-domains = < MT2701_POWER_DOMAIN_DISP>;
> > > + };
> > > +
> > > + ovl@14007000 {
> > > + compatible = "mediatek,mt7623-disp-ovl",
> >
> > I think this is also un-documented, but I don't know why checkpatch does
> > not show any warning.
> >
> > Regards,
> > CK
> > > + "mediatek,mt2701-disp-ovl";
> > > + reg = <0 0x14007000 0 0x1000>;
> > > + interrupts = ;
> > > + clocks = < CLK_MM_DISP_OVL>;
> > > + iommus = < MT2701_M4U_PORT_DISP_OVL_0>;
> > > + mediatek,larb = <>;
> > > + };
> > > +
>
> I fallback to use the MT2701's compatible string here and there, but I
> could add a new one for MT7623.
>
>
[PATCH] platform/x86: mlx-platform: Properly use mlxplat_mlxcpld_msn201x_items
Clang warns that mlxplat_mlxcpld_msn201x_items is not going to be
emitted in the final assembly because it's only used in ARRAY_SIZE right
now, which is a compile time evaluation since the array's size is known.
drivers/platform/x86/mlx-platform.c:555:32: warning: variable
'mlxplat_mlxcpld_msn201x_items' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static struct mlxreg_core_item mlxplat_mlxcpld_msn201x_items[] = {
^
1 warning generated.
It appears this was a copy and paste mistake from when this item was
first added. Use the definition in mlxplat_mlxcpld_msn201x_data so that
Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/141
Fixes: a49a41482f61 ("platform/x86: mlx-platform: Add support for new msn201x
system type")
Signed-off-by: Nathan Chancellor
---
drivers/platform/x86/mlx-platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index d89936c93ba0..c2c3a1a19879 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -575,7 +575,7 @@ static struct mlxreg_core_item
mlxplat_mlxcpld_msn201x_items[] = {
static
struct mlxreg_core_hotplug_platform_data mlxplat_mlxcpld_msn201x_data = {
- .items = mlxplat_mlxcpld_msn21xx_items,
+ .items = mlxplat_mlxcpld_msn201x_items,
.counter = ARRAY_SIZE(mlxplat_mlxcpld_msn201x_items),
.cell = MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET,
.mask = MLXPLAT_CPLD_AGGR_MASK_DEF,
--
2.19.0
linux-next: build failure after merge of the pci tree
Hi Bjorn,
After merging the pci tree, today's linux-next build (powerpc allnoconfig)
failed like this:
ld: drivers/pci/pci.o: in function `pci_bus_error_reset':
pci.c:(.text+0x5fba): undefined reference to `pci_slot_mutex'
ld: pci.c:(.text+0x5fc2): undefined reference to `pci_slot_mutex'
Caused by commit
131b0ca2c7b2 ("PCI/ERR: Use slot reset if available")
I have applied the following hack for today (there is probably a better
way):
From: Stephen Rothwell
Date: Wed, 26 Sep 2018 14:55:37 +1000
Subject: [PATCH] pci: move pci_slot_mutex so it is available where needed
Fixes: 131b0ca2c7b2 ("PCI/ERR: Use slot reset if available")
Signed-off-by: Stephen Rothwell
---
drivers/pci/pci.c | 2 ++
drivers/pci/slot.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8c1e99a637d8..1fa67db6b21e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5190,6 +5190,8 @@ static int pci_bus_reset(struct pci_bus *bus, int probe)
return ret;
}
+DEFINE_MUTEX(pci_slot_mutex);
+
/**
* pci_bus_error_reset - reset the bridge's subordinate bus
* @bridge: The parent device that connects to the bus to reset
diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
index 3da03fcc6fbf..c46d5e1ff536 100644
--- a/drivers/pci/slot.c
+++ b/drivers/pci/slot.c
@@ -14,7 +14,6 @@
struct kset *pci_slots_kset;
EXPORT_SYMBOL_GPL(pci_slots_kset);
-DEFINE_MUTEX(pci_slot_mutex);
static ssize_t pci_slot_attr_show(struct kobject *kobj,
struct attribute *attr, char *buf)
--
2.18.0
--
Cheers,
Stephen Rothwell
pgpC9It__ga9G.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the pci tree
Hi Bjorn,
After merging the pci tree, today's linux-next build (powerpc allnoconfig)
failed like this:
ld: drivers/pci/pci.o: in function `pci_bus_error_reset':
pci.c:(.text+0x5fba): undefined reference to `pci_slot_mutex'
ld: pci.c:(.text+0x5fc2): undefined reference to `pci_slot_mutex'
Caused by commit
131b0ca2c7b2 ("PCI/ERR: Use slot reset if available")
I have applied the following hack for today (there is probably a better
way):
From: Stephen Rothwell
Date: Wed, 26 Sep 2018 14:55:37 +1000
Subject: [PATCH] pci: move pci_slot_mutex so it is available where needed
Fixes: 131b0ca2c7b2 ("PCI/ERR: Use slot reset if available")
Signed-off-by: Stephen Rothwell
---
drivers/pci/pci.c | 2 ++
drivers/pci/slot.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8c1e99a637d8..1fa67db6b21e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5190,6 +5190,8 @@ static int pci_bus_reset(struct pci_bus *bus, int probe)
return ret;
}
+DEFINE_MUTEX(pci_slot_mutex);
+
/**
* pci_bus_error_reset - reset the bridge's subordinate bus
* @bridge: The parent device that connects to the bus to reset
diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
index 3da03fcc6fbf..c46d5e1ff536 100644
--- a/drivers/pci/slot.c
+++ b/drivers/pci/slot.c
@@ -14,7 +14,6 @@
struct kset *pci_slots_kset;
EXPORT_SYMBOL_GPL(pci_slots_kset);
-DEFINE_MUTEX(pci_slot_mutex);
static ssize_t pci_slot_attr_show(struct kobject *kobj,
struct attribute *attr, char *buf)
--
2.18.0
--
Cheers,
Stephen Rothwell
pgpC9It__ga9G.pgp
Description: OpenPGP digital signature
Re: [BUG] mm: direct I/O (using GUP) can write to COW anonymous pages
On 9/18/18 2:58 AM, Jan Kara wrote: > On Tue 18-09-18 02:35:43, Jann Horn wrote: >> On Tue, Sep 18, 2018 at 2:05 AM Hugh Dickins wrote: > > Thanks for CC Hugh. > >>> On Mon, 17 Sep 2018, Jann Horn wrote: >>> >> >> Makes sense, I guess. >> >> I wonder whether there's a concise way to express this in the fork.2 >> manpage, or something like that. Maybe I'll take a stab at writing >> something. The biggest issue I see with documenting this edgecase is >> that, as an application developer, if you don't know whether some file >> might be coming from a FUSE filesystem that has opted out of using the >> disk cache, the "don't do that" essentially becomes "don't read() into >> heap buffers while fork()ing in another thread", since with FUSE, >> direct I/O can happen even if you don't open files as O_DIRECT as long >> as the filesystem requests direct I/O, and get_user_pages_fast() will >> AFAIU be used for non-page-aligned buffers, meaning that an adjacent >> heap memory access could trigger CoW page duplication. But then, FUSE >> filesystems that opt out of the disk cache are probably so rare that >> it's not a concern in practice... > > So at least for shared file mappings we do need to fix this issue as it's > currently userspace triggerable Oops if you try hard enough. And with RDMA > you don't even have to try that hard. Properly dealing with private > mappings should not be that hard once the infrastructure is there I hope > but I didn't seriously look into that. I've added Miklos and John to CC as > they are interested as well. John was working on fixing this problem - > https://lkml.org/lkml/2018/7/9/158 - but I didn't hear from him for quite a > while so I'm not sure whether it died off or what's the current situation. > Hi, Sorry for missing this even though I was CC'd, I only just now noticed it, while trying to get caught up again. Anyway, I've been sidetracked for a...while (since July!), but am jumping back in and working on this now. And I've got time allocated for it. So here goes. thanks, -- John Hubbard NVIDIA
Re: [BUG] mm: direct I/O (using GUP) can write to COW anonymous pages
On 9/18/18 2:58 AM, Jan Kara wrote: > On Tue 18-09-18 02:35:43, Jann Horn wrote: >> On Tue, Sep 18, 2018 at 2:05 AM Hugh Dickins wrote: > > Thanks for CC Hugh. > >>> On Mon, 17 Sep 2018, Jann Horn wrote: >>> >> >> Makes sense, I guess. >> >> I wonder whether there's a concise way to express this in the fork.2 >> manpage, or something like that. Maybe I'll take a stab at writing >> something. The biggest issue I see with documenting this edgecase is >> that, as an application developer, if you don't know whether some file >> might be coming from a FUSE filesystem that has opted out of using the >> disk cache, the "don't do that" essentially becomes "don't read() into >> heap buffers while fork()ing in another thread", since with FUSE, >> direct I/O can happen even if you don't open files as O_DIRECT as long >> as the filesystem requests direct I/O, and get_user_pages_fast() will >> AFAIU be used for non-page-aligned buffers, meaning that an adjacent >> heap memory access could trigger CoW page duplication. But then, FUSE >> filesystems that opt out of the disk cache are probably so rare that >> it's not a concern in practice... > > So at least for shared file mappings we do need to fix this issue as it's > currently userspace triggerable Oops if you try hard enough. And with RDMA > you don't even have to try that hard. Properly dealing with private > mappings should not be that hard once the infrastructure is there I hope > but I didn't seriously look into that. I've added Miklos and John to CC as > they are interested as well. John was working on fixing this problem - > https://lkml.org/lkml/2018/7/9/158 - but I didn't hear from him for quite a > while so I'm not sure whether it died off or what's the current situation. > Hi, Sorry for missing this even though I was CC'd, I only just now noticed it, while trying to get caught up again. Anyway, I've been sidetracked for a...while (since July!), but am jumping back in and working on this now. And I've got time allocated for it. So here goes. thanks, -- John Hubbard NVIDIA
[PATCH] arm64: dts: rockchip: Enable SPI NOR flash on Rock64
The Pine64 Rock64 board comes with a GigaDevice GD25Q128CSIG
or GD25Q127CSIG chip, which is a 128 Mbit SPI NOR flash chip
that supports the JEDEC read-ID command.
This patch enables the SPI controller and adds a device node
for the flash chip using the generic "jedec,spi-nor" comaptible.
Signed-off-by: Chen-Yu Tsai
---
This was working on linux-next 20180910, but now fails on linux-next
20180925, with the following error messages:
m25p80 spi0.0: error -22 reading 9f
m25p80: probe of spi0.0 failed with error -2
Reverting the spi/for-next branch makes it work again:
m25p80 spi0.0: gd25q128 (16384 Kbytes)
Not sure what's up.
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 9ee4f57557f3..2170cf63845e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -290,6 +290,18 @@
};
};
+ {
+ status = "okay";
+
+ spiflash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+
+ /* maximum speed for Rockchip SPI */
+ spi-max-frequency = <5000>;
+ };
+};
+
{
rockchip,hw-tshut-mode = <0>;
rockchip,hw-tshut-polarity = <0>;
--
2.19.0
[PATCH] arm64: dts: rockchip: Enable SPI NOR flash on Rock64
The Pine64 Rock64 board comes with a GigaDevice GD25Q128CSIG
or GD25Q127CSIG chip, which is a 128 Mbit SPI NOR flash chip
that supports the JEDEC read-ID command.
This patch enables the SPI controller and adds a device node
for the flash chip using the generic "jedec,spi-nor" comaptible.
Signed-off-by: Chen-Yu Tsai
---
This was working on linux-next 20180910, but now fails on linux-next
20180925, with the following error messages:
m25p80 spi0.0: error -22 reading 9f
m25p80: probe of spi0.0 failed with error -2
Reverting the spi/for-next branch makes it work again:
m25p80 spi0.0: gd25q128 (16384 Kbytes)
Not sure what's up.
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 9ee4f57557f3..2170cf63845e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -290,6 +290,18 @@
};
};
+ {
+ status = "okay";
+
+ spiflash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+
+ /* maximum speed for Rockchip SPI */
+ spi-max-frequency = <5000>;
+ };
+};
+
{
rockchip,hw-tshut-mode = <0>;
rockchip,hw-tshut-polarity = <0>;
--
2.19.0
Re: possible deadlock in path_openat
[Cc linux-unionfs]
On Wed, Sep 26, 2018 at 1:44 AM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:2dd68cc7fd8c Merge gitolite.kernel.org:/pub/scm/linux/kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=111a60e640
> kernel config: https://syzkaller.appspot.com/x/.config?x=22a62640793a83c9
> dashboard link: https://syzkaller.appspot.com/bug?extid=a55ccfc8a853d3cff213
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a55ccfc8a853d3cff...@syzkaller.appspotmail.com
>
> ntfs: (device loop1): ntfs_fill_super(): Unable to determine device size.
> team0 (unregistering): Port device team_slave_1 removed
> kobject: 'team_slave_1' (1c55f79f): kobject_uevent_env
>
> ==
> WARNING: possible circular locking dependency detected
> kobject: 'team_slave_1' (1c55f79f): kobject_uevent_env:
> uevent_suppress caused the event to drop!
> 4.19.0-rc5+ #253 Not tainted
> --
> syz-executor1/545 is trying to acquire lock:
> b04209e4 (_i_mutex_dir_key[depth]){}, at: inode_lock_shared
> include/linux/fs.h:748 [inline]
> b04209e4 (_i_mutex_dir_key[depth]){}, at: do_last
> fs/namei.c:3323 [inline]
> b04209e4 (_i_mutex_dir_key[depth]){}, at:
> path_openat+0x250d/0x5160 fs/namei.c:3534
> kobject: 'rx-0' (ca3546e9): kobject_cleanup, parent 4d034f96
>
> but task is already holding lock:
> 44500cca (>cred_guard_mutex){+.+.}, at:
> prepare_bprm_creds+0x53/0x120 fs/exec.c:1404
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (>cred_guard_mutex){+.+.}:
>__mutex_lock_common kernel/locking/mutex.c:925 [inline]
>__mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
> kobject: 'rx-0' (ca3546e9): auto cleanup 'remove' event
>mutex_lock_killable_nested+0x16/0x20 kernel/locking/mutex.c:1102
>lock_trace+0x4c/0xe0 fs/proc/base.c:384
>proc_pid_stack+0x196/0x3b0 fs/proc/base.c:420
>proc_single_show+0x101/0x190 fs/proc/base.c:723
>seq_read+0x4af/0x1150 fs/seq_file.c:229
>do_loop_readv_writev fs/read_write.c:700 [inline]
>do_iter_read+0x4a3/0x650 fs/read_write.c:924
> kobject: 'rx-0' (ca3546e9): kobject_uevent_env
>vfs_readv+0x175/0x1c0 fs/read_write.c:986
>do_preadv+0x1cc/0x280 fs/read_write.c:1070
>__do_sys_preadv fs/read_write.c:1120 [inline]
>__se_sys_preadv fs/read_write.c:1115 [inline]
>__x64_sys_preadv+0x9a/0xf0 fs/read_write.c:1115
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> kobject: 'rx-0' (ca3546e9): kobject_uevent_env: uevent_suppress
> caused the event to drop!
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #2 (>lock){+.+.}:
>__mutex_lock_common kernel/locking/mutex.c:925 [inline]
>__mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
>seq_read+0x71/0x1150 fs/seq_file.c:161
>do_loop_readv_writev fs/read_write.c:700 [inline]
>do_iter_read+0x4a3/0x650 fs/read_write.c:924
>vfs_readv+0x175/0x1c0 fs/read_write.c:986
> kobject: 'rx-0' (ca3546e9): auto cleanup kobject_del
>kernel_readv fs/splice.c:362 [inline]
>default_file_splice_read+0x53c/0xb20 fs/splice.c:417
>do_splice_to+0x12e/0x190 fs/splice.c:881
>splice_direct_to_actor+0x270/0x8f0 fs/splice.c:953
>do_splice_direct+0x2d4/0x420 fs/splice.c:1062
>do_sendfile+0x62a/0xe20 fs/read_write.c:1440
>__do_sys_sendfile64 fs/read_write.c:1495 [inline]
>__se_sys_sendfile64 fs/read_write.c:1487 [inline]
>__x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1487
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> kobject: 'rx-0' (ca3546e9): calling ktype release
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #1 (sb_writers#5){.+.+}:
>percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> [inline]
>percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
>__sb_start_write+0x214/0x370 fs/super.c:1387
>sb_start_write include/linux/fs.h:1566 [inline]
>mnt_want_write+0x3f/0xc0 fs/namespace.c:360
>ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> kobject: 'rx-0': free name
>ovl_create_object+0x142/0x3a0 fs/overlayfs/dir.c:596
>ovl_create+0x2b/0x30 fs/overlayfs/dir.c:627
>lookup_open+0x1319/0x1b90 fs/namei.c:3234
>do_last fs/namei.c:3324 [inline]
>path_openat+0x15e7/0x5160 fs/namei.c:3534
>do_filp_open+0x255/0x380
Re: possible deadlock in path_openat
[Cc linux-unionfs]
On Wed, Sep 26, 2018 at 1:44 AM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:2dd68cc7fd8c Merge gitolite.kernel.org:/pub/scm/linux/kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=111a60e640
> kernel config: https://syzkaller.appspot.com/x/.config?x=22a62640793a83c9
> dashboard link: https://syzkaller.appspot.com/bug?extid=a55ccfc8a853d3cff213
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a55ccfc8a853d3cff...@syzkaller.appspotmail.com
>
> ntfs: (device loop1): ntfs_fill_super(): Unable to determine device size.
> team0 (unregistering): Port device team_slave_1 removed
> kobject: 'team_slave_1' (1c55f79f): kobject_uevent_env
>
> ==
> WARNING: possible circular locking dependency detected
> kobject: 'team_slave_1' (1c55f79f): kobject_uevent_env:
> uevent_suppress caused the event to drop!
> 4.19.0-rc5+ #253 Not tainted
> --
> syz-executor1/545 is trying to acquire lock:
> b04209e4 (_i_mutex_dir_key[depth]){}, at: inode_lock_shared
> include/linux/fs.h:748 [inline]
> b04209e4 (_i_mutex_dir_key[depth]){}, at: do_last
> fs/namei.c:3323 [inline]
> b04209e4 (_i_mutex_dir_key[depth]){}, at:
> path_openat+0x250d/0x5160 fs/namei.c:3534
> kobject: 'rx-0' (ca3546e9): kobject_cleanup, parent 4d034f96
>
> but task is already holding lock:
> 44500cca (>cred_guard_mutex){+.+.}, at:
> prepare_bprm_creds+0x53/0x120 fs/exec.c:1404
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (>cred_guard_mutex){+.+.}:
>__mutex_lock_common kernel/locking/mutex.c:925 [inline]
>__mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
> kobject: 'rx-0' (ca3546e9): auto cleanup 'remove' event
>mutex_lock_killable_nested+0x16/0x20 kernel/locking/mutex.c:1102
>lock_trace+0x4c/0xe0 fs/proc/base.c:384
>proc_pid_stack+0x196/0x3b0 fs/proc/base.c:420
>proc_single_show+0x101/0x190 fs/proc/base.c:723
>seq_read+0x4af/0x1150 fs/seq_file.c:229
>do_loop_readv_writev fs/read_write.c:700 [inline]
>do_iter_read+0x4a3/0x650 fs/read_write.c:924
> kobject: 'rx-0' (ca3546e9): kobject_uevent_env
>vfs_readv+0x175/0x1c0 fs/read_write.c:986
>do_preadv+0x1cc/0x280 fs/read_write.c:1070
>__do_sys_preadv fs/read_write.c:1120 [inline]
>__se_sys_preadv fs/read_write.c:1115 [inline]
>__x64_sys_preadv+0x9a/0xf0 fs/read_write.c:1115
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> kobject: 'rx-0' (ca3546e9): kobject_uevent_env: uevent_suppress
> caused the event to drop!
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #2 (>lock){+.+.}:
>__mutex_lock_common kernel/locking/mutex.c:925 [inline]
>__mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
>seq_read+0x71/0x1150 fs/seq_file.c:161
>do_loop_readv_writev fs/read_write.c:700 [inline]
>do_iter_read+0x4a3/0x650 fs/read_write.c:924
>vfs_readv+0x175/0x1c0 fs/read_write.c:986
> kobject: 'rx-0' (ca3546e9): auto cleanup kobject_del
>kernel_readv fs/splice.c:362 [inline]
>default_file_splice_read+0x53c/0xb20 fs/splice.c:417
>do_splice_to+0x12e/0x190 fs/splice.c:881
>splice_direct_to_actor+0x270/0x8f0 fs/splice.c:953
>do_splice_direct+0x2d4/0x420 fs/splice.c:1062
>do_sendfile+0x62a/0xe20 fs/read_write.c:1440
>__do_sys_sendfile64 fs/read_write.c:1495 [inline]
>__se_sys_sendfile64 fs/read_write.c:1487 [inline]
>__x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1487
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> kobject: 'rx-0' (ca3546e9): calling ktype release
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #1 (sb_writers#5){.+.+}:
>percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> [inline]
>percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
>__sb_start_write+0x214/0x370 fs/super.c:1387
>sb_start_write include/linux/fs.h:1566 [inline]
>mnt_want_write+0x3f/0xc0 fs/namespace.c:360
>ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> kobject: 'rx-0': free name
>ovl_create_object+0x142/0x3a0 fs/overlayfs/dir.c:596
>ovl_create+0x2b/0x30 fs/overlayfs/dir.c:627
>lookup_open+0x1319/0x1b90 fs/namei.c:3234
>do_last fs/namei.c:3324 [inline]
>path_openat+0x15e7/0x5160 fs/namei.c:3534
>do_filp_open+0x255/0x380
Re: [PATCH v2] RISC-V: Show CPU ID and Hart ID separately in /proc/cpuinfo
On Tue, Sep 25, 2018 at 11:29 PM Atish Patra wrote: > > On 9/23/18 6:37 AM, Anup Patel wrote: > > Currently, /proc/cpuinfo show logical CPU ID as Hart ID which > > is in-correct. This patch shows CPU ID and Hart ID separately > > in /proc/cpuinfo using cpuid_to_hardid_map(). > > > I noticed it should be cpuid_to_hartid_map instead of > cpuid_to_hardid_map. It was a typo in my smp cleanup patch series. > Sorry for the inconvenience here. Thanks for pointing. > > I can include this patch in into my series fixing the typo if you want. Yes, please. You can also include "RISC-V: Show IPI stats" patch in your series. This patch was reviewed by Christoph. Thanks, Anup
Re: [PATCH v2] RISC-V: Show CPU ID and Hart ID separately in /proc/cpuinfo
On Tue, Sep 25, 2018 at 11:29 PM Atish Patra wrote: > > On 9/23/18 6:37 AM, Anup Patel wrote: > > Currently, /proc/cpuinfo show logical CPU ID as Hart ID which > > is in-correct. This patch shows CPU ID and Hart ID separately > > in /proc/cpuinfo using cpuid_to_hardid_map(). > > > I noticed it should be cpuid_to_hartid_map instead of > cpuid_to_hardid_map. It was a typo in my smp cleanup patch series. > Sorry for the inconvenience here. Thanks for pointing. > > I can include this patch in into my series fixing the typo if you want. Yes, please. You can also include "RISC-V: Show IPI stats" patch in your series. This patch was reviewed by Christoph. Thanks, Anup
[PATCH v2] of: unittest: Disable interrupt node tests for old world MAC systems
On systems with OF_IMAP_OLDWORLD_MAC set in of_irq_workarounds, the
devicetree interrupt parsing code is different, causing unit tests of
devicetree interrupt nodes to fail. Due to a bug in unittest code, which
tries to dereference an uninitialized pointer, this results in a crash.
OF: /testcase-data/phandle-tests/consumer-a: arguments longer than property
Unable to handle kernel paging request for data at address 0x00bc616e
Faulting instruction address: 0xc08e9468
Oops: Kernel access of bad area, sig: 11 [#1]
BE PREEMPT PowerMac
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.72-rc1-yocto-standard+ #1
task: cf8e task.stack: cf8da000
NIP: c08e9468 LR: c08ea5bc CTR: c08ea5ac
REGS: cf8dbb50 TRAP: 0300 Not tainted (4.14.72-rc1-yocto-standard+)
MSR: 1032 CR: 82004044 XER:
DAR: 00bc616e DSISR: 4000
GPR00: c08ea5bc cf8dbc00 cf8e c13ca517 c13ca517 c13ca8a0 0066 0002
GPR08: 0063 00bc614e c0b05865 000a 82004048 c00047f0
GPR16: c0a8 c0a9cc34 c13ca517 c0ad1134 05ff 000a c0b05860 c0abeef8
GPR24: cecec278 cecec278 c0a8c4d0 c0a885e0 c13ca8a0 05ff c13ca8a0 c13ca517
NIP [c08e9468] device_node_gen_full_name+0x30/0x15c
LR [c08ea5bc] device_node_string+0x190/0x3c8
Call Trace:
[cf8dbc00] [c007f670] trace_hardirqs_on_caller+0x118/0x1fc (unreliable)
[cf8dbc40] [c08ea5bc] device_node_string+0x190/0x3c8
[cf8dbcb0] [c08eb794] pointer+0x25c/0x4d0
[cf8dbd00] [c08ebcbc] vsnprintf+0x2b4/0x5ec
[cf8dbd60] [c08ec00c] vscnprintf+0x18/0x48
[cf8dbd70] [c008e268] vprintk_store+0x4c/0x22c
[cf8dbda0] [c008ecac] vprintk_emit+0x94/0x130
[cf8dbdd0] [c008ff54] printk+0x5c/0x6c
[cf8dbe10] [c0b8ddd4] of_unittest+0x2220/0x26f8
[cf8dbea0] [c0004434] do_one_initcall+0x4c/0x184
[cf8dbf00] [c0b4534c] kernel_init_freeable+0x13c/0x1d8
[cf8dbf30] [c0004814] kernel_init+0x24/0x118
[cf8dbf40] [c0013398] ret_from_kernel_thread+0x5c/0x64
The problem was observed when running a qemu test for the g3beige machine
with devicetree unittests enabled.
Disable interrupt node tests on affected systems to avoid both false
unittest failures and the crash.
With this patch in place, unittest on the affected system passes with
the following message.
dt-test ### end of unittest - 144 passed, 0 failed
Fixes: 53a42093d96ef ("of: Add device tree selftests")
Signed-off-by: Guenter Roeck
---
v2: Do not use goto to skip tests.
Provide test log in commit message.
drivers/of/unittest.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 722537e14848..41b49716ac75 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -771,6 +771,9 @@ static void __init of_unittest_parse_interrupts(void)
struct of_phandle_args args;
int i, rc;
+ if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
+ return;
+
np = of_find_node_by_path("/testcase-data/interrupts/interrupts0");
if (!np) {
pr_err("missing testcase data\n");
@@ -845,6 +848,9 @@ static void __init
of_unittest_parse_interrupts_extended(void)
struct of_phandle_args args;
int i, rc;
+ if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
+ return;
+
np =
of_find_node_by_path("/testcase-data/interrupts/interrupts-extended0");
if (!np) {
pr_err("missing testcase data\n");
@@ -1001,15 +1007,19 @@ static void __init of_unittest_platform_populate(void)
pdev = of_find_device_by_node(np);
unittest(pdev, "device 1 creation failed\n");
- irq = platform_get_irq(pdev, 0);
- unittest(irq == -EPROBE_DEFER, "device deferred probe failed - %d\n",
irq);
+ if (!(of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)) {
+ irq = platform_get_irq(pdev, 0);
+ unittest(irq == -EPROBE_DEFER,
+"device deferred probe failed - %d\n", irq);
- /* Test that a parsing failure does not return -EPROBE_DEFER */
- np = of_find_node_by_path("/testcase-data/testcase-device2");
- pdev = of_find_device_by_node(np);
- unittest(pdev, "device 2 creation failed\n");
- irq = platform_get_irq(pdev, 0);
- unittest(irq < 0 && irq != -EPROBE_DEFER, "device parsing error failed
- %d\n", irq);
+ /* Test that a parsing failure does not return -EPROBE_DEFER */
+ np = of_find_node_by_path("/testcase-data/testcase-device2");
+ pdev = of_find_device_by_node(np);
+ unittest(pdev, "device 2 creation failed\n");
+ irq = platform_get_irq(pdev, 0);
+ unittest(irq < 0 && irq != -EPROBE_DEFER,
+"device parsing error failed - %d\n", irq);
+ }
np = of_find_node_by_path("/testcase-data/platform-tests");
unittest(np, "No testcase data in device tree\n");
--
2.7.4
[PATCH v2] of: unittest: Disable interrupt node tests for old world MAC systems
On systems with OF_IMAP_OLDWORLD_MAC set in of_irq_workarounds, the
devicetree interrupt parsing code is different, causing unit tests of
devicetree interrupt nodes to fail. Due to a bug in unittest code, which
tries to dereference an uninitialized pointer, this results in a crash.
OF: /testcase-data/phandle-tests/consumer-a: arguments longer than property
Unable to handle kernel paging request for data at address 0x00bc616e
Faulting instruction address: 0xc08e9468
Oops: Kernel access of bad area, sig: 11 [#1]
BE PREEMPT PowerMac
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.72-rc1-yocto-standard+ #1
task: cf8e task.stack: cf8da000
NIP: c08e9468 LR: c08ea5bc CTR: c08ea5ac
REGS: cf8dbb50 TRAP: 0300 Not tainted (4.14.72-rc1-yocto-standard+)
MSR: 1032 CR: 82004044 XER:
DAR: 00bc616e DSISR: 4000
GPR00: c08ea5bc cf8dbc00 cf8e c13ca517 c13ca517 c13ca8a0 0066 0002
GPR08: 0063 00bc614e c0b05865 000a 82004048 c00047f0
GPR16: c0a8 c0a9cc34 c13ca517 c0ad1134 05ff 000a c0b05860 c0abeef8
GPR24: cecec278 cecec278 c0a8c4d0 c0a885e0 c13ca8a0 05ff c13ca8a0 c13ca517
NIP [c08e9468] device_node_gen_full_name+0x30/0x15c
LR [c08ea5bc] device_node_string+0x190/0x3c8
Call Trace:
[cf8dbc00] [c007f670] trace_hardirqs_on_caller+0x118/0x1fc (unreliable)
[cf8dbc40] [c08ea5bc] device_node_string+0x190/0x3c8
[cf8dbcb0] [c08eb794] pointer+0x25c/0x4d0
[cf8dbd00] [c08ebcbc] vsnprintf+0x2b4/0x5ec
[cf8dbd60] [c08ec00c] vscnprintf+0x18/0x48
[cf8dbd70] [c008e268] vprintk_store+0x4c/0x22c
[cf8dbda0] [c008ecac] vprintk_emit+0x94/0x130
[cf8dbdd0] [c008ff54] printk+0x5c/0x6c
[cf8dbe10] [c0b8ddd4] of_unittest+0x2220/0x26f8
[cf8dbea0] [c0004434] do_one_initcall+0x4c/0x184
[cf8dbf00] [c0b4534c] kernel_init_freeable+0x13c/0x1d8
[cf8dbf30] [c0004814] kernel_init+0x24/0x118
[cf8dbf40] [c0013398] ret_from_kernel_thread+0x5c/0x64
The problem was observed when running a qemu test for the g3beige machine
with devicetree unittests enabled.
Disable interrupt node tests on affected systems to avoid both false
unittest failures and the crash.
With this patch in place, unittest on the affected system passes with
the following message.
dt-test ### end of unittest - 144 passed, 0 failed
Fixes: 53a42093d96ef ("of: Add device tree selftests")
Signed-off-by: Guenter Roeck
---
v2: Do not use goto to skip tests.
Provide test log in commit message.
drivers/of/unittest.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 722537e14848..41b49716ac75 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -771,6 +771,9 @@ static void __init of_unittest_parse_interrupts(void)
struct of_phandle_args args;
int i, rc;
+ if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
+ return;
+
np = of_find_node_by_path("/testcase-data/interrupts/interrupts0");
if (!np) {
pr_err("missing testcase data\n");
@@ -845,6 +848,9 @@ static void __init
of_unittest_parse_interrupts_extended(void)
struct of_phandle_args args;
int i, rc;
+ if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
+ return;
+
np =
of_find_node_by_path("/testcase-data/interrupts/interrupts-extended0");
if (!np) {
pr_err("missing testcase data\n");
@@ -1001,15 +1007,19 @@ static void __init of_unittest_platform_populate(void)
pdev = of_find_device_by_node(np);
unittest(pdev, "device 1 creation failed\n");
- irq = platform_get_irq(pdev, 0);
- unittest(irq == -EPROBE_DEFER, "device deferred probe failed - %d\n",
irq);
+ if (!(of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)) {
+ irq = platform_get_irq(pdev, 0);
+ unittest(irq == -EPROBE_DEFER,
+"device deferred probe failed - %d\n", irq);
- /* Test that a parsing failure does not return -EPROBE_DEFER */
- np = of_find_node_by_path("/testcase-data/testcase-device2");
- pdev = of_find_device_by_node(np);
- unittest(pdev, "device 2 creation failed\n");
- irq = platform_get_irq(pdev, 0);
- unittest(irq < 0 && irq != -EPROBE_DEFER, "device parsing error failed
- %d\n", irq);
+ /* Test that a parsing failure does not return -EPROBE_DEFER */
+ np = of_find_node_by_path("/testcase-data/testcase-device2");
+ pdev = of_find_device_by_node(np);
+ unittest(pdev, "device 2 creation failed\n");
+ irq = platform_get_irq(pdev, 0);
+ unittest(irq < 0 && irq != -EPROBE_DEFER,
+"device parsing error failed - %d\n", irq);
+ }
np = of_find_node_by_path("/testcase-data/platform-tests");
unittest(np, "No testcase data in device tree\n");
--
2.7.4
[PATCH 7/7] x86/mm/tlb: Make lazy TLB mode lazier
Lazy TLB mode can result in an idle CPU being woken up by a TLB flush,
when all it really needs to do is reload %CR3 at the next context switch,
assuming no page table pages got freed.
Memory ordering is used to prevent race conditions between switch_mm_irqs_off,
which checks whether .tlb_gen changed, and the TLB invalidation code, which
increments .tlb_gen whenever page table entries get invalidated.
The atomic increment in inc_mm_tlb_gen is its own barrier; the context
switch code adds an explicit barrier between reading tlbstate.is_lazy and
next->context.tlb_gen.
CPUs in lazy TLB mode remain part of the mm_cpumask(mm), both because
that allows TLB flush IPIs to be sent at page table freeing time, and
because the cache line bouncing on the mm_cpumask(mm) was responsible
for about half the CPU use in switch_mm_irqs_off().
Tested-by: Song Liu
Signed-off-by: Rik van Riel
---
arch/x86/mm/tlb.c | 67 ---
1 file changed, 58 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index b228d2a6b5fa..707d757e70ec 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -185,6 +185,7 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
{
struct mm_struct *real_prev = this_cpu_read(cpu_tlbstate.loaded_mm);
u16 prev_asid = this_cpu_read(cpu_tlbstate.loaded_mm_asid);
+ bool was_lazy = this_cpu_read(cpu_tlbstate.is_lazy);
unsigned cpu = smp_processor_id();
u64 next_tlb_gen;
bool need_flush;
@@ -242,17 +243,40 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
next->context.ctx_id);
/*
-* We don't currently support having a real mm loaded without
-* our cpu set in mm_cpumask(). We have all the bookkeeping
-* in place to figure out whether we would need to flush
-* if our cpu were cleared in mm_cpumask(), but we don't
-* currently use it.
+* Even in lazy TLB mode, the CPU should stay set in the
+* mm_cpumask. The TLB shootdown code can figure out from
+* from cpu_tlbstate.is_lazy whether or not to send an IPI.
*/
if (WARN_ON_ONCE(real_prev != _mm &&
!cpumask_test_cpu(cpu, mm_cpumask(next
cpumask_set_cpu(cpu, mm_cpumask(next));
- return;
+ /*
+* If the CPU is not in lazy TLB mode, we are just switching
+* from one thread in a process to another thread in the same
+* process. No TLB flush required.
+*/
+ if (!was_lazy)
+ return;
+
+ /*
+* Read the tlb_gen to check whether a flush is needed.
+* If the TLB is up to date, just use it.
+* The barrier synchronizes with the tlb_gen increment in
+* the TLB shootdown code.
+*/
+ smp_mb();
+ next_tlb_gen = atomic64_read(>context.tlb_gen);
+ if (this_cpu_read(cpu_tlbstate.ctxs[prev_asid].tlb_gen) ==
+ next_tlb_gen)
+ return;
+
+ /*
+* TLB contents went out of date while we were in lazy
+* mode. Fall through to the TLB switching code below.
+*/
+ new_asid = prev_asid;
+ need_flush = true;
} else {
u16 new_asid;
bool need_flush;
@@ -348,8 +372,10 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
this_cpu_write(cpu_tlbstate.loaded_mm, next);
this_cpu_write(cpu_tlbstate.loaded_mm_asid, new_asid);
- load_mm_cr4(next);
- switch_ldt(real_prev, next);
+ if (next != real_prev) {
+ load_mm_cr4(next);
+ switch_ldt(real_prev, next);
+ }
}
/*
@@ -457,6 +483,9 @@ static void flush_tlb_func_common(const struct
flush_tlb_info *f,
* paging-structure cache to avoid speculatively reading
* garbage into our TLB. Since switching to init_mm is barely
* slower than a minimal flush, just switch to init_mm.
+*
+* This should be rare, with native_flush_tlb_others skipping
+* IPIs to lazy TLB mode CPUs.
*/
switch_mm_irqs_off(NULL, _mm, NULL);
return;
@@ -559,6 +588,11 @@ static void flush_tlb_func_remote(void *info)
flush_tlb_func_common(f, false, TLB_REMOTE_SHOOTDOWN);
}
+static bool tlb_is_not_lazy(int cpu, void *data)
+{
+ return !per_cpu(cpu_tlbstate.is_lazy, cpu);
+}
+
void native_flush_tlb_others(const struct cpumask *cpumask,
const
[PATCH 4/7] smp,cpumask: introduce on_each_cpu_cond_mask
Introduce a variant of on_each_cpu_cond that iterates only over the
CPUs in a cpumask, in order to avoid making callbacks for every single
CPU in the system when we only need to test a subset.
Signed-off-by: Rik van Riel
---
include/linux/smp.h | 4
kernel/smp.c| 17 +
kernel/up.c | 14 +++---
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 9fb239e12b82..a56f08ff3097 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -53,6 +53,10 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
smp_call_func_t func, void *info, bool wait,
gfp_t gfp_flags);
+void on_each_cpu_cond_mask(bool (*cond_func)(int cpu, void *info),
+ smp_call_func_t func, void *info, bool wait,
+ gfp_t gfp_flags, const struct cpumask *mask);
+
int smp_call_function_single_async(int cpu, call_single_data_t *csd);
#ifdef CONFIG_SMP
diff --git a/kernel/smp.c b/kernel/smp.c
index a7d4f9f50a49..163c451af42e 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -669,9 +669,9 @@ EXPORT_SYMBOL(on_each_cpu_mask);
* You must not call this function with disabled interrupts or
* from a hardware interrupt handler or from a bottom half handler.
*/
-void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
+void on_each_cpu_cond_mask(bool (*cond_func)(int cpu, void *info),
smp_call_func_t func, void *info, bool wait,
- gfp_t gfp_flags)
+ gfp_t gfp_flags, const struct cpumask *mask)
{
cpumask_var_t cpus;
int cpu, ret;
@@ -680,7 +680,7 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void
*info),
if (likely(zalloc_cpumask_var(, (gfp_flags|__GFP_NOWARN {
preempt_disable();
- for_each_online_cpu(cpu)
+ for_each_cpu(cpu, mask)
if (cond_func(cpu, info))
__cpumask_set_cpu(cpu, cpus);
on_each_cpu_mask(cpus, func, info, wait);
@@ -692,7 +692,7 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void
*info),
* just have to IPI them one by one.
*/
preempt_disable();
- for_each_online_cpu(cpu)
+ for_each_cpu(cpu, mask)
if (cond_func(cpu, info)) {
ret = smp_call_function_single(cpu, func,
info, wait);
@@ -701,6 +701,15 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void
*info),
preempt_enable();
}
}
+EXPORT_SYMBOL(on_each_cpu_cond_mask);
+
+void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
+ smp_call_func_t func, void *info, bool wait,
+ gfp_t gfp_flags)
+{
+ on_each_cpu_cond_mask(cond_func, func, info, wait, gfp_flags,
+ cpu_online_mask);
+}
EXPORT_SYMBOL(on_each_cpu_cond);
static void do_nothing(void *unused)
diff --git a/kernel/up.c b/kernel/up.c
index 42c46bf3e0a5..ff536f9cc8a2 100644
--- a/kernel/up.c
+++ b/kernel/up.c
@@ -68,9 +68,9 @@ EXPORT_SYMBOL(on_each_cpu_mask);
* Preemption is disabled here to make sure the cond_func is called under the
* same condtions in UP and SMP.
*/
-void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
- smp_call_func_t func, void *info, bool wait,
- gfp_t gfp_flags)
+void on_each_cpu_cond_mask(bool (*cond_func)(int cpu, void *info),
+ smp_call_func_t func, void *info, bool wait,
+ gfp_t gfp_flags, const struct cpumask *mask)
{
unsigned long flags;
@@ -82,6 +82,14 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
}
preempt_enable();
}
+EXPORT_SYMBOL(on_each_cpu_cond_mask);
+
+void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
+ smp_call_func_t func, void *info, bool wait,
+ gfp_t gfp_flags)
+{
+ on_each_cpu_cond_mask(cond_func, func, info, wait, gfp_flags, NULL);
+}
EXPORT_SYMBOL(on_each_cpu_cond);
int smp_call_on_cpu(unsigned int cpu, int (*func)(void *), void *par, bool
phys)
--
2.17.1
[PATCH 5/7] Add freed_tables argument to flush_tlb_mm_range
Add an argument to flush_tlb_mm_range to indicate whether page tables
are about to be freed after this TLB flush. This allows for an
optimization of flush_tlb_mm_range to skip CPUs in lazy TLB mode.
No functional changes.
Signed-off-by: Rik van Riel
---
arch/x86/include/asm/tlb.h | 2 +-
arch/x86/include/asm/tlbflush.h | 10 ++
arch/x86/kernel/ldt.c | 2 +-
arch/x86/kernel/vm86_32.c | 2 +-
arch/x86/mm/tlb.c | 3 ++-
5 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
index afbe7d1e68cf..404b8b1d44f5 100644
--- a/arch/x86/include/asm/tlb.h
+++ b/arch/x86/include/asm/tlb.h
@@ -20,7 +20,7 @@ static inline void tlb_flush(struct mmu_gather *tlb)
end = tlb->end;
}
- flush_tlb_mm_range(tlb->mm, start, end, stride_shift);
+ flush_tlb_mm_range(tlb->mm, start, end, stride_shift,
tlb->freed_tables);
}
/*
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index d6c0cd9e9591..1dea9860ce5b 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -536,22 +536,24 @@ struct flush_tlb_info {
#define local_flush_tlb() __flush_tlb()
-#define flush_tlb_mm(mm) flush_tlb_mm_range(mm, 0UL, TLB_FLUSH_ALL, 0UL)
+#define flush_tlb_mm(mm) \
+ flush_tlb_mm_range(mm, 0UL, TLB_FLUSH_ALL, 0UL, true)
#define flush_tlb_range(vma, start, end) \
flush_tlb_mm_range((vma)->vm_mm, start, end,\
((vma)->vm_flags & VM_HUGETLB) \
? huge_page_shift(hstate_vma(vma)) \
- : PAGE_SHIFT)
+ : PAGE_SHIFT, false)
extern void flush_tlb_all(void);
extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
- unsigned long end, unsigned int stride_shift);
+ unsigned long end, unsigned int stride_shift,
+ bool freed_tables);
extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
static inline void flush_tlb_page(struct vm_area_struct *vma, unsigned long a)
{
- flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, PAGE_SHIFT);
+ flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, PAGE_SHIFT, false);
}
void native_flush_tlb_others(const struct cpumask *cpumask,
diff --git a/arch/x86/kernel/ldt.c b/arch/x86/kernel/ldt.c
index 733e6ace0fa4..91eae79ef686 100644
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -273,7 +273,7 @@ map_ldt_struct(struct mm_struct *mm, struct ldt_struct
*ldt, int slot)
map_ldt_struct_to_user(mm);
va = (unsigned long)ldt_slot_va(slot);
- flush_tlb_mm_range(mm, va, va + LDT_SLOT_STRIDE, 0);
+ flush_tlb_mm_range(mm, va, va + LDT_SLOT_STRIDE, 0, false);
ldt->slot = slot;
return 0;
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 1c03e4aa6474..91460acbb650 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -199,7 +199,7 @@ static void mark_screen_rdonly(struct mm_struct *mm)
pte_unmap_unlock(pte, ptl);
out:
up_write(>mmap_sem);
- flush_tlb_mm_range(mm, 0xA, 0xA + 32*PAGE_SIZE, 0UL);
+ flush_tlb_mm_range(mm, 0xA, 0xA + 32*PAGE_SIZE, 0UL, false);
}
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 1224f7fb1311..1d74fbc71ad6 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -611,7 +611,8 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
static unsigned long tlb_single_page_flush_ceiling __read_mostly = 33;
void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
- unsigned long end, unsigned int stride_shift)
+ unsigned long end, unsigned int stride_shift,
+ bool freed_tables)
{
int cpu;
--
2.17.1
[PATCH 5/7] Add freed_tables argument to flush_tlb_mm_range
Add an argument to flush_tlb_mm_range to indicate whether page tables
are about to be freed after this TLB flush. This allows for an
optimization of flush_tlb_mm_range to skip CPUs in lazy TLB mode.
No functional changes.
Signed-off-by: Rik van Riel
---
arch/x86/include/asm/tlb.h | 2 +-
arch/x86/include/asm/tlbflush.h | 10 ++
arch/x86/kernel/ldt.c | 2 +-
arch/x86/kernel/vm86_32.c | 2 +-
arch/x86/mm/tlb.c | 3 ++-
5 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
index afbe7d1e68cf..404b8b1d44f5 100644
--- a/arch/x86/include/asm/tlb.h
+++ b/arch/x86/include/asm/tlb.h
@@ -20,7 +20,7 @@ static inline void tlb_flush(struct mmu_gather *tlb)
end = tlb->end;
}
- flush_tlb_mm_range(tlb->mm, start, end, stride_shift);
+ flush_tlb_mm_range(tlb->mm, start, end, stride_shift,
tlb->freed_tables);
}
/*
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index d6c0cd9e9591..1dea9860ce5b 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -536,22 +536,24 @@ struct flush_tlb_info {
#define local_flush_tlb() __flush_tlb()
-#define flush_tlb_mm(mm) flush_tlb_mm_range(mm, 0UL, TLB_FLUSH_ALL, 0UL)
+#define flush_tlb_mm(mm) \
+ flush_tlb_mm_range(mm, 0UL, TLB_FLUSH_ALL, 0UL, true)
#define flush_tlb_range(vma, start, end) \
flush_tlb_mm_range((vma)->vm_mm, start, end,\
((vma)->vm_flags & VM_HUGETLB) \
? huge_page_shift(hstate_vma(vma)) \
- : PAGE_SHIFT)
+ : PAGE_SHIFT, false)
extern void flush_tlb_all(void);
extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
- unsigned long end, unsigned int stride_shift);
+ unsigned long end, unsigned int stride_shift,
+ bool freed_tables);
extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
static inline void flush_tlb_page(struct vm_area_struct *vma, unsigned long a)
{
- flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, PAGE_SHIFT);
+ flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, PAGE_SHIFT, false);
}
void native_flush_tlb_others(const struct cpumask *cpumask,
diff --git a/arch/x86/kernel/ldt.c b/arch/x86/kernel/ldt.c
index 733e6ace0fa4..91eae79ef686 100644
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -273,7 +273,7 @@ map_ldt_struct(struct mm_struct *mm, struct ldt_struct
*ldt, int slot)
map_ldt_struct_to_user(mm);
va = (unsigned long)ldt_slot_va(slot);
- flush_tlb_mm_range(mm, va, va + LDT_SLOT_STRIDE, 0);
+ flush_tlb_mm_range(mm, va, va + LDT_SLOT_STRIDE, 0, false);
ldt->slot = slot;
return 0;
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 1c03e4aa6474..91460acbb650 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -199,7 +199,7 @@ static void mark_screen_rdonly(struct mm_struct *mm)
pte_unmap_unlock(pte, ptl);
out:
up_write(>mmap_sem);
- flush_tlb_mm_range(mm, 0xA, 0xA + 32*PAGE_SIZE, 0UL);
+ flush_tlb_mm_range(mm, 0xA, 0xA + 32*PAGE_SIZE, 0UL, false);
}
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 1224f7fb1311..1d74fbc71ad6 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -611,7 +611,8 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
static unsigned long tlb_single_page_flush_ceiling __read_mostly = 33;
void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
- unsigned long end, unsigned int stride_shift)
+ unsigned long end, unsigned int stride_shift,
+ bool freed_tables)
{
int cpu;
--
2.17.1
[PATCH 7/7] x86/mm/tlb: Make lazy TLB mode lazier
Lazy TLB mode can result in an idle CPU being woken up by a TLB flush,
when all it really needs to do is reload %CR3 at the next context switch,
assuming no page table pages got freed.
Memory ordering is used to prevent race conditions between switch_mm_irqs_off,
which checks whether .tlb_gen changed, and the TLB invalidation code, which
increments .tlb_gen whenever page table entries get invalidated.
The atomic increment in inc_mm_tlb_gen is its own barrier; the context
switch code adds an explicit barrier between reading tlbstate.is_lazy and
next->context.tlb_gen.
CPUs in lazy TLB mode remain part of the mm_cpumask(mm), both because
that allows TLB flush IPIs to be sent at page table freeing time, and
because the cache line bouncing on the mm_cpumask(mm) was responsible
for about half the CPU use in switch_mm_irqs_off().
Tested-by: Song Liu
Signed-off-by: Rik van Riel
---
arch/x86/mm/tlb.c | 67 ---
1 file changed, 58 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index b228d2a6b5fa..707d757e70ec 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -185,6 +185,7 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
{
struct mm_struct *real_prev = this_cpu_read(cpu_tlbstate.loaded_mm);
u16 prev_asid = this_cpu_read(cpu_tlbstate.loaded_mm_asid);
+ bool was_lazy = this_cpu_read(cpu_tlbstate.is_lazy);
unsigned cpu = smp_processor_id();
u64 next_tlb_gen;
bool need_flush;
@@ -242,17 +243,40 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
next->context.ctx_id);
/*
-* We don't currently support having a real mm loaded without
-* our cpu set in mm_cpumask(). We have all the bookkeeping
-* in place to figure out whether we would need to flush
-* if our cpu were cleared in mm_cpumask(), but we don't
-* currently use it.
+* Even in lazy TLB mode, the CPU should stay set in the
+* mm_cpumask. The TLB shootdown code can figure out from
+* from cpu_tlbstate.is_lazy whether or not to send an IPI.
*/
if (WARN_ON_ONCE(real_prev != _mm &&
!cpumask_test_cpu(cpu, mm_cpumask(next
cpumask_set_cpu(cpu, mm_cpumask(next));
- return;
+ /*
+* If the CPU is not in lazy TLB mode, we are just switching
+* from one thread in a process to another thread in the same
+* process. No TLB flush required.
+*/
+ if (!was_lazy)
+ return;
+
+ /*
+* Read the tlb_gen to check whether a flush is needed.
+* If the TLB is up to date, just use it.
+* The barrier synchronizes with the tlb_gen increment in
+* the TLB shootdown code.
+*/
+ smp_mb();
+ next_tlb_gen = atomic64_read(>context.tlb_gen);
+ if (this_cpu_read(cpu_tlbstate.ctxs[prev_asid].tlb_gen) ==
+ next_tlb_gen)
+ return;
+
+ /*
+* TLB contents went out of date while we were in lazy
+* mode. Fall through to the TLB switching code below.
+*/
+ new_asid = prev_asid;
+ need_flush = true;
} else {
u16 new_asid;
bool need_flush;
@@ -348,8 +372,10 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
this_cpu_write(cpu_tlbstate.loaded_mm, next);
this_cpu_write(cpu_tlbstate.loaded_mm_asid, new_asid);
- load_mm_cr4(next);
- switch_ldt(real_prev, next);
+ if (next != real_prev) {
+ load_mm_cr4(next);
+ switch_ldt(real_prev, next);
+ }
}
/*
@@ -457,6 +483,9 @@ static void flush_tlb_func_common(const struct
flush_tlb_info *f,
* paging-structure cache to avoid speculatively reading
* garbage into our TLB. Since switching to init_mm is barely
* slower than a minimal flush, just switch to init_mm.
+*
+* This should be rare, with native_flush_tlb_others skipping
+* IPIs to lazy TLB mode CPUs.
*/
switch_mm_irqs_off(NULL, _mm, NULL);
return;
@@ -559,6 +588,11 @@ static void flush_tlb_func_remote(void *info)
flush_tlb_func_common(f, false, TLB_REMOTE_SHOOTDOWN);
}
+static bool tlb_is_not_lazy(int cpu, void *data)
+{
+ return !per_cpu(cpu_tlbstate.is_lazy, cpu);
+}
+
void native_flush_tlb_others(const struct cpumask *cpumask,
const
[PATCH 4/7] smp,cpumask: introduce on_each_cpu_cond_mask
Introduce a variant of on_each_cpu_cond that iterates only over the
CPUs in a cpumask, in order to avoid making callbacks for every single
CPU in the system when we only need to test a subset.
Signed-off-by: Rik van Riel
---
include/linux/smp.h | 4
kernel/smp.c| 17 +
kernel/up.c | 14 +++---
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 9fb239e12b82..a56f08ff3097 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -53,6 +53,10 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
smp_call_func_t func, void *info, bool wait,
gfp_t gfp_flags);
+void on_each_cpu_cond_mask(bool (*cond_func)(int cpu, void *info),
+ smp_call_func_t func, void *info, bool wait,
+ gfp_t gfp_flags, const struct cpumask *mask);
+
int smp_call_function_single_async(int cpu, call_single_data_t *csd);
#ifdef CONFIG_SMP
diff --git a/kernel/smp.c b/kernel/smp.c
index a7d4f9f50a49..163c451af42e 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -669,9 +669,9 @@ EXPORT_SYMBOL(on_each_cpu_mask);
* You must not call this function with disabled interrupts or
* from a hardware interrupt handler or from a bottom half handler.
*/
-void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
+void on_each_cpu_cond_mask(bool (*cond_func)(int cpu, void *info),
smp_call_func_t func, void *info, bool wait,
- gfp_t gfp_flags)
+ gfp_t gfp_flags, const struct cpumask *mask)
{
cpumask_var_t cpus;
int cpu, ret;
@@ -680,7 +680,7 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void
*info),
if (likely(zalloc_cpumask_var(, (gfp_flags|__GFP_NOWARN {
preempt_disable();
- for_each_online_cpu(cpu)
+ for_each_cpu(cpu, mask)
if (cond_func(cpu, info))
__cpumask_set_cpu(cpu, cpus);
on_each_cpu_mask(cpus, func, info, wait);
@@ -692,7 +692,7 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void
*info),
* just have to IPI them one by one.
*/
preempt_disable();
- for_each_online_cpu(cpu)
+ for_each_cpu(cpu, mask)
if (cond_func(cpu, info)) {
ret = smp_call_function_single(cpu, func,
info, wait);
@@ -701,6 +701,15 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void
*info),
preempt_enable();
}
}
+EXPORT_SYMBOL(on_each_cpu_cond_mask);
+
+void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
+ smp_call_func_t func, void *info, bool wait,
+ gfp_t gfp_flags)
+{
+ on_each_cpu_cond_mask(cond_func, func, info, wait, gfp_flags,
+ cpu_online_mask);
+}
EXPORT_SYMBOL(on_each_cpu_cond);
static void do_nothing(void *unused)
diff --git a/kernel/up.c b/kernel/up.c
index 42c46bf3e0a5..ff536f9cc8a2 100644
--- a/kernel/up.c
+++ b/kernel/up.c
@@ -68,9 +68,9 @@ EXPORT_SYMBOL(on_each_cpu_mask);
* Preemption is disabled here to make sure the cond_func is called under the
* same condtions in UP and SMP.
*/
-void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
- smp_call_func_t func, void *info, bool wait,
- gfp_t gfp_flags)
+void on_each_cpu_cond_mask(bool (*cond_func)(int cpu, void *info),
+ smp_call_func_t func, void *info, bool wait,
+ gfp_t gfp_flags, const struct cpumask *mask)
{
unsigned long flags;
@@ -82,6 +82,14 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
}
preempt_enable();
}
+EXPORT_SYMBOL(on_each_cpu_cond_mask);
+
+void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
+ smp_call_func_t func, void *info, bool wait,
+ gfp_t gfp_flags)
+{
+ on_each_cpu_cond_mask(cond_func, func, info, wait, gfp_flags, NULL);
+}
EXPORT_SYMBOL(on_each_cpu_cond);
int smp_call_on_cpu(unsigned int cpu, int (*func)(void *), void *par, bool
phys)
--
2.17.1
[PATCH 3/7] smp: use __cpumask_set_cpu in on_each_cpu_cond
The code in on_each_cpu_cond sets CPUs in a locally allocated bitmask, which should never be used by other CPUs simultaneously. There is no need to use locked memory accesses to set the bits in this bitmap. Switch to __cpumask_set_cpu. Suggested-by: Peter Zijlstra Signed-off-by: Rik van Riel Reviewed-by: Andy Lutomirski --- kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/smp.c b/kernel/smp.c index d86eec5f51c1..a7d4f9f50a49 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -682,7 +682,7 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info), preempt_disable(); for_each_online_cpu(cpu) if (cond_func(cpu, info)) - cpumask_set_cpu(cpu, cpus); + __cpumask_set_cpu(cpu, cpus); on_each_cpu_mask(cpus, func, info, wait); preempt_enable(); free_cpumask_var(cpus); -- 2.17.1
[PATCH 2/7] x86/mm/tlb: Restructure switch_mm_irqs_off()
Move some code that will be needed for the lazy -> !lazy state
transition when a lazy TLB CPU has gotten out of date.
No functional changes, since the if (real_prev == next) branch
always returns.
Suggested-by: Andy Lutomirski
Signed-off-by: Rik van Riel
Acked-by: Dave Hansen
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: efa...@gmx.de
Cc: kernel-t...@fb.com
Link: http://lkml.kernel.org/r/20180716190337.26133-4-r...@surriel.com
Signed-off-by: Ingo Molnar
(cherry picked from commit 61d0beb5796ab11f7f3bf38cb2eccc6579aaa70b)
---
arch/x86/mm/tlb.c | 64 ---
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 54a5870190a6..1224f7fb1311 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -187,6 +187,8 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
u16 prev_asid = this_cpu_read(cpu_tlbstate.loaded_mm_asid);
unsigned cpu = smp_processor_id();
u64 next_tlb_gen;
+ bool need_flush;
+ u16 new_asid;
/*
* NB: The scheduler will call us with prev == next when switching
@@ -308,44 +310,44 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
/* Let nmi_uaccess_okay() know that we're changing CR3. */
this_cpu_write(cpu_tlbstate.loaded_mm, LOADED_MM_SWITCHING);
barrier();
+ }
- if (need_flush) {
- this_cpu_write(cpu_tlbstate.ctxs[new_asid].ctx_id,
next->context.ctx_id);
- this_cpu_write(cpu_tlbstate.ctxs[new_asid].tlb_gen,
next_tlb_gen);
- load_new_mm_cr3(next->pgd, new_asid, true);
-
- /*
-* NB: This gets called via leave_mm() in the idle path
-* where RCU functions differently. Tracing normally
-* uses RCU, so we need to use the _rcuidle variant.
-*
-* (There is no good reason for this. The idle code
should
-* be rearranged to call this before rcu_idle_enter().)
-*/
- trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH,
TLB_FLUSH_ALL);
- } else {
- /* The new ASID is already up to date. */
- load_new_mm_cr3(next->pgd, new_asid, false);
-
- /* See above wrt _rcuidle. */
- trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH, 0);
- }
+ if (need_flush) {
+ this_cpu_write(cpu_tlbstate.ctxs[new_asid].ctx_id,
next->context.ctx_id);
+ this_cpu_write(cpu_tlbstate.ctxs[new_asid].tlb_gen,
next_tlb_gen);
+ load_new_mm_cr3(next->pgd, new_asid, true);
/*
-* Record last user mm's context id, so we can avoid
-* flushing branch buffer with IBPB if we switch back
-* to the same user.
+* NB: This gets called via leave_mm() in the idle path
+* where RCU functions differently. Tracing normally
+* uses RCU, so we need to use the _rcuidle variant.
+*
+* (There is no good reason for this. The idle code should
+* be rearranged to call this before rcu_idle_enter().)
*/
- if (next != _mm)
- this_cpu_write(cpu_tlbstate.last_ctx_id,
next->context.ctx_id);
-
- /* Make sure we write CR3 before loaded_mm. */
- barrier();
+ trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH,
TLB_FLUSH_ALL);
+ } else {
+ /* The new ASID is already up to date. */
+ load_new_mm_cr3(next->pgd, new_asid, false);
- this_cpu_write(cpu_tlbstate.loaded_mm, next);
- this_cpu_write(cpu_tlbstate.loaded_mm_asid, new_asid);
+ /* See above wrt _rcuidle. */
+ trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH, 0);
}
+ /*
+* Record last user mm's context id, so we can avoid
+* flushing branch buffer with IBPB if we switch back
+* to the same user.
+*/
+ if (next != _mm)
+ this_cpu_write(cpu_tlbstate.last_ctx_id, next->context.ctx_id);
+
+ /* Make sure we write CR3 before loaded_mm. */
+ barrier();
+
+ this_cpu_write(cpu_tlbstate.loaded_mm, next);
+ this_cpu_write(cpu_tlbstate.loaded_mm_asid, new_asid);
+
load_mm_cr4(next);
switch_ldt(real_prev, next);
}
--
2.17.1
[PATCH 1/7] x86/mm/tlb: Always use lazy TLB mode
Now that CPUs in lazy TLB mode no longer receive TLB shootdown IPIs, except
at page table freeing time, and idle CPUs will no longer get shootdown IPIs
for things like mprotect and madvise, we can always use lazy TLB mode.
Tested-by: Song Liu
Signed-off-by: Rik van Riel
Acked-by: Dave Hansen
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: efa...@gmx.de
Cc: kernel-t...@fb.com
Cc: l...@kernel.org
Link: http://lkml.kernel.org/r/20180716190337.26133-7-r...@surriel.com
Signed-off-by: Ingo Molnar
(cherry picked from commit 95b0e6357d3e4e05349668940d7ff8f3b7e7e11e)
---
arch/x86/include/asm/tlbflush.h | 16
arch/x86/mm/tlb.c | 15 +--
2 files changed, 1 insertion(+), 30 deletions(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 671f65309ce7..d6c0cd9e9591 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -148,22 +148,6 @@ static inline unsigned long build_cr3_noflush(pgd_t *pgd,
u16 asid)
#define __flush_tlb_one_user(addr) __native_flush_tlb_one_user(addr)
#endif
-static inline bool tlb_defer_switch_to_init_mm(void)
-{
- /*
-* If we have PCID, then switching to init_mm is reasonably
-* fast. If we don't have PCID, then switching to init_mm is
-* quite slow, so we try to defer it in the hopes that we can
-* avoid it entirely. The latter approach runs the risk of
-* receiving otherwise unnecessary IPIs.
-*
-* This choice is just a heuristic. The tlb code can handle this
-* function returning true or false regardless of whether we have
-* PCID.
-*/
- return !static_cpu_has(X86_FEATURE_PCID);
-}
-
struct tlb_context {
u64 ctx_id;
u64 tlb_gen;
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 6aa195796dec..54a5870190a6 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -368,20 +368,7 @@ void enter_lazy_tlb(struct mm_struct *mm, struct
task_struct *tsk)
if (this_cpu_read(cpu_tlbstate.loaded_mm) == _mm)
return;
- if (tlb_defer_switch_to_init_mm()) {
- /*
-* There's a significant optimization that may be possible
-* here. We have accurate enough TLB flush tracking that we
-* don't need to maintain coherence of TLB per se when we're
-* lazy. We do, however, need to maintain coherence of
-* paging-structure caches. We could, in principle, leave our
-* old mm loaded and only switch to init_mm when
-* tlb_remove_page() happens.
-*/
- this_cpu_write(cpu_tlbstate.is_lazy, true);
- } else {
- switch_mm(NULL, _mm, NULL);
- }
+ this_cpu_write(cpu_tlbstate.is_lazy, true);
}
/*
--
2.17.1
[PATCH 3/7] smp: use __cpumask_set_cpu in on_each_cpu_cond
The code in on_each_cpu_cond sets CPUs in a locally allocated bitmask, which should never be used by other CPUs simultaneously. There is no need to use locked memory accesses to set the bits in this bitmap. Switch to __cpumask_set_cpu. Suggested-by: Peter Zijlstra Signed-off-by: Rik van Riel Reviewed-by: Andy Lutomirski --- kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/smp.c b/kernel/smp.c index d86eec5f51c1..a7d4f9f50a49 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -682,7 +682,7 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info), preempt_disable(); for_each_online_cpu(cpu) if (cond_func(cpu, info)) - cpumask_set_cpu(cpu, cpus); + __cpumask_set_cpu(cpu, cpus); on_each_cpu_mask(cpus, func, info, wait); preempt_enable(); free_cpumask_var(cpus); -- 2.17.1
[PATCH 2/7] x86/mm/tlb: Restructure switch_mm_irqs_off()
Move some code that will be needed for the lazy -> !lazy state
transition when a lazy TLB CPU has gotten out of date.
No functional changes, since the if (real_prev == next) branch
always returns.
Suggested-by: Andy Lutomirski
Signed-off-by: Rik van Riel
Acked-by: Dave Hansen
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: efa...@gmx.de
Cc: kernel-t...@fb.com
Link: http://lkml.kernel.org/r/20180716190337.26133-4-r...@surriel.com
Signed-off-by: Ingo Molnar
(cherry picked from commit 61d0beb5796ab11f7f3bf38cb2eccc6579aaa70b)
---
arch/x86/mm/tlb.c | 64 ---
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 54a5870190a6..1224f7fb1311 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -187,6 +187,8 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
u16 prev_asid = this_cpu_read(cpu_tlbstate.loaded_mm_asid);
unsigned cpu = smp_processor_id();
u64 next_tlb_gen;
+ bool need_flush;
+ u16 new_asid;
/*
* NB: The scheduler will call us with prev == next when switching
@@ -308,44 +310,44 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
/* Let nmi_uaccess_okay() know that we're changing CR3. */
this_cpu_write(cpu_tlbstate.loaded_mm, LOADED_MM_SWITCHING);
barrier();
+ }
- if (need_flush) {
- this_cpu_write(cpu_tlbstate.ctxs[new_asid].ctx_id,
next->context.ctx_id);
- this_cpu_write(cpu_tlbstate.ctxs[new_asid].tlb_gen,
next_tlb_gen);
- load_new_mm_cr3(next->pgd, new_asid, true);
-
- /*
-* NB: This gets called via leave_mm() in the idle path
-* where RCU functions differently. Tracing normally
-* uses RCU, so we need to use the _rcuidle variant.
-*
-* (There is no good reason for this. The idle code
should
-* be rearranged to call this before rcu_idle_enter().)
-*/
- trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH,
TLB_FLUSH_ALL);
- } else {
- /* The new ASID is already up to date. */
- load_new_mm_cr3(next->pgd, new_asid, false);
-
- /* See above wrt _rcuidle. */
- trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH, 0);
- }
+ if (need_flush) {
+ this_cpu_write(cpu_tlbstate.ctxs[new_asid].ctx_id,
next->context.ctx_id);
+ this_cpu_write(cpu_tlbstate.ctxs[new_asid].tlb_gen,
next_tlb_gen);
+ load_new_mm_cr3(next->pgd, new_asid, true);
/*
-* Record last user mm's context id, so we can avoid
-* flushing branch buffer with IBPB if we switch back
-* to the same user.
+* NB: This gets called via leave_mm() in the idle path
+* where RCU functions differently. Tracing normally
+* uses RCU, so we need to use the _rcuidle variant.
+*
+* (There is no good reason for this. The idle code should
+* be rearranged to call this before rcu_idle_enter().)
*/
- if (next != _mm)
- this_cpu_write(cpu_tlbstate.last_ctx_id,
next->context.ctx_id);
-
- /* Make sure we write CR3 before loaded_mm. */
- barrier();
+ trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH,
TLB_FLUSH_ALL);
+ } else {
+ /* The new ASID is already up to date. */
+ load_new_mm_cr3(next->pgd, new_asid, false);
- this_cpu_write(cpu_tlbstate.loaded_mm, next);
- this_cpu_write(cpu_tlbstate.loaded_mm_asid, new_asid);
+ /* See above wrt _rcuidle. */
+ trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH, 0);
}
+ /*
+* Record last user mm's context id, so we can avoid
+* flushing branch buffer with IBPB if we switch back
+* to the same user.
+*/
+ if (next != _mm)
+ this_cpu_write(cpu_tlbstate.last_ctx_id, next->context.ctx_id);
+
+ /* Make sure we write CR3 before loaded_mm. */
+ barrier();
+
+ this_cpu_write(cpu_tlbstate.loaded_mm, next);
+ this_cpu_write(cpu_tlbstate.loaded_mm_asid, new_asid);
+
load_mm_cr4(next);
switch_ldt(real_prev, next);
}
--
2.17.1
[PATCH 1/7] x86/mm/tlb: Always use lazy TLB mode
Now that CPUs in lazy TLB mode no longer receive TLB shootdown IPIs, except
at page table freeing time, and idle CPUs will no longer get shootdown IPIs
for things like mprotect and madvise, we can always use lazy TLB mode.
Tested-by: Song Liu
Signed-off-by: Rik van Riel
Acked-by: Dave Hansen
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: efa...@gmx.de
Cc: kernel-t...@fb.com
Cc: l...@kernel.org
Link: http://lkml.kernel.org/r/20180716190337.26133-7-r...@surriel.com
Signed-off-by: Ingo Molnar
(cherry picked from commit 95b0e6357d3e4e05349668940d7ff8f3b7e7e11e)
---
arch/x86/include/asm/tlbflush.h | 16
arch/x86/mm/tlb.c | 15 +--
2 files changed, 1 insertion(+), 30 deletions(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 671f65309ce7..d6c0cd9e9591 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -148,22 +148,6 @@ static inline unsigned long build_cr3_noflush(pgd_t *pgd,
u16 asid)
#define __flush_tlb_one_user(addr) __native_flush_tlb_one_user(addr)
#endif
-static inline bool tlb_defer_switch_to_init_mm(void)
-{
- /*
-* If we have PCID, then switching to init_mm is reasonably
-* fast. If we don't have PCID, then switching to init_mm is
-* quite slow, so we try to defer it in the hopes that we can
-* avoid it entirely. The latter approach runs the risk of
-* receiving otherwise unnecessary IPIs.
-*
-* This choice is just a heuristic. The tlb code can handle this
-* function returning true or false regardless of whether we have
-* PCID.
-*/
- return !static_cpu_has(X86_FEATURE_PCID);
-}
-
struct tlb_context {
u64 ctx_id;
u64 tlb_gen;
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 6aa195796dec..54a5870190a6 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -368,20 +368,7 @@ void enter_lazy_tlb(struct mm_struct *mm, struct
task_struct *tsk)
if (this_cpu_read(cpu_tlbstate.loaded_mm) == _mm)
return;
- if (tlb_defer_switch_to_init_mm()) {
- /*
-* There's a significant optimization that may be possible
-* here. We have accurate enough TLB flush tracking that we
-* don't need to maintain coherence of TLB per se when we're
-* lazy. We do, however, need to maintain coherence of
-* paging-structure caches. We could, in principle, leave our
-* old mm loaded and only switch to init_mm when
-* tlb_remove_page() happens.
-*/
- this_cpu_write(cpu_tlbstate.is_lazy, true);
- } else {
- switch_mm(NULL, _mm, NULL);
- }
+ this_cpu_write(cpu_tlbstate.is_lazy, true);
}
/*
--
2.17.1
[PATCH 6/7] Add freed_tables element to flush_tlb_info
Pass the information on to native_flush_tlb_others.
No functional changes.
Signed-off-by: Rik van Riel
---
arch/x86/include/asm/tlbflush.h | 1 +
arch/x86/mm/tlb.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 1dea9860ce5b..323a313947e0 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -532,6 +532,7 @@ struct flush_tlb_info {
unsigned long end;
u64 new_tlb_gen;
unsigned intstride_shift;
+ boolfreed_tables;
};
#define local_flush_tlb() __flush_tlb()
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 1d74fbc71ad6..b228d2a6b5fa 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -619,6 +619,7 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned long
start,
struct flush_tlb_info info __aligned(SMP_CACHE_BYTES) = {
.mm = mm,
.stride_shift = stride_shift,
+ .freed_tables = freed_tables,
};
cpu = get_cpu();
--
2.17.1
[PATCH 6/7] Add freed_tables element to flush_tlb_info
Pass the information on to native_flush_tlb_others.
No functional changes.
Signed-off-by: Rik van Riel
---
arch/x86/include/asm/tlbflush.h | 1 +
arch/x86/mm/tlb.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 1dea9860ce5b..323a313947e0 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -532,6 +532,7 @@ struct flush_tlb_info {
unsigned long end;
u64 new_tlb_gen;
unsigned intstride_shift;
+ boolfreed_tables;
};
#define local_flush_tlb() __flush_tlb()
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 1d74fbc71ad6..b228d2a6b5fa 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -619,6 +619,7 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned long
start,
struct flush_tlb_info info __aligned(SMP_CACHE_BYTES) = {
.mm = mm,
.stride_shift = stride_shift,
+ .freed_tables = freed_tables,
};
cpu = get_cpu();
--
2.17.1
[PATCH v2 0/7] x86/mm/tlb: make lazy TLB mode even lazier
Linus asked me to come up with a smaller patch set to get the benefits
of lazy TLB mode, so I spent some time trying out various permutations
of the code, with a few workloads that do lots of context switches, and
also happen to have a fair number of TLB flushes a second.
Both of the workloads tested are memcache style workloads, running
on two socket systems. One of the workloads has around 300,000
context switches a second, and around 19,000 TLB flushes.
The first patch in the series, of always using lazy TLB mode,
reduces CPU use around 1% on both Haswell and Broadwell systems.
The rest of the series reduces the number of TLB flush IPIs by
about 1,500 a second, resulting in a 0.2% reduction in CPU use,
on top of the 1% seen by just enabling lazy TLB mode.
These are the low hanging fruits in the context switch code.
The big thing remaining is the reference count overhead of
the lazy TLB mm_struct, but getting rid of that is rather a
lot of code for a small performance gain. Not quite what
Linus asked for :)
This v2 is "identical" to the version I posted yesterday,
except this one is actually against current -tip (not sure
what went wrong before), with a number of relevant patches
on top:
- tip x86/core
012e77a903d ("x86/nmi: Fix NMI uaccess race against CR3 switching")
- arm64 tlb/asm-generic (entire branch)
- peterz queue mm/tlb
12b2b80ec6f4 ("x86/mm: Page size aware flush_tlb_mm_range()")
[PATCH v2 0/7] x86/mm/tlb: make lazy TLB mode even lazier
Linus asked me to come up with a smaller patch set to get the benefits
of lazy TLB mode, so I spent some time trying out various permutations
of the code, with a few workloads that do lots of context switches, and
also happen to have a fair number of TLB flushes a second.
Both of the workloads tested are memcache style workloads, running
on two socket systems. One of the workloads has around 300,000
context switches a second, and around 19,000 TLB flushes.
The first patch in the series, of always using lazy TLB mode,
reduces CPU use around 1% on both Haswell and Broadwell systems.
The rest of the series reduces the number of TLB flush IPIs by
about 1,500 a second, resulting in a 0.2% reduction in CPU use,
on top of the 1% seen by just enabling lazy TLB mode.
These are the low hanging fruits in the context switch code.
The big thing remaining is the reference count overhead of
the lazy TLB mm_struct, but getting rid of that is rather a
lot of code for a small performance gain. Not quite what
Linus asked for :)
This v2 is "identical" to the version I posted yesterday,
except this one is actually against current -tip (not sure
what went wrong before), with a number of relevant patches
on top:
- tip x86/core
012e77a903d ("x86/nmi: Fix NMI uaccess race against CR3 switching")
- arm64 tlb/asm-generic (entire branch)
- peterz queue mm/tlb
12b2b80ec6f4 ("x86/mm: Page size aware flush_tlb_mm_range()")
Re: [PATCH v3] dt-bindings: arm: Explicitly mark Samsung Exynos SoC as unstable
On Mon, Sep 24, 2018 at 07:16:45PM +0200, Krzysztof Kozlowski wrote: > On Sun, Sep 23, 2018 at 02:46:20PM +0100, Olof Johansson wrote: > > On Thu, Aug 30, 2018 at 7:02 PM, Krzysztof Kozlowski > > wrote: > > > Samsung Exynos SoCs and boards related bindings evolved since the initial > > > introduction, but initially the bindings were minimal and a bit incomplete > > > (they never described all the hardware modules available in the SoCs). > > > Since then some significant (not fully compatible) changes have been > > > already committed a few times (like gpio replaced by pinctrl, display ddc, > > > mfc reserved memory, some core clocks added to various hardware modules, > > > added more required nodes). > > > > > > On the other side there are no boards which have device tree embedded in > > > the bootloader. Device tree blob is always compiled from the kernel tree > > > and updated together with the kernel image. > > > > > > Thus to avoid further adding a bunch of workarounds for old/missing > > > bindings, make development of new platforms easier and allow to make > > > cleanup of the existing code and device tree files, lets mark some > > > Samsung Exynos SoC platform bindings as unstable. This means that > > > bindings can may change at any time and users should use the dtb file > > > compiled from the same kernel source tree as the kernel image. > > > > I have to admit that I don't really like this approach, and I missed > > the patch when originally posted (I did notice it in the pull request > > it came in with though). > > > > The main concern for me is that with a blanket "everything is always > > unstable" we discard the notion that we should strive for bindings to > > be stable and backwards compatible. > > The original idea from Marek was to mark everything unstable. After > comments from Rob I made it weaker already by changing to specific group > of compatibles. Accepting their instability does not mean that we will > be doing this on whenever possible. It just opens the possibility of > finding some balance in cleanups and development. Sometimes things have > to be seriously changed (fixed) and implementing workarounds for > existing ABI might be huge work by itself. > > IOW, we want stability but not with the costs of huge development > efforts... because no one else except us cares about the stability. I think it's really problematic to retroactively mark a binding as unstable. The best way to do it is probably at the time of introduction if you anticipate it needing adjustments down the road (i.e. if it's for a complex IP block). For major overhauls, it might be worth updating to a new binding instead (by appending a suffix to the name or similar, and documenting that). > > Questions that come to mind are: > > > > - When do they stop being unstable? > > They became unstable in a subjective way so I assume that reverse is the > same, based on consensus and discussions. > > I am not sure if a hard time limit is good. There is no timeline for the > Exynos development, no public roadmaps but rather community and > partially volountary effort. Therefore whatever number we set, it might > be totally not matching reality. I think that sets up for a pretty bad experience for some downstream users. The main problem with unstable bindings is if you have a platform that you haven't (yet) upstreamed the devicetrees for. Moving around base kernel versions in those cases can be really awkward. "Just upstream your devicetrees" is one counter-argument, but it's not always that easy -- it might be unreleased products or just some experimental platforms that might even be tracking fairly close to mainline during whatever development is ongoing. > > - Is there a way to note in the binding itself that it's still > > unstable with an anticipation of when it will be settled in? > > Hmm, I see that some existing bindings are being added with "Unstable" > warning: > > git grep -i unstable Documentation/devicetree/ > > so there should be no problem for putting there a timeframe. Yeah, adding them with unstable up front is a good way to do it (and then remove that warning once things have settled down). > > - Is there a better way to version the bindings to avoid complete > > backwards compatibility? > > Some architectures are using overlays for handling backward > compatibility. Anyway it might put additional effort on driver > development. In some cases it's pretty easy to stay backwards compatible by making sure that things like missing properties have the same defaults as they used to before the properties became mandatory. For complex subsystems it might be a different story, but that's also where it _might_ be worth looking at a new revision of the binding instead, this time maybe closer to a permanent one. > > Pointing out a couple of cases where it has been painful to stay > > backwards compatible could also be useful for understanding (even > > though you run the risk of
Re: [PATCH v3] dt-bindings: arm: Explicitly mark Samsung Exynos SoC as unstable
On Mon, Sep 24, 2018 at 07:16:45PM +0200, Krzysztof Kozlowski wrote: > On Sun, Sep 23, 2018 at 02:46:20PM +0100, Olof Johansson wrote: > > On Thu, Aug 30, 2018 at 7:02 PM, Krzysztof Kozlowski > > wrote: > > > Samsung Exynos SoCs and boards related bindings evolved since the initial > > > introduction, but initially the bindings were minimal and a bit incomplete > > > (they never described all the hardware modules available in the SoCs). > > > Since then some significant (not fully compatible) changes have been > > > already committed a few times (like gpio replaced by pinctrl, display ddc, > > > mfc reserved memory, some core clocks added to various hardware modules, > > > added more required nodes). > > > > > > On the other side there are no boards which have device tree embedded in > > > the bootloader. Device tree blob is always compiled from the kernel tree > > > and updated together with the kernel image. > > > > > > Thus to avoid further adding a bunch of workarounds for old/missing > > > bindings, make development of new platforms easier and allow to make > > > cleanup of the existing code and device tree files, lets mark some > > > Samsung Exynos SoC platform bindings as unstable. This means that > > > bindings can may change at any time and users should use the dtb file > > > compiled from the same kernel source tree as the kernel image. > > > > I have to admit that I don't really like this approach, and I missed > > the patch when originally posted (I did notice it in the pull request > > it came in with though). > > > > The main concern for me is that with a blanket "everything is always > > unstable" we discard the notion that we should strive for bindings to > > be stable and backwards compatible. > > The original idea from Marek was to mark everything unstable. After > comments from Rob I made it weaker already by changing to specific group > of compatibles. Accepting their instability does not mean that we will > be doing this on whenever possible. It just opens the possibility of > finding some balance in cleanups and development. Sometimes things have > to be seriously changed (fixed) and implementing workarounds for > existing ABI might be huge work by itself. > > IOW, we want stability but not with the costs of huge development > efforts... because no one else except us cares about the stability. I think it's really problematic to retroactively mark a binding as unstable. The best way to do it is probably at the time of introduction if you anticipate it needing adjustments down the road (i.e. if it's for a complex IP block). For major overhauls, it might be worth updating to a new binding instead (by appending a suffix to the name or similar, and documenting that). > > Questions that come to mind are: > > > > - When do they stop being unstable? > > They became unstable in a subjective way so I assume that reverse is the > same, based on consensus and discussions. > > I am not sure if a hard time limit is good. There is no timeline for the > Exynos development, no public roadmaps but rather community and > partially volountary effort. Therefore whatever number we set, it might > be totally not matching reality. I think that sets up for a pretty bad experience for some downstream users. The main problem with unstable bindings is if you have a platform that you haven't (yet) upstreamed the devicetrees for. Moving around base kernel versions in those cases can be really awkward. "Just upstream your devicetrees" is one counter-argument, but it's not always that easy -- it might be unreleased products or just some experimental platforms that might even be tracking fairly close to mainline during whatever development is ongoing. > > - Is there a way to note in the binding itself that it's still > > unstable with an anticipation of when it will be settled in? > > Hmm, I see that some existing bindings are being added with "Unstable" > warning: > > git grep -i unstable Documentation/devicetree/ > > so there should be no problem for putting there a timeframe. Yeah, adding them with unstable up front is a good way to do it (and then remove that warning once things have settled down). > > - Is there a better way to version the bindings to avoid complete > > backwards compatibility? > > Some architectures are using overlays for handling backward > compatibility. Anyway it might put additional effort on driver > development. In some cases it's pretty easy to stay backwards compatible by making sure that things like missing properties have the same defaults as they used to before the properties became mandatory. For complex subsystems it might be a different story, but that's also where it _might_ be worth looking at a new revision of the binding instead, this time maybe closer to a permanent one. > > Pointing out a couple of cases where it has been painful to stay > > backwards compatible could also be useful for understanding (even > > though you run the risk of
Re: [GIT PULL] ARM: dts: exynos: DT for v4.20 (or 5.0) (revised)
On Mon, Sep 24, 2018 at 07:21:33PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Pull request without ABI-stability patch. > > Best regards, > Krzysztof > > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-dt-4.20-2 > > for you to fetch changes up to ff1e37c6809daab75f7b2dea1efe69330e8eb65b: > > ARM: dts: exynos: Correct audio subsystem parent clock on Peach Chromebooks > (2018-09-24 18:55:16 +0200) > > > Samsung DTS ARM changes for v4.20 > > 1. Bring up DSI and HDMI on Exynos5250 Arndale. > 2. Use the new way of setting external wakeup interrupts on S5Pv210. > 3. Use proper cpufreq suspend OPP to fix suspend/wakeup from RAM on Snow >Chromebook (Exynos5250). > 4. Fully describe regualtors on Odroid XU3-family boards. > 5. Fix sound in Snow-rev5 Chromebook. > 6. Fix regulators configuration on Peach Pi/Pit Chromebooks (Exynos5420) >which should be always on. > 7. Fix pull control on PMIC interrupt lines on multiple boards which >essentially fixes waking up by RTC. > 8. Add PMIC interrupts on Exynos4210 UniversalC210 board. > 9. Add external SD card support for Trats board (Exynos4210). > 10. Correct audio subsystem parent clock on Peach Chromebooks. > 11. Minor cleanups. Merged, thanks! -Olof
Re: [GIT PULL 2/2] ARM: dts: exynos: DT for v4.20 (or 5.0)
On Mon, Sep 24, 2018 at 07:18:41PM +0200, Krzysztof Kozlowski wrote: > On Sun, Sep 23, 2018 at 06:47:42AM -0700, Olof Johansson wrote: > > Hi, > > > > On Fri, Sep 21, 2018 at 07:45:19PM +0200, Krzysztof Kozlowski wrote: > > > Hi, > > > > > > Nothing special, description in tag. > > > > Hmm. Point 12 is special, I'd say. > > > > I commented on the patch, and I don't want to hold everything else up so it > > might make sense to separate that out and send a fresh pull request with the > > base material while that part is discussed a bit more. > > I was thinking about any special merging care and effects. I did not > hide this point 12 as it received pretty big explanation. No worries. :) -Olof
Re: [GIT PULL] ARM: dts: exynos: DT for v4.20 (or 5.0) (revised)
On Mon, Sep 24, 2018 at 07:21:33PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Pull request without ABI-stability patch. > > Best regards, > Krzysztof > > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-dt-4.20-2 > > for you to fetch changes up to ff1e37c6809daab75f7b2dea1efe69330e8eb65b: > > ARM: dts: exynos: Correct audio subsystem parent clock on Peach Chromebooks > (2018-09-24 18:55:16 +0200) > > > Samsung DTS ARM changes for v4.20 > > 1. Bring up DSI and HDMI on Exynos5250 Arndale. > 2. Use the new way of setting external wakeup interrupts on S5Pv210. > 3. Use proper cpufreq suspend OPP to fix suspend/wakeup from RAM on Snow >Chromebook (Exynos5250). > 4. Fully describe regualtors on Odroid XU3-family boards. > 5. Fix sound in Snow-rev5 Chromebook. > 6. Fix regulators configuration on Peach Pi/Pit Chromebooks (Exynos5420) >which should be always on. > 7. Fix pull control on PMIC interrupt lines on multiple boards which >essentially fixes waking up by RTC. > 8. Add PMIC interrupts on Exynos4210 UniversalC210 board. > 9. Add external SD card support for Trats board (Exynos4210). > 10. Correct audio subsystem parent clock on Peach Chromebooks. > 11. Minor cleanups. Merged, thanks! -Olof
Re: [GIT PULL 2/2] ARM: dts: exynos: DT for v4.20 (or 5.0)
On Mon, Sep 24, 2018 at 07:18:41PM +0200, Krzysztof Kozlowski wrote: > On Sun, Sep 23, 2018 at 06:47:42AM -0700, Olof Johansson wrote: > > Hi, > > > > On Fri, Sep 21, 2018 at 07:45:19PM +0200, Krzysztof Kozlowski wrote: > > > Hi, > > > > > > Nothing special, description in tag. > > > > Hmm. Point 12 is special, I'd say. > > > > I commented on the patch, and I don't want to hold everything else up so it > > might make sense to separate that out and send a fresh pull request with the > > base material while that part is discussed a bit more. > > I was thinking about any special merging care and effects. I did not > hide this point 12 as it received pretty big explanation. No worries. :) -Olof
Re: [GIT PULL] ARM: at91: defconfig for 4.20
On Tue, Sep 25, 2018 at 12:53:44PM +0200, Alexandre Belloni wrote: > Arnd, Olof > > The addition of the generic ADC touchscreen driver can probably benefit > other architectures. Also add the sama5 I2S driver. > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux > tags/at91-4.20-defconfig > > for you to fetch changes up to 4eb2534057b1b01014a2b2bb6898d9934d2ba831: > > ARM: multi_v7_defconfig: add Atmel I2S driver (2018-08-30 22:19:32 +0200) > Merged, thanks! -Olof
Re: [GIT PULL] ARM: at91: defconfig for 4.20
On Tue, Sep 25, 2018 at 12:53:44PM +0200, Alexandre Belloni wrote: > Arnd, Olof > > The addition of the generic ADC touchscreen driver can probably benefit > other architectures. Also add the sama5 I2S driver. > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux > tags/at91-4.20-defconfig > > for you to fetch changes up to 4eb2534057b1b01014a2b2bb6898d9934d2ba831: > > ARM: multi_v7_defconfig: add Atmel I2S driver (2018-08-30 22:19:32 +0200) > Merged, thanks! -Olof
Re: [GIT PULL] ARM: at91: SoC for 4.20
On Tue, Sep 25, 2018 at 12:37:35PM +0200, Alexandre Belloni wrote: > Arnd, Olof, > > Most changes are shuffling around the maintainers entries. There are > also two PM non urgent fixes. > > This one as a trivial conflict with the staging tree solved in linux-next. > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-4.20-soc > > for you to fetch changes up to 34d2a7db77ad837cfb88bd01b33fd1f3855ce9c0: > > MAINTAINERS: sdhci: move the Microchip entry to proper location (2018-09-25 > 12:26:31 +0200) > > > AT91 SoC for 4.20 > > - rename MAINTAINERS entries and change maintainers > - two pm cleanups Merged, thanks. Welcome aboard as maintainer, Ludovic! -Olof
Re: [GIT PULL] ARM: at91: DT for 4.20
On Tue, Sep 25, 2018 at 12:42:26PM +0200, Alexandre Belloni wrote: > Arnd, Olof, > > Here are the DT changes for 4.20. Mostly cleanups and small additions. > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-4.20-dt > > for you to fetch changes up to 97181516b0785dd032700ae4899842389c6bea78: > > arm: dts: sama5d2: Update coresight bindings for hardware ports (2018-09-19 > 19:12:25 +0200) > > > AT91 DT for 4.20 > > - warning fiwes from Rob > - many updates for the axentia boards > - ADC, I2S and touch screen support for sama5d2 Merged, thanks! Tiny nit: > Suzuki K Poulose (1): > arm: dts: sama5d2: Update coresight bindings for hardware ports s/arm/ARM/ -Olof
Re: [GIT PULL] STi DT update for v4.20 round 1
On Tue, Sep 25, 2018 at 04:21:26PM +, Patrice CHOTARD wrote: > Hi Arnd, Kevin, Olof > > PLease consider this first round of STi dts update for v4.20 > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git > tags/sti-dt-for-v4.20-round1 > > for you to fetch changes up to b5b4c8dd5c44edc112a362f87a8d8953336571bd: > > ARM: dts: stih410: change syntax of multiple DAI (2018-09-25 17:41:51 > +0200) > > > STi DT update: > _ Change syntax of multiple DAI links Merged, thanks. -Olof
Re: [GIT PULL] ARM: at91: drivers for 4.20
On Tue, Sep 25, 2018 at 12:23:58PM +0200, Alexandre Belloni wrote: > Hi, > > A single trivial patch for at91 drivers. > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux > tags/at91-4.20-drivers > > for you to fetch changes up to f62df676d7f16580fa5085a8f51a1cbe27f7dd10: > > memory: atmel-ebi: Use struct_size() in devm_kzalloc() (2018-08-27 23:10:31 > +0200) > > > AT91 drivers for 4.20 > > - use struct_size in atmel-ebi Merged, thanks! -Olof
Re: [GIT PULL] ARM: at91: SoC for 4.20
On Tue, Sep 25, 2018 at 12:37:35PM +0200, Alexandre Belloni wrote: > Arnd, Olof, > > Most changes are shuffling around the maintainers entries. There are > also two PM non urgent fixes. > > This one as a trivial conflict with the staging tree solved in linux-next. > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-4.20-soc > > for you to fetch changes up to 34d2a7db77ad837cfb88bd01b33fd1f3855ce9c0: > > MAINTAINERS: sdhci: move the Microchip entry to proper location (2018-09-25 > 12:26:31 +0200) > > > AT91 SoC for 4.20 > > - rename MAINTAINERS entries and change maintainers > - two pm cleanups Merged, thanks. Welcome aboard as maintainer, Ludovic! -Olof
Re: [GIT PULL] ARM: at91: DT for 4.20
On Tue, Sep 25, 2018 at 12:42:26PM +0200, Alexandre Belloni wrote: > Arnd, Olof, > > Here are the DT changes for 4.20. Mostly cleanups and small additions. > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-4.20-dt > > for you to fetch changes up to 97181516b0785dd032700ae4899842389c6bea78: > > arm: dts: sama5d2: Update coresight bindings for hardware ports (2018-09-19 > 19:12:25 +0200) > > > AT91 DT for 4.20 > > - warning fiwes from Rob > - many updates for the axentia boards > - ADC, I2S and touch screen support for sama5d2 Merged, thanks! Tiny nit: > Suzuki K Poulose (1): > arm: dts: sama5d2: Update coresight bindings for hardware ports s/arm/ARM/ -Olof
Re: [GIT PULL] STi DT update for v4.20 round 1
On Tue, Sep 25, 2018 at 04:21:26PM +, Patrice CHOTARD wrote: > Hi Arnd, Kevin, Olof > > PLease consider this first round of STi dts update for v4.20 > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git > tags/sti-dt-for-v4.20-round1 > > for you to fetch changes up to b5b4c8dd5c44edc112a362f87a8d8953336571bd: > > ARM: dts: stih410: change syntax of multiple DAI (2018-09-25 17:41:51 > +0200) > > > STi DT update: > _ Change syntax of multiple DAI links Merged, thanks. -Olof
Re: [GIT PULL] ARM: at91: drivers for 4.20
On Tue, Sep 25, 2018 at 12:23:58PM +0200, Alexandre Belloni wrote: > Hi, > > A single trivial patch for at91 drivers. > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux > tags/at91-4.20-drivers > > for you to fetch changes up to f62df676d7f16580fa5085a8f51a1cbe27f7dd10: > > memory: atmel-ebi: Use struct_size() in devm_kzalloc() (2018-08-27 23:10:31 > +0200) > > > AT91 drivers for 4.20 > > - use struct_size in atmel-ebi Merged, thanks! -Olof
[PATCH] Allow hwrng to initialize crng.
Some systems, for example embedded systems, do not generate
enough entropy on boot through interrupts, and boot may be blocked for
several minutes waiting for a call to getrandom to complete.
Currently, random data is read from a hwrng when it is registered,
and is loaded into primary_crng. This data is treated in the same
way as data that is device-specific but otherwise unchanging, and
so primary_crng cannot become initialized with the data from the
hwrng.
This change causes the data initially read from the hwrng to be
treated the same as subsequent data that is read from the hwrng if
it's quality score is non-zero.
The implications of this are:
The data read from hwrng can cause primary_crng to become
initialized, therefore avoiding problems of getrandom blocking
on boot.
Calls to getrandom (with GRND_RANDOM) may be using entropy
exclusively (or in practise, almost exclusively) from the hwrng.
Regarding the latter point; this behavior is the same as if a
user specified a quality score of 1 (bit of entropy per 1024 bits)
so hopefully this is not too scary a change to make.
This change is the result of the discussion here:
https://patchwork.kernel.org/patch/10453893/
Signed-off-by: Louis Collard
---
drivers/char/hw_random/core.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aaf9e5afaad4..47f358aa0c3d 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define RNG_MODULE_NAME"hw_random"
@@ -64,13 +65,17 @@ static size_t rng_buffer_size(void)
static void add_early_randomness(struct hwrng *rng)
{
int bytes_read;
- size_t size = min_t(size_t, 16, rng_buffer_size());
+ /* Read enough to initialize crng. */
+ size_t size = 2*CHACHA20_KEY_SIZE;
mutex_lock(_mutex);
bytes_read = rng_get_data(rng, rng_buffer, size, 1);
mutex_unlock(_mutex);
if (bytes_read > 0)
- add_device_randomness(rng_buffer, bytes_read);
+ /* Allow crng to become initialized, but do not add
+* entropy to the pool.
+*/
+ add_hwgenerator_randomness(rng_buffer, bytes_read, 0);
}
static inline void cleanup_rng(struct kref *kref)
--
2.13.5
[PATCH] Allow hwrng to initialize crng.
Some systems, for example embedded systems, do not generate
enough entropy on boot through interrupts, and boot may be blocked for
several minutes waiting for a call to getrandom to complete.
Currently, random data is read from a hwrng when it is registered,
and is loaded into primary_crng. This data is treated in the same
way as data that is device-specific but otherwise unchanging, and
so primary_crng cannot become initialized with the data from the
hwrng.
This change causes the data initially read from the hwrng to be
treated the same as subsequent data that is read from the hwrng if
it's quality score is non-zero.
The implications of this are:
The data read from hwrng can cause primary_crng to become
initialized, therefore avoiding problems of getrandom blocking
on boot.
Calls to getrandom (with GRND_RANDOM) may be using entropy
exclusively (or in practise, almost exclusively) from the hwrng.
Regarding the latter point; this behavior is the same as if a
user specified a quality score of 1 (bit of entropy per 1024 bits)
so hopefully this is not too scary a change to make.
This change is the result of the discussion here:
https://patchwork.kernel.org/patch/10453893/
Signed-off-by: Louis Collard
---
drivers/char/hw_random/core.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aaf9e5afaad4..47f358aa0c3d 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define RNG_MODULE_NAME"hw_random"
@@ -64,13 +65,17 @@ static size_t rng_buffer_size(void)
static void add_early_randomness(struct hwrng *rng)
{
int bytes_read;
- size_t size = min_t(size_t, 16, rng_buffer_size());
+ /* Read enough to initialize crng. */
+ size_t size = 2*CHACHA20_KEY_SIZE;
mutex_lock(_mutex);
bytes_read = rng_get_data(rng, rng_buffer, size, 1);
mutex_unlock(_mutex);
if (bytes_read > 0)
- add_device_randomness(rng_buffer, bytes_read);
+ /* Allow crng to become initialized, but do not add
+* entropy to the pool.
+*/
+ add_hwgenerator_randomness(rng_buffer, bytes_read, 0);
}
static inline void cleanup_rng(struct kref *kref)
--
2.13.5
Re: [PATCH] parisc: Remove PTE load and fault check from L2_ptep macro
Hi, On Sun, Sep 23, 2018 at 10:55:18AM -0400, John David Anglin wrote: > This change removes the PTE load and present check from the L2_ptep > macro. The load and check for kernel pages is now done in the tlb_lock > macro. This avoids a double load and check for user pages. The load > and check for user pages is now done inside the lock so the fault > handler can't be called while the entry is being updated. > This patch causes my parisc qemu tests to fail. Unfortunately I don't have any useful log output; the failure is silent. Reverting the patch fixes the problem. Guenter > Signed-off-by: John David Anglin > Signed-off-by: Helge Deller > --- > arch/parisc/kernel/entry.S | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S > index 1d2c4b8e..3371472379a6 100644 > --- a/arch/parisc/kernel/entry.S > +++ b/arch/parisc/kernel/entry.S > @@ -431,8 +431,6 @@ > extru \va,31-PAGE_SHIFT,ASM_BITS_PER_PTE,\index > dep %r0,31,PAGE_SHIFT,\pmd /* clear offset */ > shladd \index,BITS_PER_PTE_ENTRY,\pmd,\pmd /* pmd is now pte */ > - LDREG %r0(\pmd),\pte > - bb,>=,n \pte,_PAGE_PRESENT_BIT,\fault > .endm > > /* Look up PTE in a 3-Level scheme. > @@ -463,7 +461,7 @@ > L2_ptep \pgd,\pte,\index,\va,\fault > .endm > > - /* Acquire pa_tlb_lock lock and recheck page is still present. */ > + /* Acquire pa_tlb_lock lock and check page is present. */ > .macro tlb_lockspc,ptp,pte,tmp,tmp1,fault > #ifdef CONFIG_SMP > cmpib,COND(=),n 0,\spc,2f > @@ -472,10 +470,12 @@ > cmpib,COND(=) 0,\tmp1,1b > nop > LDREG 0(\ptp),\pte > - bb,<,n \pte,_PAGE_PRESENT_BIT,2f > + bb,<,n \pte,_PAGE_PRESENT_BIT,3f > b \fault > stw \spc,0(\tmp) > -2: > +2: LDREG 0(\ptp),\pte > + bb,>=,n \pte,_PAGE_PRESENT_BIT,\fault > +3: > #endif > .endm > > -- > 2.7.4
Re: [PATCH] parisc: Remove PTE load and fault check from L2_ptep macro
Hi, On Sun, Sep 23, 2018 at 10:55:18AM -0400, John David Anglin wrote: > This change removes the PTE load and present check from the L2_ptep > macro. The load and check for kernel pages is now done in the tlb_lock > macro. This avoids a double load and check for user pages. The load > and check for user pages is now done inside the lock so the fault > handler can't be called while the entry is being updated. > This patch causes my parisc qemu tests to fail. Unfortunately I don't have any useful log output; the failure is silent. Reverting the patch fixes the problem. Guenter > Signed-off-by: John David Anglin > Signed-off-by: Helge Deller > --- > arch/parisc/kernel/entry.S | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S > index 1d2c4b8e..3371472379a6 100644 > --- a/arch/parisc/kernel/entry.S > +++ b/arch/parisc/kernel/entry.S > @@ -431,8 +431,6 @@ > extru \va,31-PAGE_SHIFT,ASM_BITS_PER_PTE,\index > dep %r0,31,PAGE_SHIFT,\pmd /* clear offset */ > shladd \index,BITS_PER_PTE_ENTRY,\pmd,\pmd /* pmd is now pte */ > - LDREG %r0(\pmd),\pte > - bb,>=,n \pte,_PAGE_PRESENT_BIT,\fault > .endm > > /* Look up PTE in a 3-Level scheme. > @@ -463,7 +461,7 @@ > L2_ptep \pgd,\pte,\index,\va,\fault > .endm > > - /* Acquire pa_tlb_lock lock and recheck page is still present. */ > + /* Acquire pa_tlb_lock lock and check page is present. */ > .macro tlb_lockspc,ptp,pte,tmp,tmp1,fault > #ifdef CONFIG_SMP > cmpib,COND(=),n 0,\spc,2f > @@ -472,10 +470,12 @@ > cmpib,COND(=) 0,\tmp1,1b > nop > LDREG 0(\ptp),\pte > - bb,<,n \pte,_PAGE_PRESENT_BIT,2f > + bb,<,n \pte,_PAGE_PRESENT_BIT,3f > b \fault > stw \spc,0(\tmp) > -2: > +2: LDREG 0(\ptp),\pte > + bb,>=,n \pte,_PAGE_PRESENT_BIT,\fault > +3: > #endif > .endm > > -- > 2.7.4
[PATCH V2] mm: Recheck page table entry with page table lock held
We clear the pte temporarily during read/modify/write update of the pte. If we
take a page fault while the pte is cleared, the application can get SIGBUS. One
such case is with remap_pfn_range without a backing vm_ops->fault callback.
do_fault will return SIGBUS in that case.
cpu 0 cpu1
mprotect()
ptep_modify_prot_start()/pte cleared.
.
. page fault.
.
.
prep_modify_prot_commit()
Fix this by taking page table lock and rechecking for pte_none.
Signed-off-by: Aneesh Kumar K.V
---
V1:
* update commit message.
mm/memory.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index c467102a5cbc..c2f933184303 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3745,10 +3745,33 @@ static vm_fault_t do_fault(struct vm_fault *vmf)
struct vm_area_struct *vma = vmf->vma;
vm_fault_t ret;
- /* The VMA was not fully populated on mmap() or missing VM_DONTEXPAND */
- if (!vma->vm_ops->fault)
- ret = VM_FAULT_SIGBUS;
- else if (!(vmf->flags & FAULT_FLAG_WRITE))
+ /*
+* The VMA was not fully populated on mmap() or missing VM_DONTEXPAND
+*/
+ if (!vma->vm_ops->fault) {
+
+ /*
+* pmd entries won't be marked none during a R/M/W cycle.
+*/
+ if (unlikely(pmd_none(*vmf->pmd)))
+ ret = VM_FAULT_SIGBUS;
+ else {
+ vmf->ptl = pte_lockptr(vmf->vma->vm_mm, vmf->pmd);
+ /*
+* Make sure this is not a temporary clearing of pte
+* by holding ptl and checking again. A R/M/W update
+* of pte involves: take ptl, clearing the pte so that
+* we don't have concurrent modification by hardware
+* followed by an update.
+*/
+ spin_lock(vmf->ptl);
+ if (unlikely(pte_none(*vmf->pte)))
+ ret = VM_FAULT_SIGBUS;
+ else
+ ret = VM_FAULT_NOPAGE;
+ spin_unlock(vmf->ptl);
+ }
+ } else if (!(vmf->flags & FAULT_FLAG_WRITE))
ret = do_read_fault(vmf);
else if (!(vma->vm_flags & VM_SHARED))
ret = do_cow_fault(vmf);
--
2.17.1
[PATCH V2] mm: Recheck page table entry with page table lock held
We clear the pte temporarily during read/modify/write update of the pte. If we
take a page fault while the pte is cleared, the application can get SIGBUS. One
such case is with remap_pfn_range without a backing vm_ops->fault callback.
do_fault will return SIGBUS in that case.
cpu 0 cpu1
mprotect()
ptep_modify_prot_start()/pte cleared.
.
. page fault.
.
.
prep_modify_prot_commit()
Fix this by taking page table lock and rechecking for pte_none.
Signed-off-by: Aneesh Kumar K.V
---
V1:
* update commit message.
mm/memory.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index c467102a5cbc..c2f933184303 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3745,10 +3745,33 @@ static vm_fault_t do_fault(struct vm_fault *vmf)
struct vm_area_struct *vma = vmf->vma;
vm_fault_t ret;
- /* The VMA was not fully populated on mmap() or missing VM_DONTEXPAND */
- if (!vma->vm_ops->fault)
- ret = VM_FAULT_SIGBUS;
- else if (!(vmf->flags & FAULT_FLAG_WRITE))
+ /*
+* The VMA was not fully populated on mmap() or missing VM_DONTEXPAND
+*/
+ if (!vma->vm_ops->fault) {
+
+ /*
+* pmd entries won't be marked none during a R/M/W cycle.
+*/
+ if (unlikely(pmd_none(*vmf->pmd)))
+ ret = VM_FAULT_SIGBUS;
+ else {
+ vmf->ptl = pte_lockptr(vmf->vma->vm_mm, vmf->pmd);
+ /*
+* Make sure this is not a temporary clearing of pte
+* by holding ptl and checking again. A R/M/W update
+* of pte involves: take ptl, clearing the pte so that
+* we don't have concurrent modification by hardware
+* followed by an update.
+*/
+ spin_lock(vmf->ptl);
+ if (unlikely(pte_none(*vmf->pte)))
+ ret = VM_FAULT_SIGBUS;
+ else
+ ret = VM_FAULT_NOPAGE;
+ spin_unlock(vmf->ptl);
+ }
+ } else if (!(vmf->flags & FAULT_FLAG_WRITE))
ret = do_read_fault(vmf);
else if (!(vma->vm_flags & VM_SHARED))
ret = do_cow_fault(vmf);
--
2.17.1
[PATCHv2] misc: genwqe: remove duplicated include and order header files alphabetically in card_utils.c
dma-mapping.h and delay.h have included twice. It is unnecessary. Meanwhile, Arrange header files in alphabetical sequence to improve readability. Signed-off-by: zhong jiang --- drivers/misc/genwqe/card_utils.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/misc/genwqe/card_utils.c b/drivers/misc/genwqe/card_utils.c index 8679e0b..994e8fa 100644 --- a/drivers/misc/genwqe/card_utils.c +++ b/drivers/misc/genwqe/card_utils.c @@ -22,26 +22,24 @@ * Miscelanous functionality used in the other GenWQE driver parts. */ -#include +#include +#include +#include #include -#include -#include -#include -#include #include #include -#include -#include -#include -#include +#include #include +#include +#include #include -#include -#include +#include +#include +#include -#include "genwqe_driver.h" #include "card_base.h" #include "card_ddcb.h" +#include "genwqe_driver.h" /** * __genwqe_writeq() - Write 64-bit register -- 1.7.12.4
[PATCHv2] misc: genwqe: remove duplicated include and order header files alphabetically in card_utils.c
dma-mapping.h and delay.h have included twice. It is unnecessary. Meanwhile, Arrange header files in alphabetical sequence to improve readability. Signed-off-by: zhong jiang --- drivers/misc/genwqe/card_utils.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/misc/genwqe/card_utils.c b/drivers/misc/genwqe/card_utils.c index 8679e0b..994e8fa 100644 --- a/drivers/misc/genwqe/card_utils.c +++ b/drivers/misc/genwqe/card_utils.c @@ -22,26 +22,24 @@ * Miscelanous functionality used in the other GenWQE driver parts. */ -#include +#include +#include +#include #include -#include -#include -#include -#include #include #include -#include -#include -#include -#include +#include #include +#include +#include #include -#include -#include +#include +#include +#include -#include "genwqe_driver.h" #include "card_base.h" #include "card_ddcb.h" +#include "genwqe_driver.h" /** * __genwqe_writeq() - Write 64-bit register -- 1.7.12.4
Re: Leaking path for set_task_comm
On Tue, Sep 25, 2018 at 08:44:39PM -0400, TongZhang wrote: > Yes, this is exactly what I am saying. > A process can change its own name using prctl or /proc/self/comm. > prctl is protected by security_task_prctl, whereas /proc/self/comm is not > protected by this LSM hook. > > A system admin may expect to use security_task_prctl to block all attempt to > change process name, however, it can still change name using /proc/self/comm. None of the in-tree LSM's try to affect PR_SET_NAME. Looking at security/commoncap.c, it's clear what is of interest is to checking things relating to security sensitive things relating to capabilities, such as: PR_SET_SECUREBITS PR_CAPBSET_* PR_*_SECUREBITS PR_*_KEEPCAPS PR_CAP_AMBIENT Trying to depend on task name for anything security sensitive is at _really_ bad idea, so it seems unlikely that a LSM would want to protect the process name. (And if they did, the first thing I would ask is "Why? What are you trying to do? Do you realize how many *other* ways the process name can be spoofed or otherwise controlled by a potentially malicious user?") - Ted
Re: Leaking path for set_task_comm
On Tue, Sep 25, 2018 at 08:44:39PM -0400, TongZhang wrote: > Yes, this is exactly what I am saying. > A process can change its own name using prctl or /proc/self/comm. > prctl is protected by security_task_prctl, whereas /proc/self/comm is not > protected by this LSM hook. > > A system admin may expect to use security_task_prctl to block all attempt to > change process name, however, it can still change name using /proc/self/comm. None of the in-tree LSM's try to affect PR_SET_NAME. Looking at security/commoncap.c, it's clear what is of interest is to checking things relating to security sensitive things relating to capabilities, such as: PR_SET_SECUREBITS PR_CAPBSET_* PR_*_SECUREBITS PR_*_KEEPCAPS PR_CAP_AMBIENT Trying to depend on task name for anything security sensitive is at _really_ bad idea, so it seems unlikely that a LSM would want to protect the process name. (And if they did, the first thing I would ask is "Why? What are you trying to do? Do you realize how many *other* ways the process name can be spoofed or otherwise controlled by a potentially malicious user?") - Ted
Re: [PATCH v12 1/2] leds: core: Introduce LED pattern trigger
On 26 September 2018 at 04:00, Jacek Anaszewski
wrote:
> Hi Baolin,
>
> On 09/25/2018 01:15 PM, Baolin Wang wrote:
>> On 23 September 2018 at 20:25, Jacek Anaszewski
>> wrote:
>>> On 09/22/2018 09:44 PM, Pavel Machek wrote:
On Sat 2018-09-22 00:18:13, Pavel Machek wrote:
> On Sat 2018-09-22 00:11:29, Jacek Anaszewski wrote:
>> On 09/21/2018 11:17 PM, Pavel Machek wrote:
>>> On Fri 2018-09-21 22:59:40, Jacek Anaszewski wrote:
Hi Baolin,
On 09/21/2018 05:31 AM, Baolin Wang wrote:
> Hi Jacek and Pavel,
>
> On 11 September 2018 at 10:47, Baolin Wang
> wrote:
>> This patch adds one new led trigger that LED device can configure
>> the software or hardware pattern and trigger it.
>>
>> Consumers can write 'pattern' file to enable the software pattern
>> which alters the brightness for the specified duration with one
>> software timer.
>>
>> Moreover consumers can write 'hw_pattern' file to enable the hardware
>> pattern for some LED controllers which can autonomously control
>> brightness over time, according to some preprogrammed hardware
>> patterns.
>>
>> Signed-off-by: Raphael Teysseyre
>> Signed-off-by: Baolin Wang
>>>
> Do you have any comments for the v12 patch set? Thanks.
We will probably have to remove hw_pattern from ledtrig-pattern
since we are unable to come up with generic interface for it.
Unless thread [0] will end up with some brilliant ideas. So far
we're waiting for Pavel's reply.
[0] https://lkml.org/lkml/2018/9/13/1216
>>>
>>> To paint a picture:
>>>
>>> brightness
>>>
>>>rise hold lower hold down
>>> ^XXX
>>> | X XX
>>> | X XX
>>> | X XX
>>> +---> time
>>>
>>> This is what Baolin's hardware can do, right?
>>>
>>> This is also what pattern trigger can do, right?
>>>
>>> So all we need to do is match the two interfaces, so that hw_pattern
>>> returns -EINVAL on patterns hardware can not actually do.
>>>
>>> I believe I described code to do that in [0] above.
>>
>> You said that we should get the same effect by writing the
>> same series of tuples to either pattern or hw_pattern file.
>>
>> Below command consists of four tuples (marked with brackets
>> to highlight), and it will activate breathing mode in Baolin's
>> hw_pattern:
>>
>> "[0 rise_duration] [brightness high_duration] [brightness fall_duration]
>> [0 low_duration]"
>>
>> Now, I can't see how these four tuples could force the software
>> fallback to produce breathing effect you depicted.
>
> I really should get some sleep now. But my intention was that software
> fallback produces just that with those four tuples. (If it does not,
> we can fix the software fallback to do just that).
And you are right, v12 1/2 seems to do the wrong thing.
My "brilliant idea" is to something closer to the original version I
posted here. I'm attaching it for reference.
I'm also attaching the original documentation. It was clearly designed
to do smooth transitions, too. (But pattern is written in slightly
different way there, AFAICT).
Clearly, having same semantics for pattern and hw_pattern is possible.
>>>
>>> Thank you for the attachment. The documentation part makes everything
>>> clear. Comparing the patch from the attachment and the Baolin's patch
>>> there is one vital part missing, from the original
>>> pattern_trig_update():
>>>
>>> if (data->next->brightness == data->curr->brightness) {
>>> [...]
>>> } else {
>>> /* Gradual dimming */
>>> led_set_brightness(data->led_cdev, compute_brightness(data));
>>> data->delta_t += UPDATE_INTERVAL;
>>> mod_timer(>timer, jiffies
>>> + msecs_to_jiffies(UPDATE_INTERVAL));
>>> }
>>
>> I have some confusions about this, if data->next->brightness !=
>> data->curr->brightness, we should always do gradual dimming? But
>> suppose below pattan values:
>> echo "0 100 20 100 40 100 80 100 100 100" > patter
> ledtrig-pattern.txt attached by Pavel explains this:
>
> "To make the LED go instantly from one brightness value to another,
> use zero-time lengths."
>
> Actually you have it also:
> "Duration of 0 means brightness should immediately change to new value"
>
> According to this, to get instant changes your pattern should look
> like this:
>
> echo "0 100 0 0 20 100 20 0 40 100 40 0 80 100 80 0 100 100" > pattern
Make sense. Thanks for your explanation.
>
>> I do not want to do gradual dimming, just change the brightness with
>>
Re: [PATCH v12 1/2] leds: core: Introduce LED pattern trigger
On 26 September 2018 at 04:00, Jacek Anaszewski
wrote:
> Hi Baolin,
>
> On 09/25/2018 01:15 PM, Baolin Wang wrote:
>> On 23 September 2018 at 20:25, Jacek Anaszewski
>> wrote:
>>> On 09/22/2018 09:44 PM, Pavel Machek wrote:
On Sat 2018-09-22 00:18:13, Pavel Machek wrote:
> On Sat 2018-09-22 00:11:29, Jacek Anaszewski wrote:
>> On 09/21/2018 11:17 PM, Pavel Machek wrote:
>>> On Fri 2018-09-21 22:59:40, Jacek Anaszewski wrote:
Hi Baolin,
On 09/21/2018 05:31 AM, Baolin Wang wrote:
> Hi Jacek and Pavel,
>
> On 11 September 2018 at 10:47, Baolin Wang
> wrote:
>> This patch adds one new led trigger that LED device can configure
>> the software or hardware pattern and trigger it.
>>
>> Consumers can write 'pattern' file to enable the software pattern
>> which alters the brightness for the specified duration with one
>> software timer.
>>
>> Moreover consumers can write 'hw_pattern' file to enable the hardware
>> pattern for some LED controllers which can autonomously control
>> brightness over time, according to some preprogrammed hardware
>> patterns.
>>
>> Signed-off-by: Raphael Teysseyre
>> Signed-off-by: Baolin Wang
>>>
> Do you have any comments for the v12 patch set? Thanks.
We will probably have to remove hw_pattern from ledtrig-pattern
since we are unable to come up with generic interface for it.
Unless thread [0] will end up with some brilliant ideas. So far
we're waiting for Pavel's reply.
[0] https://lkml.org/lkml/2018/9/13/1216
>>>
>>> To paint a picture:
>>>
>>> brightness
>>>
>>>rise hold lower hold down
>>> ^XXX
>>> | X XX
>>> | X XX
>>> | X XX
>>> +---> time
>>>
>>> This is what Baolin's hardware can do, right?
>>>
>>> This is also what pattern trigger can do, right?
>>>
>>> So all we need to do is match the two interfaces, so that hw_pattern
>>> returns -EINVAL on patterns hardware can not actually do.
>>>
>>> I believe I described code to do that in [0] above.
>>
>> You said that we should get the same effect by writing the
>> same series of tuples to either pattern or hw_pattern file.
>>
>> Below command consists of four tuples (marked with brackets
>> to highlight), and it will activate breathing mode in Baolin's
>> hw_pattern:
>>
>> "[0 rise_duration] [brightness high_duration] [brightness fall_duration]
>> [0 low_duration]"
>>
>> Now, I can't see how these four tuples could force the software
>> fallback to produce breathing effect you depicted.
>
> I really should get some sleep now. But my intention was that software
> fallback produces just that with those four tuples. (If it does not,
> we can fix the software fallback to do just that).
And you are right, v12 1/2 seems to do the wrong thing.
My "brilliant idea" is to something closer to the original version I
posted here. I'm attaching it for reference.
I'm also attaching the original documentation. It was clearly designed
to do smooth transitions, too. (But pattern is written in slightly
different way there, AFAICT).
Clearly, having same semantics for pattern and hw_pattern is possible.
>>>
>>> Thank you for the attachment. The documentation part makes everything
>>> clear. Comparing the patch from the attachment and the Baolin's patch
>>> there is one vital part missing, from the original
>>> pattern_trig_update():
>>>
>>> if (data->next->brightness == data->curr->brightness) {
>>> [...]
>>> } else {
>>> /* Gradual dimming */
>>> led_set_brightness(data->led_cdev, compute_brightness(data));
>>> data->delta_t += UPDATE_INTERVAL;
>>> mod_timer(>timer, jiffies
>>> + msecs_to_jiffies(UPDATE_INTERVAL));
>>> }
>>
>> I have some confusions about this, if data->next->brightness !=
>> data->curr->brightness, we should always do gradual dimming? But
>> suppose below pattan values:
>> echo "0 100 20 100 40 100 80 100 100 100" > patter
> ledtrig-pattern.txt attached by Pavel explains this:
>
> "To make the LED go instantly from one brightness value to another,
> use zero-time lengths."
>
> Actually you have it also:
> "Duration of 0 means brightness should immediately change to new value"
>
> According to this, to get instant changes your pattern should look
> like this:
>
> echo "0 100 0 0 20 100 20 0 40 100 40 0 80 100 80 0 100 100" > pattern
Make sense. Thanks for your explanation.
>
>> I do not want to do gradual dimming, just change the brightness with
>>
Re: [PATCH 4.14 000/173] 4.14.72-stable review
Greg, > > > This is the start of the stable review cycle for the 4.14.72 release. > > > There are 173 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Wed Sep 26 11:30:10 UTC 2018. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.72-rc1.gz > > > or in the git tree and branch at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > linux-4.14.y > > > and the diffstat can be found below. > > > > -rc2 is out to resolve some reported problems: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.72-rc2.gz > > -rc2 looks good. There is a problem on dragonboard during boot that was > introduced in v4.14.71 that I didn't notice last week. We'll bisect it > and report back later this week. dragonboard on the other branches (4.9, > 4.18, mainline) looks fine. As Dan pointed out, during validation, we have bisected this issue on a dragonboard 410c (can't find root device) to the following commit for v4.14: [1ed3a9307230] rpmsg: core: add support to power domains for devices There is an on-going discussion on "[PATCH] rpmsg: core: add support to power domains for devices" about this patch having other dependencies and breaking something else on v4.14 as well. Do you think we could drop this patch, for now, in a possible -rc3 for v4.14.72 ? Dragonboards aren't being tested, because of this, since v4.14.70. Hopefully it isn't too late for this release =). BTW, I have just tested removing the commit from -rc2 and the board boots okay. Thank you -Rafael
Re: [PATCH 4.14 000/173] 4.14.72-stable review
Greg, > > > This is the start of the stable review cycle for the 4.14.72 release. > > > There are 173 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Wed Sep 26 11:30:10 UTC 2018. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.72-rc1.gz > > > or in the git tree and branch at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > linux-4.14.y > > > and the diffstat can be found below. > > > > -rc2 is out to resolve some reported problems: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.72-rc2.gz > > -rc2 looks good. There is a problem on dragonboard during boot that was > introduced in v4.14.71 that I didn't notice last week. We'll bisect it > and report back later this week. dragonboard on the other branches (4.9, > 4.18, mainline) looks fine. As Dan pointed out, during validation, we have bisected this issue on a dragonboard 410c (can't find root device) to the following commit for v4.14: [1ed3a9307230] rpmsg: core: add support to power domains for devices There is an on-going discussion on "[PATCH] rpmsg: core: add support to power domains for devices" about this patch having other dependencies and breaking something else on v4.14 as well. Do you think we could drop this patch, for now, in a possible -rc3 for v4.14.72 ? Dragonboards aren't being tested, because of this, since v4.14.70. Hopefully it isn't too late for this release =). BTW, I have just tested removing the commit from -rc2 and the board boots okay. Thank you -Rafael
[PATCH v2 2/4] power: supply: core: Introduce properties to present the battery OCV table
Some battery driver will use the open circuit voltage (OCV) value to look
up the corresponding battery capacity percent in one certain degree Celsius.
Thus this patch provides some battery properties to present the OCV table
temperatures and OCV capacity table values.
Suggested-by: Sebastian Reichel
Signed-off-by: Baolin Wang
---
Changes from v1:
- New patch in v2.
---
.../devicetree/bindings/power/supply/battery.txt | 14 +
drivers/power/supply/power_supply_core.c | 63 +++-
include/linux/power_supply.h | 11
3 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt
b/Documentation/devicetree/bindings/power/supply/battery.txt
index 25b9d2e..ac2b303 100644
--- a/Documentation/devicetree/bindings/power/supply/battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/battery.txt
@@ -23,6 +23,16 @@ Optional Properties:
- constant-charge-current-max-microamp: maximum constant input current
- constant-charge-voltage-max-microvolt: maximum constant input voltage
- internal-resistance-micro-ohms: battery internal resistance
+ - ocv-capacity-table-0: An array providing the battery capacity percent
+ with corresponding open circuit voltage (OCV) of the battery, which
+ is used to look up battery capacity according to current OCV value.
+ - ocv-capacity-table-1: Same as ocv-capacity-table-0
+ ..
+ - ocv-capacity-table-n: Same as ocv-capacity-table-0
+ - ocv-capacity-table-temperatures: An array containing the temperature
+ in degree Celsius, for each of the battery capacity lookup table.
+ The first temperature value specifies the OCV table 0, and the second
+ temperature value specifies the OCV table 1, and so on.
Battery properties are named, where possible, for the corresponding
elements in enum power_supply_property, defined in
@@ -44,6 +54,10 @@ Example:
constant-charge-current-max-microamp = <90>;
constant-charge-voltage-max-microvolt = <420>;
internal-resistance-micro-ohms = <25>;
+ ocv-capacity-table-temperatures = <(-10) 0 10>;
+ ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000
90>, ...;
+ ocv-capacity-table-1 = <420 100>, <4185000 95>, <4113000
90>, ...;
+ ocv-capacity-table-2 = <425 100>, <420 95>, <4185000
90>, ...;
};
charger: charger@11 {
diff --git a/drivers/power/supply/power_supply_core.c
b/drivers/power/supply/power_supply_core.c
index 9f3452f..151ff03 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -570,7 +570,7 @@ int power_supply_get_battery_info(struct power_supply *psy,
{
struct device_node *battery_np;
const char *value;
- int err;
+ int err, len, index;
info->energy_full_design_uwh = -EINVAL;
info->charge_full_design_uah = -EINVAL;
@@ -581,6 +581,12 @@ int power_supply_get_battery_info(struct power_supply *psy,
info->constant_charge_voltage_max_uv = -EINVAL;
info->internal_resistance_uohm = -EINVAL;
+ for (index = 0; index < POWER_SUPPLY_OCV_TEMP_MAX; index++) {
+ info->ocv_table[index] = NULL;
+ info->ocv_temp[index]= -EINVAL;
+ info->ocv_table_size[index] = -EINVAL;
+ }
+
if (!psy->of_node) {
dev_warn(>dev, "%s currently only supports devicetree\n",
__func__);
@@ -620,10 +626,65 @@ int power_supply_get_battery_info(struct power_supply
*psy,
of_property_read_u32(battery_np, "internal-resistance-micro-ohms",
>internal_resistance_uohm);
+ len = of_property_count_u32_elems(battery_np,
+ "ocv-capacity-table-temperatures");
+ if (len < 0 && len != -EINVAL) {
+ return len;
+ } else if (len > POWER_SUPPLY_OCV_TEMP_MAX) {
+ dev_err(>dev, "Too many temperature values\n");
+ return -EINVAL;
+ } else if (len > 0) {
+ of_property_read_u32_array(battery_np,
+ "ocv-capacity-table-temperatures",
+ info->ocv_temp, len);
+ }
+
+ for (index = 0; index < len; index++) {
+ struct power_supply_battery_ocv_table *table;
+ char *propname;
+ const __be32 *list;
+ int i, tab_len, size;
+
+ propname = kasprintf(GFP_KERNEL, "ocv-capacity-table-%d",
index);
+ list = of_get_property(battery_np, propname, );
+ kfree(propname);
+ if (!list || !size) {
+ dev_err(>dev, "failed to get ocv capacity
table\n");
+
[PATCH v2 3/4] dt-bindings: power: Add Spreadtrum SC27XX fuel gauge unit documentation
This patch adds the binding documentation for Spreadtrum SC27XX series PMICs
fuel gauge unit device, which is used to calculate the battery capacity.
Signed-off-by: Baolin Wang
---
Changes from v1:
- Renamed GPIO property.
- Use standand battery properties instead of 'sprd,inner-resist' and
'sprd,ocv-cap-table'.
- Remove battery node's description.
---
.../devicetree/bindings/power/supply/sc27xx-fg.txt | 52
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/sc27xx-fg.txt
diff --git a/Documentation/devicetree/bindings/power/supply/sc27xx-fg.txt
b/Documentation/devicetree/bindings/power/supply/sc27xx-fg.txt
new file mode 100644
index 000..b161468
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/sc27xx-fg.txt
@@ -0,0 +1,52 @@
+Spreadtrum SC27XX PMICs Fuel Gauge Unit Power Supply Bindings
+
+Required properties:
+- compatible: Should be one of the following:
+ "sprd,sc2720-fgu",
+ "sprd,sc2721-fgu",
+ "sprd,sc2723-fgu",
+ "sprd,sc2730-fgu",
+ "sprd,sc2731-fgu".
+- reg: The address offset of fuel gauge unit.
+- battery-detect-gpios: GPIO for battery detection.
+- io-channels: Specify the IIO ADC channel to get temperature.
+- io-channel-names: Should be "bat-temp".
+- monitored-battery: Phandle of battery characteristics devicetree node.
+ See Documentation/devicetree/bindings/power/supply/battery.txt
+
+Example:
+
+ bat: battery {
+ compatible = "simple-battery";
+ charge-full-design-microamp-hours = <190>;
+ constant-charge-voltage-max-microvolt = <435>;
+ ocv-capacity-table-temperatures = <20>;
+ ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000
90>,
+ <4022000 85>, <3983000 80>, <3949000
75>,
+ <3917000 70>, <3889000 65>, <3864000
60>,
+ <3835000 55>, <3805000 50>, <3787000
45>,
+ <3777000 40>, <3773000 35>, <377
30>,
+ <3765000 25>, <3752000 20>, <3724000
15>,
+ <368 10>, <3605000 5>, <340 0>;
+ ..
+ };
+
+ sc2731_pmic: pmic@0 {
+ compatible = "sprd,sc2731";
+ reg = <0>;
+ spi-max-frequency = <2600>;
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fgu@a00 {
+ compatible = "sprd,sc2731-fgu";
+ reg = <0xa00>;
+ battery-detect-gpios = <_eic 9 GPIO_ACTIVE_HIGH>;
+ io-channels = <_adc 5>;
+ io-channel-names = "bat-temp";
+ monitored-battery = <>;
+ };
+ };
--
1.7.9.5
[PATCH v2 4/4] power: supply: Add Spreadtrum SC27XX fuel gauge unit driver
This patch adds the Spreadtrum SC27XX serial PMICs fuel gauge support,
which is used to calculate the battery capacity.
Original-by: Yuanjiang Yu
Signed-off-by: Baolin Wang
---
Changes from v1:
- Use battery standard properties to get internal resistance and ocv table.
- Change devm_gpiod_get_optional() to devm_gpiod_get().
- Add power_supply_changed() when detecting battery present change.
- Return micro volts for sc27xx_fgu_get_vbat_ocv().
---
drivers/power/supply/Kconfig |7 +
drivers/power/supply/Makefile|1 +
drivers/power/supply/sc27xx_fuel_gauge.c | 691 ++
3 files changed, 699 insertions(+)
create mode 100644 drivers/power/supply/sc27xx_fuel_gauge.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index f27cf07..917f4b7 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -652,4 +652,11 @@ config CHARGER_SC2731
Say Y here to enable support for battery charging with SC2731
PMIC chips.
+config FUEL_GAUGE_SC27XX
+ tristate "Spreadtrum SC27XX fuel gauge driver"
+ depends on MFD_SC27XX_PMIC || COMPILE_TEST
+ help
+Say Y here to enable support for fuel gauge with SC27XX
+PMIC chips.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 767105b..b731c2a 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -86,3 +86,4 @@ obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
obj-$(CONFIG_CHARGER_CROS_USBPD) += cros_usbpd-charger.o
obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o
+obj-$(CONFIG_FUEL_GAUGE_SC27XX)+= sc27xx_fuel_gauge.o
diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c
b/drivers/power/supply/sc27xx_fuel_gauge.c
new file mode 100644
index 000..d3422cf
--- /dev/null
+++ b/drivers/power/supply/sc27xx_fuel_gauge.c
@@ -0,0 +1,691 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Spreadtrum Communications Inc.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PMIC global control registers definition */
+#define SC27XX_MODULE_EN0 0xc08
+#define SC27XX_CLK_EN0 0xc18
+#define SC27XX_FGU_EN BIT(7)
+#define SC27XX_FGU_RTC_EN BIT(6)
+
+/* FGU registers definition */
+#define SC27XX_FGU_START 0x0
+#define SC27XX_FGU_CONFIG 0x4
+#define SC27XX_FGU_ADC_CONFIG 0x8
+#define SC27XX_FGU_STATUS 0xc
+#define SC27XX_FGU_INT_EN 0x10
+#define SC27XX_FGU_INT_CLR 0x14
+#define SC27XX_FGU_INT_STS 0x1c
+#define SC27XX_FGU_VOLTAGE 0x20
+#define SC27XX_FGU_OCV 0x24
+#define SC27XX_FGU_POCV0x28
+#define SC27XX_FGU_CURRENT 0x2c
+#define SC27XX_FGU_CLBCNT_SETH 0x50
+#define SC27XX_FGU_CLBCNT_SETL 0x54
+#define SC27XX_FGU_CLBCNT_VALH 0x68
+#define SC27XX_FGU_CLBCNT_VALL 0x6c
+#define SC27XX_FGU_CLBCNT_QMAXL0x74
+
+#define SC27XX_WRITE_SELCLB_EN BIT(0)
+#define SC27XX_FGU_CLBCNT_MASK GENMASK(15, 0)
+#define SC27XX_FGU_CLBCNT_SHIFT16
+
+#define SC27XX_FGU_1000MV_ADC 686
+#define SC27XX_FGU_1000MA_ADC 1372
+#define SC27XX_FGU_CUR_BASIC_ADC 8192
+#define SC27XX_FGU_SAMPLE_HZ 2
+
+/*
+ * struct sc27xx_fgu_data: describe the FGU device
+ * @regmap: regmap for register access
+ * @dev: platform device
+ * @battery: battery power supply
+ * @base: the base offset for the controller
+ * @lock: protect the structure
+ * @gpiod: GPIO for battery detection
+ * @channel: IIO channel to get battery temperature
+ * @internal_resist: the battery internal resistance in mOhm
+ * @total_cap: the total capacity of the battery in mAh
+ * @init_cap: the initial capacity of the battery in mAh
+ * @init_clbcnt: the initial coulomb counter
+ * @max_volt: the maximum constant input voltage in millivolt
+ * @table_len: the capacity table length
+ * @cap_table: capacity table with corresponding ocv
+ */
+struct sc27xx_fgu_data {
+ struct regmap *regmap;
+ struct device *dev;
+ struct power_supply *battery;
+ u32 base;
+ struct mutex lock;
+ struct gpio_desc *gpiod;
+ struct iio_channel *channel;
+ bool bat_present;
+ int internal_resist;
+ int total_cap;
+ int init_cap;
+ int init_clbcnt;
+ int max_volt;
+ int table_len;
+ struct power_supply_battery_ocv_table *cap_table;
+};
+
+static const char * const sc27xx_charger_supply_name[] = {
+ "sc2731_charger",
+ "sc2720_charger",
+ "sc2721_charger",
+ "sc2723_charger",
+};
+
+static int sc27xx_fgu_adc_to_current(int adc)
+{
+ return (adc * 1000) / SC27XX_FGU_1000MA_ADC;
+}
+
[PATCH v2 1/4] power: supply: core: Introduce one property to present the battery internal resistance
Introduce one property to present the battery internal resistance for battery
information.
Signed-off-by: Baolin Wang
---
Changes from v1:
- New patch in v2.
---
.../devicetree/bindings/power/supply/battery.txt |2 ++
drivers/power/supply/power_supply_core.c |3 +++
include/linux/power_supply.h |1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt
b/Documentation/devicetree/bindings/power/supply/battery.txt
index f4d3b4a..25b9d2e 100644
--- a/Documentation/devicetree/bindings/power/supply/battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/battery.txt
@@ -22,6 +22,7 @@ Optional Properties:
- charge-term-current-microamp: current for charge termination phase
- constant-charge-current-max-microamp: maximum constant input current
- constant-charge-voltage-max-microvolt: maximum constant input voltage
+ - internal-resistance-micro-ohms: battery internal resistance
Battery properties are named, where possible, for the corresponding
elements in enum power_supply_property, defined in
@@ -42,6 +43,7 @@ Example:
charge-term-current-microamp = <128000>;
constant-charge-current-max-microamp = <90>;
constant-charge-voltage-max-microvolt = <420>;
+ internal-resistance-micro-ohms = <25>;
};
charger: charger@11 {
diff --git a/drivers/power/supply/power_supply_core.c
b/drivers/power/supply/power_supply_core.c
index e853618..9f3452f 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -579,6 +579,7 @@ int power_supply_get_battery_info(struct power_supply *psy,
info->charge_term_current_ua = -EINVAL;
info->constant_charge_current_max_ua = -EINVAL;
info->constant_charge_voltage_max_uv = -EINVAL;
+ info->internal_resistance_uohm = -EINVAL;
if (!psy->of_node) {
dev_warn(>dev, "%s currently only supports devicetree\n",
@@ -616,6 +617,8 @@ int power_supply_get_battery_info(struct power_supply *psy,
>constant_charge_current_max_ua);
of_property_read_u32(battery_np,
"constant_charge_voltage_max_microvolt",
>constant_charge_voltage_max_uv);
+ of_property_read_u32(battery_np, "internal-resistance-micro-ohms",
+>internal_resistance_uohm);
return 0;
}
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index f807691..019452d 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -326,6 +326,7 @@ struct power_supply_battery_info {
int charge_term_current_ua; /* microAmps */
int constant_charge_current_max_ua; /* microAmps */
int constant_charge_voltage_max_uv; /* microVolts */
+ int internal_resistance_uohm; /* microOhms */
};
extern struct atomic_notifier_head power_supply_notifier;
--
1.7.9.5
[PATCH v2 2/4] power: supply: core: Introduce properties to present the battery OCV table
Some battery driver will use the open circuit voltage (OCV) value to look
up the corresponding battery capacity percent in one certain degree Celsius.
Thus this patch provides some battery properties to present the OCV table
temperatures and OCV capacity table values.
Suggested-by: Sebastian Reichel
Signed-off-by: Baolin Wang
---
Changes from v1:
- New patch in v2.
---
.../devicetree/bindings/power/supply/battery.txt | 14 +
drivers/power/supply/power_supply_core.c | 63 +++-
include/linux/power_supply.h | 11
3 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt
b/Documentation/devicetree/bindings/power/supply/battery.txt
index 25b9d2e..ac2b303 100644
--- a/Documentation/devicetree/bindings/power/supply/battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/battery.txt
@@ -23,6 +23,16 @@ Optional Properties:
- constant-charge-current-max-microamp: maximum constant input current
- constant-charge-voltage-max-microvolt: maximum constant input voltage
- internal-resistance-micro-ohms: battery internal resistance
+ - ocv-capacity-table-0: An array providing the battery capacity percent
+ with corresponding open circuit voltage (OCV) of the battery, which
+ is used to look up battery capacity according to current OCV value.
+ - ocv-capacity-table-1: Same as ocv-capacity-table-0
+ ..
+ - ocv-capacity-table-n: Same as ocv-capacity-table-0
+ - ocv-capacity-table-temperatures: An array containing the temperature
+ in degree Celsius, for each of the battery capacity lookup table.
+ The first temperature value specifies the OCV table 0, and the second
+ temperature value specifies the OCV table 1, and so on.
Battery properties are named, where possible, for the corresponding
elements in enum power_supply_property, defined in
@@ -44,6 +54,10 @@ Example:
constant-charge-current-max-microamp = <90>;
constant-charge-voltage-max-microvolt = <420>;
internal-resistance-micro-ohms = <25>;
+ ocv-capacity-table-temperatures = <(-10) 0 10>;
+ ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000
90>, ...;
+ ocv-capacity-table-1 = <420 100>, <4185000 95>, <4113000
90>, ...;
+ ocv-capacity-table-2 = <425 100>, <420 95>, <4185000
90>, ...;
};
charger: charger@11 {
diff --git a/drivers/power/supply/power_supply_core.c
b/drivers/power/supply/power_supply_core.c
index 9f3452f..151ff03 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -570,7 +570,7 @@ int power_supply_get_battery_info(struct power_supply *psy,
{
struct device_node *battery_np;
const char *value;
- int err;
+ int err, len, index;
info->energy_full_design_uwh = -EINVAL;
info->charge_full_design_uah = -EINVAL;
@@ -581,6 +581,12 @@ int power_supply_get_battery_info(struct power_supply *psy,
info->constant_charge_voltage_max_uv = -EINVAL;
info->internal_resistance_uohm = -EINVAL;
+ for (index = 0; index < POWER_SUPPLY_OCV_TEMP_MAX; index++) {
+ info->ocv_table[index] = NULL;
+ info->ocv_temp[index]= -EINVAL;
+ info->ocv_table_size[index] = -EINVAL;
+ }
+
if (!psy->of_node) {
dev_warn(>dev, "%s currently only supports devicetree\n",
__func__);
@@ -620,10 +626,65 @@ int power_supply_get_battery_info(struct power_supply
*psy,
of_property_read_u32(battery_np, "internal-resistance-micro-ohms",
>internal_resistance_uohm);
+ len = of_property_count_u32_elems(battery_np,
+ "ocv-capacity-table-temperatures");
+ if (len < 0 && len != -EINVAL) {
+ return len;
+ } else if (len > POWER_SUPPLY_OCV_TEMP_MAX) {
+ dev_err(>dev, "Too many temperature values\n");
+ return -EINVAL;
+ } else if (len > 0) {
+ of_property_read_u32_array(battery_np,
+ "ocv-capacity-table-temperatures",
+ info->ocv_temp, len);
+ }
+
+ for (index = 0; index < len; index++) {
+ struct power_supply_battery_ocv_table *table;
+ char *propname;
+ const __be32 *list;
+ int i, tab_len, size;
+
+ propname = kasprintf(GFP_KERNEL, "ocv-capacity-table-%d",
index);
+ list = of_get_property(battery_np, propname, );
+ kfree(propname);
+ if (!list || !size) {
+ dev_err(>dev, "failed to get ocv capacity
table\n");
+
[PATCH v2 3/4] dt-bindings: power: Add Spreadtrum SC27XX fuel gauge unit documentation
This patch adds the binding documentation for Spreadtrum SC27XX series PMICs
fuel gauge unit device, which is used to calculate the battery capacity.
Signed-off-by: Baolin Wang
---
Changes from v1:
- Renamed GPIO property.
- Use standand battery properties instead of 'sprd,inner-resist' and
'sprd,ocv-cap-table'.
- Remove battery node's description.
---
.../devicetree/bindings/power/supply/sc27xx-fg.txt | 52
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/sc27xx-fg.txt
diff --git a/Documentation/devicetree/bindings/power/supply/sc27xx-fg.txt
b/Documentation/devicetree/bindings/power/supply/sc27xx-fg.txt
new file mode 100644
index 000..b161468
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/sc27xx-fg.txt
@@ -0,0 +1,52 @@
+Spreadtrum SC27XX PMICs Fuel Gauge Unit Power Supply Bindings
+
+Required properties:
+- compatible: Should be one of the following:
+ "sprd,sc2720-fgu",
+ "sprd,sc2721-fgu",
+ "sprd,sc2723-fgu",
+ "sprd,sc2730-fgu",
+ "sprd,sc2731-fgu".
+- reg: The address offset of fuel gauge unit.
+- battery-detect-gpios: GPIO for battery detection.
+- io-channels: Specify the IIO ADC channel to get temperature.
+- io-channel-names: Should be "bat-temp".
+- monitored-battery: Phandle of battery characteristics devicetree node.
+ See Documentation/devicetree/bindings/power/supply/battery.txt
+
+Example:
+
+ bat: battery {
+ compatible = "simple-battery";
+ charge-full-design-microamp-hours = <190>;
+ constant-charge-voltage-max-microvolt = <435>;
+ ocv-capacity-table-temperatures = <20>;
+ ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000
90>,
+ <4022000 85>, <3983000 80>, <3949000
75>,
+ <3917000 70>, <3889000 65>, <3864000
60>,
+ <3835000 55>, <3805000 50>, <3787000
45>,
+ <3777000 40>, <3773000 35>, <377
30>,
+ <3765000 25>, <3752000 20>, <3724000
15>,
+ <368 10>, <3605000 5>, <340 0>;
+ ..
+ };
+
+ sc2731_pmic: pmic@0 {
+ compatible = "sprd,sc2731";
+ reg = <0>;
+ spi-max-frequency = <2600>;
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fgu@a00 {
+ compatible = "sprd,sc2731-fgu";
+ reg = <0xa00>;
+ battery-detect-gpios = <_eic 9 GPIO_ACTIVE_HIGH>;
+ io-channels = <_adc 5>;
+ io-channel-names = "bat-temp";
+ monitored-battery = <>;
+ };
+ };
--
1.7.9.5
[PATCH v2 4/4] power: supply: Add Spreadtrum SC27XX fuel gauge unit driver
This patch adds the Spreadtrum SC27XX serial PMICs fuel gauge support,
which is used to calculate the battery capacity.
Original-by: Yuanjiang Yu
Signed-off-by: Baolin Wang
---
Changes from v1:
- Use battery standard properties to get internal resistance and ocv table.
- Change devm_gpiod_get_optional() to devm_gpiod_get().
- Add power_supply_changed() when detecting battery present change.
- Return micro volts for sc27xx_fgu_get_vbat_ocv().
---
drivers/power/supply/Kconfig |7 +
drivers/power/supply/Makefile|1 +
drivers/power/supply/sc27xx_fuel_gauge.c | 691 ++
3 files changed, 699 insertions(+)
create mode 100644 drivers/power/supply/sc27xx_fuel_gauge.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index f27cf07..917f4b7 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -652,4 +652,11 @@ config CHARGER_SC2731
Say Y here to enable support for battery charging with SC2731
PMIC chips.
+config FUEL_GAUGE_SC27XX
+ tristate "Spreadtrum SC27XX fuel gauge driver"
+ depends on MFD_SC27XX_PMIC || COMPILE_TEST
+ help
+Say Y here to enable support for fuel gauge with SC27XX
+PMIC chips.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 767105b..b731c2a 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -86,3 +86,4 @@ obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
obj-$(CONFIG_CHARGER_CROS_USBPD) += cros_usbpd-charger.o
obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o
+obj-$(CONFIG_FUEL_GAUGE_SC27XX)+= sc27xx_fuel_gauge.o
diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c
b/drivers/power/supply/sc27xx_fuel_gauge.c
new file mode 100644
index 000..d3422cf
--- /dev/null
+++ b/drivers/power/supply/sc27xx_fuel_gauge.c
@@ -0,0 +1,691 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Spreadtrum Communications Inc.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PMIC global control registers definition */
+#define SC27XX_MODULE_EN0 0xc08
+#define SC27XX_CLK_EN0 0xc18
+#define SC27XX_FGU_EN BIT(7)
+#define SC27XX_FGU_RTC_EN BIT(6)
+
+/* FGU registers definition */
+#define SC27XX_FGU_START 0x0
+#define SC27XX_FGU_CONFIG 0x4
+#define SC27XX_FGU_ADC_CONFIG 0x8
+#define SC27XX_FGU_STATUS 0xc
+#define SC27XX_FGU_INT_EN 0x10
+#define SC27XX_FGU_INT_CLR 0x14
+#define SC27XX_FGU_INT_STS 0x1c
+#define SC27XX_FGU_VOLTAGE 0x20
+#define SC27XX_FGU_OCV 0x24
+#define SC27XX_FGU_POCV0x28
+#define SC27XX_FGU_CURRENT 0x2c
+#define SC27XX_FGU_CLBCNT_SETH 0x50
+#define SC27XX_FGU_CLBCNT_SETL 0x54
+#define SC27XX_FGU_CLBCNT_VALH 0x68
+#define SC27XX_FGU_CLBCNT_VALL 0x6c
+#define SC27XX_FGU_CLBCNT_QMAXL0x74
+
+#define SC27XX_WRITE_SELCLB_EN BIT(0)
+#define SC27XX_FGU_CLBCNT_MASK GENMASK(15, 0)
+#define SC27XX_FGU_CLBCNT_SHIFT16
+
+#define SC27XX_FGU_1000MV_ADC 686
+#define SC27XX_FGU_1000MA_ADC 1372
+#define SC27XX_FGU_CUR_BASIC_ADC 8192
+#define SC27XX_FGU_SAMPLE_HZ 2
+
+/*
+ * struct sc27xx_fgu_data: describe the FGU device
+ * @regmap: regmap for register access
+ * @dev: platform device
+ * @battery: battery power supply
+ * @base: the base offset for the controller
+ * @lock: protect the structure
+ * @gpiod: GPIO for battery detection
+ * @channel: IIO channel to get battery temperature
+ * @internal_resist: the battery internal resistance in mOhm
+ * @total_cap: the total capacity of the battery in mAh
+ * @init_cap: the initial capacity of the battery in mAh
+ * @init_clbcnt: the initial coulomb counter
+ * @max_volt: the maximum constant input voltage in millivolt
+ * @table_len: the capacity table length
+ * @cap_table: capacity table with corresponding ocv
+ */
+struct sc27xx_fgu_data {
+ struct regmap *regmap;
+ struct device *dev;
+ struct power_supply *battery;
+ u32 base;
+ struct mutex lock;
+ struct gpio_desc *gpiod;
+ struct iio_channel *channel;
+ bool bat_present;
+ int internal_resist;
+ int total_cap;
+ int init_cap;
+ int init_clbcnt;
+ int max_volt;
+ int table_len;
+ struct power_supply_battery_ocv_table *cap_table;
+};
+
+static const char * const sc27xx_charger_supply_name[] = {
+ "sc2731_charger",
+ "sc2720_charger",
+ "sc2721_charger",
+ "sc2723_charger",
+};
+
+static int sc27xx_fgu_adc_to_current(int adc)
+{
+ return (adc * 1000) / SC27XX_FGU_1000MA_ADC;
+}
+
[PATCH v2 1/4] power: supply: core: Introduce one property to present the battery internal resistance
Introduce one property to present the battery internal resistance for battery
information.
Signed-off-by: Baolin Wang
---
Changes from v1:
- New patch in v2.
---
.../devicetree/bindings/power/supply/battery.txt |2 ++
drivers/power/supply/power_supply_core.c |3 +++
include/linux/power_supply.h |1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt
b/Documentation/devicetree/bindings/power/supply/battery.txt
index f4d3b4a..25b9d2e 100644
--- a/Documentation/devicetree/bindings/power/supply/battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/battery.txt
@@ -22,6 +22,7 @@ Optional Properties:
- charge-term-current-microamp: current for charge termination phase
- constant-charge-current-max-microamp: maximum constant input current
- constant-charge-voltage-max-microvolt: maximum constant input voltage
+ - internal-resistance-micro-ohms: battery internal resistance
Battery properties are named, where possible, for the corresponding
elements in enum power_supply_property, defined in
@@ -42,6 +43,7 @@ Example:
charge-term-current-microamp = <128000>;
constant-charge-current-max-microamp = <90>;
constant-charge-voltage-max-microvolt = <420>;
+ internal-resistance-micro-ohms = <25>;
};
charger: charger@11 {
diff --git a/drivers/power/supply/power_supply_core.c
b/drivers/power/supply/power_supply_core.c
index e853618..9f3452f 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -579,6 +579,7 @@ int power_supply_get_battery_info(struct power_supply *psy,
info->charge_term_current_ua = -EINVAL;
info->constant_charge_current_max_ua = -EINVAL;
info->constant_charge_voltage_max_uv = -EINVAL;
+ info->internal_resistance_uohm = -EINVAL;
if (!psy->of_node) {
dev_warn(>dev, "%s currently only supports devicetree\n",
@@ -616,6 +617,8 @@ int power_supply_get_battery_info(struct power_supply *psy,
>constant_charge_current_max_ua);
of_property_read_u32(battery_np,
"constant_charge_voltage_max_microvolt",
>constant_charge_voltage_max_uv);
+ of_property_read_u32(battery_np, "internal-resistance-micro-ohms",
+>internal_resistance_uohm);
return 0;
}
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index f807691..019452d 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -326,6 +326,7 @@ struct power_supply_battery_info {
int charge_term_current_ua; /* microAmps */
int constant_charge_current_max_ua; /* microAmps */
int constant_charge_voltage_max_uv; /* microVolts */
+ int internal_resistance_uohm; /* microOhms */
};
extern struct atomic_notifier_head power_supply_notifier;
--
1.7.9.5
Re: [PATCH] of: unittest: Disable interrupt node tests for old world MAC systems
On 09/25/2018 07:49 PM, Frank Rowand wrote:
Hi Guenter,
Moving in the right direction, but some comments below.
On 09/25/18 10:32, Guenter Roeck wrote:
On systems with OF_IMAP_OLDWORLD_MAC set in of_irq_workarounds, the
devicetree interrupt parsing code is different, causing unit tests of
devicetree interrupt nodes to fail. Due to a bug in unittest code, which
tries to dereference an uninitialized pointer, this results in a crash.
OF: /testcase-data/phandle-tests/consumer-a: arguments longer than property
Unable to handle kernel paging request for data at address 0x00bc616e
Faulting instruction address: 0xc08e9468
Oops: Kernel access of bad area, sig: 11 [#1]
BE PREEMPT PowerMac
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.72-rc1-yocto-standard+ #1
task: cf8e task.stack: cf8da000
NIP: c08e9468 LR: c08ea5bc CTR: c08ea5ac
REGS: cf8dbb50 TRAP: 0300 Not tainted (4.14.72-rc1-yocto-standard+)
MSR: 1032 CR: 82004044 XER:
DAR: 00bc616e DSISR: 4000
GPR00: c08ea5bc cf8dbc00 cf8e c13ca517 c13ca517 c13ca8a0 0066 0002
GPR08: 0063 00bc614e c0b05865 000a 82004048 c00047f0
GPR16: c0a8 c0a9cc34 c13ca517 c0ad1134 05ff 000a c0b05860 c0abeef8
GPR24: cecec278 cecec278 c0a8c4d0 c0a885e0 c13ca8a0 05ff c13ca8a0 c13ca517
NIP [c08e9468] device_node_gen_full_name+0x30/0x15c
LR [c08ea5bc] device_node_string+0x190/0x3c8
Call Trace:
[cf8dbc00] [c007f670] trace_hardirqs_on_caller+0x118/0x1fc (unreliable)
[cf8dbc40] [c08ea5bc] device_node_string+0x190/0x3c8
[cf8dbcb0] [c08eb794] pointer+0x25c/0x4d0
[cf8dbd00] [c08ebcbc] vsnprintf+0x2b4/0x5ec
[cf8dbd60] [c08ec00c] vscnprintf+0x18/0x48
[cf8dbd70] [c008e268] vprintk_store+0x4c/0x22c
[cf8dbda0] [c008ecac] vprintk_emit+0x94/0x130
[cf8dbdd0] [c008ff54] printk+0x5c/0x6c
[cf8dbe10] [c0b8ddd4] of_unittest+0x2220/0x26f8
[cf8dbea0] [c0004434] do_one_initcall+0x4c/0x184
[cf8dbf00] [c0b4534c] kernel_init_freeable+0x13c/0x1d8
[cf8dbf30] [c0004814] kernel_init+0x24/0x118
[cf8dbf40] [c0013398] ret_from_kernel_thread+0x5c/0x64
The problem was observed when running a qemu test for the g3beige machine
with devicetree unittests enabled.
Disable interrupt node tests on affected systems to avoid both false
unittest failures and the crash.
Fixes: 53a42093d96ef ("of: Add device tree selftests")
Signed-off-by: Guenter Roeck
---
The changes in of_unittest_platform_populate() are kept at the minimum;
I wanted to avoid changing the intendation.
An alternative fix might be to move the interrupt tests to a separate
function.
drivers/of/unittest.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 722537e14848..bd1d56cf1962 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
The previous patch had fixes for of_unittest_parse_phandle_with_args() and
of_unittest_parse_phandle_with_args_map(). Do those two functions need to
have the test for OF_IMAP_OLDWORLD_MAC and return that this patch adds to
the other functions?
No. The reason for adding those locations was that they accessed args.np
after an error. As mentioned before, the primary idea of the original patch
was to address the problem of accessing args.np, not to address the
unnecessarily failing test. Sorry for the confusion.
@@ -771,6 +771,9 @@ static void __init of_unittest_parse_interrupts(void)
struct of_phandle_args args;
int i, rc;
+ if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
+ return;
+
np = of_find_node_by_path("/testcase-data/interrupts/interrupts0");
if (!np) {
pr_err("missing testcase data\n");
@@ -845,6 +848,9 @@ static void __init
of_unittest_parse_interrupts_extended(void)
struct of_phandle_args args;
int i, rc;
+ if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
+ return;
+
np =
of_find_node_by_path("/testcase-data/interrupts/interrupts-extended0");
if (!np) {
pr_err("missing testcase data\n");
@@ -1001,6 +1007,9 @@ static void __init of_unittest_platform_populate(void)
pdev = of_find_device_by_node(np);
unittest(pdev, "device 1 creation failed\n");
+ if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
+ goto skip_irqtests;
+
This does not follow the normal use of goto. Just put the skipped over code
into an indented if block.
The code being skipped over already has some unittest() lines that are over
80 characters, and the indentation will make them worse. Please clean up those
unittest() lines up when you add the indentation.
Sure, NP.
Thanks,
Guenter
-Frank
irq = platform_get_irq(pdev, 0);
unittest(irq == -EPROBE_DEFER, "device deferred probe failed - %d\n",
irq);
@@ -1011,6 +1020,7 @@ static void __init of_unittest_platform_populate(void)
irq = platform_get_irq(pdev, 0);
unittest(irq < 0 && irq != -EPROBE_DEFER, "device parsing error
Re: [PATCH] of: unittest: Disable interrupt node tests for old world MAC systems
On 09/25/2018 07:49 PM, Frank Rowand wrote:
Hi Guenter,
Moving in the right direction, but some comments below.
On 09/25/18 10:32, Guenter Roeck wrote:
On systems with OF_IMAP_OLDWORLD_MAC set in of_irq_workarounds, the
devicetree interrupt parsing code is different, causing unit tests of
devicetree interrupt nodes to fail. Due to a bug in unittest code, which
tries to dereference an uninitialized pointer, this results in a crash.
OF: /testcase-data/phandle-tests/consumer-a: arguments longer than property
Unable to handle kernel paging request for data at address 0x00bc616e
Faulting instruction address: 0xc08e9468
Oops: Kernel access of bad area, sig: 11 [#1]
BE PREEMPT PowerMac
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.72-rc1-yocto-standard+ #1
task: cf8e task.stack: cf8da000
NIP: c08e9468 LR: c08ea5bc CTR: c08ea5ac
REGS: cf8dbb50 TRAP: 0300 Not tainted (4.14.72-rc1-yocto-standard+)
MSR: 1032 CR: 82004044 XER:
DAR: 00bc616e DSISR: 4000
GPR00: c08ea5bc cf8dbc00 cf8e c13ca517 c13ca517 c13ca8a0 0066 0002
GPR08: 0063 00bc614e c0b05865 000a 82004048 c00047f0
GPR16: c0a8 c0a9cc34 c13ca517 c0ad1134 05ff 000a c0b05860 c0abeef8
GPR24: cecec278 cecec278 c0a8c4d0 c0a885e0 c13ca8a0 05ff c13ca8a0 c13ca517
NIP [c08e9468] device_node_gen_full_name+0x30/0x15c
LR [c08ea5bc] device_node_string+0x190/0x3c8
Call Trace:
[cf8dbc00] [c007f670] trace_hardirqs_on_caller+0x118/0x1fc (unreliable)
[cf8dbc40] [c08ea5bc] device_node_string+0x190/0x3c8
[cf8dbcb0] [c08eb794] pointer+0x25c/0x4d0
[cf8dbd00] [c08ebcbc] vsnprintf+0x2b4/0x5ec
[cf8dbd60] [c08ec00c] vscnprintf+0x18/0x48
[cf8dbd70] [c008e268] vprintk_store+0x4c/0x22c
[cf8dbda0] [c008ecac] vprintk_emit+0x94/0x130
[cf8dbdd0] [c008ff54] printk+0x5c/0x6c
[cf8dbe10] [c0b8ddd4] of_unittest+0x2220/0x26f8
[cf8dbea0] [c0004434] do_one_initcall+0x4c/0x184
[cf8dbf00] [c0b4534c] kernel_init_freeable+0x13c/0x1d8
[cf8dbf30] [c0004814] kernel_init+0x24/0x118
[cf8dbf40] [c0013398] ret_from_kernel_thread+0x5c/0x64
The problem was observed when running a qemu test for the g3beige machine
with devicetree unittests enabled.
Disable interrupt node tests on affected systems to avoid both false
unittest failures and the crash.
Fixes: 53a42093d96ef ("of: Add device tree selftests")
Signed-off-by: Guenter Roeck
---
The changes in of_unittest_platform_populate() are kept at the minimum;
I wanted to avoid changing the intendation.
An alternative fix might be to move the interrupt tests to a separate
function.
drivers/of/unittest.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 722537e14848..bd1d56cf1962 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
The previous patch had fixes for of_unittest_parse_phandle_with_args() and
of_unittest_parse_phandle_with_args_map(). Do those two functions need to
have the test for OF_IMAP_OLDWORLD_MAC and return that this patch adds to
the other functions?
No. The reason for adding those locations was that they accessed args.np
after an error. As mentioned before, the primary idea of the original patch
was to address the problem of accessing args.np, not to address the
unnecessarily failing test. Sorry for the confusion.
@@ -771,6 +771,9 @@ static void __init of_unittest_parse_interrupts(void)
struct of_phandle_args args;
int i, rc;
+ if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
+ return;
+
np = of_find_node_by_path("/testcase-data/interrupts/interrupts0");
if (!np) {
pr_err("missing testcase data\n");
@@ -845,6 +848,9 @@ static void __init
of_unittest_parse_interrupts_extended(void)
struct of_phandle_args args;
int i, rc;
+ if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
+ return;
+
np =
of_find_node_by_path("/testcase-data/interrupts/interrupts-extended0");
if (!np) {
pr_err("missing testcase data\n");
@@ -1001,6 +1007,9 @@ static void __init of_unittest_platform_populate(void)
pdev = of_find_device_by_node(np);
unittest(pdev, "device 1 creation failed\n");
+ if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
+ goto skip_irqtests;
+
This does not follow the normal use of goto. Just put the skipped over code
into an indented if block.
The code being skipped over already has some unittest() lines that are over
80 characters, and the indentation will make them worse. Please clean up those
unittest() lines up when you add the indentation.
Sure, NP.
Thanks,
Guenter
-Frank
irq = platform_get_irq(pdev, 0);
unittest(irq == -EPROBE_DEFER, "device deferred probe failed - %d\n",
irq);
@@ -1011,6 +1020,7 @@ static void __init of_unittest_platform_populate(void)
irq = platform_get_irq(pdev, 0);
unittest(irq < 0 && irq != -EPROBE_DEFER, "device parsing error
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 9/24/2018 8:01 AM, Jim Quinlan wrote: On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel wrote: On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: On 20 September 2018 at 14:31, Florian Fainelli wrote: On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: On 20 September 2018 at 13:55, Florian Fainelli wrote: On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: On 19 September 2018 at 07:31, Jim Quinlan wrote: The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB of system memory. Here is how the PCIe controller maps the system memory to PCIe memory: memc0-a@[03fff] <=> pci@[03fff] memc0-b@[1...13fff] <=> pci@[ 40007fff] memc1-a@[ 40007fff] <=> pci@[ 8000bfff] memc1-b@[3...33fff] <=> pci@[ c000] memc2-a@[ 8000bfff] <=> pci@[1...13fff] memc2-b@[c...c3fff] <=> pci@[14000...17fff] So is describing this as dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, <0x0 0x4000 0x1 0x0 0x0 0x4000>, <0x0 0x8000 0x0 0x4000 0x0 0x4000>, <0x0 0xc000 0x3 0x0 0x0 0x4000>, <0x1 0x0 0x0 0x8000 0x0 0x4000>, <0x1 0x4000 0x0 0xc000 0x0 0x4000>; not working for you? I haven't tried this myself, but since DT permits describing the inbound mappings this way, we should fix the code if it doesn't work at the moment. You mean encoding the memory controller index in the first cell? If that works, that's indeed a much cleaner solution, though is it standard compliant in any form? No those are just memory addresses (although I may have screwed up the order). From Documentation/devicetree/booting-without-of.txt: """ Optional property: - dma-ranges: encoded as arbitrary number of triplets of (child-bus-address, parent-bus-address, length). Each triplet specified describes a contiguous DMA address range. """ Then I am confused by your comment, that's what this patch does, it adds support for reading "dma-ranges" from Device Tree and setting up inbound windows using that. The only caveat is that because the PCIe root complex has some ties with the memory bus architecture it is connected to (SCB in our case) there is still a requirement to know the translation between a given physical address and its backing memory controller/aperture. Ah ok, apologies for the noise then. I was hoping that having working support for dma-ranges would remove the need for the special phys<->dma conversion routines. What you describe definitively works with platform devices, but I am not sure this is working for PCIe devices, although, conceptually it should, yes. Sorry for my delay in responding. One problem is that of_dma_configure() only looks at the first dma-range given and then converts it to dev->dma_pfn_offset which is respected by the DMA API. However, we often have multiple dma-ranges, not just one. This is the big issue. Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? It looks like this has been brought up before in the "[RFC PATCH] of: Fix DMA configuration for non-DT masters" thread aka https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html In the thread "Oza Oza", a Broadcom coworker probably dealing with the same exact problem as I, enumerates three problems. #1 and #2 are the exact same ones I've just given: the "dma-ranges" prop of the RC DT node is "skipped", and of_dma_get_range() only considers the first entry in any "dma-ranges". Robin, is that something that is expected or should the "dma-ranges" somehow propagate from host bridge down the PCIe end-point drivers? Thanks, Jim In any case, the description of dma-ranges should be in sync with the way Linux interprets it, so this is either a documentation bug or a DMA layer bug. There is another issue with of_dma_configure() being invoked by the EP driver on "bridge->parent->of_node", which is our RC device, Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of our RC's device node and this misses the dma-ranges property which is contained within the RC. I think I could workaround this but there is no getting around the first problem. IIUC dma-ranges should be added to the parent bus of a device, which I guess is slightly ambiguous for a root complex that incorporates a host bridge. Humm, why is that ambiguous for a host bridge/root
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 9/24/2018 8:01 AM, Jim Quinlan wrote: On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel wrote: On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: On 20 September 2018 at 14:31, Florian Fainelli wrote: On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: On 20 September 2018 at 13:55, Florian Fainelli wrote: On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: On 19 September 2018 at 07:31, Jim Quinlan wrote: The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB of system memory. Here is how the PCIe controller maps the system memory to PCIe memory: memc0-a@[03fff] <=> pci@[03fff] memc0-b@[1...13fff] <=> pci@[ 40007fff] memc1-a@[ 40007fff] <=> pci@[ 8000bfff] memc1-b@[3...33fff] <=> pci@[ c000] memc2-a@[ 8000bfff] <=> pci@[1...13fff] memc2-b@[c...c3fff] <=> pci@[14000...17fff] So is describing this as dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, <0x0 0x4000 0x1 0x0 0x0 0x4000>, <0x0 0x8000 0x0 0x4000 0x0 0x4000>, <0x0 0xc000 0x3 0x0 0x0 0x4000>, <0x1 0x0 0x0 0x8000 0x0 0x4000>, <0x1 0x4000 0x0 0xc000 0x0 0x4000>; not working for you? I haven't tried this myself, but since DT permits describing the inbound mappings this way, we should fix the code if it doesn't work at the moment. You mean encoding the memory controller index in the first cell? If that works, that's indeed a much cleaner solution, though is it standard compliant in any form? No those are just memory addresses (although I may have screwed up the order). From Documentation/devicetree/booting-without-of.txt: """ Optional property: - dma-ranges: encoded as arbitrary number of triplets of (child-bus-address, parent-bus-address, length). Each triplet specified describes a contiguous DMA address range. """ Then I am confused by your comment, that's what this patch does, it adds support for reading "dma-ranges" from Device Tree and setting up inbound windows using that. The only caveat is that because the PCIe root complex has some ties with the memory bus architecture it is connected to (SCB in our case) there is still a requirement to know the translation between a given physical address and its backing memory controller/aperture. Ah ok, apologies for the noise then. I was hoping that having working support for dma-ranges would remove the need for the special phys<->dma conversion routines. What you describe definitively works with platform devices, but I am not sure this is working for PCIe devices, although, conceptually it should, yes. Sorry for my delay in responding. One problem is that of_dma_configure() only looks at the first dma-range given and then converts it to dev->dma_pfn_offset which is respected by the DMA API. However, we often have multiple dma-ranges, not just one. This is the big issue. Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? It looks like this has been brought up before in the "[RFC PATCH] of: Fix DMA configuration for non-DT masters" thread aka https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html In the thread "Oza Oza", a Broadcom coworker probably dealing with the same exact problem as I, enumerates three problems. #1 and #2 are the exact same ones I've just given: the "dma-ranges" prop of the RC DT node is "skipped", and of_dma_get_range() only considers the first entry in any "dma-ranges". Robin, is that something that is expected or should the "dma-ranges" somehow propagate from host bridge down the PCIe end-point drivers? Thanks, Jim In any case, the description of dma-ranges should be in sync with the way Linux interprets it, so this is either a documentation bug or a DMA layer bug. There is another issue with of_dma_configure() being invoked by the EP driver on "bridge->parent->of_node", which is our RC device, Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of our RC's device node and this misses the dma-ranges property which is contained within the RC. I think I could workaround this but there is no getting around the first problem. IIUC dma-ranges should be added to the parent bus of a device, which I guess is slightly ambiguous for a root complex that incorporates a host bridge. Humm, why is that ambiguous for a host bridge/root
Re: leaking path in android binder: set_nice
On Tue, Sep 25, 2018 at 01:52:57PM -0400, Stephen Smalley wrote: > On 09/25/2018 01:27 PM, Tong Zhang wrote: > > Kernel Version: 4.18.5 > > > > Problem Description: > > > > When setting nice value, it is checked by LSM function > > security_task_setnice(). > > see kernel/sched/core.c:3972 SYSCALL_DEFINE1(nice, int, increment) > > > > We discovered a leaking path in android binder which allows using binder’s > > interface to change > > a process’s nice value. This path is leaked from being monitored by LSM. > > see drivers/android/binder.c:1107 binder_set_nice. > > Not sure you want to invoke the LSM hook (or at least the same hook) when > binder is performing priority inheritance. There is a difference between a > userspace process switching its own priority and the kernel binder driver > performing it. IIUC, the can_nice() check is more about honoring > RLIMIT_NICE than anything else. I agree with Stephen; it doesn't make sense to subject the binder PI mechanism to the LSM hook. - Ted
Re: leaking path in android binder: set_nice
On Tue, Sep 25, 2018 at 01:52:57PM -0400, Stephen Smalley wrote: > On 09/25/2018 01:27 PM, Tong Zhang wrote: > > Kernel Version: 4.18.5 > > > > Problem Description: > > > > When setting nice value, it is checked by LSM function > > security_task_setnice(). > > see kernel/sched/core.c:3972 SYSCALL_DEFINE1(nice, int, increment) > > > > We discovered a leaking path in android binder which allows using binder’s > > interface to change > > a process’s nice value. This path is leaked from being monitored by LSM. > > see drivers/android/binder.c:1107 binder_set_nice. > > Not sure you want to invoke the LSM hook (or at least the same hook) when > binder is performing priority inheritance. There is a difference between a > userspace process switching its own priority and the kernel binder driver > performing it. IIUC, the can_nice() check is more about honoring > RLIMIT_NICE than anything else. I agree with Stephen; it doesn't make sense to subject the binder PI mechanism to the LSM hook. - Ted
Re: [PATCH 3/4] MIPS: BMIPS: Remove special handling of CONFIG_MIPS_ELF_APPENDED_DTB=y
On 9/25/2018 11:08 AM, Yasha Cherikovsky wrote:
The ELF appended dtb can be accessed now via 'fw_passed_dtb'.
Signed-off-by: Yasha Cherikovsky
Reviewed-by: Florian Fainelli
Cc: Kevin Cernekee
Cc: Florian Fainelli
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
arch/mips/bmips/setup.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
index 3b6f687f177c..b71b6eaaf7ed 100644
--- a/arch/mips/bmips/setup.c
+++ b/arch/mips/bmips/setup.c
@@ -153,8 +153,6 @@ void __init plat_time_init(void)
mips_hpt_frequency = freq;
}
-extern const char __appended_dtb;
-
void __init plat_mem_setup(void)
{
void *dtb;
@@ -164,15 +162,10 @@ void __init plat_mem_setup(void)
ioport_resource.start = 0;
ioport_resource.end = ~0;
-#ifdef CONFIG_MIPS_ELF_APPENDED_DTB
- if (!fdt_check_header(&__appended_dtb))
- dtb = (void *)&__appended_dtb;
- else
-#endif
/* intended to somewhat resemble ARM; see Documentation/arm/Booting */
if (fw_arg0 == 0 && fw_arg1 == 0x)
dtb = phys_to_virt(fw_arg2);
- else if (fw_passed_dtb) /* UHI interface */
+ else if (fw_passed_dtb) /* UHI interface or appended dtb */
dtb = (void *)fw_passed_dtb;
else if (__dtb_start != __dtb_end)
dtb = (void *)__dtb_start;
--
Florian
Re: [PATCH 3/4] MIPS: BMIPS: Remove special handling of CONFIG_MIPS_ELF_APPENDED_DTB=y
On 9/25/2018 11:08 AM, Yasha Cherikovsky wrote:
The ELF appended dtb can be accessed now via 'fw_passed_dtb'.
Signed-off-by: Yasha Cherikovsky
Reviewed-by: Florian Fainelli
Cc: Kevin Cernekee
Cc: Florian Fainelli
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
arch/mips/bmips/setup.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
index 3b6f687f177c..b71b6eaaf7ed 100644
--- a/arch/mips/bmips/setup.c
+++ b/arch/mips/bmips/setup.c
@@ -153,8 +153,6 @@ void __init plat_time_init(void)
mips_hpt_frequency = freq;
}
-extern const char __appended_dtb;
-
void __init plat_mem_setup(void)
{
void *dtb;
@@ -164,15 +162,10 @@ void __init plat_mem_setup(void)
ioport_resource.start = 0;
ioport_resource.end = ~0;
-#ifdef CONFIG_MIPS_ELF_APPENDED_DTB
- if (!fdt_check_header(&__appended_dtb))
- dtb = (void *)&__appended_dtb;
- else
-#endif
/* intended to somewhat resemble ARM; see Documentation/arm/Booting */
if (fw_arg0 == 0 && fw_arg1 == 0x)
dtb = phys_to_virt(fw_arg2);
- else if (fw_passed_dtb) /* UHI interface */
+ else if (fw_passed_dtb) /* UHI interface or appended dtb */
dtb = (void *)fw_passed_dtb;
else if (__dtb_start != __dtb_end)
dtb = (void *)__dtb_start;
--
Florian
Re: [Resend PATCH 5/5] arm: dts: mt7623: add display subsystem related device nodes
On Tue, 2018-09-25 at 17:48 +0200, Matthias Brugger wrote: > > On 05/09/2018 16:09, Ryder Lee wrote: > > Add display subsystem related device nodes for MT7623. > > > > Cc: CK Hu > > Signed-off-by: chunhui dai > > Signed-off-by: Bibby Hsieh > > Signed-off-by: Ryder Lee > > --- > > I forgot to sort nodes in my previous mail. Sorry for the inconvenience. > > > > This patch depends on the series: https://lkml.org/lkml/2018/9/5/223 > > That's not yet merged, right? Yes. > > > > @Matthias, > > I know you're working on broken MMSYS - just want to ask whether it's > > possible > > to let the patch to go to your tree (if others are okay with it), and send a > > fixup one for MT7623 MMSYS later? > > I know I'm a big blocker here, sorry for the inconvenience. > I'll do my best to get that in for the next release. If I make no progress on > that then we should find a different solution. No problem. Thanks for your great effort :) > Regards, > Matthias > > > --- > > arch/arm/boot/dts/mt7623.dtsi | 177 > > ++ > > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 83 > > arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 83 > > 3 files changed, 343 insertions(+)
Re: [Resend PATCH 5/5] arm: dts: mt7623: add display subsystem related device nodes
On Tue, 2018-09-25 at 17:48 +0200, Matthias Brugger wrote: > > On 05/09/2018 16:09, Ryder Lee wrote: > > Add display subsystem related device nodes for MT7623. > > > > Cc: CK Hu > > Signed-off-by: chunhui dai > > Signed-off-by: Bibby Hsieh > > Signed-off-by: Ryder Lee > > --- > > I forgot to sort nodes in my previous mail. Sorry for the inconvenience. > > > > This patch depends on the series: https://lkml.org/lkml/2018/9/5/223 > > That's not yet merged, right? Yes. > > > > @Matthias, > > I know you're working on broken MMSYS - just want to ask whether it's > > possible > > to let the patch to go to your tree (if others are okay with it), and send a > > fixup one for MT7623 MMSYS later? > > I know I'm a big blocker here, sorry for the inconvenience. > I'll do my best to get that in for the next release. If I make no progress on > that then we should find a different solution. No problem. Thanks for your great effort :) > Regards, > Matthias > > > --- > > arch/arm/boot/dts/mt7623.dtsi | 177 > > ++ > > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 83 > > arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 83 > > 3 files changed, 343 insertions(+)
Re: [PATCH] of: unittest: Disable interrupt node tests for old world MAC systems
Hi Guenter,
Moving in the right direction, but some comments below.
On 09/25/18 10:32, Guenter Roeck wrote:
> On systems with OF_IMAP_OLDWORLD_MAC set in of_irq_workarounds, the
> devicetree interrupt parsing code is different, causing unit tests of
> devicetree interrupt nodes to fail. Due to a bug in unittest code, which
> tries to dereference an uninitialized pointer, this results in a crash.
>
> OF: /testcase-data/phandle-tests/consumer-a: arguments longer than property
> Unable to handle kernel paging request for data at address 0x00bc616e
> Faulting instruction address: 0xc08e9468
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PREEMPT PowerMac
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.72-rc1-yocto-standard+ #1
> task: cf8e task.stack: cf8da000
> NIP: c08e9468 LR: c08ea5bc CTR: c08ea5ac
> REGS: cf8dbb50 TRAP: 0300 Not tainted (4.14.72-rc1-yocto-standard+)
> MSR: 1032 CR: 82004044 XER:
> DAR: 00bc616e DSISR: 4000
> GPR00: c08ea5bc cf8dbc00 cf8e c13ca517 c13ca517 c13ca8a0 0066 0002
> GPR08: 0063 00bc614e c0b05865 000a 82004048 c00047f0
> GPR16: c0a8 c0a9cc34 c13ca517 c0ad1134 05ff 000a c0b05860 c0abeef8
> GPR24: cecec278 cecec278 c0a8c4d0 c0a885e0 c13ca8a0 05ff c13ca8a0 c13ca517
>
> NIP [c08e9468] device_node_gen_full_name+0x30/0x15c
> LR [c08ea5bc] device_node_string+0x190/0x3c8
> Call Trace:
> [cf8dbc00] [c007f670] trace_hardirqs_on_caller+0x118/0x1fc (unreliable)
> [cf8dbc40] [c08ea5bc] device_node_string+0x190/0x3c8
> [cf8dbcb0] [c08eb794] pointer+0x25c/0x4d0
> [cf8dbd00] [c08ebcbc] vsnprintf+0x2b4/0x5ec
> [cf8dbd60] [c08ec00c] vscnprintf+0x18/0x48
> [cf8dbd70] [c008e268] vprintk_store+0x4c/0x22c
> [cf8dbda0] [c008ecac] vprintk_emit+0x94/0x130
> [cf8dbdd0] [c008ff54] printk+0x5c/0x6c
> [cf8dbe10] [c0b8ddd4] of_unittest+0x2220/0x26f8
> [cf8dbea0] [c0004434] do_one_initcall+0x4c/0x184
> [cf8dbf00] [c0b4534c] kernel_init_freeable+0x13c/0x1d8
> [cf8dbf30] [c0004814] kernel_init+0x24/0x118
> [cf8dbf40] [c0013398] ret_from_kernel_thread+0x5c/0x64
>
> The problem was observed when running a qemu test for the g3beige machine
> with devicetree unittests enabled.
>
> Disable interrupt node tests on affected systems to avoid both false
> unittest failures and the crash.
>
> Fixes: 53a42093d96ef ("of: Add device tree selftests")
> Signed-off-by: Guenter Roeck
> ---
> The changes in of_unittest_platform_populate() are kept at the minimum;
> I wanted to avoid changing the intendation.
> An alternative fix might be to move the interrupt tests to a separate
> function.
>
> drivers/of/unittest.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 722537e14848..bd1d56cf1962 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
The previous patch had fixes for of_unittest_parse_phandle_with_args() and
of_unittest_parse_phandle_with_args_map(). Do those two functions need to
have the test for OF_IMAP_OLDWORLD_MAC and return that this patch adds to
the other functions?
> @@ -771,6 +771,9 @@ static void __init of_unittest_parse_interrupts(void)
> struct of_phandle_args args;
> int i, rc;
>
> + if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
> + return;
> +
> np = of_find_node_by_path("/testcase-data/interrupts/interrupts0");
> if (!np) {
> pr_err("missing testcase data\n");
> @@ -845,6 +848,9 @@ static void __init
> of_unittest_parse_interrupts_extended(void)
> struct of_phandle_args args;
> int i, rc;
>
> + if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
> + return;
> +
> np =
> of_find_node_by_path("/testcase-data/interrupts/interrupts-extended0");
> if (!np) {
> pr_err("missing testcase data\n");
> @@ -1001,6 +1007,9 @@ static void __init of_unittest_platform_populate(void)
> pdev = of_find_device_by_node(np);
> unittest(pdev, "device 1 creation failed\n");
>
> + if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
> + goto skip_irqtests;
> +
This does not follow the normal use of goto. Just put the skipped over code
into an indented if block.
The code being skipped over already has some unittest() lines that are over
80 characters, and the indentation will make them worse. Please clean up those
unittest() lines up when you add the indentation.
-Frank
> irq = platform_get_irq(pdev, 0);
> unittest(irq == -EPROBE_DEFER, "device deferred probe failed - %d\n",
> irq);
>
> @@ -1011,6 +1020,7 @@ static void __init of_unittest_platform_populate(void)
> irq = platform_get_irq(pdev, 0);
> unittest(irq < 0 && irq != -EPROBE_DEFER, "device parsing error failed
> - %d\n", irq);
>
> +skip_irqtests:
> np = of_find_node_by_path("/testcase-data/platform-tests");
> unittest(np, "No testcase data in device tree\n");
> if (!np)
>
Re: [PATCH] of: unittest: Disable interrupt node tests for old world MAC systems
Hi Guenter,
Moving in the right direction, but some comments below.
On 09/25/18 10:32, Guenter Roeck wrote:
> On systems with OF_IMAP_OLDWORLD_MAC set in of_irq_workarounds, the
> devicetree interrupt parsing code is different, causing unit tests of
> devicetree interrupt nodes to fail. Due to a bug in unittest code, which
> tries to dereference an uninitialized pointer, this results in a crash.
>
> OF: /testcase-data/phandle-tests/consumer-a: arguments longer than property
> Unable to handle kernel paging request for data at address 0x00bc616e
> Faulting instruction address: 0xc08e9468
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PREEMPT PowerMac
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.72-rc1-yocto-standard+ #1
> task: cf8e task.stack: cf8da000
> NIP: c08e9468 LR: c08ea5bc CTR: c08ea5ac
> REGS: cf8dbb50 TRAP: 0300 Not tainted (4.14.72-rc1-yocto-standard+)
> MSR: 1032 CR: 82004044 XER:
> DAR: 00bc616e DSISR: 4000
> GPR00: c08ea5bc cf8dbc00 cf8e c13ca517 c13ca517 c13ca8a0 0066 0002
> GPR08: 0063 00bc614e c0b05865 000a 82004048 c00047f0
> GPR16: c0a8 c0a9cc34 c13ca517 c0ad1134 05ff 000a c0b05860 c0abeef8
> GPR24: cecec278 cecec278 c0a8c4d0 c0a885e0 c13ca8a0 05ff c13ca8a0 c13ca517
>
> NIP [c08e9468] device_node_gen_full_name+0x30/0x15c
> LR [c08ea5bc] device_node_string+0x190/0x3c8
> Call Trace:
> [cf8dbc00] [c007f670] trace_hardirqs_on_caller+0x118/0x1fc (unreliable)
> [cf8dbc40] [c08ea5bc] device_node_string+0x190/0x3c8
> [cf8dbcb0] [c08eb794] pointer+0x25c/0x4d0
> [cf8dbd00] [c08ebcbc] vsnprintf+0x2b4/0x5ec
> [cf8dbd60] [c08ec00c] vscnprintf+0x18/0x48
> [cf8dbd70] [c008e268] vprintk_store+0x4c/0x22c
> [cf8dbda0] [c008ecac] vprintk_emit+0x94/0x130
> [cf8dbdd0] [c008ff54] printk+0x5c/0x6c
> [cf8dbe10] [c0b8ddd4] of_unittest+0x2220/0x26f8
> [cf8dbea0] [c0004434] do_one_initcall+0x4c/0x184
> [cf8dbf00] [c0b4534c] kernel_init_freeable+0x13c/0x1d8
> [cf8dbf30] [c0004814] kernel_init+0x24/0x118
> [cf8dbf40] [c0013398] ret_from_kernel_thread+0x5c/0x64
>
> The problem was observed when running a qemu test for the g3beige machine
> with devicetree unittests enabled.
>
> Disable interrupt node tests on affected systems to avoid both false
> unittest failures and the crash.
>
> Fixes: 53a42093d96ef ("of: Add device tree selftests")
> Signed-off-by: Guenter Roeck
> ---
> The changes in of_unittest_platform_populate() are kept at the minimum;
> I wanted to avoid changing the intendation.
> An alternative fix might be to move the interrupt tests to a separate
> function.
>
> drivers/of/unittest.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 722537e14848..bd1d56cf1962 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
The previous patch had fixes for of_unittest_parse_phandle_with_args() and
of_unittest_parse_phandle_with_args_map(). Do those two functions need to
have the test for OF_IMAP_OLDWORLD_MAC and return that this patch adds to
the other functions?
> @@ -771,6 +771,9 @@ static void __init of_unittest_parse_interrupts(void)
> struct of_phandle_args args;
> int i, rc;
>
> + if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
> + return;
> +
> np = of_find_node_by_path("/testcase-data/interrupts/interrupts0");
> if (!np) {
> pr_err("missing testcase data\n");
> @@ -845,6 +848,9 @@ static void __init
> of_unittest_parse_interrupts_extended(void)
> struct of_phandle_args args;
> int i, rc;
>
> + if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
> + return;
> +
> np =
> of_find_node_by_path("/testcase-data/interrupts/interrupts-extended0");
> if (!np) {
> pr_err("missing testcase data\n");
> @@ -1001,6 +1007,9 @@ static void __init of_unittest_platform_populate(void)
> pdev = of_find_device_by_node(np);
> unittest(pdev, "device 1 creation failed\n");
>
> + if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
> + goto skip_irqtests;
> +
This does not follow the normal use of goto. Just put the skipped over code
into an indented if block.
The code being skipped over already has some unittest() lines that are over
80 characters, and the indentation will make them worse. Please clean up those
unittest() lines up when you add the indentation.
-Frank
> irq = platform_get_irq(pdev, 0);
> unittest(irq == -EPROBE_DEFER, "device deferred probe failed - %d\n",
> irq);
>
> @@ -1011,6 +1020,7 @@ static void __init of_unittest_platform_populate(void)
> irq = platform_get_irq(pdev, 0);
> unittest(irq < 0 && irq != -EPROBE_DEFER, "device parsing error failed
> - %d\n", irq);
>
> +skip_irqtests:
> np = of_find_node_by_path("/testcase-data/platform-tests");
> unittest(np, "No testcase data in device tree\n");
> if (!np)
>
Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines
Christoph Hellwig 於 2018年9月25日 週二 下午11:25寫道： > > On Tue, Sep 25, 2018 at 10:19:55AM +0800, Zong Li wrote: > > The RV32 need the umoddi3 to do modulo when the operands are long long > > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > > so on. I encounter the undefined reference 'umoddi3' when I use the in > > house dma driver, although it is in house driver, but I think that > > umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are > > copies from libgcc in gcc. There are other functions use the > > udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for > > flexible extension in the future. > > I don't think libgcc is GPLv2 licensed, is it? Also please retain > the copyright notices from libgcc. I will give next version patch. Thanks.
Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines
Christoph Hellwig 於 2018年9月25日 週二 下午11:25寫道： > > On Tue, Sep 25, 2018 at 10:19:55AM +0800, Zong Li wrote: > > The RV32 need the umoddi3 to do modulo when the operands are long long > > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > > so on. I encounter the undefined reference 'umoddi3' when I use the in > > house dma driver, although it is in house driver, but I think that > > umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are > > copies from libgcc in gcc. There are other functions use the > > udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for > > flexible extension in the future. > > I don't think libgcc is GPLv2 licensed, is it? Also please retain > the copyright notices from libgcc. I will give next version patch. Thanks.
Re: [Resend PATCH 5/5] arm: dts: mt7623: add display subsystem related device nodes
On Wed, 2018-09-26 at 09:37 +0800, CK Hu wrote:
> Hi, Ryder:
>
> On Wed, 2018-09-05 at 22:09 +0800, Ryder Lee wrote:
> > Add display subsystem related device nodes for MT7623.
> >
> > Cc: CK Hu
> > Signed-off-by: chunhui dai
> > Signed-off-by: Bibby Hsieh
> > Signed-off-by: Ryder Lee
> > ---
> > I forgot to sort nodes in my previous mail. Sorry for the inconvenience.
> >
> > This patch depends on the series: https://lkml.org/lkml/2018/9/5/223
> >
> > @Matthias,
> > I know you're working on broken MMSYS - just want to ask whether it's
> > possible
> > to let the patch to go to your tree (if others are okay with it), and send a
> > fixup one for MT7623 MMSYS later?
> > ---
> > arch/arm/boot/dts/mt7623.dtsi | 177
> > ++
> > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 83
> > arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 83
> > 3 files changed, 343 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> > index d01bdee..fdf9078 100644
> > --- a/arch/arm/boot/dts/mt7623.dtsi
> > +++ b/arch/arm/boot/dts/mt7623.dtsi
> > @@ -23,6 +23,11 @@
> > #address-cells = <2>;
> > #size-cells = <2>;
> >
> > + aliases {
> > + rdma0 =
> > + rdma1 =
> > + };
> > +
> > cpu_opp_table: opp-table {
> > compatible = "operating-points-v2";
> > opp-shared;
> > @@ -311,6 +316,25 @@
> > clock-names = "spi", "wrap";
> > };
> >
> > + mipi_tx0: mipi-dphy@1001 {
> > + compatible = "mediatek,mt7623-mipi-tx",
> > +"mediatek,mt2701-mipi-tx";
> > + reg = <0 0x1001 0 0x90>;
> > + clocks = <>;
> > + clock-output-names = "mipi_tx0_pll";
> > + #clock-cells = <0>;
> > + #phy-cells = <0>;
> > + };
> > +
> > + cec: cec@10012000 {
> > + compatible = "mediatek,mt7623-cec",
> > +"mediatek,mt8173-cec";
> > + reg = <0 0x10012000 0 0xbc>;
> > + interrupts = ;
> > + clocks = < CLK_INFRA_CEC>;
> > + status = "disabled";
> > + };
> > +
> > cir: cir@10013000 {
> > compatible = "mediatek,mt7623-cir";
> > reg = <0 0x10013000 0 0x1000>;
> > @@ -359,6 +383,18 @@
> > #clock-cells = <1>;
> > };
> >
> > + hdmi_phy: phy@10209100 {
> > + compatible = "mediatek,mt7623-hdmi-phy",
> > +"mediatek,mt2701-hdmi-phy";
> > + reg = <0 0x10209100 0 0x24>;
> > + clocks = < CLK_APMIXED_HDMI_REF>;
> > + clock-names = "pll_ref";
> > + clock-output-names = "hdmitx_dig_cts";
> > + #clock-cells = <0>;
> > + #phy-cells = <0>;
> > + status = "disabled";
> > + };
> > +
> > rng: rng@1020f000 {
> > compatible = "mediatek,mt7623-rng";
> > reg = <0 0x1020f000 0 0x1000>;
> > @@ -558,6 +594,16 @@
> > status = "disabled";
> > };
> >
> > + hdmiddc0: i2c@11013000 {
> > + compatible = "mediatek,mt7623-hdmi-ddc",
> > +"mediatek,mt8173-hdmi-ddc";
> > + interrupts = ;
> > + reg = <0 0x11013000 0 0x1C>;
> > + clocks = < CLK_PERI_I2C3>;
> > + clock-names = "ddc-i2c";
> > + status = "disabled";
> > + };
> > +
> > nor_flash: spi@11014000 {
> > compatible = "mediatek,mt7623-nor",
> > "mediatek,mt8173-nor";
> > @@ -732,6 +778,84 @@
> > #clock-cells = <1>;
> > };
> >
> > + display_components: dispsys@1400 {
> > + compatible = "mediatek,mt7623-mmsys",
>
> Checkpatch warning:
>
> WARNING: DT compatible string "mediatek,mt7623-mmsys" appears
> un-documented -- check ./Documentation/devicetree/bindings/
> #101: FILE: arch/arm/boot/dts/mt7623.dtsi:782:
> + compatible = "mediatek,mt7623-mmsys",
>
>
> > +"mediatek,mt2701-mmsys";
> > + reg = <0 0x1400 0 0x1000>;
> > + power-domains = < MT2701_POWER_DOMAIN_DISP>;
> > + };
> > +
> > + ovl@14007000 {
> > + compatible = "mediatek,mt7623-disp-ovl",
>
> I think this is also un-documented, but I don't know why checkpatch does
> not show any warning.
>
> Regards,
> CK
> > +"mediatek,mt2701-disp-ovl";
> > + reg = <0 0x14007000 0 0x1000>;
> > + interrupts = ;
> > + clocks = < CLK_MM_DISP_OVL>;
> > + iommus = < MT2701_M4U_PORT_DISP_OVL_0>;
> > + mediatek,larb = <>;
> > + };
> > +
I fallback to use the MT2701's compatible string here and there, but I
could add a new one for MT7623.
BTW, I've had this question for a long time - should I add a new
compatible for the very same IPs, or could we just use the old one in
DTS?
Ryder
Re: [Resend PATCH 5/5] arm: dts: mt7623: add display subsystem related device nodes
On Wed, 2018-09-26 at 09:37 +0800, CK Hu wrote:
> Hi, Ryder:
>
> On Wed, 2018-09-05 at 22:09 +0800, Ryder Lee wrote:
> > Add display subsystem related device nodes for MT7623.
> >
> > Cc: CK Hu
> > Signed-off-by: chunhui dai
> > Signed-off-by: Bibby Hsieh
> > Signed-off-by: Ryder Lee
> > ---
> > I forgot to sort nodes in my previous mail. Sorry for the inconvenience.
> >
> > This patch depends on the series: https://lkml.org/lkml/2018/9/5/223
> >
> > @Matthias,
> > I know you're working on broken MMSYS - just want to ask whether it's
> > possible
> > to let the patch to go to your tree (if others are okay with it), and send a
> > fixup one for MT7623 MMSYS later?
> > ---
> > arch/arm/boot/dts/mt7623.dtsi | 177
> > ++
> > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 83
> > arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 83
> > 3 files changed, 343 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> > index d01bdee..fdf9078 100644
> > --- a/arch/arm/boot/dts/mt7623.dtsi
> > +++ b/arch/arm/boot/dts/mt7623.dtsi
> > @@ -23,6 +23,11 @@
> > #address-cells = <2>;
> > #size-cells = <2>;
> >
> > + aliases {
> > + rdma0 =
> > + rdma1 =
> > + };
> > +
> > cpu_opp_table: opp-table {
> > compatible = "operating-points-v2";
> > opp-shared;
> > @@ -311,6 +316,25 @@
> > clock-names = "spi", "wrap";
> > };
> >
> > + mipi_tx0: mipi-dphy@1001 {
> > + compatible = "mediatek,mt7623-mipi-tx",
> > +"mediatek,mt2701-mipi-tx";
> > + reg = <0 0x1001 0 0x90>;
> > + clocks = <>;
> > + clock-output-names = "mipi_tx0_pll";
> > + #clock-cells = <0>;
> > + #phy-cells = <0>;
> > + };
> > +
> > + cec: cec@10012000 {
> > + compatible = "mediatek,mt7623-cec",
> > +"mediatek,mt8173-cec";
> > + reg = <0 0x10012000 0 0xbc>;
> > + interrupts = ;
> > + clocks = < CLK_INFRA_CEC>;
> > + status = "disabled";
> > + };
> > +
> > cir: cir@10013000 {
> > compatible = "mediatek,mt7623-cir";
> > reg = <0 0x10013000 0 0x1000>;
> > @@ -359,6 +383,18 @@
> > #clock-cells = <1>;
> > };
> >
> > + hdmi_phy: phy@10209100 {
> > + compatible = "mediatek,mt7623-hdmi-phy",
> > +"mediatek,mt2701-hdmi-phy";
> > + reg = <0 0x10209100 0 0x24>;
> > + clocks = < CLK_APMIXED_HDMI_REF>;
> > + clock-names = "pll_ref";
> > + clock-output-names = "hdmitx_dig_cts";
> > + #clock-cells = <0>;
> > + #phy-cells = <0>;
> > + status = "disabled";
> > + };
> > +
> > rng: rng@1020f000 {
> > compatible = "mediatek,mt7623-rng";
> > reg = <0 0x1020f000 0 0x1000>;
> > @@ -558,6 +594,16 @@
> > status = "disabled";
> > };
> >
> > + hdmiddc0: i2c@11013000 {
> > + compatible = "mediatek,mt7623-hdmi-ddc",
> > +"mediatek,mt8173-hdmi-ddc";
> > + interrupts = ;
> > + reg = <0 0x11013000 0 0x1C>;
> > + clocks = < CLK_PERI_I2C3>;
> > + clock-names = "ddc-i2c";
> > + status = "disabled";
> > + };
> > +
> > nor_flash: spi@11014000 {
> > compatible = "mediatek,mt7623-nor",
> > "mediatek,mt8173-nor";
> > @@ -732,6 +778,84 @@
> > #clock-cells = <1>;
> > };
> >
> > + display_components: dispsys@1400 {
> > + compatible = "mediatek,mt7623-mmsys",
>
> Checkpatch warning:
>
> WARNING: DT compatible string "mediatek,mt7623-mmsys" appears
> un-documented -- check ./Documentation/devicetree/bindings/
> #101: FILE: arch/arm/boot/dts/mt7623.dtsi:782:
> + compatible = "mediatek,mt7623-mmsys",
>
>
> > +"mediatek,mt2701-mmsys";
> > + reg = <0 0x1400 0 0x1000>;
> > + power-domains = < MT2701_POWER_DOMAIN_DISP>;
> > + };
> > +
> > + ovl@14007000 {
> > + compatible = "mediatek,mt7623-disp-ovl",
>
> I think this is also un-documented, but I don't know why checkpatch does
> not show any warning.
>
> Regards,
> CK
> > +"mediatek,mt2701-disp-ovl";
> > + reg = <0 0x14007000 0 0x1000>;
> > + interrupts = ;
> > + clocks = < CLK_MM_DISP_OVL>;
> > + iommus = < MT2701_M4U_PORT_DISP_OVL_0>;
> > + mediatek,larb = <>;
> > + };
> > +
I fallback to use the MT2701's compatible string here and there, but I
could add a new one for MT7623.
BTW, I've had this question for a long time - should I add a new
compatible for the very same IPs, or could we just use the old one in
DTS?
Ryder
Re: [PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100
On 26/09/2018 9:49 AM, Song Qiang wrote:
On Tue, Sep 25, 2018 at 10:36:54PM +0800, Phil Reid wrote:
On 25/09/2018 9:30 PM, Jonathan Cameron wrote:
+static irqreturn_t rm3100_trigger_handler(int irq, void *p)
+{
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct rm3100_data *data = iio_priv(indio_dev);
+ struct regmap *regmap = data->regmap;
+ u8 buffer[9];
+ int ret;
+ int i;
+
+ mutex_lock(>lock);
+ ret = rm3100_wait_measurement(data);
+ if (ret < 0) {
+ mutex_unlock(>lock);
+ goto done;
+ }
+
+ ret = regmap_bulk_read(regmap, RM3100_REG_MX2, buffer, sizeof(buffer));
+ mutex_unlock(>lock);
+ if (ret < 0)
+ goto done;
+
+ /* Convert XXXYYYZZZxxx to XXXxYYYxZZZx. x for padding. */
+ for (i = 0; i < 3; i++)
+ memcpy(data->buffer + i * 4, buffer + i * 3, 3);
Firstly X doesn't need copying.
Secondly the copy of Y actually overwrites the value of Z
XXXYYYZZZxxx
XXXxYYYZZxxx
XXXxYYYxYZZx
I think...
+
+ iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
+ iio_get_time_ns(indio_dev));
memcpy target is a different buffer so should be ok.
But that raises the question of does it need to be?
'buffer' could be 12 bytes long and just shuffle Z then Y.
Do the unused bytes need to be zeroed? or does libiio mask them anyway?
--
Regards
Phil Reid
Hi Phil,
This is interesting, last patch I submitted uses three transactions and
shuffles X, Y and Z respectively. You said it should be better to use one
transactions, I thought it makes point, and one transaction may reduce
IO pressure of the i2c bus. :)
And that's not necessary for unused bytes to be zero. I'm not familiar
with libiio, actually just been studying it, can't say anything about
it.
yours,
Song Qiang
G'day Song,
yes the one transaction suggestion was to reduce pressure on the bus.
I think also with 3 calls you can up up with other devices taking over
the i2c / spi bus in between.
We've got a devkit for this part, but haven't got to wiring it up to our system
as yet.
We're looking at using the i2c interface which could push things at max
samplerate, so yes I'm
keen to see bus pressure reduced as much as possible.
I was thinking something like the following:
u8 buffer[12];
regmap_bulk_read(regmap, RM3100_REG_MX2, buffer, 9);
buffer[10] = buffer[8]; // or memcpy or some other fancy shuffle code.
buffer[9] = buffer[7];
buffer[8] = buffer[6];
buffer[6] = buffer[5];
buffer[5] = buffer[4];
buffer[4] = buffer[3];
iio_push_to_buffers_with_timestamp(indio_dev, buffer,
iio_get_time_ns(indio_dev));
but I'm unsure if this would be needed:
buffer[7] = 0
buffer[3] = 0
What you've got does the job I think.
I haven't dug into the datasheet in great detail, and my iio knownledge is
limited.
Are you sure the RM3100_CHANNEL scantype endianness is IIO_LE.
rm3100_read_mag looks to be doing big endian conversion and the datasheet
agrees with that.
--
Regards
Phil Reid
Re: [PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100
On 26/09/2018 9:49 AM, Song Qiang wrote:
On Tue, Sep 25, 2018 at 10:36:54PM +0800, Phil Reid wrote:
On 25/09/2018 9:30 PM, Jonathan Cameron wrote:
+static irqreturn_t rm3100_trigger_handler(int irq, void *p)
+{
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct rm3100_data *data = iio_priv(indio_dev);
+ struct regmap *regmap = data->regmap;
+ u8 buffer[9];
+ int ret;
+ int i;
+
+ mutex_lock(>lock);
+ ret = rm3100_wait_measurement(data);
+ if (ret < 0) {
+ mutex_unlock(>lock);
+ goto done;
+ }
+
+ ret = regmap_bulk_read(regmap, RM3100_REG_MX2, buffer, sizeof(buffer));
+ mutex_unlock(>lock);
+ if (ret < 0)
+ goto done;
+
+ /* Convert XXXYYYZZZxxx to XXXxYYYxZZZx. x for padding. */
+ for (i = 0; i < 3; i++)
+ memcpy(data->buffer + i * 4, buffer + i * 3, 3);
Firstly X doesn't need copying.
Secondly the copy of Y actually overwrites the value of Z
XXXYYYZZZxxx
XXXxYYYZZxxx
XXXxYYYxYZZx
I think...
+
+ iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
+ iio_get_time_ns(indio_dev));
memcpy target is a different buffer so should be ok.
But that raises the question of does it need to be?
'buffer' could be 12 bytes long and just shuffle Z then Y.
Do the unused bytes need to be zeroed? or does libiio mask them anyway?
--
Regards
Phil Reid
Hi Phil,
This is interesting, last patch I submitted uses three transactions and
shuffles X, Y and Z respectively. You said it should be better to use one
transactions, I thought it makes point, and one transaction may reduce
IO pressure of the i2c bus. :)
And that's not necessary for unused bytes to be zero. I'm not familiar
with libiio, actually just been studying it, can't say anything about
it.
yours,
Song Qiang
G'day Song,
yes the one transaction suggestion was to reduce pressure on the bus.
I think also with 3 calls you can up up with other devices taking over
the i2c / spi bus in between.
We've got a devkit for this part, but haven't got to wiring it up to our system
as yet.
We're looking at using the i2c interface which could push things at max
samplerate, so yes I'm
keen to see bus pressure reduced as much as possible.
I was thinking something like the following:
u8 buffer[12];
regmap_bulk_read(regmap, RM3100_REG_MX2, buffer, 9);
buffer[10] = buffer[8]; // or memcpy or some other fancy shuffle code.
buffer[9] = buffer[7];
buffer[8] = buffer[6];
buffer[6] = buffer[5];
buffer[5] = buffer[4];
buffer[4] = buffer[3];
iio_push_to_buffers_with_timestamp(indio_dev, buffer,
iio_get_time_ns(indio_dev));
but I'm unsure if this would be needed:
buffer[7] = 0
buffer[3] = 0
What you've got does the job I think.
I haven't dug into the datasheet in great detail, and my iio knownledge is
limited.
Are you sure the RM3100_CHANNEL scantype endianness is IIO_LE.
rm3100_read_mag looks to be doing big endian conversion and the datasheet
agrees with that.
--
Regards
Phil Reid
Re: [PATCH v2] staging: mt7621-mmc: Fix single statement macros in sd.c
On Tue, Sep 25 2018, Joe Perches wrote:
> On Tue, 2018-09-25 at 20:49 +0200, Greg Kroah-Hartman wrote:
>> On Sun, Sep 23, 2018 at 06:31:32AM -0700, Joe Perches wrote:
>> > On Sun, 2018-09-23 at 15:08 +0530, Nishad Kamdar wrote:
>> > > This patch fixes a few single statement macros in sd.c.
>> > > It converts two macros to inline functions. It removes
>> > > five other macros and replaces their usages with calls to
>> > > the function being called in the macro definition.
>> > > Issue found by checkpatch.
>> > >
>> > > Signed-off-by: Nishad Kamdar
>> > > ---
>> > > Changes in v2:
>> > > - Convert msdc_gate_clk() and msdc_ungate_clk() to inline functions.
>> > > - Delete msdc_irq_restore(), msdc_vcore_on(), msdc_vcore_off(),
>> > > msdc_vdd_on() and msdc_vdd_off() and replace their usages directly
>> > > with calls to the function being called by these macros.
>> >
>> > Nishad, do please look again for uses of these functions
>> > you are changing.
>> >
>> > Please try removing all the #if 0 blocks instead, and then
>> > see if there are also now unused functions from those removed
>> > blocks that could also be removed.
>> >
>> > And Greg, if you look at this, look at the odd license of
>> > these files.
>> >
>> > It's possible the license is incompatible with the GPL.
>>
>> It is odd, but the GPL at the bottom of the file kind of implies it is
>> ok.
>
> Implications are not licenses.
>
>> Given that it was published by mtk, I am assuming all is good, but
>> it would be a good idea to check with the authors to fix this up
>> properly.
>
> The initial patch was submitted by
> John Crispin
Actually it was submitted by me. I extracted it from libreCMC (I think -
it is in most of the various openWRT-like distros).
In libreCMC the patch has John listed as the Author, and I thought it
right to preserve that.
I believe the code comes from a code-dump made by Mediatek several years
ago. It can be found at git://github.com/mqmaker/linux.git.
The code there contains (in drivers/mmc/host/mtk-mmc/sd.c) both the
copyright statement and the
MODULE_LICENSE("GPL");
declaration.
I took this declaration as sufficient evidence that Mediatek
intentionally released it under the GPL. The fact that the whole
code dump contains the GPL COPYING file is extra evidence.
NeilBrown
>
> I do not know John's relationship to mediatek.
>
> commit 8b634a9c7620b15691322cd53071122d2ab249a7
> Author: John Crispin
> Date: Thu Mar 15 07:22:35 2018 +1100
>
> John? Any idea of the providence of these files?
>
> I do not see anything like it in
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/mediatek;h=ad50ab7e407372a482aafb4183c4e49e25f93739;hb=refs/tags/v18.06.1
signature.asc
Description: PGP signature
Re: [PATCH v2] staging: mt7621-mmc: Fix single statement macros in sd.c
On Tue, Sep 25 2018, Joe Perches wrote:
> On Tue, 2018-09-25 at 20:49 +0200, Greg Kroah-Hartman wrote:
>> On Sun, Sep 23, 2018 at 06:31:32AM -0700, Joe Perches wrote:
>> > On Sun, 2018-09-23 at 15:08 +0530, Nishad Kamdar wrote:
>> > > This patch fixes a few single statement macros in sd.c.
>> > > It converts two macros to inline functions. It removes
>> > > five other macros and replaces their usages with calls to
>> > > the function being called in the macro definition.
>> > > Issue found by checkpatch.
>> > >
>> > > Signed-off-by: Nishad Kamdar
>> > > ---
>> > > Changes in v2:
>> > > - Convert msdc_gate_clk() and msdc_ungate_clk() to inline functions.
>> > > - Delete msdc_irq_restore(), msdc_vcore_on(), msdc_vcore_off(),
>> > > msdc_vdd_on() and msdc_vdd_off() and replace their usages directly
>> > > with calls to the function being called by these macros.
>> >
>> > Nishad, do please look again for uses of these functions
>> > you are changing.
>> >
>> > Please try removing all the #if 0 blocks instead, and then
>> > see if there are also now unused functions from those removed
>> > blocks that could also be removed.
>> >
>> > And Greg, if you look at this, look at the odd license of
>> > these files.
>> >
>> > It's possible the license is incompatible with the GPL.
>>
>> It is odd, but the GPL at the bottom of the file kind of implies it is
>> ok.
>
> Implications are not licenses.
>
>> Given that it was published by mtk, I am assuming all is good, but
>> it would be a good idea to check with the authors to fix this up
>> properly.
>
> The initial patch was submitted by
> John Crispin
Actually it was submitted by me. I extracted it from libreCMC (I think -
it is in most of the various openWRT-like distros).
In libreCMC the patch has John listed as the Author, and I thought it
right to preserve that.
I believe the code comes from a code-dump made by Mediatek several years
ago. It can be found at git://github.com/mqmaker/linux.git.
The code there contains (in drivers/mmc/host/mtk-mmc/sd.c) both the
copyright statement and the
MODULE_LICENSE("GPL");
declaration.
I took this declaration as sufficient evidence that Mediatek
intentionally released it under the GPL. The fact that the whole
code dump contains the GPL COPYING file is extra evidence.
NeilBrown
>
> I do not know John's relationship to mediatek.
>
> commit 8b634a9c7620b15691322cd53071122d2ab249a7
> Author: John Crispin
> Date: Thu Mar 15 07:22:35 2018 +1100
>
> John? Any idea of the providence of these files?
>
> I do not see anything like it in
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/mediatek;h=ad50ab7e407372a482aafb4183c4e49e25f93739;hb=refs/tags/v18.06.1
signature.asc
Description: PGP signature
linux-next: manual merge of the vfio tree with the vfs tree
Hi Alex,
Today's linux-next merge of the vfio tree got a conflict in:
drivers/vfio/Kconfig
between commit:
f57d445eb317 ("Make anon_inodes unconditional")
from the vfs tree and commit:
cf3f98c7f466 ("drivers/vfio: Allow type-1 IOMMU instantiation with all
ARM/ARM64 IOMMUs")
from the vfio 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 drivers/vfio/Kconfig
index 9aa91e736023,9de5ed38da83..
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@@ -21,7 -21,8 +21,7 @@@ config VFIO_VIRQF
menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
- select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3)
+ select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM || ARM64)
- select ANON_INODES
help
VFIO provides a framework for secure userspace device drivers.
See Documentation/vfio.txt for more details.
pgpmH3zmw3uNk.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the vfio tree with the vfs tree
Hi Alex,
Today's linux-next merge of the vfio tree got a conflict in:
drivers/vfio/Kconfig
between commit:
f57d445eb317 ("Make anon_inodes unconditional")
from the vfs tree and commit:
cf3f98c7f466 ("drivers/vfio: Allow type-1 IOMMU instantiation with all
ARM/ARM64 IOMMUs")
from the vfio 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 drivers/vfio/Kconfig
index 9aa91e736023,9de5ed38da83..
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@@ -21,7 -21,8 +21,7 @@@ config VFIO_VIRQF
menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
- select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3)
+ select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM || ARM64)
- select ANON_INODES
help
VFIO provides a framework for secure userspace device drivers.
See Documentation/vfio.txt for more details.
pgpmH3zmw3uNk.pgp
Description: OpenPGP digital signature
