Re: [PATCH] drivers: isdn: capi: Fix data-race bug
On Fri, Jul 24, 2020 at 10:18:07AM +0530, Madhuparna Bhowmik wrote: > On Thu, Jul 23, 2020 at 03:11:58PM -0700, David Miller wrote: > > From: madhuparnabhowmi...@gmail.com > > Date: Wed, 22 Jul 2020 22:53:29 +0530 > > > > > From: Madhuparna Bhowmik > > > > > > In capi_init(), after register_chrdev() the file operation callbacks > > > can be called. However capinc_tty_init() is called later. > > > Since capiminors and capinc_tty_driver are initialized in > > > capinc_tty_init(), their initialization can race with their usage > > > in various callbacks like in capi_release(). > > > > > > Therefore, call capinc_tty_init() before register_chrdev to avoid > > > such race conditions. > > > > > > Found by Linux Driver Verification project (linuxtesting.org). > > > > > > Signed-off-by: Madhuparna Bhowmik > > > > I agree with Arnd that this just exchanges one set of problems for > > another. > > Thanks Arnd and David, for reviewing the patch. > Do you have any suggestions on how to fix this correctly? Based on the installed base of ISDN systems, and the fact that no one has ever actually hit this race and reported it ever, I wouldn't worry about it :) thanks, greg k-h
[PATCH v5 01/16] dt-bindings: clk: sunxi-ccu: add compatible string for A100 CCU and R-CCU
From: Yangtao Li This patch adds binding to a100's ccu clock and r-ccu clock. Signed-off-by: Yangtao Li Reviewed-by: Rob Herring --- .../devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml index 4d382128b711..3b45344ed758 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml @@ -36,6 +36,8 @@ properties: - allwinner,sun9i-a80-ccu - allwinner,sun50i-a64-ccu - allwinner,sun50i-a64-r-ccu + - allwinner,sun50i-a100-ccu + - allwinner,sun50i-a100-r-ccu - allwinner,sun50i-h5-ccu - allwinner,sun50i-h6-ccu - allwinner,sun50i-h6-r-ccu @@ -78,6 +80,7 @@ if: - allwinner,sun8i-a83t-r-ccu - allwinner,sun8i-h3-r-ccu - allwinner,sun50i-a64-r-ccu +- allwinner,sun50i-a100-r-ccu - allwinner,sun50i-h6-r-ccu then: @@ -94,7 +97,9 @@ else: if: properties: compatible: -const: allwinner,sun50i-h6-ccu +enum: + - allwinner,sun50i-a100-ccu + - allwinner,sun50i-h6-ccu then: properties: -- 2.24.0
Re: [PATCH v3 2/2] soc: mediatek: add mtk-devapc driver
Hi Chun-Kuang,
On Fri, 2020-07-24 at 00:32 +0800, Chun-Kuang Hu wrote:
> Hi, Neal:
>
> Neal Liu 於 2020年7月23日 週四 下午2:11寫道：
> >
> > Hi Chun-Kuang,
> >
> > On Wed, 2020-07-22 at 22:25 +0800, Chun-Kuang Hu wrote:
> > > Hi, Neal:
> > >
> > > Neal Liu 於 2020年7月22日 週三 上午11:49寫道：
> > > >
> > > > Hi Chun-Kuang,
> > > >
> > > > On Wed, 2020-07-22 at 07:21 +0800, Chun-Kuang Hu wrote:
> > > > > Hi, Neal:
> > > > >
> > > > > Neal Liu 於 2020年7月21日 週二 下午12:00寫道：
> > > > > >
> > > > >
> > > > > > +
> > > > > > +/*
> > > > > > + * mtk_devapc_dump_vio_dbg - get the violation index and dump the
> > > > > > full violation
> > > > > > + * debug information.
> > > > > > + */
> > > > > > +static bool mtk_devapc_dump_vio_dbg(struct mtk_devapc_context
> > > > > > *ctx, u32 vio_idx)
> > > > > > +{
> > > > > > + u32 shift_bit;
> > > > > > +
> > > > > > + if (check_vio_mask(ctx, vio_idx))
> > > > > > + return false;
> > > > > > +
> > > > > > + if (!check_vio_status(ctx, vio_idx))
> > > > > > + return false;
> > > > > > +
> > > > > > + shift_bit = get_shift_group(ctx, vio_idx);
> > > > > > +
> > > > > > + if (sync_vio_dbg(ctx, shift_bit))
> > > > > > + return false;
> > > > > > +
> > > > > > + devapc_extract_vio_dbg(ctx);
> > > > >
> > > > > I think get_shift_group(), sync_vio_dbg(), and
> > > > > devapc_extract_vio_dbg() should be moved out of vio_idx for-loop (the
> > > > > loop in devapc_violation_irq()) because these three function is not
> > > > > related to vio_idx.
> > > > > Another question: when multiple vio_idx violation occur, vio_addr is
> > > > > related to which one vio_idx? The latest happened one?
> > > > >
> > > >
> > > > Actually, it's related to vio_idx. But we don't use it directly on these
> > > > function. I think below snip code might be better way to understand it.
> > > >
> > > > for (...)
> > > > {
> > > > check_vio_mask()
> > > > check_vio_status()
> > > >
> > > > // if get vio_idx, mask it temporarily
> > > > mask_module_irq(true)
> > > > clear_vio_status()
> > > >
> > > > // dump violation info
> > > > get_shift_group()
> > > > sync_vio_dbg()
> > > > devapc_extract_vio_dbg()
> > > >
> > > > // unmask
> > > > mask_module_irq(false)
> > > > }
> > >
> > > This snip code does not explain any thing. I could rewrite this code as:
> > >
> > > for (...)
> > > {
> > > check_vio_mask()
> > > check_vio_status()
> > >
> > > // if get vio_idx, mask it temporarily
> > > mask_module_irq(true)
> > > clear_vio_status()
> > > // unmask
> > > mask_module_irq(false)
> > > }
> > >
> > > // dump violation info
> > > get_shift_group()
> > > sync_vio_dbg()
> > > devapc_extract_vio_dbg()
> > >
> > > And my version is identical with your version, isn't it?
> >
> > Sorry, I did not explain it clearly. Let's me try again.
> > The reason why I put "dump violation info" between mask & unmask context
> > is because it has to stop interrupt first before dump violation info,
> > and then unmask it to prepare next violation.
> > These sequence guarantee that if multiple violation is triggered, we
> > still have information to debug.
> > If the code sequence in your version and multiple violation is
> > triggered, there might be no any information but keeps entering ISR.
> > Finally, system might be abnormal and watchdog timeout.
> > In this case, we still don't have any information to debug.
>
> I still don't understand why no information to debug. For example when
> vio_idx 5, 10, 15 has violation,
> You would mask vio_idx 5 to get information, but vio_idx 10, 15 does
> not mask yet.
> In your words, when vio_idx 10, 15 not mask, you would not get any
> debug information when you process vio_idx 5.
>
> In my version, I would clear all status, why keeps entering ISR?
Think about this case, if someone tries to dump "AAA" module's register.
It would keep read reg base, base+0x4, base+0x8, ...
All these registers are in the same slave, which would be same vio_idx.
(Take vio_idx 5 as example)
In this case, vio_idx 5 will keep triggering interrupt. If you did not
do "dump violation info" between mask & unmask, you cannot get any
violation info until the last interrupt being handled.
Normally, system will crash before last interrupt coming.
>
> >
> > >
> > > >
> > > > About your question, vio_addr would be the first one.
> > >
> > > So other vio_addr would be dropped? Or hardware would keep all
> > > vio_addr and you have some way to get all vio_addr?
> > >
> >
> > In this case, hardware will drop other violation info and keep the first
> > one until it been handled.
>
> Does 'handled' mean status is cleared?
"handled" means clear status and dump violation info.
>
> Regards,
> Chun-Kuang.
>
> >
> > > >
> > > > > > +
> > > > > > + return true;
> > > > > > +}
> > > > > > +
> > > > > > +/*
> > > > > > + * deva
[PATCH v5 00/16] Allwinner A100 Initial support
This patch set adds initial support for allwinner a100 soc, which is a 64-bit tablet chip. v5: -Drop redundant SOB for thermal series patch -Trival a100 dtsi fix v4: -Drop "dt-bindings: pinctrl: sunxi: make gpio banks supplies required" -Fix dcdc1 regulator name -Get rid of underscore in dts node name -Some trivial things in yaml files v3: -Add pmu and nmi support -Add read data mask for calibration -Code style -Some trivial things in yaml files v2: -Some naming consistency -Repair email address -Fix mmc clock -Don't export system clock -Fix checkpatch warning -Drop unneeded pin function, convert to jtag_gpu and i2s_x Yangtao Li (16): dt-bindings: clk: sunxi-ccu: add compatible string for A100 CCU and R-CCU clk: sunxi-ng: add support for the Allwinner A100 CCU dt-bindings: pinctrl: sunxi: Get rid of continual nesting dt-bindings: pinctrl: sunxi: Add A100 pinctrl bindings pinctrl: sunxi: add support for the Allwinner A100 pin controller dt-bindings: nvmem: SID: add binding for A100's SID controller dt-bindings: thermal: sun8i: Add binding for A100's THS controller thermal: sun8i: add TEMP_CALIB_MASK for calibration data in sun50i_h6_ths_calibrate thermal: sun8i: Add A100's THS controller support mfd: axp20x: Allow the AXP803 to be probed by I2C dt-bindings: irq: sun7i-nmi: fix dt-binding for a80 nmi dt-bindings: irq: sun7i-nmi: Add binding for A100's NMI controller dt-bindings: i2c: mv64xxx: Add compatible for the A100 i2c node. arm64: allwinner: A100: add the basical Allwinner A100 DTSI file dt-bindings: arm: sunxi: Add Allwinner A100 Perf1 Board bindings arm64: allwinner: A100: add support for Allwinner Perf1 board .../devicetree/bindings/arm/sunxi.yaml|5 + .../clock/allwinner,sun4i-a10-ccu.yaml|7 +- .../bindings/i2c/marvell,mv64xxx-i2c.yaml |3 + .../allwinner,sun7i-a20-sc-nmi.yaml |5 +- .../nvmem/allwinner,sun4i-a10-sid.yaml| 19 +- .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 139 +- .../thermal/allwinner,sun8i-a83t-ths.yaml |6 +- arch/arm64/boot/dts/allwinner/Makefile|1 + .../allwinner/sun50i-a100-allwinner-perf1.dts | 180 +++ .../arm64/boot/dts/allwinner/sun50i-a100.dtsi | 364 + drivers/clk/sunxi-ng/Kconfig | 10 + drivers/clk/sunxi-ng/Makefile |2 + drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c | 214 +++ drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h | 21 + drivers/clk/sunxi-ng/ccu-sun50i-a100.c| 1276 + drivers/clk/sunxi-ng/ccu-sun50i-a100.h| 56 + drivers/mfd/axp20x-i2c.c |2 + drivers/pinctrl/sunxi/Kconfig | 10 + drivers/pinctrl/sunxi/Makefile|2 + drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c | 105 ++ drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c | 708 + drivers/thermal/sun8i_thermal.c | 16 +- include/dt-bindings/clock/sun50i-a100-ccu.h | 116 ++ include/dt-bindings/clock/sun50i-a100-r-ccu.h | 23 + include/dt-bindings/reset/sun50i-a100-ccu.h | 68 + include/dt-bindings/reset/sun50i-a100-r-ccu.h | 18 + 26 files changed, 3308 insertions(+), 68 deletions(-) create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.h create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c create mode 100644 include/dt-bindings/clock/sun50i-a100-ccu.h create mode 100644 include/dt-bindings/clock/sun50i-a100-r-ccu.h create mode 100644 include/dt-bindings/reset/sun50i-a100-ccu.h create mode 100644 include/dt-bindings/reset/sun50i-a100-r-ccu.h -- 2.24.0
arm-linux-gnueabi-ld: section .data VMA overlaps section .ARM.unwind_idx VMA
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f37e99aca03f63aa3f2bd13ceaf769455d12c4b0 commit: 58ad13729a8a3e0a354de46eaf9969f9116d4763 vdpa: make vhost, virtio depend on menu date: 3 months ago config: arm-randconfig-s032-20200723 (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty git checkout 58ad13729a8a3e0a354de46eaf9969f9116d4763 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> arm-linux-gnueabi-ld: section .data VMA [40008000,402725b3] >> overlaps section .ARM.unwind_idx VMA [3ffb6aa8,4000a7af] >> arm-linux-gnueabi-ld: section .ARM.unwind_tab VMA >> [4000a7b0,4000b68b] overlaps section .data VMA >> [40008000,402725b3] --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
net/core/pktgen.c:720:21: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f37e99aca03f63aa3f2bd13ceaf769455d12c4b0 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 5 weeks ago config: sh-randconfig-s031-20200724 (attached as .config) compiler: sh4-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sh If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) net/core/pktgen.c:720:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char const *__gu_addr @@ got char const [noderef] __user * @@ net/core/pktgen.c:720:21: sparse: expected char const *__gu_addr net/core/pktgen.c:720:21: sparse: got char const [noderef] __user * >> net/core/pktgen.c:720:21: sparse: sparse: incorrect type in argument 1 >> (different address spaces) @@ expected void const volatile [noderef] >> __user * @@ got char const *__gu_addr @@ >> net/core/pktgen.c:720:21: sparse: expected void const volatile [noderef] >> __user * net/core/pktgen.c:720:21: sparse: got char const *__gu_addr net/core/pktgen.c:738:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char const *__gu_addr @@ got char const [noderef] __user * @@ net/core/pktgen.c:738:21: sparse: expected char const *__gu_addr net/core/pktgen.c:738:21: sparse: got char const [noderef] __user * net/core/pktgen.c:738:21: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __user * @@ got char const *__gu_addr @@ net/core/pktgen.c:738:21: sparse: expected void const volatile [noderef] __user * net/core/pktgen.c:738:21: sparse: got char const *__gu_addr net/core/pktgen.c:764:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char const *__gu_addr @@ got char const [noderef] __user * @@ net/core/pktgen.c:764:21: sparse: expected char const *__gu_addr net/core/pktgen.c:764:21: sparse: got char const [noderef] __user * net/core/pktgen.c:764:21: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __user * @@ got char const *__gu_addr @@ net/core/pktgen.c:764:21: sparse: expected void const volatile [noderef] __user * net/core/pktgen.c:764:21: sparse: got char const *__gu_addr net/core/pktgen.c:781:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char const *__gu_addr @@ got char const [noderef] __user * @@ net/core/pktgen.c:781:21: sparse: expected char const *__gu_addr net/core/pktgen.c:781:21: sparse: got char const [noderef] __user * net/core/pktgen.c:781:21: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __user * @@ got char const *__gu_addr @@ net/core/pktgen.c:781:21: sparse: expected void const volatile [noderef] __user * net/core/pktgen.c:781:21: sparse: got char const *__gu_addr net/core/pktgen.c:815:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char const *__gu_addr @@ got char const [noderef] __user * @@ net/core/pktgen.c:815:21: sparse: expected char const *__gu_addr net/core/pktgen.c:815:21: sparse: got char const [noderef] __user * net/core/pktgen.c:815:21: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __user * @@ got char const *__gu_addr @@ net/core/pktgen.c:815:21: sparse: expected void const volatile [noderef] __user * net/core/pktgen.c:815:21: sparse: got char const *__gu_addr -- >> fs/nfsd/nfs4recover.c:800:13: sparse: sparse: incorrect type in initializer >> (different address spaces) @@ expected unsigned char const *__gu_addr @@ >> got unsigned char const [noderef] __user * @@ fs/nfsd/nfs4recover.c:800:13: sparse: expected unsigned char const *__gu_addr >> fs/nfsd/nfs4recover.c:800:13: sparse: got unsigned char const [noderef] >> __user * >> fs/nfsd/nfs4recover.c:800:13: sparse: sparse: incorrect type in argument 1 >> (different address spaces) @@ expected void const volatile [noderef] >> __user * @@ got unsigned char const *__gu
[GIT PULL] tpmdd update for Linux v5.9
Hi An issue was fixed with the TPM space buffer size. The buffer is used to store in-TPM objects while swapped out of the TPM for a /dev/tpmrm0 session. The code incorrectly used PAGE_SIZE, which obviously can vary. With v5.9 changes the buffer has a fixed size of 16 kB. In addition, the PR contains support for acquiring TPM even log from TPM2 ACPI table. This method is used by QEMU in particular. /Jarkko The following changes since commit f37e99aca03f63aa3f2bd13ceaf769455d12c4b0: Merge tag 's390-5.8-6' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux into master (2020-07-23 13:42:46 -0700) are available in the Git repository at: git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-v5.9 for you to fetch changes up to 85467f63a05c43364ba0b90d0c05bb89191543fa: tpm: Add support for event log pointer found in TPM2 ACPI table (2020-07-24 09:29:21 +0300) tpmdd updates for Linux v5.9 Jarkko Sakkinen (1): tpm: Unify the mismatching TPM space buffer sizes Stefan Berger (2): acpi: Extend TPM2 ACPI table with missing log fields tpm: Add support for event log pointer found in TPM2 ACPI table Tyler Hicks (1): tpm: Require that all digests are present in TCG_PCR_EVENT2 structures drivers/char/tpm/eventlog/acpi.c | 63 ++-- drivers/char/tpm/tpm-chip.c | 9 ++ drivers/char/tpm/tpm.h | 5 +++- drivers/char/tpm/tpm2-space.c| 26 ++--- drivers/char/tpm/tpmrm-dev.c | 2 +- include/acpi/actbl3.h| 7 + include/linux/tpm.h | 1 + include/linux/tpm_eventlog.h | 11 +-- 8 files changed, 82 insertions(+), 42 deletions(-)
Re: [PATCH v2 04/20] unify generic instances of csum_partial_copy_nocheck()
On Fri, Jul 24, 2020 at 02:25:30AM +0100, Al Viro wrote: > From: Al Viro > > quite a few architectures have the same csum_partial_copy_nocheck() - > simply memcpy() the data and then return the csum of the copy. > > hexagon, parisc, ia64, s390, um: explicitly spelled out that way. > > arc, arm64, csky, h8300, m68k/nommu, microblaze, mips/GENERIC_CSUM, nds32, > nios2, openrisc, riscv, unicore32: end up picking the same thing spelled > out in lib/checksum.h (with varying amounts of perversions along the way). > > everybody else (alpha, arm, c6x, m68k/mmu, mips/!GENERIC_CSUM, powerpc, > sh, sparc, x86, xtensa) have non-generic variants. For all except c6x > the declaration is in their asm/checksum.h. c6x uses the wrapper > from asm-generic/checksum.h that would normally lead to the lib/checksum.h > instance, but in case of c6x we end up using an asm function from arch/c6x > instead. > > Screw that mess - have architectures with private instances define > _HAVE_ARCH_CSUM_AND_COPY in their asm/checksum.h and have the default > one right in net/checksum.h conditional on _HAVE_ARCH_CSUM_AND_COPY > *not* defined. net-next has a patch from me killing off csum_and_copy_from_user already: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=f1bfd71c8662f20d53e71ef4e18bfb0e5677c27f
Re: [PATCH 4/4] dt-binding: mediatek: mt8192: update mtk-wdt document
On Fri, 2020-07-24 at 06:02 +0800, Matthias Brugger wrote: > > On 23/07/2020 23:29, Rob Herring wrote: > > On Thu, Jul 23, 2020 at 05:07:31PM +0800, Seiya Wang wrote: > >> From: Crystal Guo > >> > >> update mtk-wdt document for MT8192 platform > >> > >> Signed-off-by: Crystal Guo > >> --- > >> Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > >> b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > >> index 4dd36bd3f1ad..d760ca8a630e 100644 > >> --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > >> +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > >> @@ -12,6 +12,8 @@ Required properties: > >>"mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 > >>"mediatek,mt8183-wdt", "mediatek,mt6589-wdt": for MT8183 > >>"mediatek,mt8516-wdt", "mediatek,mt6589-wdt": for MT8516 > >> + "mediatek,mt8192-wdt": for MT8192 > >> + > > > > So, not compatible with "mediatek,mt6589-wdt"? Is so, perhaps summarize > > what the differences are. > > > > Hm, looks to me as if the binding description for mt2712 and mt8183 isn't > correct, as we have a OF data just as we have for mt8192 now. Could you fix > this > in a separate patch? > > Regards, > Matthias > > Besides watchdog, mt8192 toprgu module also provide sub-system software reset > features. > mt2712 and mt8183 are same as mt8192. But mt6589 not support sub-system > software reset. > > >> > >> - reg : Specifies base physical address and size of the registers. > >> > >> -- > >> 2.14.1
Re: [PATCH v2 2/3] powerpc/powernv/idle: save-restore DAWR0,DAWRX0 for P10
On 24/07/20 6:55 am, Michael Neuling wrote:
On Fri, 2020-07-10 at 10:52 +0530, Pratik Rajesh Sampat wrote:
Additional registers DAWR0, DAWRX0 may be lost on Power 10 for
stop levels < 4.
Therefore save the values of these SPRs before entering a "stop"
state and restore their values on wakeup.
Signed-off-by: Pratik Rajesh Sampat
---
arch/powerpc/platforms/powernv/idle.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index 19d94d021357..f2e2a6a4c274 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -600,6 +600,8 @@ struct p9_sprs {
u64 iamr;
u64 amor;
u64 uamor;
+ u64 dawr0;
+ u64 dawrx0;
};
static unsigned long power9_idle_stop(unsigned long psscr, bool mmu_on)
@@ -687,6 +689,10 @@ static unsigned long power9_idle_stop(unsigned long
psscr, bool mmu_on)
sprs.iamr = mfspr(SPRN_IAMR);
sprs.amor = mfspr(SPRN_AMOR);
sprs.uamor = mfspr(SPRN_UAMOR);
+ if (cpu_has_feature(CPU_FTR_ARCH_31)) {
You are actually viewing an old version of the patches
The main point of change were based on comments from Nick Piggin, I
have changed the top level function check from ARCH_300 to a P9 PVR
check instead.
A similar thing needs to be done for P10, however as the P10 PVR isn't
exposed yet, I've shelved this particular patch.
Nick's comment to check based on PVR:https://lkml.org/lkml/2020/7/13/1018
v4 of the series:https://lkml.org/lkml/2020/7/21/784
Thanks for your review,
Pratik
Can you add a comment here saying even though DAWR0 is ARCH_30, it's only
required to be saved on 31. Otherwise this looks pretty odd.
+ sprs.dawr0 = mfspr(SPRN_DAWR0);
+ sprs.dawrx0 = mfspr(SPRN_DAWRX0);
+ }
srr1 = isa300_idle_stop_mayloss(psscr); /* go idle */
@@ -710,6 +716,10 @@ static unsigned long power9_idle_stop(unsigned long
psscr, bool mmu_on)
mtspr(SPRN_IAMR,sprs.iamr);
mtspr(SPRN_AMOR,sprs.amor);
mtspr(SPRN_UAMOR, sprs.uamor);
+ if (cpu_has_feature(CPU_FTR_ARCH_31)) {
+ mtspr(SPRN_DAWR0, sprs.dawr0);
+ mtspr(SPRN_DAWRX0, sprs.dawrx0);
+ }
/*
* Workaround for POWER9 DD2.0, if we lost resources, the ERAT
Re: [PATCH] xen-netfront: fix potential deadlock in xennet_remove()
On Thu, Jul 23, 2020 at 02:57:22PM -0700, David Miller wrote:
> From: Andrea Righi
> Date: Wed, 22 Jul 2020 08:52:11 +0200
>
> > +static int xennet_remove(struct xenbus_device *dev)
> > +{
> > + struct netfront_info *info = dev_get_drvdata(&dev->dev);
> > +
> > + dev_dbg(&dev->dev, "%s\n", dev->nodename);
>
> These kinds of debugging messages provide zero context and are so much
> less useful than simply using tracepoints which are more universally
> available than printk debugging facilities.
>
> Please remove all of the dev_dbg() calls from this patch.
I didn't add that dev_dbg() call, it's just the old code moved around,
but I agree, I'll remove that call and send a new version of this patch.
Thanks for looking at it!
-Andrea
[PATCH] newport_con: vc_color is now in state
Since commit 28bc24fc46f9 (vc: separate state), vc->vc_color is known as
vc->state.color. Somehow both me and 0-day bot missed this driver during
the conversion.
So fix the driver now.
Signed-off-by: Jiri Slaby
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-de...@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-m...@vger.kernel.org
---
drivers/video/console/newport_con.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/console/newport_con.c
b/drivers/video/console/newport_con.c
index df3c52d72159..72f146d047d9 100644
--- a/drivers/video/console/newport_con.c
+++ b/drivers/video/console/newport_con.c
@@ -362,12 +362,12 @@ static void newport_clear(struct vc_data *vc, int sy, int
sx, int height,
if (ystart < yend) {
newport_clear_screen(sx << 3, ystart, xend, yend,
-(vc->vc_color & 0xf0) >> 4);
+(vc->state.color & 0xf0) >> 4);
} else {
newport_clear_screen(sx << 3, ystart, xend, 1023,
-(vc->vc_color & 0xf0) >> 4);
+(vc->state.color & 0xf0) >> 4);
newport_clear_screen(sx << 3, 0, xend, yend,
-(vc->vc_color & 0xf0) >> 4);
+(vc->state.color & 0xf0) >> 4);
}
}
@@ -591,11 +591,11 @@ static bool newport_scroll(struct vc_data *vc, unsigned
int t, unsigned int b,
topscan = (topscan + (lines << 4)) & 0x3ff;
newport_clear_lines(vc->vc_rows - lines,
vc->vc_rows - 1,
- (vc->vc_color & 0xf0) >> 4);
+ (vc->state.color & 0xf0) >> 4);
} else {
topscan = (topscan + (-lines << 4)) & 0x3ff;
newport_clear_lines(0, lines - 1,
- (vc->vc_color & 0xf0) >> 4);
+ (vc->state.color & 0xf0) >> 4);
}
npregs->cset.topscan = (topscan - 1) & 0x3ff;
return false;
--
2.27.0
Re: [PATCH v4 14/16] arm64: allwinner: A100: add the basical Allwinner A100 DTSI file
HI,
On Fri, Jul 24, 2020 at 12:54 AM Maxime Ripard wrote:
>
> Hi,
>
> On Tue, Jul 14, 2020 at 03:20:29PM +0800, Frank Lee wrote:
> > From: Yangtao Li
> >
> > Allwinner A100 is a new SoC with Cortex-A53 cores, this commit adds
> > the basical DTSI file of it, including the clock, i2c, pins, sid, ths,
> > nmi, and UART support.
> >
> > Signed-off-by: Yangtao Li
> > ---
> > .../arm64/boot/dts/allwinner/sun50i-a100.dtsi | 364 ++
> > 1 file changed, 364 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > new file mode 100644
> > index ..3fb2443f2121
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > @@ -0,0 +1,364 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (c) 2020 Yangtao Li
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/ {
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + compatible = "arm,armv8";
>
> You should use the arm,cortex-a53 compatible here, arm,armv8 is for
> software models.
>
> > + sid@3006000 {
>
> The node name is supposed to be the class of the device, and the DT spec
> defines a list of them already. eeprom would be better suited here.
EFuse is more accurate?
Thx,
Yangtao
RE: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON
> -Original Message- > From: Johannes Berg > Sent: Friday, July 24, 2020 1:37 AM > To: Rakesh Pillai ; ath...@lists.infradead.org > Cc: linux-wirel...@vger.kernel.org; linux-kernel@vger.kernel.org; > kv...@codeaurora.org; da...@davemloft.net; k...@kernel.org; > net...@vger.kernel.org; diand...@chromium.org; evgr...@chromium.org > Subject: Re: [RFC 1/7] mac80211: Add check for napi handle before > WARN_ON > > On Thu, 2020-07-23 at 23:56 +0530, Rakesh Pillai wrote: > > > > > - WARN_ON_ONCE(softirq_count() == 0); > > > > + WARN_ON_ONCE(napi && softirq_count() == 0); > > > > > > FWIW, I'm pretty sure this is incorrect - we make assumptions on > > > softirqs being disabled in mac80211 for serialization and in place of > > > some locking, I believe. > > > > > > > I checked this, but let me double confirm. > > But after this change, no packet is submitted from driver in a softirq > context. > > So ideally this should take care of serialization. > > I'd guess that we have some reliance on BHs already being disabled, for > things like u64 sync updates, or whatnot. I mean, we did "rx_ni()" for a > reason ... Maybe lockdep can help catch some of the issues. > > But couldn't you be in a thread and have BHs disabled too? This would ideally beat the purpose and possibly hurt the other subsystems running on the same core. > > johannes
RE: [RFC 0/7] Add support to process rx packets in thread
> -Original Message- > From: Florian Fainelli > Sent: Friday, July 24, 2020 12:33 AM > To: Rakesh Pillai ; 'Andrew Lunn' > > Cc: ath...@lists.infradead.org; linux-wirel...@vger.kernel.org; linux- > ker...@vger.kernel.org; kv...@codeaurora.org; johan...@sipsolutions.net; > da...@davemloft.net; k...@kernel.org; net...@vger.kernel.org; > diand...@chromium.org; evgr...@chromium.org > Subject: Re: [RFC 0/7] Add support to process rx packets in thread > > On 7/23/20 11:21 AM, Rakesh Pillai wrote: > > > > > >> -Original Message- > >> From: Florian Fainelli > >> Sent: Tuesday, July 21, 2020 11:35 PM > >> To: Andrew Lunn ; Rakesh Pillai > > >> Cc: ath...@lists.infradead.org; linux-wirel...@vger.kernel.org; linux- > >> ker...@vger.kernel.org; kv...@codeaurora.org; > johan...@sipsolutions.net; > >> da...@davemloft.net; k...@kernel.org; net...@vger.kernel.org; > >> diand...@chromium.org; evgr...@chromium.org > >> Subject: Re: [RFC 0/7] Add support to process rx packets in thread > >> > >> On 7/21/20 10:25 AM, Andrew Lunn wrote: > >>> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote: > NAPI gets scheduled on the CPU core which got the > interrupt. The linux scheduler cannot move it to a > different core, even if the CPU on which NAPI is running > is heavily loaded. This can lead to degraded wifi > performance when running traffic at peak data rates. > > A thread on the other hand can be moved to different > CPU cores, if the one on which its running is heavily > loaded. During high incoming data traffic, this gives > better performance, since the thread can be moved to a > less loaded or sometimes even a more powerful CPU core > to account for the required CPU performance in order > to process the incoming packets. > > This patch series adds the support to use a high priority > thread to process the incoming packets, as opposed to > everything being done in NAPI context. > >>> > >>> I don't see why this problem is limited to the ath10k driver. I expect > >>> it applies to all drivers using NAPI. So shouldn't you be solving this > >>> in the NAPI core? Allow a driver to request the NAPI core uses a > >>> thread? > >> > >> What's more, you should be able to configure interrupt affinity to steer > >> RX processing onto a desired CPU core, is not that working for you > >> somehow? > > > > Hi Florian, > > Yes, the affinity of IRQ does work for me. > > But the affinity of IRQ does not happen runtime based on load. > > It can if you also run irqbalance. Hi Florian, Is it some kernel feature ? Sorry I am not aware of this ? I know it can be done in userspace. > -- > Florian
RE: [RFC 7/7] ath10k: Handle rx thread suspend and resume
> -Original Message-
> From: Sebastian Gottschall
> Sent: Friday, July 24, 2020 4:36 AM
> To: Rakesh Pillai ; ath...@lists.infradead.org
> Cc: linux-wirel...@vger.kernel.org; linux-kernel@vger.kernel.org;
> kv...@codeaurora.org; johan...@sipsolutions.net; da...@davemloft.net;
> k...@kernel.org; net...@vger.kernel.org; diand...@chromium.org;
> evgr...@chromium.org
> Subject: Re: [RFC 7/7] ath10k: Handle rx thread suspend and resume
>
> your patch seem to only affect the WCN3990 chipset. all other ath10k
> supported chipset are not supported here. so you see a chance to
> implement this more generic?
>
> Sebastian
Hi Sebastian,
A generic core for handling threads is added with this patchset.
So the handling of rx packet processing in thread can always be extended to
other targets, if they wish so.
The thread related APIs are in core.c which gives all the other targets access
to these APIs for using them.
Thanks,
Rakesh Pillai.
>
> Am 21.07.2020 um 19:14 schrieb Rakesh Pillai:
> > During the system suspend or resume, the rx thread
> > also needs to be suspended or resume respectively.
> >
> > Handle the rx thread as well during the system
> > suspend and resume.
> >
> > Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
> >
> > Signed-off-by: Rakesh Pillai
> > ---
> > drivers/net/wireless/ath/ath10k/core.c | 23 ++
> > drivers/net/wireless/ath/ath10k/core.h | 5
> > drivers/net/wireless/ath/ath10k/snoc.c | 44
> +-
> > 3 files changed, 71 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c
> b/drivers/net/wireless/ath/ath10k/core.c
> > index 4064fa2..b82b355 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -668,6 +668,27 @@ static unsigned int
> ath10k_core_get_fw_feature_str(char *buf,
> > return scnprintf(buf, buf_len, "%s",
> ath10k_core_fw_feature_str[feat]);
> > }
> >
> > +int ath10k_core_thread_suspend(struct ath10k_thread *thread)
> > +{
> > + ath10k_dbg(thread->ar, ATH10K_DBG_BOOT, "Suspending thread
> %s\n",
> > + thread->name);
> > + set_bit(ATH10K_THREAD_EVENT_SUSPEND, thread->event_flags);
> > + wait_for_completion(&thread->suspend);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(ath10k_core_thread_suspend);
> > +
> > +int ath10k_core_thread_resume(struct ath10k_thread *thread)
> > +{
> > + ath10k_dbg(thread->ar, ATH10K_DBG_BOOT, "Resuming thread
> %s\n",
> > + thread->name);
> > + complete(&thread->resume);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(ath10k_core_thread_resume);
> > +
> > void ath10k_core_thread_post_event(struct ath10k_thread *thread,
> >enum ath10k_thread_events event)
> > {
> > @@ -700,6 +721,8 @@ int ath10k_core_thread_init(struct ath10k *ar,
> >
> > init_waitqueue_head(&thread->wait_q);
> > init_completion(&thread->shutdown);
> > + init_completion(&thread->suspend);
> > + init_completion(&thread->resume);
> > memcpy(thread->name, thread_name,
> ATH10K_THREAD_NAME_SIZE_MAX);
> > clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN, thread-
> >event_flags);
> > ath10k_info(ar, "Starting thread %s\n", thread_name);
> > diff --git a/drivers/net/wireless/ath/ath10k/core.h
> b/drivers/net/wireless/ath/ath10k/core.h
> > index 596d31b..df65e75 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.h
> > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > @@ -976,6 +976,7 @@ enum ath10k_thread_events {
> > ATH10K_THREAD_EVENT_SHUTDOWN,
> > ATH10K_THREAD_EVENT_RX_POST,
> > ATH10K_THREAD_EVENT_TX_POST,
> > + ATH10K_THREAD_EVENT_SUSPEND,
> > ATH10K_THREAD_EVENT_MAX,
> > };
> >
> > @@ -983,6 +984,8 @@ struct ath10k_thread {
> > struct ath10k *ar;
> > struct task_struct *task;
> > struct completion shutdown;
> > + struct completion suspend;
> > + struct completion resume;
> > wait_queue_head_t wait_q;
> > DECLARE_BITMAP(event_flags, ATH10K_THREAD_EVENT_MAX);
> > char name[ATH10K_THREAD_NAME_SIZE_MAX];
> > @@ -1296,6 +1299,8 @@ static inline bool
> ath10k_peer_stats_enabled(struct ath10k *ar)
> >
> > extern unsigned long ath10k_coredump_mask;
> >
> > +int ath10k_core_thread_suspend(struct ath10k_thread *thread);
> > +int ath10k_core_thread_resume(struct ath10k_thread *thread);
> > void ath10k_core_thread_post_event(struct ath10k_thread *thread,
> >enum ath10k_thread_events event);
> > int ath10k_core_thread_shutdown(struct ath10k *ar,
> > diff --git a/drivers/net/wireless/ath/ath10k/snoc.c
> b/drivers/net/wireless/ath/ath10k/snoc.c
> > index 3eb5eac..a373b2b 100644
> > --- a/drivers/net/wireless/ath/ath10k/snoc.c
> > +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> > @@ -932,13 +932,31 @@ int ath10k_snoc_rx_thread_loop(void *data)
> > rx_thread->event_flags) ||
> >
> test_and_clear_bit(A
Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state
> On 24-Jul-2020, at 9:46 AM, Alexey Kardashevskiy wrote:
>
>
>
> On 23/07/2020 23:11, Nicholas Piggin wrote:
>> Excerpts from Peter Zijlstra's message of July 23, 2020 9:40 pm:
>>> On Thu, Jul 23, 2020 at 08:56:14PM +1000, Nicholas Piggin wrote:
>>>
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index 3a0db7b0b46e..35060be09073 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -200,17 +200,14 @@ static inline bool arch_irqs_disabled(void)
#define powerpc_local_irq_pmu_save(flags) \
do { \
raw_local_irq_pmu_save(flags); \
- trace_hardirqs_off(); \
+ if (!raw_irqs_disabled_flags(flags))\
+ trace_hardirqs_off(); \
} while(0)
#define powerpc_local_irq_pmu_restore(flags) \
do {\
- if (raw_irqs_disabled_flags(flags)) { \
- raw_local_irq_pmu_restore(flags); \
- trace_hardirqs_off(); \
- } else {\
+ if (!raw_irqs_disabled_flags(flags))\
trace_hardirqs_on();\
- raw_local_irq_pmu_restore(flags); \
- } \
+ raw_local_irq_pmu_restore(flags); \
} while(0)
>>>
>>> You shouldn't be calling lockdep from NMI context!
>>
>> After this patch it doesn't.
>>
>> trace_hardirqs_on/off implementation appears to expect to be called in NMI
>> context though, for some reason.
>>
>>> That is, I recently
>>> added suport for that on x86:
>>>
>>> https://lkml.kernel.org/r/20200623083721.155449...@infradead.org
>>> https://lkml.kernel.org/r/20200623083721.216740...@infradead.org
>>>
>>> But you need to be very careful on how you order things, as you can see
>>> the above relies on preempt_count() already having been incremented with
>>> NMI_MASK.
>>
>> Hmm. My patch seems simpler.
>
> And your patches fix my error while Peter's do not:
>
>
> IRQs not enabled as expected
> WARNING: CPU: 0 PID: 1377 at /home/aik/p/kernel/kernel/softirq.c:169
> __local_bh_enable_ip+0x118/0x190
Hi Nicholas, Alexey
I was able to reproduce the warning which Alexey reported using perf_fuzzer
test suite.
With the patch provided by Nick, I don’t see the issue anymore. This patch
fixes the
warnings I got with perf fuzzer run.
Thanks Nick for the fix.
Tested-by: Athira Rajeev
>
>
>>
>> I don't know this stuff very well, I don't really understand what your patch
>> enables for x86 but at least it shouldn't be incompatible with this one
>> AFAIKS.
>>
>> Thanks,
>> Nick
>>
>
> --
> Alexey
[PATCH] tty: serial: qcom_geni_serial: To correct logic for QUP HW version
To correct the logic to detect whether the QUP HW version is greater than 2.5. Signed-off-by: Paras Sharma --- drivers/tty/serial/qcom_geni_serial.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c index 1ed3d35..5b0efb49 100644 --- a/drivers/tty/serial/qcom_geni_serial.c +++ b/drivers/tty/serial/qcom_geni_serial.c @@ -954,7 +954,8 @@ static void qcom_geni_serial_set_termios(struct uart_port *uport, sampling_rate = UART_OVERSAMPLING; /* Sampling rate is halved for IP versions >= 2.5 */ ver = geni_se_get_qup_hw_version(&port->se); - if (GENI_SE_VERSION_MAJOR(ver) >= 2 && GENI_SE_VERSION_MINOR(ver) >= 5) + if ((GENI_SE_VERSION_MAJOR(ver) >= 2 && GENI_SE_VERSION_MINOR(ver) >= 5) + || GENI_SE_VERSION_MAJOR(ver) >= 3) sampling_rate /= 2; clk_rate = get_clk_div_rate(baud, sampling_rate, &clk_div); -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v5 03/10] bus: mhi: core: Use helper API to trigger a non-blocking host resume
On Thu, Jul 23, 2020 at 03:36:35PM -0700, Bhaumik Bhatt wrote:
> Autonomous low power mode support requires the MHI host to resume from
> multiple places and post a wakeup source to exit system suspend. This
> needs to be done in a non-blocking manner. Introduce a helper API to
> trigger the host resume for data transfers and other non-blocking use
> cases while supporting implementation of autonomous low power modes.
>
> Signed-off-by: Bhaumik Bhatt
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> drivers/bus/mhi/core/internal.h | 7 +++
> drivers/bus/mhi/core/main.c | 21 +++--
> drivers/bus/mhi/core/pm.c | 13 -
> 3 files changed, 18 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
> index bcfa7b6..1bbd6e9 100644
> --- a/drivers/bus/mhi/core/internal.h
> +++ b/drivers/bus/mhi/core/internal.h
> @@ -599,6 +599,13 @@ int __mhi_device_get_sync(struct mhi_controller
> *mhi_cntrl);
> int mhi_send_cmd(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan,
>enum mhi_cmd_type cmd);
>
> +static inline void mhi_trigger_resume(struct mhi_controller *mhi_cntrl)
> +{
> + pm_wakeup_event(&mhi_cntrl->mhi_dev->dev, 0);
> + mhi_cntrl->runtime_get(mhi_cntrl);
> + mhi_cntrl->runtime_put(mhi_cntrl);
> +}
> +
> /* Register access methods */
> void mhi_db_brstmode(struct mhi_controller *mhi_cntrl, struct db_cfg *db_cfg,
>void __iomem *db_addr, dma_addr_t db_val);
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 1f622ce..79be18e 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -909,8 +909,7 @@ void mhi_ctrl_ev_task(unsigned long data)
>* process it since we are probably in a suspended state,
>* so trigger a resume.
>*/
> - mhi_cntrl->runtime_get(mhi_cntrl);
> - mhi_cntrl->runtime_put(mhi_cntrl);
> + mhi_trigger_resume(mhi_cntrl);
>
> return;
> }
> @@ -971,10 +970,8 @@ int mhi_queue_skb(struct mhi_device *mhi_dev, enum
> dma_data_direction dir,
> }
>
> /* we're in M3 or transitioning to M3 */
> - if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) {
> - mhi_cntrl->runtime_get(mhi_cntrl);
> - mhi_cntrl->runtime_put(mhi_cntrl);
> - }
> + if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
> + mhi_trigger_resume(mhi_cntrl);
>
> /* Toggle wake to exit out of M2 */
> mhi_cntrl->wake_toggle(mhi_cntrl);
> @@ -1032,10 +1029,8 @@ int mhi_queue_dma(struct mhi_device *mhi_dev, enum
> dma_data_direction dir,
> }
>
> /* we're in M3 or transitioning to M3 */
> - if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) {
> - mhi_cntrl->runtime_get(mhi_cntrl);
> - mhi_cntrl->runtime_put(mhi_cntrl);
> - }
> + if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
> + mhi_trigger_resume(mhi_cntrl);
>
> /* Toggle wake to exit out of M2 */
> mhi_cntrl->wake_toggle(mhi_cntrl);
> @@ -1147,10 +1142,8 @@ int mhi_queue_buf(struct mhi_device *mhi_dev, enum
> dma_data_direction dir,
> read_lock_irqsave(&mhi_cntrl->pm_lock, flags);
>
> /* we're in M3 or transitioning to M3 */
> - if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) {
> - mhi_cntrl->runtime_get(mhi_cntrl);
> - mhi_cntrl->runtime_put(mhi_cntrl);
> - }
> + if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
> + mhi_trigger_resume(mhi_cntrl);
>
> /* Toggle wake to exit out of M2 */
> mhi_cntrl->wake_toggle(mhi_cntrl);
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index 661d704..b227d41 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -824,11 +824,8 @@ int __mhi_device_get_sync(struct mhi_controller
> *mhi_cntrl)
> /* Wake up the device */
> read_lock_bh(&mhi_cntrl->pm_lock);
> mhi_cntrl->wake_get(mhi_cntrl, true);
> - if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) {
> - pm_wakeup_event(&mhi_cntrl->mhi_dev->dev, 0);
> - mhi_cntrl->runtime_get(mhi_cntrl);
> - mhi_cntrl->runtime_put(mhi_cntrl);
> - }
> + if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
> + mhi_trigger_resume(mhi_cntrl);
> read_unlock_bh(&mhi_cntrl->pm_lock);
>
> ret = wait_event_timeout(mhi_cntrl->state_event,
> @@ -1139,10 +1136,8 @@ void mhi_device_put(struct mhi_device *mhi_dev)
>
> mhi_dev->dev_wake--;
> read_lock_bh(&mhi_cntrl->pm_lock);
> - if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state)) {
> - mhi_cntrl->runtime_get(mhi_cntrl);
> - mhi_cntrl->runtime_put(mhi_cntrl);
> - }
> + if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
> + mhi_trigger_resume(mhi_cnt
Re: [f2fs-dev] [PATCH v2] f2fs: fix use-after-free issue in f2fs_put_super()
> During umount, … Do you refer to the action “unmount” here? > f2fs_destroy_segment_manager(), it may cause … Wording adjustments: f2fs_destroy_segment_manager(). It might cause … > … with procfs accessing, … Avoid another typo?: … with procfs accesses, … > …, fix it by … Please replace this wording by the tag “Fixes”. Regards, Markus
Re: WARNING in ptrace_stop
On 07/23, syzbot wrote: > > do not call blocking ops when !TASK_RUNNING; state=8 set at > [<076362f5>] ptrace_stop+0x0/0x9e0 kernel/signal.c:2054 > WARNING: CPU: 1 PID: 17054 at kernel/sched/core.c:6883 > __might_sleep+0x135/0x190 kernel/sched/core.c:6883 #syz fix: sched: Fix race against ptrace_freeze_trace()
[PATCH 2/2] ASoC: max98390: Update dsm init sequence and condition.
Modify dsm_init sequence and dsm param bin check condition.
- Move dsm_init() to after amp init setting to
make sure dsm init is last setting.
- dsm param bin check condition changed for extended register setting.
Signed-off-by: Steve Lee
---
sound/soc/codecs/max98390.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/max98390.c b/sound/soc/codecs/max98390.c
index 44ffebac15ad..ff5cc9bbec29 100644
--- a/sound/soc/codecs/max98390.c
+++ b/sound/soc/codecs/max98390.c
@@ -790,7 +790,7 @@ static int max98390_dsm_init(struct snd_soc_component
*component)
param_start_addr = (dsm_param[0] & 0xff) | (dsm_param[1] & 0xff) << 8;
param_size = (dsm_param[2] & 0xff) | (dsm_param[3] & 0xff) << 8;
if (param_size > MAX98390_DSM_PARAM_MAX_SIZE ||
- param_start_addr < DSM_STBASS_HPF_B0_BYTE0 ||
+ param_start_addr < MAX98390_IRQ_CTRL ||
fw->size < param_size + MAX98390_DSM_PAYLOAD_OFFSET) {
dev_err(component->dev,
"param fw is invalid.\n");
@@ -864,11 +864,11 @@ static int max98390_probe(struct snd_soc_component
*component)
regmap_write(max98390->regmap, MAX98390_SOFTWARE_RESET, 0x01);
/* Sleep reset settle time */
msleep(20);
- /* Update dsm bin param */
- max98390_dsm_init(component);
/* Amp init setting */
max98390_init_regs(component);
+ /* Update dsm bin param */
+ max98390_dsm_init(component);
/* Dsm Setting */
if (max98390->ref_rdc_value) {
--
2.17.1
[PATCH 1/2] ASoC: max98390: Fix dac event dapm mixer.
Global EN register guide to off before AMP_EN register
when amp disable sequence.
- remove AMP_EN control before max98390_dac_event call
Signed-off-by: Steve Lee
---
sound/soc/codecs/max98390.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/max98390.c b/sound/soc/codecs/max98390.c
index 3e8094241645..44ffebac15ad 100644
--- a/sound/soc/codecs/max98390.c
+++ b/sound/soc/codecs/max98390.c
@@ -678,7 +678,7 @@ static const struct snd_kcontrol_new max98390_dai_controls =
static const struct snd_soc_dapm_widget max98390_dapm_widgets[] = {
SND_SOC_DAPM_DAC_E("Amp Enable", "HiFi Playback",
- MAX98390_R203A_AMP_EN, 0, 0, max98390_dac_event,
+ SND_SOC_NOPM, 0, 0, max98390_dac_event,
SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
SND_SOC_DAPM_MUX("DAI Sel Mux", SND_SOC_NOPM, 0, 0,
&max98390_dai_controls),
--
2.17.1
linux-next: manual merge of the phy-next tree with the dmaengine tree
Hi all,
Today's linux-next merge of the phy-next tree got a conflict in:
MAINTAINERS
between commit:
ef9303fdf46f ("dt: bindings: dma: xilinx: dpdma: DT bindings for Xilinx
DPDMA")
from the dmaengine tree and commit:
4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit
Transceiver")
from the phy-next 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 MAINTAINERS
index f9bba40873cc,82a12abe24c6..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -19007,15 -18852,15 +19007,24 @@@ F:
Documentation/devicetree/bindings/me
F:drivers/media/platform/xilinx/
F:include/uapi/linux/xilinx-v4l2-controls.h
+XILINX ZYNQMP DPDMA DRIVER
+M:Hyun Kwon
+M:Laurent Pinchart
+L:dmaeng...@vger.kernel.org
+S:Supported
+F:Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
+F:drivers/dma/xilinx/xilinx_dpdma.c
+F:include/dt-bindings/dma/xlnx-zynqmp-dpdma.h
+
+ XILINX ZYNQMP PSGTR PHY DRIVER
+ M:Anurag Kumar Vulisha
+ M:Laurent Pinchart
+ L:linux-kernel@vger.kernel.org
+ S:Supported
+ T:git https://github.com/Xilinx/linux-xlnx.git
+ F:Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
+ F:drivers/phy/xilinx/phy-zynqmp.c
+
XILLYBUS DRIVER
M:Eli Billauer
L:linux-kernel@vger.kernel.org
pgpSSZDms2P65.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state
Excerpts from Alexey Kardashevskiy's message of July 24, 2020 2:16 pm:
>
>
> On 23/07/2020 23:11, Nicholas Piggin wrote:
>> Excerpts from Peter Zijlstra's message of July 23, 2020 9:40 pm:
>>> On Thu, Jul 23, 2020 at 08:56:14PM +1000, Nicholas Piggin wrote:
>>>
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index 3a0db7b0b46e..35060be09073 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -200,17 +200,14 @@ static inline bool arch_irqs_disabled(void)
#define powerpc_local_irq_pmu_save(flags) \
do { \
raw_local_irq_pmu_save(flags); \
- trace_hardirqs_off(); \
+ if (!raw_irqs_disabled_flags(flags))\
+ trace_hardirqs_off(); \
} while(0)
#define powerpc_local_irq_pmu_restore(flags) \
do {\
- if (raw_irqs_disabled_flags(flags)) { \
- raw_local_irq_pmu_restore(flags); \
- trace_hardirqs_off(); \
- } else {\
+ if (!raw_irqs_disabled_flags(flags))\
trace_hardirqs_on();\
- raw_local_irq_pmu_restore(flags); \
- } \
+ raw_local_irq_pmu_restore(flags); \
} while(0)
>>>
>>> You shouldn't be calling lockdep from NMI context!
>>
>> After this patch it doesn't.
>>
>> trace_hardirqs_on/off implementation appears to expect to be called in NMI
>> context though, for some reason.
>>
>>> That is, I recently
>>> added suport for that on x86:
>>>
>>> https://lkml.kernel.org/r/20200623083721.155449...@infradead.org
>>> https://lkml.kernel.org/r/20200623083721.216740...@infradead.org
>>>
>>> But you need to be very careful on how you order things, as you can see
>>> the above relies on preempt_count() already having been incremented with
>>> NMI_MASK.
>>
>> Hmm. My patch seems simpler.
>
> And your patches fix my error while Peter's do not:
>
>
> IRQs not enabled as expected
> WARNING: CPU: 0 PID: 1377 at /home/aik/p/kernel/kernel/softirq.c:169
> __local_bh_enable_ip+0x118/0x190
I think they would have needed some powerpc bits as well. But I don't
see a reason we can't merge my patches, at least they fix this case and
don't seem to make things worse in any way.
Thanks,
Nick
[PATCH 1/2] arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes
Add PCIe device tree node (both RC and EP) for the four
PCIe instances here.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 218 ++
arch/arm64/boot/dts/ti/k3-j721e.dtsi | 5 +-
2 files changed, 222 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index d14060207f00..2090fcf667a3 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -28,6 +28,26 @@
#size-cells = <1>;
ranges = <0x0 0x0 0x0010 0x1c000>;
+ pcie0_ctrl: pcie-ctrl@4070 {
+ compatible = "syscon";
+ reg = <0x4070 0x4>;
+ };
+
+ pcie1_ctrl: pcie-ctrl@4074 {
+ compatible = "syscon";
+ reg = <0x4074 0x4>;
+ };
+
+ pcie2_ctrl: pcie-ctrl@4078 {
+ compatible = "syscon";
+ reg = <0x4078 0x4>;
+ };
+
+ pcie3_ctrl: pcie-ctrl@407c {
+ compatible = "syscon";
+ reg = <0x407c 0x4>;
+ };
+
serdes_ln_ctrl: serdes-ln-ctrl@4080 {
compatible = "mmio-mux";
reg = <0x4080 0x50>;
@@ -552,6 +572,204 @@
};
};
+ pcie0_rc: pcie@290 {
+ compatible = "ti,j721e-pcie-host";
+ reg = <0x00 0x0290 0x00 0x1000>,
+ <0x00 0x02907000 0x00 0x400>,
+ <0x00 0x0d00 0x00 0x0080>,
+ <0x00 0x1000 0x00 0x1000>;
+ reg-names = "intd_cfg", "user_cfg", "reg", "cfg";
+ interrupt-names = "link_state";
+ interrupts = ;
+ device_type = "pci";
+ ti,syscon-pcie-ctrl = <&pcie0_ctrl>;
+ max-link-speed = <3>;
+ num-lanes = <2>;
+ power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 239 1>;
+ clock-names = "fck";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x0 0xf>;
+ vendor-id = <0x104c>;
+ device-id = <0xb00d>;
+ msi-map = <0x0 &gic_its 0x0 0x1>;
+ dma-coherent;
+ ranges = <0x0100 0x0 0x10001000 0x0 0x10001000 0x0
0x001>,
+<0x0200 0x0 0x10011000 0x0 0x10011000 0x0
0x7fef000>;
+ dma-ranges = <0x0200 0x0 0x0 0x0 0x0 0x1 0x0>;
+ };
+
+ pcie0_ep: pcie-ep@290 {
+ compatible = "ti,j721e-pcie-ep";
+ reg = <0x00 0x0290 0x00 0x1000>,
+ <0x00 0x02907000 0x00 0x400>,
+ <0x00 0x0d00 0x00 0x0080>,
+ <0x00 0x1000 0x00 0x0800>;
+ reg-names = "intd_cfg", "user_cfg", "reg", "mem";
+ interrupt-names = "link_state";
+ interrupts = ;
+ ti,syscon-pcie-ctrl = <&pcie0_ctrl>;
+ max-link-speed = <3>;
+ num-lanes = <2>;
+ power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 239 1>;
+ clock-names = "fck";
+ cdns,max-outbound-regions = <16>;
+ max-functions = /bits/ 8 <6>;
+ max-virtual-functions = /bits/ 16 <4 4 4 4 0 0>;
+ dma-coherent;
+ };
+
+ pcie1_rc: pcie@291 {
+ compatible = "ti,j721e-pcie-host";
+ reg = <0x00 0x0291 0x00 0x1000>,
+ <0x00 0x02917000 0x00 0x400>,
+ <0x00 0x0d80 0x00 0x0080>,
+ <0x00 0x1800 0x00 0x1000>;
+ reg-names = "intd_cfg", "user_cfg", "reg", "cfg";
+ interrupt-names = "link_state";
+ interrupts = ;
+ device_type = "pci";
+ ti,syscon-pcie-ctrl = <&pcie1_ctrl>;
+ max-link-speed = <3>;
+ num-lanes = <2>;
+ power-domains = <&k3_pds 240 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 240 1>;
+ clock-names = "fck";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x0 0xf>;
+ vendor-id = <0x104c>;
+ device-id = <0xb00d>;
+ msi-map = <0x0 &gic_its 0x1 0x1>;
+ dma-coherent;
+ ranges = <0x0100 0x0 0x18001000 0x0 0x18001000 0x0
0x001>,
+<0x0200 0x0 0x18011000 0x0 0x18011000 0x0
0x7fef000>;
+ dma-ranges = <0x0200 0x0 0x0 0x0 0x0 0x1 0x0>;
+ };
+
+ pcie1_ep:
[PATCH 2/2] arm64: dts: ti: k3-j721e-common-proc-board: Configure the PCIe instances
J721E Common Processor Board has PCIe connectors for the 1st three PCIe
instances. Configure the three PCIe instances in RC mode and disable the
4th PCIe instance.
Signed-off-by: Kishon Vijay Abraham I
---
.../dts/ti/k3-j721e-common-proc-board.dts | 80 +++
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index 8bc1e6ecc50e..29be88811132 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -651,3 +651,83 @@
status = "okay";
};
+
+&serdes0 {
+ serdes0_pcie_link: link@0 {
+ reg = <0>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = ;
+ resets = <&serdes_wiz0 1>;
+ };
+};
+
+&serdes1 {
+ serdes1_pcie_link: link@0 {
+ reg = <0>;
+ cdns,num-lanes = <2>;
+ #phy-cells = <0>;
+ cdns,phy-type = ;
+ resets = <&serdes_wiz1 1>, <&serdes_wiz1 2>;
+ };
+};
+
+&serdes2 {
+ serdes2_pcie_link: link@0 {
+ reg = <0>;
+ cdns,num-lanes = <2>;
+ #phy-cells = <0>;
+ cdns,phy-type = ;
+ resets = <&serdes_wiz2 1>, <&serdes_wiz2 2>;
+ };
+};
+
+&pcie0_rc {
+ reset-gpios = <&exp1 6 GPIO_ACTIVE_HIGH>;
+ phys = <&serdes0_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <1>;
+};
+
+&pcie1_rc {
+ reset-gpios = <&exp1 2 GPIO_ACTIVE_HIGH>;
+ phys = <&serdes1_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <2>;
+};
+
+&pcie2_rc {
+ reset-gpios = <&exp2 20 GPIO_ACTIVE_HIGH>;
+ phys = <&serdes2_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <2>;
+};
+
+&pcie0_ep {
+ phys = <&serdes0_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <1>;
+ status = "disabled";
+};
+
+&pcie1_ep {
+ phys = <&serdes1_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <2>;
+ status = "disabled";
+};
+
+&pcie2_ep {
+ phys = <&serdes2_pcie_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <2>;
+ status = "disabled";
+};
+
+&pcie3_rc {
+ status = "disabled";
+};
+
+&pcie3_ep {
+ status = "disabled";
+};
--
2.17.1
[PATCH 0/2] Add DT to get PCIe working in J721E SoC
Series adds device tree of I2C and PCIe DT nodes to get PCIe working in both RC mode and EP mode in J721E. The PCIe support patch series is queued in Lorenzo's branch [1] This patch series is rebased to Tero's ti-k3-next branch [2] [1] -> https://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git/log/?h=pci/cadence [2] -> https://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux.git/log/?h=ti-k3-next Kishon Vijay Abraham I (2): arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes arm64: dts: ti: k3-j721e-common-proc-board: Configure the PCIe instances .../dts/ti/k3-j721e-common-proc-board.dts | 80 +++ arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 218 ++ arch/arm64/boot/dts/ti/k3-j721e.dtsi | 5 +- 3 files changed, 302 insertions(+), 1 deletion(-) -- 2.17.1
Re: [PATCHv3 00/19] perf metric: Add support to reuse metric
On 7/21/20 12:46 AM, Jiri Olsa wrote:
> On Mon, Jul 20, 2020 at 02:32:40PM +0530, kajoljain wrote:
>>
>>
>> On 7/20/20 1:49 PM, Jiri Olsa wrote:
>>> On Mon, Jul 20, 2020 at 01:39:24PM +0530, kajoljain wrote:
>>>
>>> SNIP
>>>
This is with your perf/metric branch:
command# ./perf stat -M PowerBUS_Frequency -C 0 -I 1000
assertion failed at util/metricgroup.c:709
# time counts unit events
1.54545 7,807,505 hv_24x7/pm_pb_cyc,chip=0/ #
2.0 GHz PowerBUS_Frequency_0
1.54545 7,807,485 hv_24x7/pm_pb_cyc,chip=1/
2.000232761 7,807,500 hv_24x7/pm_pb_cyc,chip=0/ #
2.0 GHz PowerBUS_Frequency_0
2.000232761 7,807,478 hv_24x7/pm_pb_cyc,chip=1/
3.000363762 7,799,665 hv_24x7/pm_pb_cyc,chip=0/ #
1.9 GHz PowerBUS_Frequency_0
3.000363762 7,807,502 hv_24x7/pm_pb_cyc,chip=1/
^C 3.259418599 2,022,150 hv_24x7/pm_pb_cyc,chip=0/ #
0.5 GHz PowerBUS_Frequency_0
3.259418599 2,022,164 hv_24x7/pm_pb_cyc,chip=1/
Performance counter stats for 'CPU(s) 0':
25,436,820 hv_24x7/pm_pb_cyc,chip=0/ # 6.4 GHz
PowerBUS_Frequency_0
25,444,629 hv_24x7/pm_pb_cyc,chip=1/
3.259505529 seconds time elapsed
>>>
>>> I found the bug, we are not adding runtime metrics as standalone ones,
>>> but as referenced metrics.. will fix and try to add test for that
>>>
>>> as for testing.. do I need some special ppc server to have support for
>>> this?
>>
>> Hi jiri,
>> We need power9 lpar machine and need to make sure `CONFIG_HV_PERF_CTRS`
>> is
>> enabled.
>
> could you please try with following patch on top?
Hi Jiri,
The change looks good to me. I tried with adding this patch on top of
your perf/metric branch. It did resolve the issue of not printing
all chips data. And now I can see proper values for hv-24x7 metric events.
I was also trying by adding new metric using the feature added in this patchset
with something like this:
diff --git a/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
b/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
index 8383a37647ad..dfe4bd63b587 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
@@ -16,6 +16,11 @@
"MetricName": "PowerBUS_Frequency",
"ScaleUnit": "2.5e-7GHz"
},
+{
+ "MetricExpr": "Memory_WR_BW_Chip + Memory_RD_BW_Chip",
+"MetricName": "Total_Memory_BW",
+"ScaleUnit": "1.6e-2MB"
+},
I guess as we have dependency on '?' symbol, I am not able to see all chips
data for Total_Memory_BW.
I am not sure if Its expected behavior?
This is what I am getting:
[root@ltc-zz189-lp4 perf]# ./perf stat --metric-only -M
Total_Memory_BW,Memory_WR_BW_Chip,Memory_RD_BW_Chip -I 1000 -C 0
# time MB Total_Memory_BW MB Memory_RD_BW_Chip_1 MB
Memory_WR_BW_Chip_1 MB Memory_WR_BW_Chip_0 MB Memory_RD_BW_Chip_0
1.67388 36.4 0.2
36.3 65.0 72.1
2.000374276 36.2 0.3
35.9 65.4 77.9
3.000543202 36.3 0.3
36.0 68.7 81.2
4.000702855 36.3 0.3
36.0 70.9 93.3
5.000856837 36.0 0.2
35.8 67.4 81.5
^C 5.367865273 13.2 0.1
13.1 23.5 28.3
Performance counter stats for 'CPU(s) 0':
194.4 1.3193.1
361.0434.3
5.368039176 seconds time elapsed
We can only get single chip data's sum in Total_Memory_BW. Please let me know
if I am missing something.
Thanks,
Kajol Jain
>
> thanks,
> jirka
>
>
> ---
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 6f179b9903a0..03aa4bd4a38b 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -820,11 +820,11 @@ static int add_metric(struct list_head *metric_list,
> struct expr_id *parent,
> struct expr_ids *ids);
>
> -static int resolve_metric(st
Re: [PATCH V17 3/3] Input: new da7280 haptic driver
On 7/23/20 10:47 PM, Roy Im wrote: > OK, thanks for your comments. To be clearer, I would like to update as below > if you agree > > depends on INPUT && I2C > ... > The haptics can be controlled by PWM or GPIO > with I2C communication. Yes, that sounds good. Thanks. -- ~Randy
RE: [PATCH V17 3/3] Input: new da7280 haptic driver
Friday, July 24, 2020 11:57 AM, Randy Dunlap wrote > On 7/23/20 6:54 PM, Roy Im wrote: > > On Fri, July 24, 2020 5:51 AM, Randy Dunlap wrote > >> On 7/23/20 8:01 AM, Roy Im wrote: > >>> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig > >>> index 362e8a0..06dc5a3 100644 > >>> --- a/drivers/input/misc/Kconfig > >>> +++ b/drivers/input/misc/Kconfig > >>> @@ -869,4 +869,17 @@ config INPUT_STPMIC1_ONKEY > >>> To compile this driver as a module, choose M here: the > >>> module will be called stpmic1_onkey. > >>> > >>> +config INPUT_DA7280_HAPTICS > >>> + tristate "Dialog Semiconductor DA7280 haptics support" > >>> + depends on INPUT && I2C > >>> + select INPUT_FF_MEMLESS > >>> + select REGMAP_I2C > >>> + help > >>> + Say Y to enable support for the Dialog DA7280 haptics driver. > >>> + The haptics can be controlled by I2C communication, > >>> + or by PWM input, or by GPI. > >> > >> Is thatGPIO. > >> ? > > The Haptics can be working by GPI(if see from the haptic device), but from > > the Host it is GPO. Do you think the GPIO is > correct? > > To me it needs to represent what services/interfaces/facilities are used by > this driver that are provided by the Linux kernel. > If it uses Linux GPIO services, then it should say GPIO -- although I don't > see it using any Linux GPIO services. OK, let me change to GPIO. > > >> > >> Can the haptics be controlled only by PWM or only by GPI(O)? > >> > >> Just curious: why is I2C required to build the driver if a user is only > >> controlling the device by PWM or GPI? > > > > I2C is required to control registers and it can be triggered by I2C or PWM > > or GPI(controlled by host outside this driver), > so PWM and GPI are optional. > > With your comments, I think it's better to remove below lines(//remove) to > > avoid confusion and add PWM as below if > you agree. > > // remove > > The haptics can be controlled by I2C communication, > > or by PWM input, or by GPI. > > // update, adding || PWM > > depends on (INPUT && I2C) || PWM > > Since provides stubs for when CONFIG_PWM is not enabled, it > appears that "depends on PWM" is not > required. > > I'll leave it up to you. I was just trying to understand better. > It may be that no changes are needed. OK, thanks for your comments. To be clearer, I would like to update as below if you agree depends on INPUT && I2C ... The haptics can be controlled by PWM or GPIO with I2C communication. > > > thanks. > -- > ~Randy Kind regards, Roy
Re: [PATCH v2 1/3] mm/shuffle: don't move pages between zones and don't read garbage memmaps
On Thu, Jul 23, 2020 at 08:08:46PM -0700, Andrew Morton wrote: >On Tue, 23 Jun 2020 17:30:18 +0800 Wei Yang > wrote: > >> On Tue, Jun 23, 2020 at 09:55:43AM +0200, David Hildenbrand wrote: >> >On 23.06.20 09:39, David Hildenbrand wrote: >> >>> Hmm.. I thought this is the behavior for early section, while it looks >> >>> current >> >>> code doesn't work like this: >> >>> >> >>>if (section_is_early && memmap) >> >>>free_map_bootmem(memmap); >> >>>else >> >>> depopulate_section_memmap(pfn, nr_pages, altmap); >> >>> >> >>> section_is_early is always "true" for early section, while memmap is >> >>> not-NULL >> >>> only when sub-section map is empty. >> >>> >> >>> If my understanding is correct, when we remove a sub-section in early >> >>> section, >> >>> the code would call depopulate_section_memmap(), which in turn free >> >>> related >> >>> memmap. By removing the memmap, the return value from >> >>> pfn_to_online_page() is >> >>> not a valid one. >> >> >> >> I think you're right, and pfn_valid() would also return true, as it is >> >> an early section. This looks broken. >> >> >> >>> >> >>> Maybe we want to write the code like this: >> >>> >> >>>if (section_is_early) >> >>>if (memmap) >> >>>free_map_bootmem(memmap); >> >>>else >> >>> depopulate_section_memmap(pfn, nr_pages, altmap); >> >>> >> >> >> >> I guess that should be the way to go >> >> >> >> @Dan, I think what Wei proposes here is correct, right? Or how does it >> >> work in the VMEMMAP case with early sections? >> >> >> > >> >Especially, if you would re-hot-add, section_activate() would assume >> >there is a memmap, it must not be removed. >> > >> >> You are right here. I didn't notice it. >> >> >@Wei, can you send a patch? >> > >> >> Sure, let me prepare for it. > >Still awaiting this, and the v3 patch was identical to this v2 patch. > >It's tagged for -stable, so there's some urgency. Should we just go >ahead with the decently-tested v2? This message is to me right? I thought the fix patch is merged, the patch link may be https://lkml.org/lkml/2020/6/23/380. If I missed something, just let me know. -- Wei Yang Help you, Help me
INFO: rcu detected stall in rtnl_newlink
Hello, syzbot found the following issue on: HEAD commit:e6827d1a cxgb4: add missing release on skb in uld_send() git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=17a227b490 kernel config: https://syzkaller.appspot.com/x/.config?x=dddbcb5a9f4192db dashboard link: https://syzkaller.appspot.com/bug?extid=d46d08c4209a3a86ccc5 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15a3822890 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1302e4c490 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+d46d08c4209a3a86c...@syzkaller.appspotmail.com rcu: INFO: rcu_preempt self-detected stall on CPU rcu:1-: (10491 ticks this GP) idle=5d2/1/0x4000 softirq=10100/10100 fqs=5226 (t=10500 jiffies g=8229 q=552) NMI backtrace for cpu 1 CPU: 1 PID: 6812 Comm: syz-executor138 Not tainted 5.8.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 nmi_cpu_backtrace.cold+0x70/0xb1 lib/nmi_backtrace.c:101 nmi_trigger_cpumask_backtrace+0x1b3/0x223 lib/nmi_backtrace.c:62 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x194/0x1cf kernel/rcu/tree_stall.h:320 print_cpu_stall kernel/rcu/tree_stall.h:553 [inline] check_cpu_stall kernel/rcu/tree_stall.h:627 [inline] rcu_pending kernel/rcu/tree.c:3489 [inline] rcu_sched_clock_irq.cold+0x5b3/0xccc kernel/rcu/tree.c:2504 update_process_times+0x25/0x60 kernel/time/timer.c:1726 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:176 tick_sched_timer+0x108/0x290 kernel/time/tick-sched.c:1320 __run_hrtimer kernel/time/hrtimer.c:1520 [inline] __hrtimer_run_queues+0x1d5/0xfc0 kernel/time/hrtimer.c:1584 hrtimer_interrupt+0x32a/0x930 kernel/time/hrtimer.c:1646 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1080 [inline] __sysvec_apic_timer_interrupt+0x142/0x5e0 arch/x86/kernel/apic/apic.c:1097 asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:711 __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline] sysvec_apic_timer_interrupt+0xe0/0x120 arch/x86/kernel/apic/apic.c:1091 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:587 RIP: 0010:should_resched arch/x86/include/asm/preempt.h:102 [inline] RIP: 0010:__local_bh_enable_ip+0x189/0x250 kernel/softirq.c:196 Code: 89 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 0f 85 c4 00 00 00 48 83 3d 60 5a 6e 08 00 74 7b fb 66 0f 1f 44 00 00 <65> 8b 05 80 78 bb 7e 85 c0 74 6b 5b 5d 41 5c c3 80 3d a3 6a 63 09 RSP: 0018:c90001816d80 EFLAGS: 0286 RAX: 11369c12 RBX: 0201 RCX: 0002 RDX: dc00 RSI: RDI: 81468609 RBP: 87cdbce5 R08: R09: R10: 0001 R11: R12: 8880a9298400 R13: 0001 R14: 0034 R15: dc00 spin_unlock_bh include/linux/spinlock.h:398 [inline] batadv_tt_local_purge+0x285/0x370 net/batman-adv/translation-table.c:1446 batadv_tt_local_resize_to_mtu+0x8e/0x130 net/batman-adv/translation-table.c:4197 batadv_hardif_activate_interface.part.0.cold+0x14c/0x1ba net/batman-adv/hard-interface.c:653 batadv_hardif_activate_interface net/batman-adv/hard-interface.c:800 [inline] batadv_hardif_enable_interface+0xa7d/0xb10 net/batman-adv/hard-interface.c:792 batadv_softif_slave_add+0x92/0x150 net/batman-adv/soft-interface.c:892 do_set_master+0x1c8/0x220 net/core/rtnetlink.c:2476 do_setlink+0x903/0x35c0 net/core/rtnetlink.c:2611 __rtnl_newlink+0xc21/0x1750 net/core/rtnetlink.c:3272 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3398 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5461 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2469 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1329 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1918 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6e8/0x810 net/socket.c:2352 ___sys_sendmsg+0xf3/0x170 net/socket.c:2406 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2439 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4437d9 Code: Bad RIP value. RSP: 002b:7ffdfad85898 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 004437d9 RDX: RSI: 2140 RDI: 0004 RBP: 7ffdfad858a0 R08: 01bb R09: 01bb R10: 01bb R11: 0246 R12: 7ffdfad858b0 R13: R14: R15: ---
Re: [PATCH v5 10/10] bus: mhi: core: Introduce sysfs entries for MHI
On Thu, Jul 23, 2020 at 03:36:42PM -0700, Bhaumik Bhatt wrote:
> Introduce sysfs entries to enable userspace clients the ability to read
> the serial number and the OEM PK Hash values obtained from BHI. OEMs
> need to read these device-specific hardware information values through
> userspace for factory testing purposes and cannot be exposed via degbufs
> as it may remain disabled for performance reasons. Also, update the
> documentation for ABI to include these entries.
>
> Signed-off-by: Bhaumik Bhatt
> ---
> Documentation/ABI/stable/sysfs-bus-mhi | 25
> MAINTAINERS| 1 +
> drivers/bus/mhi/core/init.c| 53
> ++
> 3 files changed, 79 insertions(+)
> create mode 100644 Documentation/ABI/stable/sysfs-bus-mhi
>
> diff --git a/Documentation/ABI/stable/sysfs-bus-mhi
> b/Documentation/ABI/stable/sysfs-bus-mhi
> new file mode 100644
> index 000..a4e4bd2
> --- /dev/null
> +++ b/Documentation/ABI/stable/sysfs-bus-mhi
> @@ -0,0 +1,25 @@
> +What:/sys/bus/mhi/devices/.../serialnumber
> +Date:July 2020
> +KernelVersion: 5.8
> +Contact: Bhaumik Bhatt
> +Description:
> + The file holds the serial number of the client device obtained
> + using a BHI (Boot Host Interface) register read after at least
> + one attempt to power up the device has been done. If read
> + without having the device power on at least once, the file will
> + read all 0's.
> +Users: Any userspace application or clients interested in the
> device
> + hardware information.
Please align all the fields onto a single starting point. Have a look at other
ABI documentation like, Documentation/ABI/stable/sysfs-bus-vmbus.
> +
> +What:/sys/bus/mhi/devices/.../oem_pk_hash
> +Date:July 2020
> +KernelVersion: 5.8
> +Contact: Bhaumik Bhatt
> +Description:
> + The file holds the OEM PK Hash value of the endpoint device
> + obtained using a BHI (Boot Host Interface) register read after
> + at least one attempt to power up the device has been done. If
> + read without having the device power on at least once, the file
> + will read all 0's.
> +Users: Any userspace application or clients interested in the
> device
> + hardware information.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..5e49316 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11018,6 +11018,7 @@ M:Hemant Kumar
> L: linux-arm-...@vger.kernel.org
> S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git
> +F: Documentation/ABI/stable/sysfs-bus-mhi
> F: Documentation/mhi/
> F: drivers/bus/mhi/
> F: include/linux/mhi.h
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index d2c0f6e..a7b0d76 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -76,6 +76,56 @@ const char *to_mhi_pm_state_str(enum mhi_pm_state state)
> return mhi_pm_state_str[index];
> }
>
> +static ssize_t serial_number_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
We haven't followed this before but it is good to align the function parameters
with respect to '('.
> +{
> + struct mhi_device *mhi_dev = to_mhi_device(dev);
> + struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> +
> + return snprintf(buf, PAGE_SIZE, "Serial Number: %u\n",
> + mhi_cntrl->serial_number);
We need to think about what happens if the mhi_cntrl structure is not zero
initialized by the controller driver. All throughout the stack we assume that
the mhi_cntrl struct is zero initialized but things can go awry if it was not
the case!
There was one API in the downstream (mhi_alloc_controller()) for this purpose
but I removed it since we ended up with just a kzalloc(). Does it make sense to
introduce it now?
Thanks,
Mani
> +}
> +static DEVICE_ATTR_RO(serial_number);
> +
> +static ssize_t oem_pk_hash_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct mhi_device *mhi_dev = to_mhi_device(dev);
> + struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> + int i, cnt = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(mhi_cntrl->oem_pk_hash); i++)
> + cnt += snprintf(buf + cnt, PAGE_SIZE - cnt,
> + "OEMPKHASH[%d]: 0x%x\n", i,
> + mhi_cntrl->oem_pk_hash[i]);
> +
> + return cnt;
> +}
> +static DEVICE_ATTR_RO(oem_pk_hash);
> +
> +static struct attribute *mhi_sysfs_attrs[] = {
> + &dev_attr_serial_number.attr,
> + &dev_attr_oem_pk_hash.attr,
> + NULL,
> +};
> +
> +static const struct attribute_gr
Re: [PATCH v9 2/7] dt-bindings: pinctrl: add bindings for MediaTek MT6779 SoC
On Thu, 2020-07-23 at 09:51 -0600, Rob Herring wrote: > On Thu, 23 Jul 2020 19:19:52 +0800, Hanks Chen wrote: > > From: Andy Teng > > > > Add devicetree bindings for MediaTek MT6779 pinctrl driver. > > > > Reviewed-by: Rob Herring > > Signed-off-by: Andy Teng > > Signed-off-by: Hanks Chen > > --- > > .../pinctrl/mediatek,mt6779-pinctrl.yaml | 197 ++ > > 1 file changed, 197 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:0: [0, 268455936, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:1: [0, 297926656, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:2: [0, 298909696, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:3: [0, 300023808, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:4: [0, 300351488, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:5: [0, 300548096, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:6: [0, 301072384, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:7: [0, 301137920, 0, 4096] is too long > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.example.dt.yaml: > example-0: pinctrl@10005000:reg:8: [0, 268480512, 0, 4096] is too long > > > See > https://urldefense.com/v3/__https://patchwork.ozlabs.org/patch/1334743__;!!CTRNKA9wMg0ARbw!xVq21s-Vaw3If1-Q8EWJEDBBIUp0j30PIaGQWDyhCftbcOgFrjRqZMNHoHgOXksD3g$ > > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure dt-schema is up to date: > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > --upgrade > > Please check and re-submit. > Hi Rob, It's my fault I could reproduce the error log after dt-schema updates to the latest version. I'll fix it in next version. Thanks! Hanks Chen
Re: [Softirq] a76eadba0d: WARNING:at_net/mac80211/rx.c:#ieee80211_rx_napi[mac80211]
On Thu, Jul 23, 2020 at 10:35 PM Thomas Gleixner wrote:
>
> jun qian writes:
> > On Thu, Jul 23, 2020 at 6:58 PM Thomas Gleixner wrote:
> >> That drops everything which has not yet been processed and the above
> >> warning is due to this.
> >>
> > wow, I made a mistake, thank you for finding the cause of the problem
> > so quickly.
> >
> > How about the following code. we need to clear the corresponding
> > pending bit at the
> > right time Instead of all the pending bits cleared in the start.
> >
> > pending = softirq_pending();
> >
> > while ((softirq_bit = ffs(pending))) {
> >
> > pending >>= softirq_bit;
> >
> > set_softirq_pending(pending); //Only clear the corresponding
> > bit which will be processed.
>
> How is that supposed to be correct. pending has been shifted
> right. Something like this should work:
>
> h++;
> pending >>= softirq_bit;
>
> if (timeout()) {
> /*
> * Ensure that the remaining pending bits
> * are handled.
> */
> or_softirq_pending(pending << (vec_nr + 1));
> break;
> }
> }
>
> Thanks,
>
> tglx
>
I have two questions that need to be discussed.
1. If the __do_sofrirq() is executed in the ksoftirqd, we may not need
to check the timeout in the loop.
2. Both the invoke_softirq() and run_ksoftirqd() will execute
__do_sofirq, they all execute the same code，
when it is in the ksoftirqd, Do we need to wake up ksoftirqd in
the process context according to
max_restart and MAX_SOFTIRQ_TIME. In my opinion, If we use a flag
to distinguish where
__do_softirq() is called from, we can do what is most suitable
for __do_softirq based on this flag.
Re: [PATCH] tty: Add MOXA NPort Real TTY Driver
Hi "Johnson, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tty/tty-testing] [also build test WARNING on v5.8-rc6 next-20200723] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Johnson-CH-Chen/tty-Add-MOXA-NPort-Real-TTY-Driver/20200714-142712 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing config: mips-randconfig-s032-20200723 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/tty/npreal2.c:1107:26: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] __user *to @@ got struct serial_struct *retinfo @@ drivers/tty/npreal2.c:1107:26: sparse: expected void [noderef] __user *to drivers/tty/npreal2.c:1107:26: sparse: got struct serial_struct *retinfo drivers/tty/npreal2.c:1122:56: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const [noderef] __user *from @@ got struct serial_struct *new_info @@ drivers/tty/npreal2.c:1122:56: sparse: expected void const [noderef] __user *from drivers/tty/npreal2.c:1122:56: sparse: got struct serial_struct *new_info drivers/tty/npreal2.c:1149:57: sparse: sparse: Using plain integer as NULL pointer drivers/tty/npreal2.c:1186:9: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected unsigned int [noderef] __user *__pu_addr @@ got unsigned int *value @@ drivers/tty/npreal2.c:1186:9: sparse: expected unsigned int [noderef] __user *__pu_addr drivers/tty/npreal2.c:1186:9: sparse: got unsigned int *value drivers/tty/npreal2.c:1624:38: sparse: sparse: Using plain integer as NULL pointer drivers/tty/npreal2.c:1897:34: sparse: sparse: Using plain integer as NULL pointer drivers/tty/npreal2.c:1914:21: sparse: sparse: Using plain integer as NULL pointer drivers/tty/npreal2.c:1984:46: sparse: sparse: Using plain integer as NULL pointer drivers/tty/npreal2.c:2261:17: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected unsigned long [noderef] __user *__pu_addr @@ got unsigned long * @@ drivers/tty/npreal2.c:2261:17: sparse: expected unsigned long [noderef] __user *__pu_addr drivers/tty/npreal2.c:2261:17: sparse: got unsigned long * >> drivers/tty/npreal2.c:2265:17: sparse: sparse: incorrect type in initializer >> (different address spaces) @@ expected unsigned long const [noderef] >> __user *__gu_ptr @@ got unsigned long * @@ >> drivers/tty/npreal2.c:2265:17: sparse: expected unsigned long const >> [noderef] __user *__gu_ptr drivers/tty/npreal2.c:2265:17: sparse: got unsigned long * drivers/tty/npreal2.c:2319:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@ drivers/tty/npreal2.c:2319:21: sparse: expected int [noderef] __user *__pu_addr drivers/tty/npreal2.c:2319:21: sparse: got int * drivers/tty/npreal2.c:2319:62: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@ drivers/tty/npreal2.c:2319:62: sparse: expected int [noderef] __user *__pu_addr drivers/tty/npreal2.c:2319:62: sparse: got int * drivers/tty/npreal2.c:2320:25: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@ drivers/tty/npreal2.c:2320:25: sparse: expected int [noderef] __user *__pu_addr drivers/tty/npreal2.c:2320:25: sparse: got int * drivers/tty/npreal2.c:2321:25: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@ drivers/tty/npreal2.c:2321:25: sparse: expected int [noderef] __user *__pu_addr drivers/tty/npreal2.c:2321:25: sparse: got int * drivers/tty/npreal2.c:2322:25: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr
Re: [PATCH v2 0/3] ARM: dts: aspeed: fixup wedge40 device tree
On Thu, 23 Jul 2020 at 23:05, wrote: > > From: Tao Ren > > The patch series update several devices' settings in Facebook Wedge40 > device tree. > > Patch #1 disables a few i2c controllers as they are not being used at > present. > > Patch #2 enables adc device for voltage monitoring. > > Patch #3 enables pwm_tacho device for fan control and monitoring. > > Tao Ren (3): > ARM: dts: aspeed: wedge40: disable a few i2c controllers > ARM: dts: aspeed: wedge40: enable adc device > ARM: dts: aspeed: wedge40: enable pwm_tacho device I have merged this series into the aspeed dt-for-5.9 branch. Cheers, Joel > > .../boot/dts/aspeed-bmc-facebook-wedge40.dts | 42 +++ > 1 file changed, 34 insertions(+), 8 deletions(-) > > -- > 2.17.1 >
Re: [PATCH v5 bpf-next 5/5] selftests/bpf: add get_stackid_cannot_attach
On Thu, Jul 23, 2020 at 11:06:48AM -0700, Song Liu wrote:
> + pmu_fd = syscall(__NR_perf_event_open, &attr, -1 /* pid */,
> + 0 /* cpu 0 */, -1 /* group id */,
> + 0 /* flags */);
> + if (pmu_fd < 0 && errno == ENOENT) {
> + printf("%s:SKIP:cannot open PERF_COUNT_HW_CPU_CYCLES with
> precise_ip > 0\n",
> +__func__);
> + test__skip();
> + goto cleanup;
> + }
That wasn't enough in my test VM.
I've changed it to be: (errno == ENOENT || errno == EOPNOTSUPP)
and applied the set.
Thanks
Re: [PATCH v2] ARM: dts: aspeed: cmm: fixup i2c tree
On Thu, 23 Jul 2020 at 23:08, wrote: > > From: Tao Ren > > Create all the i2c switches in device tree and use aliases to assign > child channels with consistent bus numbers. > > Besides, "i2c-mux-idle-disconnect" is set for all the i2c switches to > avoid potential conflicts when multiple devices (beind the switches) > use the same device address. > > Signed-off-by: Tao Ren Reviewed-by: Joel Stanley I have merged this patch into the aspeed dt-for-5.9 branch. Cheers, Joel > --- > Changes in v2: >- Nothing changed. Resending the patch just in case the previous > email was not delivered. > > arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts | 1231 - > 1 file changed, 1228 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts > b/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts > index 016bbcb99bb6..7bc7df7ed428 100644 > --- a/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts > +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts > @@ -19,8 +19,8 @@ > serial3 = &uart4; > > /* > -* Hardcode the bus number of i2c switches' channels to > -* avoid breaking the legacy applications. > +* PCA9548 (1-0077) provides 8 channels for connecting to > +* 4 Line Cards and 4 Fabric Cards. > */ > i2c16 = &imux16; > i2c17 = &imux17; > @@ -30,6 +30,11 @@ > i2c21 = &imux21; > i2c22 = &imux22; > i2c23 = &imux23; > + > + /* > +* PCA9548 (2-0071) provides 8 channels for connecting to > +* Power Distribution Board. > +*/ > i2c24 = &imux24; > i2c25 = &imux25; > i2c26 = &imux26; > @@ -38,6 +43,11 @@ > i2c29 = &imux29; > i2c30 = &imux30; > i2c31 = &imux31; > + > + /* > +* PCA9548 (8-0077) provides 8 channels and the first 4 > +* channels are connecting to 4 Fan Control Boards. > +*/ > i2c32 = &imux32; > i2c33 = &imux33; > i2c34 = &imux34; > @@ -46,6 +56,226 @@ > i2c37 = &imux37; > i2c38 = &imux38; > i2c39 = &imux39; > + > + /* > +* 2 PCA9548 (18-0070 & 18-0073), 16 channels connecting > +* to Line Card #1. > +*/ > + i2c40 = &imux40; > + i2c41 = &imux41; > + i2c42 = &imux42; > + i2c43 = &imux43; > + i2c44 = &imux44; > + i2c45 = &imux45; > + i2c46 = &imux46; > + i2c47 = &imux47; > + i2c48 = &imux48; > + i2c49 = &imux49; > + i2c50 = &imux50; > + i2c51 = &imux51; > + i2c52 = &imux52; > + i2c53 = &imux53; > + i2c54 = &imux54; > + i2c55 = &imux55; > + > + /* > +* 2 PCA9548 (19-0070 & 19-0073), 16 channels connecting > +* to Line Card #2. > +*/ > + i2c56 = &imux56; > + i2c57 = &imux57; > + i2c58 = &imux58; > + i2c59 = &imux59; > + i2c60 = &imux60; > + i2c61 = &imux61; > + i2c62 = &imux62; > + i2c63 = &imux63; > + i2c64 = &imux64; > + i2c65 = &imux65; > + i2c66 = &imux66; > + i2c67 = &imux67; > + i2c68 = &imux68; > + i2c69 = &imux69; > + i2c70 = &imux70; > + i2c71 = &imux71; > + > + /* > +* 2 PCA9548 (20-0070 & 20-0073), 16 channels connecting > +* to Line Card #3. > +*/ > + i2c72 = &imux72; > + i2c73 = &imux73; > + i2c74 = &imux74; > + i2c75 = &imux75; > + i2c76 = &imux76; > + i2c77 = &imux77; > + i2c78 = &imux78; > + i2c79 = &imux79; > + i2c80 = &imux80; > + i2c81 = &imux81; > + i2c82 = &imux82; > + i2c83 = &imux83; > + i2c84 = &imux84; > + i2c85 = &imux85; > + i2c86 = &imux86; > + i2c87 = &imux87; > + > + /* > +* 2 PCA9548 (21-0070 & 21-0073), 16 channels connecting > +* to Line Card #4. > +*/ > + i2c88 = &imux88; > + i2c89 = &imux89; > + i2c90 = &imux90; > + i2c91 = &imux91; > + i2c92 = &imux92; > + i2c93 = &imux93; > + i2c94 = &imux94; > + i2c95 = &imux95; > +
Re: [PATCH bpf-next v6 1/7] bpf: Renames to prepare for generalizing sk_storage.
On Thu, Jul 23, 2020 at 01:50:26PM +0200, KP Singh wrote: > From: KP Singh > > A purely mechanical change to split the renaming from the actual > generalization. > > Flags/consts: > > SK_STORAGE_CREATE_FLAG_MASK BPF_LOCAL_STORAGE_CREATE_FLAG_MASK > BPF_SK_STORAGE_CACHE_SIZE BPF_LOCAL_STORAGE_CACHE_SIZE > MAX_VALUE_SIZE BPF_LOCAL_STORAGE_MAX_VALUE_SIZE > > Structs: > > bucket bpf_local_storage_map_bucket > bpf_sk_storage_map bpf_local_storage_map > bpf_sk_storage_data bpf_local_storage_data > bpf_sk_storage_elem bpf_local_storage_elem > bpf_sk_storage bpf_local_storage > selem_linked_to_sk selem_linked_to_storage > selem_alloc bpf_selem_alloc > > The "sk" member in bpf_local_storage is also updated to "owner" > in preparation for changing the type to void * in a subsequent patch. > > Functions: > > __selem_unlink_sk bpf_selem_unlink_storage > __selem_link_sk bpf_selem_link_storage > selem_unlink_sk __bpf_selem_unlink_storage > sk_storage_update bpf_local_storage_update > __sk_storage_lookup bpf_local_storage_lookup > bpf_sk_storage_map_free bpf_local_storage_map_free > bpf_sk_storage_map_allocbpf_local_storage_map_alloc > bpf_sk_storage_map_alloc_check bpf_local_storage_map_alloc_check > bpf_sk_storage_map_check_btfbpf_local_storage_map_check_btf Thanks for separating this mechanical name change in a separate patch. It is much easier to follow. This patch looks good. A minor thought is, when I look at unlink_map() and unlink_storage(), it keeps me looking back for the lock situation. I think the main reason is the bpf_selem_unlink_map() is locked but bpf_selem_unlink_storage() is unlocked now. May be: bpf_selem_unlink_map() => bpf_selem_unlink_map_locked() bpf_selem_link_map()=> bpf_selem_link_map_locked() __bpf_selem_unlink_storage()=> bpf_selem_unlink_storage_locked() bpf_link_storage() means unlocked bpf_unlink_storage() means unlocked. I think it could be one follow-up patch later instead of interrupting multiple patches in this set for this minor thing. For now, lets continue with this and remember default is nolock for storage. I will continue tomorrow.
Re: [PATCH v2] af_key: pfkey_dump needs parameter validation
On Wed, Jul 22, 2020 at 04:00:53AM -0700, Mark Salyzyn wrote:
> In pfkey_dump() dplen and splen can both be specified to access the
> xfrm_address_t structure out of bounds in__xfrm_state_filter_match()
> when it calls addr_match() with the indexes. Return EINVAL if either
> are out of range.
>
> Signed-off-by: Mark Salyzyn
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: kernel-t...@android.com
> Cc: Steffen Klassert
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Jakub Kicinski
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Applied, thanks a lot!
Re: [PATCH v5 08/10] bus: mhi: core: Use counters to track MHI device state transitions
On Thu, Jul 23, 2020 at 03:36:40PM -0700, Bhaumik Bhatt wrote: > Use counters to track MHI device state transitions such as those > to M0, M2, or M3 states. This helps in better debug by allowing > the user to see the number of transitions to a certain state when > queried using the states debugfs entry. > > Signed-off-by: Bhaumik Bhatt This patch should come before the debugfs patch. Also the header addition should be here. Thanks, Mani > --- > drivers/bus/mhi/core/pm.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c > index 27bb471..ce4d969 100644 > --- a/drivers/bus/mhi/core/pm.c > +++ b/drivers/bus/mhi/core/pm.c > @@ -256,6 +256,7 @@ int mhi_pm_m0_transition(struct mhi_controller *mhi_cntrl) > dev_err(dev, "Unable to transition to M0 state\n"); > return -EIO; > } > + mhi_cntrl->M0++; > > /* Wake up the device */ > read_lock_bh(&mhi_cntrl->pm_lock); > @@ -326,6 +327,8 @@ void mhi_pm_m1_transition(struct mhi_controller > *mhi_cntrl) > mhi_cntrl->dev_state = MHI_STATE_M2; > > write_unlock_irq(&mhi_cntrl->pm_lock); > + > + mhi_cntrl->M2++; > wake_up_all(&mhi_cntrl->state_event); > > /* If there are any pending resources, exit M2 immediately */ > @@ -362,6 +365,7 @@ int mhi_pm_m3_transition(struct mhi_controller *mhi_cntrl) > return -EIO; > } > > + mhi_cntrl->M3++; > wake_up_all(&mhi_cntrl->state_event); > > return 0; > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
RE: [PATCH 1/2] platform/x86: Add Intel Input Output Manager (IOM) driver
Hi Greg,
> Subject: Re: [PATCH 1/2] platform/x86: Add Intel Input Output Manager (IOM)
> driver
...
> > > > +struct intel_iom {
> > > > + struct device *dev;
> > > > + void __iomem *regbar;
> > > > +};
> > > > +
> > > > +static struct intel_iom iom_dev;
> > >
> > > Why just one? Why is this static?
> > >
> >
> > There is just one IOM device in the system.
>
> For today, yes, no need to force yourself to have to change this in the
> future.
> Just use a normal per-instance variable instead please, if you really need it.
>
Ack
> > > > +
> > > > + /* Prevent this driver from being unloaded while in use */
> > > > + if (!try_module_get(dev->driver->owner)) {
> > >
> > > Why are you poking around in a random device's driver's owner?
> > >
> > > That's not ok. And probably totally racy.
> > >
> > > Handle module reference counts properly, not like this.
> > >
> >
> > Ack. Will use THIS_MODULE here.
>
> No, that is not the answer, and is always wrong to use :(
>
This should not matter anymore, as I find reference counting may not be needed.
> > > And why does it even matter that you incremented the module
> > > reference count? What is that "protecting" you from?
> > >
> >
> > To prevent this driver from being unloaded, while it is being used.
>
> Why does that matter? Shouldn't normal reference counting and
> dependancies be all that you need?
>
I find just dependencies are enough to prevent the driver from being unloaded.
With Intel PMC USB mux control driver, not using
intel_iom_get()/intel_iom_put(),
just invoking intel_iom_port_status() is enough for rmmod to report failure
(citing the use by intel_pmc_mux) in unloading the IOM driver.
> > > > + put_device(iom_dev.dev);
> > > > + return ERR_PTR(-EBUSY);
> > > > + }
> > > > +
> > > > + return &iom_dev;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(intel_iom_get);
> > >
> > > Who calls this function?
> > >
> >
> > Intel PMC USB mux control driver, in this case.
> > The callers are expected to call intel_iom_get() before using the
> > intel_iom_port_status(), after which intel_iom_put() can be called to
> > release the IOM device instance.
>
> Why not just have a single call if all this driver does is support one thing.
> The
> reference counting shouldn't be needed at all, right?
>
Ack. That looks to be the case, based on my findings.
> > > > +/**
> > > > + * intel_iom_put() - Put IOM device instance
> > > > + * @iom: IOM device instance
> > > > + *
> > > > + * This function releases the IOM device instance created using
> > > > + * intel_iom_get() and allows the driver to be unloaded.
> > > > + *
> > > > + * Call intel_iom_put() to release the instance.
> > > > + */
> > > > +void intel_iom_put(struct intel_iom *iom) {
> > > > + if (!iom)
> > > > + return;
> > > > +
> > > > + module_put(iom->dev->driver->owner);
> > >
> > > And if the device doesn't have a driver? boom :(
> > >
> > > Don't do this.
> > >
> >
> > Ack. Will use THIS_MODULE here.
>
> Again, no, that will be even more incorrect.
>
This shouldn't be relevant anymore.
> > > > + put_device(iom->dev);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(intel_iom_put);
> > > > +
> > > > +/**
> > > > + * intel_iom_port_status() - Get status bits for the Type-C port
> > > > + * @iom: IOM device instance
> > > > + * @port: Type-C port number
> > > > + * @status: pointer to receive the status bits
> > > > + *
> > > > + * Returns 0 on success, error otherwise.
> > > > + */
> > > > +int intel_iom_port_status(struct intel_iom *iom, u8 port, u32
> > > > +*status) {
> > > > + void __iomem *reg;
> > > > +
> > > > + if (!iom)
> > > > + return -ENODEV;
> > > > +
> > > > + if (!status || (port > IOM_MAX_PORTS - 1))
> > > > + return -EINVAL;
> > > > +
> > > > + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN *
> > > port;
> > > > +
> > > > + *status = ioread32(reg);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(intel_iom_port_status);
> > >
> > > So the whole driver is here just to read, directly from memory, a
> > > single
> > > 32 bit value?
> >
> > Yes.
>
> Ok, then this whole driver could be about 90% smaller and more obvious.
> Don't add the reference counting, the static variables and all the other stuff
> just to get a 32bit number.
>
Ack
Re: [PATCH] rtlwifi: btcoex: remove redundant initialization of variables ant_num and single_ant_path
On Thu, 2020-07-23 at 17:32 +0100, Colin King wrote:
> From: Colin Ian King
>
> The variables ant_num and single_ant_path are being initialized with a
> value that is never read and are being updated later with a new value.
> The initializations are redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Acked-by: Ping-Ke Shih
Thank you
> ---
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> index a4940a3842de..4949f99844b5 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> @@ -1318,7 +1318,7 @@ bool exhalbtc_bind_bt_coex_withadapter(void *adapter)
> {
> struct rtl_priv *rtlpriv = adapter;
> struct btc_coexist *btcoexist = rtl_btc_coexist(rtlpriv);
> - u8 ant_num = 2, chip_type, single_ant_path = 0;
> + u8 ant_num, chip_type, single_ant_path;
>
> if (!btcoexist)
> return false;
[PATCH v5 3/6] arch/x86: Implement text_alloc() and text_free()
Implement text_alloc() and text_free() with with the vmalloc API. These can
be used to allocate pages for trampoline code without relying on the module
loader code.
Cc: linux...@kvack.org
Cc: Masami Hiramatsu
Cc: Andi Kleen
Suggested-by: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen
---
arch/x86/Kconfig | 3 +++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/text_alloc.c | 41
3 files changed, 45 insertions(+)
create mode 100644 arch/x86/kernel/text_alloc.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0dea7fdd7a00..a4ee5d1300f6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2035,6 +2035,9 @@ config KEXEC_FILE
config ARCH_HAS_KEXEC_PURGATORY
def_bool KEXEC_FILE
+config ARCH_HAS_TEXT_ALLOC
+ def_bool y
+
config KEXEC_SIG
bool "Verify kernel signature during kexec_file_load() syscall"
depends on KEXEC_FILE
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index e77261db2391..fa1415424ae3 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -68,6 +68,7 @@ obj-y += tsc.o tsc_msr.o io_delay.o rtc.o
obj-y += pci-iommu_table.o
obj-y += resource.o
obj-y += irqflags.o
+obj-y += text_alloc.o
obj-y += process.o
obj-y += fpu/
diff --git a/arch/x86/kernel/text_alloc.c b/arch/x86/kernel/text_alloc.c
new file mode 100644
index ..f31c2d82c258
--- /dev/null
+++ b/arch/x86/kernel/text_alloc.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Kernel module help for x86.
+ * Copyright (C) 2001 Rusty Russell.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+void *text_alloc(unsigned long size)
+{
+ void *p;
+
+ if (PAGE_ALIGN(size) > MODULES_LEN)
+ return NULL;
+
+ p = __vmalloc_node_range(size, MODULE_ALIGN, MODULES_VADDR, MODULES_END,
+GFP_KERNEL, PAGE_KERNEL, 0, NUMA_NO_NODE,
+__builtin_return_address(0));
+
+ if (p && (kasan_module_alloc(p, size) < 0)) {
+ vfree(p);
+ return NULL;
+ }
+
+ return p;
+}
+
+void text_free(void *region)
+{
+ /*
+* This memory may be RO, and freeing RO memory in an interrupt is not
+* supported by vmalloc.
+*/
+ lockdep_assert_irqs_enabled();
+
+ vfree(region);
+}
--
2.25.1
[PATCH v5 5/6] kprobes: Use text_alloc() and text_free()
Use text_alloc() and text_free() instead of module_alloc() and
module_memfree() when an arch provides them.
Cc: linux...@kvack.org
Cc: Andi Kleen
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen
---
kernel/kprobes.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 4e46d96d4e16..611fcda9f6bf 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#define KPROBE_HASH_BITS 6
#define KPROBE_TABLE_SIZE (1 << KPROBE_HASH_BITS)
@@ -111,12 +112,20 @@ enum kprobe_slot_state {
void __weak *alloc_insn_page(void)
{
+#ifdef CONFIG_ARCH_HAS_TEXT_ALLOC
+ return text_alloc(PAGE_SIZE);
+#else
return module_alloc(PAGE_SIZE);
+#endif
}
void __weak free_insn_page(void *page)
{
+#ifdef CONFIG_ARCH_HAS_TEXT_ALLOC
+ text_free(page);
+#else
module_memfree(page);
+#endif
}
struct kprobe_insn_cache kprobe_insn_slots = {
--
2.25.1
[PATCH v5 4/6] arch/x86: kprobes: Use text_alloc() and text_free()
Use text_alloc() and text_free() to implement alloc_insn_page() and
free_insn_page().
Cc: linux...@kvack.org
Cc: Andi Kleen
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen Im
---
arch/x86/kernel/kprobes/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index ada39ddbc922..9e57452b3a51 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -423,7 +423,7 @@ void *alloc_insn_page(void)
{
void *page;
- page = module_alloc(PAGE_SIZE);
+ page = text_alloc(PAGE_SIZE);
if (!page)
return NULL;
@@ -446,7 +446,7 @@ void *alloc_insn_page(void)
/* Recover page to RW mode before releasing it */
void free_insn_page(void *page)
{
- module_memfree(page);
+ text_free(page);
}
static int arch_copy_kprobe(struct kprobe *p)
--
2.25.1
[PATCH v5 6/6] kprobes: Remove CONFIG_MODULES dependency
Remove CONFIG_MODULES dependency by flagging out the dependent code. This
allows to use kprobes in a kernel without support for loadable modules,
which is an useful feature for test kernels and embedded kernels.
Cc: linux...@kvack.org
Cc: Andi Kleen
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen
---
arch/Kconfig| 2 +-
include/linux/module.h | 14 +--
kernel/kprobes.c| 48 +++--
kernel/trace/trace_kprobe.c | 16 +++--
4 files changed, 52 insertions(+), 28 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 8cc35dc556c7..e3d6b6868ccb 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -61,7 +61,7 @@ config OPROFILE_NMI_TIMER
config KPROBES
bool "Kprobes"
- depends on MODULES
+ depends on MODULES || ARCH_HAS_TEXT_ALLOC
depends on HAVE_KPROBES
select KALLSYMS
help
diff --git a/include/linux/module.h b/include/linux/module.h
index 8850b9692b8f..22c646cff6bd 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -290,6 +290,13 @@ extern typeof(name) __mod_##type##__##name##_device_table
\
struct notifier_block;
+enum module_state {
+ MODULE_STATE_LIVE, /* Normal state. */
+ MODULE_STATE_COMING,/* Full formed, running module_init. */
+ MODULE_STATE_GOING, /* Going away. */
+ MODULE_STATE_UNFORMED, /* Still setting it up. */
+};
+
#ifdef CONFIG_MODULES
extern int modules_disabled; /* for sysctl */
@@ -305,13 +312,6 @@ struct module_use {
struct module *source, *target;
};
-enum module_state {
- MODULE_STATE_LIVE, /* Normal state. */
- MODULE_STATE_COMING,/* Full formed, running module_init. */
- MODULE_STATE_GOING, /* Going away. */
- MODULE_STATE_UNFORMED, /* Still setting it up. */
-};
-
struct mod_tree_node {
struct module *mod;
struct latch_tree_node node;
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 611fcda9f6bf..bb2e3070481a 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1617,6 +1617,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
goto out;
}
+#ifdef CONFIG_MODULES
/*
* If the module freed .init.text, we couldn't insert
* kprobes in there.
@@ -1627,6 +1628,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
*probed_mod = NULL;
ret = -ENOENT;
}
+#endif
}
out:
preempt_enable();
@@ -2223,24 +2225,6 @@ int kprobe_add_area_blacklist(unsigned long start,
unsigned long end)
return 0;
}
-/* Remove all symbols in given area from kprobe blacklist */
-static void kprobe_remove_area_blacklist(unsigned long start, unsigned long
end)
-{
- struct kprobe_blacklist_entry *ent, *n;
-
- list_for_each_entry_safe(ent, n, &kprobe_blacklist, list) {
- if (ent->start_addr < start || ent->start_addr >= end)
- continue;
- list_del(&ent->list);
- kfree(ent);
- }
-}
-
-static void kprobe_remove_ksym_blacklist(unsigned long entry)
-{
- kprobe_remove_area_blacklist(entry, entry + 1);
-}
-
int __init __weak arch_populate_kprobe_blacklist(void)
{
return 0;
@@ -2283,6 +2267,25 @@ static int __init populate_kprobe_blacklist(unsigned
long *start,
return ret ? : arch_populate_kprobe_blacklist();
}
+#ifdef CONFIG_MODULES
+/* Remove all symbols in given area from kprobe blacklist */
+static void kprobe_remove_area_blacklist(unsigned long start, unsigned long
end)
+{
+ struct kprobe_blacklist_entry *ent, *n;
+
+ list_for_each_entry_safe(ent, n, &kprobe_blacklist, list) {
+ if (ent->start_addr < start || ent->start_addr >= end)
+ continue;
+ list_del(&ent->list);
+ kfree(ent);
+ }
+}
+
+static void kprobe_remove_ksym_blacklist(unsigned long entry)
+{
+ kprobe_remove_area_blacklist(entry, entry + 1);
+}
+
static void add_module_kprobe_blacklist(struct module *mod)
{
unsigned long start, end;
@@ -2328,6 +2331,15 @@ static void remove_module_kprobe_blacklist(struct module
*mod)
kprobe_remove_area_blacklist(start, end);
}
}
+#else
+static void add_module_kprobe_blacklist(struct module *mod)
+{
+}
+
+static void remove_module_kprobe_blacklist(struct module *mod)
+{
+}
+#endif /* CONFIG_MODULES */
/* Module notifier call back, checking kprobes on the module */
static int kprobes_module_callback(struct notifier_block *nb,
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 710ec6a6aa8f..881c998d0162 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -103,8 +103,9 @@ static nokprobe_inline bool trace_kprobe_has_gone(struct
trace_kprobe *tk)
ret
[PATCH v5 2/6] vmalloc: Add text_alloc() and text_free()
Introduce functions for allocating memory for dynamic trampolines, such as kprobes. An arch can promote the availability of these functions with CONFIG_ARCH_HAS_TEXT_ALLOC. Cc: linux...@kvack.org Cc: Andi Kleen Cc: Masami Hiramatsu Suggested-by: Peter Zijlstra Signed-off-by: Jarkko Sakkinen --- include/linux/vmalloc.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 0221f852a7e1..6c151a0ac02a 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -249,4 +249,21 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms) int register_vmap_purge_notifier(struct notifier_block *nb); int unregister_vmap_purge_notifier(struct notifier_block *nb); +/* + * These functions can be optionally implemented by an arch in order to + * provide specialized functions for allocating trampoline code. + */ + +#ifdef CONFIG_ARCH_HAS_TEXT_ALLOC +/* + * Allocate memory to be used for trampoline code. + */ +void *text_alloc(unsigned long size); + +/* + * Free memory returned from text_alloc(). + */ +void text_free(void *region); +#endif /* CONFIG_ARCH_HAS_TEXT_ALLOC */ + #endif /* _LINUX_VMALLOC_H */ -- 2.25.1
[PATCH v5 3/6] arch/x86: Implement text_alloc() and text_free()
Implement text_alloc() and text_free() with with the vmalloc API. These can
be used to allocate pages for trampoline code without relying on the module
loader code.
Cc: linux...@kvack.org
Cc: Masami Hiramatsu
Cc: Andi Kleen
Suggested-by: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen
---
arch/x86/Kconfig | 3 +++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/text_alloc.c | 41
3 files changed, 45 insertions(+)
create mode 100644 arch/x86/kernel/text_alloc.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0dea7fdd7a00..a4ee5d1300f6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2035,6 +2035,9 @@ config KEXEC_FILE
config ARCH_HAS_KEXEC_PURGATORY
def_bool KEXEC_FILE
+config ARCH_HAS_TEXT_ALLOC
+ def_bool y
+
config KEXEC_SIG
bool "Verify kernel signature during kexec_file_load() syscall"
depends on KEXEC_FILE
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index e77261db2391..fa1415424ae3 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -68,6 +68,7 @@ obj-y += tsc.o tsc_msr.o io_delay.o rtc.o
obj-y += pci-iommu_table.o
obj-y += resource.o
obj-y += irqflags.o
+obj-y += text_alloc.o
obj-y += process.o
obj-y += fpu/
diff --git a/arch/x86/kernel/text_alloc.c b/arch/x86/kernel/text_alloc.c
new file mode 100644
index ..f31c2d82c258
--- /dev/null
+++ b/arch/x86/kernel/text_alloc.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Kernel module help for x86.
+ * Copyright (C) 2001 Rusty Russell.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+void *text_alloc(unsigned long size)
+{
+ void *p;
+
+ if (PAGE_ALIGN(size) > MODULES_LEN)
+ return NULL;
+
+ p = __vmalloc_node_range(size, MODULE_ALIGN, MODULES_VADDR, MODULES_END,
+GFP_KERNEL, PAGE_KERNEL, 0, NUMA_NO_NODE,
+__builtin_return_address(0));
+
+ if (p && (kasan_module_alloc(p, size) < 0)) {
+ vfree(p);
+ return NULL;
+ }
+
+ return p;
+}
+
+void text_free(void *region)
+{
+ /*
+* This memory may be RO, and freeing RO memory in an interrupt is not
+* supported by vmalloc.
+*/
+ lockdep_assert_irqs_enabled();
+
+ vfree(region);
+}
--
2.25.1
[PATCH v5 1/6] kprobes: Remove dependency to the module_mutex
Add lock_modules() and unlock_modules() wrappers for acquiring module_mutex
in order to remove the compile time dependency to it.
Cc: linux...@kvack.org
Cc: Andi Kleen
Cc: Peter Zijlstra
Suggested-by: Masami Hiramatsu
Signed-off-by: Jarkko Sakkinen
---
include/linux/module.h | 18 ++
kernel/kprobes.c| 4 ++--
kernel/trace/trace_kprobe.c | 4 ++--
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 2e6670860d27..8850b9692b8f 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -705,6 +705,16 @@ static inline bool is_livepatch_module(struct module *mod)
bool is_module_sig_enforced(void);
void set_module_sig_enforced(void);
+static inline void lock_modules(void)
+{
+ mutex_lock(&module_mutex);
+}
+
+static inline void unlock_modules(void)
+{
+ mutex_unlock(&module_mutex);
+}
+
#else /* !CONFIG_MODULES... */
static inline struct module *__module_address(unsigned long addr)
@@ -852,6 +862,14 @@ void *dereference_module_function_descriptor(struct module
*mod, void *ptr)
return ptr;
}
+static inline void lock_modules(void)
+{
+}
+
+static inline void unlock_modules(void)
+{
+}
+
#endif /* CONFIG_MODULES */
#ifdef CONFIG_SYSFS
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 2e97febeef77..4e46d96d4e16 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -564,7 +564,7 @@ static void kprobe_optimizer(struct work_struct *work)
cpus_read_lock();
mutex_lock(&text_mutex);
/* Lock modules while optimizing kprobes */
- mutex_lock(&module_mutex);
+ lock_modules();
/*
* Step 1: Unoptimize kprobes and collect cleaned (unused and disarmed)
@@ -589,7 +589,7 @@ static void kprobe_optimizer(struct work_struct *work)
/* Step 4: Free cleaned kprobes after quiesence period */
do_free_cleaned_kprobes();
- mutex_unlock(&module_mutex);
+ unlock_modules();
mutex_unlock(&text_mutex);
cpus_read_unlock();
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index aefb6065b508..710ec6a6aa8f 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -122,9 +122,9 @@ static nokprobe_inline bool
trace_kprobe_module_exist(struct trace_kprobe *tk)
if (!p)
return true;
*p = '\0';
- mutex_lock(&module_mutex);
+ lock_modules();
ret = !!find_module(tk->symbol);
- mutex_unlock(&module_mutex);
+ unlock_modules();
*p = ':';
return ret;
--
2.25.1
[PATCH v5 2/6] vmalloc: Add text_alloc() and text_free()
Introduce functions for allocating memory for dynamic trampolines, such as kprobes. An arch can promote the availability of these functions with CONFIG_ARCH_HAS_TEXT_ALLOC. Cc: linux...@kvack.org Cc: Andi Kleen Cc: Masami Hiramatsu Suggested-by: Peter Zijlstra Signed-off-by: Jarkko Sakkinen --- include/linux/vmalloc.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 0221f852a7e1..6c151a0ac02a 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -249,4 +249,21 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms) int register_vmap_purge_notifier(struct notifier_block *nb); int unregister_vmap_purge_notifier(struct notifier_block *nb); +/* + * These functions can be optionally implemented by an arch in order to + * provide specialized functions for allocating trampoline code. + */ + +#ifdef CONFIG_ARCH_HAS_TEXT_ALLOC +/* + * Allocate memory to be used for trampoline code. + */ +void *text_alloc(unsigned long size); + +/* + * Free memory returned from text_alloc(). + */ +void text_free(void *region); +#endif /* CONFIG_ARCH_HAS_TEXT_ALLOC */ + #endif /* _LINUX_VMALLOC_H */ -- 2.25.1
[PATCH v5 0/6] arch/x86: kprobes: Remove MODULES dependency
Remove MODULES dependency by migrating from module_alloc() to the new text_alloc() API. Essentially these changes provide preliminaries for allowing to compile a static kernel with a proper tracing support. The same API can be used later on in other sites that allocate space for trampolines, and trivially scaled to other arch's. An arch can inform with CONFIG_ARCH_HAS_TEXT_ALLOC that it's providing implementation for text_alloc(). Cc: linux...@kvack.org Cc: Andi Kleen Cc: Masami Hiramatsu Cc: Peter Zijlstra v4: * Squash lock_modules() patches into one. * Remove fallback versions of text_alloc() and text_free(). Instead, use ARCH_HAS_TEXT_ALLOC at site when required. * Use lockdep_assert_irqs_enabled() in text_free() instead of WARN_ON(in_interrupt()). v3: * Make text_alloc() API disjoint. * Remove all the possible extra clutter not absolutely required and split into more logical pieces. Jarkko Sakkinen (6): kprobes: Remove dependency to the module_mutex vmalloc: Add text_alloc() and text_free() arch/x86: Implement text_alloc() and text_free() arch/x86: kprobes: Use text_alloc() and text_free() kprobes: Use text_alloc() and text_free() kprobes: Remove CONFIG_MODULES dependency arch/Kconfig | 2 +- arch/x86/Kconfig | 3 ++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/kprobes/core.c | 4 +-- arch/x86/kernel/text_alloc.c | 41 +++ include/linux/module.h | 32 ++ include/linux/vmalloc.h| 17 ++ kernel/kprobes.c | 61 +++--- kernel/trace/trace_kprobe.c| 20 --- 9 files changed, 147 insertions(+), 34 deletions(-) create mode 100644 arch/x86/kernel/text_alloc.c -- 2.25.1
[PATCH v5 1/6] kprobes: Remove dependency to the module_mutex
Add lock_modules() and unlock_modules() wrappers for acquiring module_mutex
in order to remove the compile time dependency to it.
Cc: linux...@kvack.org
Cc: Andi Kleen
Cc: Peter Zijlstra
Suggested-by: Masami Hiramatsu
Signed-off-by: Jarkko Sakkinen
---
include/linux/module.h | 18 ++
kernel/kprobes.c| 4 ++--
kernel/trace/trace_kprobe.c | 4 ++--
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 2e6670860d27..8850b9692b8f 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -705,6 +705,16 @@ static inline bool is_livepatch_module(struct module *mod)
bool is_module_sig_enforced(void);
void set_module_sig_enforced(void);
+static inline void lock_modules(void)
+{
+ mutex_lock(&module_mutex);
+}
+
+static inline void unlock_modules(void)
+{
+ mutex_unlock(&module_mutex);
+}
+
#else /* !CONFIG_MODULES... */
static inline struct module *__module_address(unsigned long addr)
@@ -852,6 +862,14 @@ void *dereference_module_function_descriptor(struct module
*mod, void *ptr)
return ptr;
}
+static inline void lock_modules(void)
+{
+}
+
+static inline void unlock_modules(void)
+{
+}
+
#endif /* CONFIG_MODULES */
#ifdef CONFIG_SYSFS
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 2e97febeef77..4e46d96d4e16 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -564,7 +564,7 @@ static void kprobe_optimizer(struct work_struct *work)
cpus_read_lock();
mutex_lock(&text_mutex);
/* Lock modules while optimizing kprobes */
- mutex_lock(&module_mutex);
+ lock_modules();
/*
* Step 1: Unoptimize kprobes and collect cleaned (unused and disarmed)
@@ -589,7 +589,7 @@ static void kprobe_optimizer(struct work_struct *work)
/* Step 4: Free cleaned kprobes after quiesence period */
do_free_cleaned_kprobes();
- mutex_unlock(&module_mutex);
+ unlock_modules();
mutex_unlock(&text_mutex);
cpus_read_unlock();
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index aefb6065b508..710ec6a6aa8f 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -122,9 +122,9 @@ static nokprobe_inline bool
trace_kprobe_module_exist(struct trace_kprobe *tk)
if (!p)
return true;
*p = '\0';
- mutex_lock(&module_mutex);
+ lock_modules();
ret = !!find_module(tk->symbol);
- mutex_unlock(&module_mutex);
+ unlock_modules();
*p = ':';
return ret;
--
2.25.1
[PATCH v5 0/6] arch/x86: kprobes: Remove MODULES dependency
Remove MODULES dependency by migrating from module_alloc() to the new text_alloc() API. Essentially these changes provide preliminaries for allowing to compile a static kernel with a proper tracing support. The same API can be used later on in other sites that allocate space for trampolines, and trivially scaled to other arch's. An arch can inform with CONFIG_ARCH_HAS_TEXT_ALLOC that it's providing implementation for text_alloc(). Cc: linux...@kvack.org Cc: Andi Kleen Cc: Masami Hiramatsu Cc: Peter Zijlstra v4: * Squash lock_modules() patches into one. * Remove fallback versions of text_alloc() and text_free(). Instead, use ARCH_HAS_TEXT_ALLOC at site when required. * Use lockdep_assert_irqs_enabled() in text_free() instead of WARN_ON(in_interrupt()). v3: * Make text_alloc() API disjoint. * Remove all the possible extra clutter not absolutely required and split into more logical pieces. Jarkko Sakkinen (6): kprobes: Remove dependency to the module_mutex vmalloc: Add text_alloc() and text_free() arch/x86: Implement text_alloc() and text_free() arch/x86: kprobes: Use text_alloc() and text_free() kprobes: Use text_alloc() and text_free() kprobes: Remove CONFIG_MODULES dependency arch/Kconfig | 2 +- arch/x86/Kconfig | 3 ++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/kprobes/core.c | 4 +-- arch/x86/kernel/text_alloc.c | 41 +++ include/linux/module.h | 32 ++ include/linux/vmalloc.h| 17 ++ kernel/kprobes.c | 61 +++--- kernel/trace/trace_kprobe.c| 20 --- 9 files changed, 147 insertions(+), 34 deletions(-) create mode 100644 arch/x86/kernel/text_alloc.c -- 2.25.1
Re: [PATCH v10 00/26] Control-flow Enforcement: Shadow Stack
On Thu, Jul 23, 2020 at 11:41:55AM -0700, Dave Hansen wrote:
> On 7/23/20 9:56 AM, Sean Christopherson wrote:
> > On Thu, Jul 23, 2020 at 09:41:37AM -0700, Dave Hansen wrote:
> >> On 7/23/20 9:25 AM, Sean Christopherson wrote:
> >>> How would people feel about taking the above two patches (02 and 03 in the
> >>> series) through the KVM tree to enable KVM virtualization of CET before
> >>> the
> >>> kernel itself gains CET support? I.e. add the MSR and feature bits, along
> >>> with the XSAVES context switching. The feature definitons could use "" to
> >>> suppress displaying them in /proc/cpuinfo to avoid falsely advertising CET
> >>> to userspace.
> >>>
> >>> AIUI, there are ABI issues that need to be sorted out, and that is likely
> >>> going to drag on for some time.
> >>>
> >>> Is this a "hell no" sort of idea, or something that would be feasible if
> >>> we
> >>> can show that there are no negative impacts to the kernel?
> >> Negative impacts like bloating every task->fpu with XSAVE state that
> >> will never get used? ;)
> > Gah, should have qualified that with "meaningful or measurable negative
> > impacts". E.g. the extra 40 bytes for CET XSAVE state seems like it would
> > be acceptable overhead, but noticeably increasing the latency of XSAVES
> > and/or XRSTORS would not be acceptable.
>
> It's 40 bytes, but it's 40 bytes of just pure, unadulterated waste. It
> would have no *chance* of being used. It's also quite precisely
Well, technically the guest would be using that space :-).
> measurable on a given system:
>
> cat /proc/slabinfo | grep task_struct | awk '{print $3 * 40}'
>
> I don't expect it would do *much* to XSAVE/XRSTOR. There's probably an
> extra conditional and jump in the ucode, but that's probably in the
> noise. I assume that all the CET state has functioning init and
> modified trackers and we don't do anything to spoil their state. It
> would be good to check that in practice, though it probably isn't the
> end of the world either way. We've had some bugs in the past where we
> accidentally took things out of their init state.
>
> It will make signal entry/return slower since we use a plain XSAVE
> without the init optimization. But, that's just a single cacheline on
> average and some 0's to write. Probably not noticeable, including the
> 40 bytes of extra userspace signal stack space.
>
> I think that puts me in the "mildly annoyed" camp more than "hell no",
> but "mildly annoyed" is pretty much my resting state, so it doesn't
> really move the needle. :)
>
> Why the urgency, though?
>
> https://windows-internals.com/cet-on-windows/
>
> ?
No urgency, it'd simply be one less KVM feature for us to be carrying and
refreshing. And as a sort of general question, I was curious if folks
would be open to merging KVM support before kernel.
[git pull] drm fixes for 5.8-rc7
Quiet fixes, I may have a single regression fix follow up to this for nouveau, but it might be next week, Ben was testing it a bit more . Otherwise two amdgpu fixes, one lima and one sun4i. Dave. drm-fixes-2020-07-24: drm fixes for 5.6-rc7 amdgpu: - Fix crash when overclocking VegaM - Fix possible crash when editing dpm levels sun4i: - Fix inverted HPD result; fixes an earlier fix lima: - fix timeout during reset The following changes since commit ba47d845d715a010f7b51f6f89bae32845e6acb7: Linux 5.8-rc6 (2020-07-19 15:41:18 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-24 for you to fetch changes up to d8904ca9d338cdaa67e3bd06d7a7d418e426648c: Merge tag 'amd-drm-fixes-5.8-2020-07-22' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-07-23 14:06:16 +1000) drm fixes for 5.6-rc7 amdgpu: - Fix crash when overclocking VegaM - Fix possible crash when editing dpm levels sun4i: - Fix inverted HPD result; fixes an earlier fix lima: - fix timeout during reset Chen-Yu Tsai (1): drm: sun4i: hdmi: Fix inverted HPD result Dave Airlie (2): Merge tag 'drm-misc-fixes-2020-07-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'amd-drm-fixes-5.8-2020-07-22' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Paweł Gronowski (1): drm/amdgpu: Fix NULL dereference in dpm sysfs handlers Qiang Yu (1): drm/lima: fix wait pp reset timeout Qiu Wenbo (1): drm/amd/powerplay: fix a crash when overclocking Vega M drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 9 +++-- drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 10 ++ drivers/gpu/drm/lima/lima_pp.c | 2 ++ drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +- 4 files changed, 12 insertions(+), 11 deletions(-)
[PATCH] rtc: ds1307: provide an indication that the watchdog has fired
There's not much feedback when the ds1388 watchdog fires. Generally it yanks on the reset line and the board reboots. To provide some feedback indicate that the watchdog has fired in the past. This should help distinguish a watchdog triggered reset from a power interruption. Signed-off-by: Chris Packham --- drivers/rtc/rtc-ds1307.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 49702942bb08..431b1a50c483 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -868,6 +868,14 @@ static int ds1388_wdt_start(struct watchdog_device *wdt_dev) struct ds1307 *ds1307 = watchdog_get_drvdata(wdt_dev); u8 regs[2]; int ret; + int val; + + ret = regmap_read(ds1307->regmap, DS1388_REG_FLAG, &val); + if (ret) + return ret; + + if (val & DS1388_BIT_WF) + dev_notice(ds1307->dev, "detected watchdog alarm flag\n"); ret = regmap_update_bits(ds1307->regmap, DS1388_REG_FLAG, DS1388_BIT_WF, 0); -- 2.27.0
Re: [PATCH v10 00/26] Control-flow Enforcement: Shadow Stack
On Thu, Jul 23, 2020 at 08:40:33PM -0700, Yu-cheng Yu wrote:
> On Thu, 2020-07-23 at 11:41 -0700, Dave Hansen wrote:
> > On 7/23/20 9:56 AM, Sean Christopherson wrote:
> > > On Thu, Jul 23, 2020 at 09:41:37AM -0700, Dave Hansen wrote:
> > > > On 7/23/20 9:25 AM, Sean Christopherson wrote:
> > > > > How would people feel about taking the above two patches (02 and 03
> > > > > in the
> > > > > series) through the KVM tree to enable KVM virtualization of CET
> > > > > before the
> > > > > kernel itself gains CET support? I.e. add the MSR and feature bits,
> > > > > along
> > > > > with the XSAVES context switching. The feature definitons could use
> > > > > "" to
> > > > > suppress displaying them in /proc/cpuinfo to avoid falsely
> > > > > advertising CET
> > > > > to userspace.
> > > > >
> > > > > AIUI, there are ABI issues that need to be sorted out, and that is
> > > > > likely
> > > > > going to drag on for some time.
> > > > >
> > > > > Is this a "hell no" sort of idea, or something that would be feasible
> > > > > if we
> > > > > can show that there are no negative impacts to the kernel?
> > > > Negative impacts like bloating every task->fpu with XSAVE state that
> > > > will never get used? ;)
> > > Gah, should have qualified that with "meaningful or measurable negative
> > > impacts". E.g. the extra 40 bytes for CET XSAVE state seems like it would
> > > be acceptable overhead, but noticeably increasing the latency of XSAVES
> > > and/or XRSTORS would not be acceptable.
> >
> > It's 40 bytes, but it's 40 bytes of just pure, unadulterated waste. It
> > would have no *chance* of being used. It's also quite precisely
> > measurable on a given system:
> >
> > cat /proc/slabinfo | grep task_struct | awk '{print $3 * 40}'
>
> If there is value in getting these two patches merged first, we can move
> XFEATURE_MASK_CET_USER to XFEATURE_MASK_SUPERVISOR_UNSUPPORTED for now, until
> CET is eventually merged. That way, there is no space wasted.
Merging them as disabled wouldn't help, KVM needs the features enabled so
that context switching the guest state works as expected.
Re: [PATCH] drivers: isdn: capi: Fix data-race bug
On Thu, Jul 23, 2020 at 03:11:58PM -0700, David Miller wrote: > From: madhuparnabhowmi...@gmail.com > Date: Wed, 22 Jul 2020 22:53:29 +0530 > > > From: Madhuparna Bhowmik > > > > In capi_init(), after register_chrdev() the file operation callbacks > > can be called. However capinc_tty_init() is called later. > > Since capiminors and capinc_tty_driver are initialized in > > capinc_tty_init(), their initialization can race with their usage > > in various callbacks like in capi_release(). > > > > Therefore, call capinc_tty_init() before register_chrdev to avoid > > such race conditions. > > > > Found by Linux Driver Verification project (linuxtesting.org). > > > > Signed-off-by: Madhuparna Bhowmik > > I agree with Arnd that this just exchanges one set of problems for > another. Thanks Arnd and David, for reviewing the patch. Do you have any suggestions on how to fix this correctly? Regards, Madhuparna
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1225:18: sparse: sparse: incorrect type in assignment (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f37e99aca03f63aa3f2bd13ceaf769455d12c4b0
commit: 4647e021193d638d3c87d1f1b9a5f7f7a48f36a3 net: stmmac: selftests: Add
selftest for L3/L4 Filters
date: 11 months ago
config: powerpc-randconfig-s032-20200723 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-93-g4c6cbe55-dirty
git checkout 4647e021193d638d3c87d1f1b9a5f7f7a48f36a3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:991:27: sparse:
sparse: incorrect type in assignment (different base types) @@ expected
restricted __be32 [usertype] mask @@ got int @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:991:27: sparse:
expected restricted __be32 [usertype] mask
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:991:27: sparse:
got int
>> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1225:18: sparse:
>> sparse: incorrect type in assignment (different base types) @@ expected
>> restricted __be32 [addressable] [usertype] src @@ got unsigned int
>> [usertype] src_mask @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1225:18: sparse:
expected restricted __be32 [addressable] [usertype] src
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1225:18: sparse:
got unsigned int [usertype] src_mask
>> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1226:18: sparse:
>> sparse: incorrect type in assignment (different base types) @@ expected
>> restricted __be32 [addressable] [usertype] dst @@ got unsigned int
>> [usertype] dst_mask @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1226:18: sparse:
expected restricted __be32 [addressable] [usertype] dst
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1226:18: sparse:
got unsigned int [usertype] dst_mask
>> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1352:24: sparse:
>> sparse: incorrect type in assignment (different base types) @@ expected
>> restricted __be16 [addressable] [usertype] src @@ got unsigned int
>> [usertype] src_mask @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1352:24: sparse:
expected restricted __be16 [addressable] [usertype] src
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1352:24: sparse:
got unsigned int [usertype] src_mask
>> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1353:24: sparse:
>> sparse: incorrect type in assignment (different base types) @@ expected
>> restricted __be16 [addressable] [usertype] dst @@ got unsigned int
>> [usertype] dst_mask @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1353:24: sparse:
expected restricted __be16 [addressable] [usertype] dst
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1353:24: sparse:
got unsigned int [usertype] dst_mask
vim +1225 drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
1170
1171 #ifdef CONFIG_NET_CLS_ACT
1172 static int __stmmac_test_l3filt(struct stmmac_priv *priv, u32 dst, u32
src,
1173 u32 dst_mask, u32 src_mask)
1174 {
1175 struct flow_dissector_key_ipv4_addrs key, mask;
1176 unsigned long dummy_cookie = 0xdeadbeef;
1177 struct stmmac_packet_attrs attr = { };
1178 struct flow_dissector *dissector;
1179 struct flow_cls_offload *cls;
1180 struct flow_rule *rule;
1181 int ret;
1182
1183 if (!tc_can_offload(priv->dev))
1184 return -EOPNOTSUPP;
1185 if (!priv->dma_cap.l3l4fnum)
1186 return -EOPNOTSUPP;
1187 if (priv->rss.enable) {
1188 struct stmmac_rss rss = { .enable = false, };
1189
1190 stmmac_rss_configure(priv, priv->hw, &rss,
1191 priv->plat->rx_queues_to_use);
1192 }
1193
1194 dissector = kzalloc(sizeof(*dissector), GFP_KERNEL);
1195 if (!dissector) {
1196 ret = -ENOMEM;
1197 goto cleanup_rss;
1198 }
1199
1200 dissector->used_keys |= (1 << FLOW_DISSECTOR_KEY_IPV4_ADDRS);
1201 dissector-&
Re: kernel BUG at mm/vmalloc.c:LINE! (2)
Hi Andrew, On Thu, 23 Jul 2020 19:50:29 -0700 Andrew Morton wrote: > > On Wed, 22 Jul 2020 16:46:50 +0200 Uladzislau Rezki wrote: > > All a bit mysterious. I think it's best that we revert this from > linux-next until we hear from Ingo. I queued a patch - I expect > Stephen will see and grab it, thanks. In the end I actually did the revert (of the revert) in the merge of the tip tree (so that -next will bisect better if necessary). So you will not need the revert in your quilt series after today. -- Cheers, Stephen Rothwell pgphlGkoXLAUT.pgp Description: OpenPGP digital signature
Re: [PATCH] drm: bridge: adv7511: Add missing bridge type
On 24-07-20, 04:30, Laurent Pinchart wrote: > Hi Vinod, > > Thank you for the patch. > > On Thu, Jul 23, 2020 at 04:15:23PM +0530, Vinod Koul wrote: > > Add bridge type as DRM_MODE_CONNECTOR_HDMIA > > > > Signed-off-by: Vinod Koul > > This has already been submitted: > https://lore.kernel.org/dri-devel/20200720124228.12552-1-laurentiu.pa...@oss.nxp.com/ OKay lets drop this one then -- ~Vinod
Re: [PATCH] drm/bridge/adv7511: set the bridge type properly
On 22-07-20, 15:15, Laurent Pinchart wrote: > Hi Laurentiu, > > Thank you for the patch. > > On Mon, Jul 20, 2020 at 03:42:27PM +0300, Laurentiu Palcu wrote: > > From: Laurentiu Palcu > > > > After the drm_bridge_connector_init() helper function has been added, the > > ADV > > driver has been changed accordingly. However, the 'type' field of the bridge > > structure was left unset, which makes the helper function always return > > -EINVAL. > > > > Signed-off-by: Laurentiu Palcu > > Reviewed-by: Laurent Pinchart Thanks Laurent for pointing me to this. Reviewed-by: Vinod Koul I have tested this on DragonBoard 410c: Tested-by: Vinod Koul -- ~Vinod
drivers/irqchip/irq-bcm7038-l1.c:312:13: error: implicit declaration of function 'cpu_logical_map'
Hi Justin,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d15be546031cf65a0fc34879beca02fd90fe7ac7
commit: 6468fc18b00685c82408f40e9569c0d3527862b8 irqchip/irq-bcm7038-l1: Add PM
support
date: 9 months ago
config: mips-randconfig-r033-20200724 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 6468fc18b00685c82408f40e9569c0d3527862b8
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/irqchip/irq-bcm7038-l1.c: In function 'bcm7038_l1_suspend':
>> drivers/irqchip/irq-bcm7038-l1.c:312:13: error: implicit declaration of
>> function 'cpu_logical_map' [-Werror=implicit-function-declaration]
312 | boot_cpu = cpu_logical_map(0);
| ^~~
drivers/irqchip/irq-bcm7038-l1.c: At top level:
drivers/irqchip/irq-bcm7038-l1.c:393:12: warning: no previous prototype for
'bcm7038_l1_of_init' [-Wmissing-prototypes]
393 | int __init bcm7038_l1_of_init(struct device_node *dn,
|^~
cc1: some warnings being treated as errors
vim +/cpu_logical_map +312 drivers/irqchip/irq-bcm7038-l1.c
305
306 static int bcm7038_l1_suspend(void)
307 {
308 struct bcm7038_l1_chip *intc;
309 int boot_cpu, word;
310
311 /* Wakeup interrupt should only come from the boot cpu */
> 312 boot_cpu = cpu_logical_map(0);
313
314 list_for_each_entry(intc, &bcm7038_l1_intcs_list, list) {
315 for (word = 0; word < intc->n_words; word++) {
316 l1_writel(~intc->wake_mask[word],
317 intc->cpus[boot_cpu]->map_base +
reg_mask_set(intc, word));
318 l1_writel(intc->wake_mask[word],
319 intc->cpus[boot_cpu]->map_base +
reg_mask_clr(intc, word));
320 }
321 }
322
323 return 0;
324 }
325
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
RE: linux-next: build failure after merge of the scsi-mkp tree
> >> ERROR: modpost: "exynos_ufs_dump_info" [drivers/scsi/ufs/ufs-exynos.ko] > undefined! > >> ERROR: modpost: "exynos_ufs_init_dbg" [drivers/scsi/ufs/ufs-exynos.ko] > undefined! > >> ERROR: modpost: "exynos_ufs_cmd_log_start" [drivers/scsi/ufs/ufs- > exynos.ko] undefined! > > *sigh* sorry about that. I did verify yesterday's exynos build fix with > COMPILE_TEST but it looks like I didn't have the new driver debugging > option enabled. > > Kiwoong/Alim: Please fix! > > -- > Martin K. PetersenOracle Linux Engineering Hi, Martin. Sorry for responding lately. I'll post a patch to fix soon. Thanks. Kiwoong Kim
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
Hi Rob,
Thanks for the review!
On Thu, 23 Jul 2020 at 23:25, Rob Herring wrote:
>
> On Wed, Jul 22, 2020 at 11:28:15AM +0530, Sumit Semwal wrote:
> > The nt36672a panel from Tianma is a FHD+ panel with a resolution of
> > 1080x2246
> > and 6.18 inches size. It is found in some of the Poco F1 phones.
> >
> > Signed-off-by: Sumit Semwal
> > Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16
>
> You know better...
Yes - Sorry :( - will correct.
>
> > ---
> > v2: remove ports node, making port@0 directly under panel@0 node.
> > ---
> > .../display/panel/tianma,nt36672a.yaml| 104 ++
> > 1 file changed, 104 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > new file mode 100644
> > index ..cb1799fbbd32
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > @@ -0,0 +1,104 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Tianma model NT36672A DSI Panel display driver
> > +
> > +maintainers:
> > + - Sumit Semwal
> > +
> > +description: |
> > + The nt36672a panel from Tianma is a FHD+ LCD display panel with a
> > resolution
> > + of 1080x2246. It is a video mode DSI panel.
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +const: tianma,nt36672a
> > +
> > + reg:
> > +description: DSI virtual channel of the peripheral
> > +
> > + reset-gpios:
> > +description: phandle of gpio for reset line - This should be 8mA, gpio
> > + can be configured using mux, pinctrl, pinctrl-names (active high)
> > +
> > + vddio-supply:
> > +description: phandle of the regulator that provides the supply voltage
> > + Power IC supply
> > +
> > + vddpos-supply:
> > +description: phandle of the positive boost supply regulator
> > +
> > + vddneg-supply:
> > +description: phandle of the negative boost supply regulator
> > +
> > + pinctrl-names:
> > +description: Pinctrl for panel active and suspend
> > +
> > + pinctrl-0:
> > +description: Active pinctrls
> > +
> > + pinctrl-1:
> > +description: Suspend pinctrls
> > +
> > + port@0:
>
> Just 'port' as there can only be 1 in this case.
>
> You can do just: 'port: true' as panel-common.yaml already has a
> definition.
Ok, let me try that and send out v3.
>
> > +type: object
> > +description: DSI input port driven by master DSI
> > +properties:
> > + reg:
> > +const: 0
> > +
> > +required:
> > + - reg
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vddi0-supply
> > + - vddpos-supply
> > + - vddneg-supply
> > + - reset-gpios
> > + - pinctrl-names
> > + - pinctrl-0
> > + - pinctrl-1
> > + - port@0
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |+
> > +#include
> > +dsi0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + panel@0 {
> > +compatible = "tianma,nt36672a";
> > +reg = <0>;
> > +vddi0-supply = <&vreg_l14a_1p88>;
> > +vddpos-supply = <&lab>;
> > +vddneg-supply = <&ibb>;
> > +
> > +reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
> > +
> > +pinctrl-names = "panel_active", "panel_suspend";
> > +pinctrl-0 = <&sde_dsi_active>;
> > +pinctrl-1 = <&sde_dsi_suspend>;
> > +
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +port@0 {
> > + reg = <0>;
> > + tianma_nt36672a_in_0: endpoint {
> > +remote-endpoint = <&dsi0_out>;
> > + };
> > +};
> > + };
> > +};
> > +
> > +...
> > --
> > 2.27.0
> >
>
Best,
Sumit.
Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state
On 23/07/2020 23:11, Nicholas Piggin wrote:
> Excerpts from Peter Zijlstra's message of July 23, 2020 9:40 pm:
>> On Thu, Jul 23, 2020 at 08:56:14PM +1000, Nicholas Piggin wrote:
>>
>>> diff --git a/arch/powerpc/include/asm/hw_irq.h
>>> b/arch/powerpc/include/asm/hw_irq.h
>>> index 3a0db7b0b46e..35060be09073 100644
>>> --- a/arch/powerpc/include/asm/hw_irq.h
>>> +++ b/arch/powerpc/include/asm/hw_irq.h
>>> @@ -200,17 +200,14 @@ static inline bool arch_irqs_disabled(void)
>>> #define powerpc_local_irq_pmu_save(flags) \
>>> do { \
>>> raw_local_irq_pmu_save(flags); \
>>> - trace_hardirqs_off(); \
>>> + if (!raw_irqs_disabled_flags(flags))\
>>> + trace_hardirqs_off(); \
>>> } while(0)
>>> #define powerpc_local_irq_pmu_restore(flags) \
>>> do {\
>>> - if (raw_irqs_disabled_flags(flags)) { \
>>> - raw_local_irq_pmu_restore(flags); \
>>> - trace_hardirqs_off(); \
>>> - } else {\
>>> + if (!raw_irqs_disabled_flags(flags))\
>>> trace_hardirqs_on();\
>>> - raw_local_irq_pmu_restore(flags); \
>>> - } \
>>> + raw_local_irq_pmu_restore(flags); \
>>> } while(0)
>>
>> You shouldn't be calling lockdep from NMI context!
>
> After this patch it doesn't.
>
> trace_hardirqs_on/off implementation appears to expect to be called in NMI
> context though, for some reason.
>
>> That is, I recently
>> added suport for that on x86:
>>
>> https://lkml.kernel.org/r/20200623083721.155449...@infradead.org
>> https://lkml.kernel.org/r/20200623083721.216740...@infradead.org
>>
>> But you need to be very careful on how you order things, as you can see
>> the above relies on preempt_count() already having been incremented with
>> NMI_MASK.
>
> Hmm. My patch seems simpler.
And your patches fix my error while Peter's do not:
IRQs not enabled as expected
WARNING: CPU: 0 PID: 1377 at /home/aik/p/kernel/kernel/softirq.c:169
__local_bh_enable_ip+0x118/0x190
>
> I don't know this stuff very well, I don't really understand what your patch
> enables for x86 but at least it shouldn't be incompatible with this one
> AFAIKS.
>
> Thanks,
> Nick
>
--
Alexey
[PATCH v8 net-next] net: hyperv: dump TX indirection table to ethtool regs
An imbalanced TX indirection table causes netvsc to have low
performance. This table is created and managed during runtime. To help
better diagnose performance issues caused by imbalanced tables, it needs
make TX indirection tables visible.
Because TX indirection table is driver specified information, so
display it via ethtool register dump.
Signed-off-by: Chi Song
---
v8: fix corrupt patch file
v7: move to ethtool register dump
v6: update names to be more precise, remove useless assignment
v5: update variable orders
v4: use a separated group to organize tx_indirection better, change
location of attributes init/exit to netvsc_drv_init/exit
drivers/net/hyperv/netvsc_drv.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 6267f706e8ee..3288221726ea 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1934,6 +1934,23 @@ static int netvsc_set_features(struct net_device *ndev,
return ret;
}
+static int netvsc_get_regs_len(struct net_device *netdev)
+{
+ return VRSS_SEND_TAB_SIZE * sizeof(u32);
+}
+
+static void netvsc_get_regs(struct net_device *netdev,
+ struct ethtool_regs *regs, void *p)
+{
+ struct net_device_context *ndc = netdev_priv(netdev);
+ u32 *regs_buff = p;
+
+ /* increase the version, if buffer format is changed. */
+ regs->version = 1;
+
+ memcpy(regs_buff, ndc->tx_table, VRSS_SEND_TAB_SIZE * sizeof(u32));
+}
+
static u32 netvsc_get_msglevel(struct net_device *ndev)
{
struct net_device_context *ndev_ctx = netdev_priv(ndev);
@@ -1950,6 +1967,8 @@ static void netvsc_set_msglevel(struct net_device *ndev,
u32 val)
static const struct ethtool_ops ethtool_ops = {
.get_drvinfo= netvsc_get_drvinfo,
+ .get_regs_len = netvsc_get_regs_len,
+ .get_regs = netvsc_get_regs,
.get_msglevel = netvsc_get_msglevel,
.set_msglevel = netvsc_set_msglevel,
.get_link = ethtool_op_get_link,
--
2.25.1
Re: drivers/irqchip/irq-bcm7038-l1.c:312:13: error: implicit declaration of function 'cpu_logical_map'
On 7/23/2020 9:07 PM, kernel test robot wrote: > Hi Justin, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: d15be546031cf65a0fc34879beca02fd90fe7ac7 > commit: 6468fc18b00685c82408f40e9569c0d3527862b8 irqchip/irq-bcm7038-l1: Add > PM support > date: 9 months ago > config: mips-randconfig-r033-20200724 (attached as .config) > compiler: mipsel-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout 6468fc18b00685c82408f40e9569c0d3527862b8 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=mips > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >drivers/irqchip/irq-bcm7038-l1.c: In function 'bcm7038_l1_suspend': >>> drivers/irqchip/irq-bcm7038-l1.c:312:13: error: implicit declaration of >>> function 'cpu_logical_map' [-Werror=implicit-function-declaration] > 312 | boot_cpu = cpu_logical_map(0); > | ^~~ >drivers/irqchip/irq-bcm7038-l1.c: At top level: >drivers/irqchip/irq-bcm7038-l1.c:393:12: warning: no previous prototype > for 'bcm7038_l1_of_init' [-Wmissing-prototypes] > 393 | int __init bcm7038_l1_of_init(struct device_node *dn, > |^~ >cc1: some warnings being treated as errors > > vim +/cpu_logical_map +312 drivers/irqchip/irq-bcm7038-l1.c Ah this needs to be guarded with CONFIG_SMP which this failing .config did not enable, I will submit a fix for that first thing in the morning. -- Florian
Re: [PATCH V2 2/3] gpio: xilinx: Add interrupt support
Hi Srinivas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on gpio/for-next]
[also build test ERROR on linus/master v5.8-rc6 next-20200723]
[cannot apply to xlnx/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Srinivas-Neeli/gpio-xilinx-Update-on-xilinx-gpio-driver/20200723-220826
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
for-next
config: x86_64-randconfig-a003-20200723 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpio/gpio-xilinx.c: In function 'xgpio_xlate':
>> drivers/gpio/gpio-xilinx.c:325:8: error: 'struct gpio_chip' has no member
>> named 'of_gpio_n_cells'
325 | if (gc->of_gpio_n_cells < 2) {
|^~
In file included from arch/x86/include/asm/bug.h:92,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/module.h:13,
from drivers/gpio/gpio-xilinx.c:11:
drivers/gpio/gpio-xilinx.c:330:39: error: 'struct gpio_chip' has no member
named 'of_gpio_n_cells'
330 | if (WARN_ON(gpiospec->args_count < gc->of_gpio_n_cells))
| ^~
include/asm-generic/bug.h:118:25: note: in definition of macro 'WARN_ON'
118 | int __ret_warn_on = !!(condition);\
| ^
drivers/gpio/gpio-xilinx.c: In function 'xgpio_probe':
drivers/gpio/gpio-xilinx.c:638:10: error: 'struct gpio_chip' has no member
named 'of_gpio_n_cells'
638 | chip->gc.of_gpio_n_cells = cells;
| ^
>> drivers/gpio/gpio-xilinx.c:639:10: error: 'struct gpio_chip' has no member
>> named 'of_xlate'
639 | chip->gc.of_xlate = xgpio_xlate;
| ^
vim +325 drivers/gpio/gpio-xilinx.c
312
313 /**
314 * xgpio_xlate - Translate gpio_spec to the GPIO number and flags
315 * @gc: Pointer to gpio_chip device structure.
316 * @gpiospec: gpio specifier as found in the device tree
317 * @flags: A flags pointer based on binding
318 *
319 * Return:
320 * irq number otherwise -EINVAL
321 */
322 static int xgpio_xlate(struct gpio_chip *gc,
323 const struct of_phandle_args *gpiospec, u32
*flags)
324 {
> 325 if (gc->of_gpio_n_cells < 2) {
326 WARN_ON(1);
327 return -EINVAL;
328 }
329
330 if (WARN_ON(gpiospec->args_count < gc->of_gpio_n_cells))
331 return -EINVAL;
332
333 if (gpiospec->args[0] >= gc->ngpio)
334 return -EINVAL;
335
336 if (flags)
337 *flags = gpiospec->args[1];
338
339 return gpiospec->args[0];
340 }
341
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v5 07/10] bus: mhi: core: Introduce debugfs entries for MHI
Hi Bhaumik,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc6 next-20200723]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Bhaumik-Bhatt/Introduce-features-and-debugfs-sysfs-entries-for-MHI/20200724-063954
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
d15be546031cf65a0fc34879beca02fd90fe7ac7
config: csky-allyesconfig (attached as .config)
compiler: csky-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=csky
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/bus/mhi/core/debugfs.c: In function 'mhi_debugfs_events_show':
>> drivers/bus/mhi/core/debugfs.c:73:51: warning: cast from pointer to integer
>> of different size [-Wpointer-to-int-cast]
73 | seq_printf(m, " local rp: 0x%llx db: 0x%llx\n", (u64)ring->rp,
| ^
>> drivers/bus/mhi/core/debugfs.c:73:45: warning: format '%llx' expects
>> argument of type 'long long unsigned int', but argument 4 has type
>> 'dma_addr_t' {aka 'unsigned int'} [-Wformat=]
73 | seq_printf(m, " local rp: 0x%llx db: 0x%llx\n", (u64)ring->rp,
| ~~~^
| |
| long long unsigned int
| %x
74 | mhi_event->db_cfg.db_val);
|
||
|dma_addr_t {aka unsigned int}
drivers/bus/mhi/core/debugfs.c: In function 'mhi_debugfs_channels_show':
drivers/bus/mhi/core/debugfs.c:121:7: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
121 | (u64)ring->rp, (u64)ring->wp,
| ^
drivers/bus/mhi/core/debugfs.c:121:22: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
121 | (u64)ring->rp, (u64)ring->wp,
| ^
drivers/bus/mhi/core/debugfs.c:120:62: warning: format '%llx' expects
argument of type 'long long unsigned int', but argument 5 has type 'dma_addr_t'
{aka 'unsigned int'} [-Wformat=]
120 | seq_printf(m, " local rp: 0x%llx local wp: 0x%llx db: 0x%llx\n",
| ~~~^
| |
| long
long unsigned int
| %x
121 | (u64)ring->rp, (u64)ring->wp,
122 | mhi_chan->db_cfg.db_val);
| ~~~
| |
| dma_addr_t {aka unsigned int}
vim +73 drivers/bus/mhi/core/debugfs.c
36
37 static int mhi_debugfs_events_show(struct seq_file *m, void *d)
38 {
39 struct mhi_controller *mhi_cntrl = m->private;
40 struct mhi_event *mhi_event;
41 struct mhi_event_ctxt *er_ctxt;
42 int i;
43
44 if (!mhi_is_active(mhi_cntrl)) {
45 seq_puts(m, "Device not ready\n");
46 return -ENODEV;
47 }
48
49 er_ctxt = mhi_cntrl->mhi_ctxt->er_ctxt;
50 mhi_event = mhi_cntrl->mhi_event;
51 for (i = 0; i < mhi_cntrl->total_ev_rings;
52 i++, er_ctxt++,
mhi_event++) {
53 struct mhi_ring *ring = &mhi_event->ring;
54
55 if (mhi_event->offload_ev) {
56 seq_printf(m, "Index: %d is an offload event
ring\n",
57 i);
58 continue;
59 }
60
61 seq_printf(m, "Index: %d intmod count: %lu time: %lu",
62 i, (er_ctxt->intmod &
[PATCH 2/2] libnvdimm/security: ensure sysfs poll thread woke up and fetch updated attr
commit 7d988097c546 ("acpi/nfit, libnvdimm/security: Add security DSM overwrite
support")
adds a sysfs_notify_dirent() to wake up userspace poll thread when the
"overwrite"
operation has completed. But the notification is issued before the internal
dimm security state and flags have been updated, so the userspace poll thread
wakes up and fetches the not-yet-updated attr and falls back to sleep, forever.
But if user from another terminal issue "ndctl wait-overwrite nmemX" again,
the command returns instantly.
Cc: Dave Jiang
Cc: Dan Williams
Fixes: 7d988097c546 ("acpi/nfit, libnvdimm/security: Add security DSM overwrite
support")
Signed-off-by: Jane Chu
---
drivers/nvdimm/security.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/nvdimm/security.c b/drivers/nvdimm/security.c
index 8f3971c..4b80150 100644
--- a/drivers/nvdimm/security.c
+++ b/drivers/nvdimm/security.c
@@ -450,14 +450,19 @@ void __nvdimm_security_overwrite_query(struct nvdimm
*nvdimm)
else
dev_dbg(&nvdimm->dev, "overwrite completed\n");
- if (nvdimm->sec.overwrite_state)
- sysfs_notify_dirent(nvdimm->sec.overwrite_state);
+ /*
+* Mark the overwrite work done and update dimm security flags,
+* then send a sysfs event notification to wake up userspace
+* poll threads to picked up the changed state.
+*/
nvdimm->sec.overwrite_tmo = 0;
clear_bit(NDD_SECURITY_OVERWRITE, &nvdimm->flags);
clear_bit(NDD_WORK_PENDING, &nvdimm->flags);
- put_device(&nvdimm->dev);
nvdimm->sec.flags = nvdimm_security_flags(nvdimm, NVDIMM_USER);
nvdimm->sec.ext_flags = nvdimm_security_flags(nvdimm, NVDIMM_MASTER);
+ if (nvdimm->sec.overwrite_state)
+ sysfs_notify_dirent(nvdimm->sec.overwrite_state);
+ put_device(&nvdimm->dev);
}
void nvdimm_security_overwrite_query(struct work_struct *work)
--
1.8.3.1
[PATCH 1/2] libnvdimm/security: 'security' attr never show 'overwrite' state
Since
commit d78c620a2e82 ("libnvdimm/security: Introduce a 'frozen' attribute"),
when issue
then immediately check the 'security' attribute,
unlocked
Actually the attribute stays 'unlocked' through out the entire overwrite
operation, never changed. That's because 'nvdimm->sec.flags' is a bitmap
that has both bits set indicating 'overwrite' and 'unlocked'.
But security_show() checks the mutually exclusive bits before it checks
the 'overwrite' bit at last. The order should be reversed.
The commit also has a typo: in one occasion, 'nvdimm->sec.ext_state'
assignment is replaced with 'nvdimm->sec.flags' assignment for
the NVDIMM_MASTER type.
Cc: Dan Williams
Fixes: d78c620a2e82 ("libnvdimm/security: Introduce a 'frozen' attribute")
Signed-off-by: Jane Chu
---
drivers/nvdimm/dimm_devs.c | 4 ++--
drivers/nvdimm/security.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
index b7b77e8..5d72026 100644
--- a/drivers/nvdimm/dimm_devs.c
+++ b/drivers/nvdimm/dimm_devs.c
@@ -363,14 +363,14 @@ __weak ssize_t security_show(struct device *dev,
{
struct nvdimm *nvdimm = to_nvdimm(dev);
+ if (test_bit(NVDIMM_SECURITY_OVERWRITE, &nvdimm->sec.flags))
+ return sprintf(buf, "overwrite\n");
if (test_bit(NVDIMM_SECURITY_DISABLED, &nvdimm->sec.flags))
return sprintf(buf, "disabled\n");
if (test_bit(NVDIMM_SECURITY_UNLOCKED, &nvdimm->sec.flags))
return sprintf(buf, "unlocked\n");
if (test_bit(NVDIMM_SECURITY_LOCKED, &nvdimm->sec.flags))
return sprintf(buf, "locked\n");
- if (test_bit(NVDIMM_SECURITY_OVERWRITE, &nvdimm->sec.flags))
- return sprintf(buf, "overwrite\n");
return -ENOTTY;
}
diff --git a/drivers/nvdimm/security.c b/drivers/nvdimm/security.c
index 4cef69b..8f3971c 100644
--- a/drivers/nvdimm/security.c
+++ b/drivers/nvdimm/security.c
@@ -457,7 +457,7 @@ void __nvdimm_security_overwrite_query(struct nvdimm
*nvdimm)
clear_bit(NDD_WORK_PENDING, &nvdimm->flags);
put_device(&nvdimm->dev);
nvdimm->sec.flags = nvdimm_security_flags(nvdimm, NVDIMM_USER);
- nvdimm->sec.flags = nvdimm_security_flags(nvdimm, NVDIMM_MASTER);
+ nvdimm->sec.ext_flags = nvdimm_security_flags(nvdimm, NVDIMM_MASTER);
}
void nvdimm_security_overwrite_query(struct work_struct *work)
--
1.8.3.1
cc1: error: '-mloongson-mmi' must be used with '-mhard-float'
Hi Thomas, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d15be546031cf65a0fc34879beca02fd90fe7ac7 commit: 26bff9eb49201aeb4e1b32d698c191831a39f5d4 MIPS: Only include the platform file needed date: 2 months ago config: mips-randconfig-c003-20200723 (attached as .config) compiler: mips64el-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 26bff9eb49201aeb4e1b32d698c191831a39f5d4 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> cc1: error: '-mloongson-mmi' must be used with '-mhard-float' >> cc1: error: '-mloongson-mmi' must be used with '-mhard-float' make[2]: *** [scripts/Makefile.build:100: kernel/bounds.s] Error 1 make[2]: Target 'missing-syscalls' not remade because of errors. make[1]: *** [arch/mips/Makefile:394: archprepare] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [Makefile:180: sub-make] Error 2 make: Target 'prepare' not remade because of errors. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
drivers/watchdog/ar7_wdt.c:193:29: sparse: sparse: incorrect type in initializer (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d15be546031cf65a0fc34879beca02fd90fe7ac7 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 5 weeks ago config: mips-randconfig-s032-20200723 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/watchdog/ar7_wdt.c:193:29: sparse: sparse: incorrect type in >> initializer (different address spaces) @@ expected char const [noderef] >> __user *__gu_ptr @@ got char const * @@ >> drivers/watchdog/ar7_wdt.c:193:29: sparse: expected char const [noderef] >> __user *__gu_ptr drivers/watchdog/ar7_wdt.c:193:29: sparse: got char const * >> drivers/watchdog/ar7_wdt.c:216:35: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void [noderef] __user >> *to @@ got struct watchdog_info * @@ >> drivers/watchdog/ar7_wdt.c:216:35: sparse: expected void [noderef] >> __user *to drivers/watchdog/ar7_wdt.c:216:35: sparse: got struct watchdog_info * >> drivers/watchdog/ar7_wdt.c:222:21: sparse: sparse: incorrect type in >> initializer (different address spaces) @@ expected int [noderef] __user >> *__pu_addr @@ got int * @@ >> drivers/watchdog/ar7_wdt.c:222:21: sparse: expected int [noderef] __user >> *__pu_addr drivers/watchdog/ar7_wdt.c:222:21: sparse: got int * >> drivers/watchdog/ar7_wdt.c:229:21: sparse: sparse: incorrect type in >> initializer (different address spaces) @@ expected int const [noderef] >> __user *__gu_ptr @@ got int * @@ >> drivers/watchdog/ar7_wdt.c:229:21: sparse: expected int const [noderef] >> __user *__gu_ptr drivers/watchdog/ar7_wdt.c:229:21: sparse: got int * drivers/watchdog/ar7_wdt.c:241:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int [noderef] __user *__pu_addr @@ got int * @@ drivers/watchdog/ar7_wdt.c:241:21: sparse: expected int [noderef] __user *__pu_addr drivers/watchdog/ar7_wdt.c:241:21: sparse: got int * drivers/watchdog/ar7_wdt.c:251:27: sparse: sparse: incorrect type in initializer (incompatible argument 2 (different address spaces)) @@ expected int ( *write )( ... ) @@ got int ( * )( ... ) @@ drivers/watchdog/ar7_wdt.c:251:27: sparse: expected int ( *write )( ... ) drivers/watchdog/ar7_wdt.c:251:27: sparse: got int ( * )( ... ) >> drivers/watchdog/ar7_wdt.c:271:17: sparse: sparse: incorrect type in >> assignment (different address spaces) @@ expected struct ar7_wdt *static >> [toplevel] ar7_wdt @@ got void [noderef] __iomem * @@ drivers/watchdog/ar7_wdt.c:271:17: sparse: expected struct ar7_wdt *static [toplevel] ar7_wdt >> drivers/watchdog/ar7_wdt.c:271:17: sparse: got void [noderef] __iomem * drivers/watchdog/ar7_wdt.c: note: in included file (through arch/mips/include/asm/mmiowb.h, include/linux/spinlock.h, include/linux/seqlock.h, ...): arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 ar
[PATCH V2 0/3] Add wakeup support over UART RX
Changes in V2: - As per Matthias's comment added wakeup support for all the UARTs of SC7180. - Added sleep state in sc7180-idp.dts file. - Modify the if check in set_mctrl API in serial driver to avoid making RFR high during suspend. Hi Greg, These patches are based on qcom tree. Please ack the serial driver patch to land via qcom-tree. Thanks, Satya Priya satya priya (3): arm64: dts: sc7180: Add wakeup support over UART RX arm64: dts: qcom: sc7180: Add sleep pin ctrl for BT uart tty: serial: qcom_geni_serial: Fix the UART wakeup issue arch/arm64/boot/dts/qcom/sc7180-idp.dts | 42 -- arch/arm64/boot/dts/qcom/sc7180.dtsi| 98 - drivers/tty/serial/qcom_geni_serial.c | 2 +- 3 files changed, 121 insertions(+), 21 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH V2 3/3] tty: serial: qcom_geni_serial: Fix the UART wakeup issue
As a part of system suspend we call uart_port_suspend from the Serial driver, which calls set_mctrl passing mctrl as NULL. This makes RFR high(NOT_READY) during suspend. Due to this BT SoC is not able to send wakeup bytes to UART during suspend. Included if check for non-suspend case to keep RFR low during suspend. Signed-off-by: satya priya --- Changes in V2: - This patch fixes the UART flow control issue during suspend. Newly added in V2. drivers/tty/serial/qcom_geni_serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c index 07b7b6b..7108dfc 100644 --- a/drivers/tty/serial/qcom_geni_serial.c +++ b/drivers/tty/serial/qcom_geni_serial.c @@ -242,7 +242,7 @@ static void qcom_geni_serial_set_mctrl(struct uart_port *uport, if (mctrl & TIOCM_LOOP) port->loopback = RX_TX_CTS_RTS_SORTED; - if (!(mctrl & TIOCM_RTS)) + if ((!(mctrl & TIOCM_RTS)) && (!(uport->suspended))) uart_manual_rfr = UART_MANUAL_RFR_EN | UART_RFR_NOT_READY; writel(uart_manual_rfr, uport->membase + SE_UART_MANUAL_RFR); } -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH V2 1/3] arm64: dts: sc7180: Add wakeup support over UART RX
Add the necessary pinctrl and interrupts to make UART wakeup capable. Signed-off-by: satya priya --- Changes in V2: - As per Matthias's comment added wakeup support for all the UARTs of SC7180. arch/arm64/boot/dts/qcom/sc7180.dtsi | 98 ++-- 1 file changed, 84 insertions(+), 14 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi index 16df08d..044a4d0 100644 --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi @@ -787,9 +787,11 @@ reg = <0 0x0088 0 0x4000>; clock-names = "se"; clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>; - pinctrl-names = "default"; + pinctrl-names = "default", "sleep"; pinctrl-0 = <&qup_uart0_default>; - interrupts = ; + pinctrl-1 = <&qup_uart0_sleep>; + interrupts-extended = <&intc GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>, + <&tlmm 37 IRQ_TYPE_EDGE_FALLING>; power-domains = <&rpmhpd SC7180_CX>; operating-points-v2 = <&qup_opp_table>; interconnects = <&qup_virt MASTER_QUP_CORE_0 &qup_virt SLAVE_QUP_CORE_0>, @@ -839,9 +841,11 @@ reg = <0 0x00884000 0 0x4000>; clock-names = "se"; clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>; - pinctrl-names = "default"; + pinctrl-names = "default", "sleep"; pinctrl-0 = <&qup_uart1_default>; - interrupts = ; + pinctrl-1 = <&qup_uart1_sleep>; + interrupts-extended = <&intc GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>, + <&tlmm 3 IRQ_TYPE_EDGE_FALLING>; power-domains = <&rpmhpd SC7180_CX>; operating-points-v2 = <&qup_opp_table>; interconnects = <&qup_virt MASTER_QUP_CORE_0 &qup_virt SLAVE_QUP_CORE_0>, @@ -925,9 +929,11 @@ reg = <0 0x0088c000 0 0x4000>; clock-names = "se"; clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>; - pinctrl-names = "default"; + pinctrl-names = "default", "sleep"; pinctrl-0 = <&qup_uart3_default>; - interrupts = ; + pinctrl-1 = <&qup_uart3_sleep>; + interrupts-extended = <&intc GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>, + <&tlmm 41 IRQ_TYPE_EDGE_FALLING>; power-domains = <&rpmhpd SC7180_CX>; operating-points-v2 = <&qup_opp_table>; interconnects = <&qup_virt MASTER_QUP_CORE_0 &qup_virt SLAVE_QUP_CORE_0>, @@ -1011,9 +1017,11 @@ reg = <0 0x00894000 0 0x4000>; clock-names = "se"; clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>; - pinctrl-names = "default"; + pinctrl-names = "default", "sleep"; pinctrl-0 = <&qup_uart5_default>; - interrupts = ; + pinctrl-1 = <&qup_uart5_sleep>; + interrupts-extended = <&intc GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>, + <&tlmm 28 IRQ_TYPE_EDGE_FALLING>; power-domains = <&rpmhpd SC7180_CX>; operating-points-v2 = <&qup_opp_table>; interconnects = <&qup_virt MASTER_QUP_CORE_0 &qup_virt SLAVE_QUP_CORE_0>, @@ -1078,9 +1086,11 @@ reg = <0 0x00a8 0 0x4000>; clock-names = "se"; clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>; - pinctrl-names = "default"; + pinctrl-names = "default", "sleep"; pinctrl-0 = <&qup_uart6_default>; - interrupts = ; + pinctrl-1 = <&qup_uart6_sleep>; + interrupts-extended = <&intc GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>, + <&tlm
[PATCH V2 2/3] arm64: dts: qcom: sc7180: Add sleep pin ctrl for BT uart
Add sleep pin ctrl for BT uart, and also change the bias
configuration to match Bluetooth module.
Signed-off-by: satya priya
---
Changes in V2:
- This patch adds sleep state for BT UART. Newly added in V2.
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 42 -
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index 26cc491..bc919f2 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
@@ -469,20 +469,50 @@
&qup_uart3_default {
pinconf-cts {
- /*
-* Configure a pull-down on 38 (CTS) to match the pull of
-* the Bluetooth module.
-*/
+ /* Configure no pull on 38 (CTS) to match Bluetooth module */
pins = "gpio38";
+ bias-disable;
+ };
+
+ pinconf-rts {
+ /* We'll drive 39 (RTS), so configure pull-down */
+ pins = "gpio39";
+ drive-strength = <2>;
bias-pull-down;
+ };
+
+ pinconf-tx {
+ /* We'll drive 40 (TX), so no pull */
+ pins = "gpio40";
+ drive-strength = <2>;
+ bias-disable;
output-high;
};
+ pinconf-rx {
+ /*
+* Configure a pull-up on 41 (RX). This is needed to avoid
+* garbage data when the TX pin of the Bluetooth module is
+* in tri-state (module powered off or not driving the
+* signal yet).
+*/
+ pins = "gpio41";
+ bias-pull-up;
+ };
+};
+
+&qup_uart3_sleep {
+ pinconf-cts {
+ /* Configure no-pull on 38 (CTS) to match Bluetooth module */
+ pins = "gpio38";
+ bias-disable;
+ };
+
pinconf-rts {
- /* We'll drive 39 (RTS), so no pull */
+ /* We'll drive 39 (RTS), so configure pull-down */
pins = "gpio39";
drive-strength = <2>;
- bias-disable;
+ bias-pull-down;
};
pinconf-tx {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] arm64: dts: sc7180: Add wakeup support over UART RX
Hi Matthias,
On 2020-04-27 22:26, Matthias Kaehlcke wrote:
Hi,
On Mon, Apr 27, 2020 at 11:57:24AM +0530, satya priya wrote:
Add the necessary pinctrl and interrupts to make UART
wakeup capable.
Signed-off-by: satya priya
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 4216b57..3a49603 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -637,9 +637,12 @@
reg = <0 0x0088c000 0 0x4000>;
clock-names = "se";
clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "sleep";
pinctrl-0 = <&qup_uart3_default>;
- interrupts = ;
+ pinctrl-1 = <&qup_uart3_default>;
Why is the 'sleep' configuration needed if it's the same as 'default'?
Sleep configuration is needed to make sure correct pinctrl setting is
done for RX.
When we register wakeup interrupt, function select is changed to 0 or
GPIO, and after that when state on is called, down the line it is
checking the current state, if it's same as previous state(default), it
won't do any thing and returns 0. Thus the pinctrl setting for RX
remains with "GPIO" function select causing transfer failures.
int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
{
if (p->state == state)
return 0;
return pinctrl_commit_state(p, state);
}
EXPORT_SYMBOL_GPL(pinctrl_select_state);
However, in V2 we have added sleep state separately to make wakeup
feature work properly.
+ interrupts-extended =
+ <&intc GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
+ <&tlmm 41 0>;
status = "disabled";
};
This patch only adds wakeup support for uart3, which seems an arbitrary
choice at SoC level. Either it should do it for all UARTs of the
SC7180,
or in the .dtsi of devices that use UART3 and need it to be wakeup
capable.
Ok. Added wakeup support to all the UARTs of SC7180 in V2.
Thanks,
Satya Priya
[PATCH] ARM: OMAP2+: Fix an IS_ERR() vs NULL check in _get_pwrdm()
The of_clk_get() function returns error pointers, it never returns NULL.
Fixes: 4ea3711aece4 ("ARM: OMAP2+: omap-iommu.c conversion to ti-sysc")
Signed-off-by: Jing Xiangfeng
---
arch/arm/mach-omap2/omap-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 54aff33e55e6..bfa5e1b8dba7 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -74,7 +74,7 @@ static struct powerdomain *_get_pwrdm(struct device *dev)
return pwrdm;
clk = of_clk_get(dev->of_node->parent, 0);
- if (!clk) {
+ if (IS_ERR(clk)) {
dev_err(dev, "no fck found\n");
return NULL;
}
--
2.17.1
Re: [fsnotify] c738fbabb0: will-it-scale.per_process_ops -9.5% regression
On Fri, Jul 24, 2020 at 5:45 AM Rong Chen wrote:
>
>
>
> On 7/21/20 11:59 PM, Amir Goldstein wrote:
> > On Tue, Jul 21, 2020 at 3:15 AM kernel test robot
> > wrote:
> >> Greeting,
> >>
> >> FYI, we noticed a -9.5% regression of will-it-scale.per_process_ops due to
> >> commit:
> >>
> >>
> >> commit: c738fbabb0ff62d0f9a9572e56e65d05a1b34c6a ("fsnotify: fold
> >> fsnotify() call into fsnotify_parent()")
> > Strange, that's a pretty dumb patch moving some inlined code from one
> > function to
> > another (assuming there are no fsnotify marks in this test).
> >
> > Unless I am missing something the only thing that changes slightly is
> > an extra d_inode(file->f_path.dentry) deference.
> > I can get rid of it.
> >
> > Is it possible to ask for a re-test with fix patch (attached)?
>
> Hi Amir,
>
> We failed to apply this patch, could you tell us the base commit or the
> base branch?
>
Hi Rong,
The patch is applied on top of the reported offending commit:
c738fbabb0ff62d0f9a9572e56e65d05a1b34c6a ("fsnotify: fold fsnotify()
call into fsnotify_parent()")
I pushed it to my github:
https://github.com/amir73il/linux/commits/for_lkp
Thanks,
Amir.
Re: [RFC PATCH] mm: silence soft lockups from unlock_page
On Thu, Jul 23, 2020 at 5:47 PM Linus Torvalds
wrote:
>
> On Thu, Jul 23, 2020 at 5:07 PM Hugh Dickins wrote:
> >
> > I say that for full disclosure, so you don't wrack your brains
> > too much, when it may still turn out to be a screwup on my part.
>
> Sounds unlikely.
>
> If that patch applied even reasonably closely, I don't see how you'd
> see a list corruption that wasn't due to the patch.
>
> You'd have had to use the wrong spinlock by mistake due to munging it,
> or something crazy like that.
>
> The main list-handling change is
>
> (a) open-coding of that finish_wait()
>
> (b) slightly different heuristics for removal in the wakeup function
>
> where (a) was because my original version of finishing the wait needed
> to do that return code checking.
>
> So a normal "finish_wait()" just does
>
> list_del_init(&wait->entry);
>
> where-as my open-coded one replaced that with
>
> if (!list_empty(&wait->entry)) {
> list_del(&wait->entry);
> ret = -EINTR;
> }
>
> and apart from that "set return to -EINTR because nobody woke us up",
> it also uses just a regular "list_del()" rather than a
> "list_del_init()". That causes the next/prev field to be poisoned
> rather than re-initialized. But that second change was because the
> list entry is on the stack, and we're not touching it any more and are
> about to return, so I removed the "init" part.
>
> Anyway, (a) really looks harmless. Unless the poisoning now triggers
> some racy debug test that had been hidden by the "init". Hmm.
>
> In contrast, (b) means that the likely access patterns of irqs
> removing the wait entry from the list might be very different from
> before. The old "autoremove" semantics would only remove the entry
> from the list when try_to_wake_up() actually woke things up. Now, a
> successful bit state _always_ removes it, which was kind of the point.
> But it might cause very different list handling patterns.
>
> All the actual list handling looks "obviously safe" because it's
> protected by the spinlock, though...
>
> If you do get oopses with the new patch too, try to send me a copy,
> and maybe I'll stare at exactly where it happens register contents and
> go "aah".
This new version is doing much better: many hours to go, but all
machines have got beyond the danger point where yesterday's version
was crashing - phew!
Hugh
Re: [PATCH v10 00/26] Control-flow Enforcement: Shadow Stack
On Thu, 2020-07-23 at 11:41 -0700, Dave Hansen wrote:
> On 7/23/20 9:56 AM, Sean Christopherson wrote:
> > On Thu, Jul 23, 2020 at 09:41:37AM -0700, Dave Hansen wrote:
> > > On 7/23/20 9:25 AM, Sean Christopherson wrote:
> > > > How would people feel about taking the above two patches (02 and 03 in
> > > > the
> > > > series) through the KVM tree to enable KVM virtualization of CET before
> > > > the
> > > > kernel itself gains CET support? I.e. add the MSR and feature bits,
> > > > along
> > > > with the XSAVES context switching. The feature definitons could use ""
> > > > to
> > > > suppress displaying them in /proc/cpuinfo to avoid falsely advertising
> > > > CET
> > > > to userspace.
> > > >
> > > > AIUI, there are ABI issues that need to be sorted out, and that is
> > > > likely
> > > > going to drag on for some time.
> > > >
> > > > Is this a "hell no" sort of idea, or something that would be feasible
> > > > if we
> > > > can show that there are no negative impacts to the kernel?
> > > Negative impacts like bloating every task->fpu with XSAVE state that
> > > will never get used? ;)
> > Gah, should have qualified that with "meaningful or measurable negative
> > impacts". E.g. the extra 40 bytes for CET XSAVE state seems like it would
> > be acceptable overhead, but noticeably increasing the latency of XSAVES
> > and/or XRSTORS would not be acceptable.
>
> It's 40 bytes, but it's 40 bytes of just pure, unadulterated waste. It
> would have no *chance* of being used. It's also quite precisely
> measurable on a given system:
>
> cat /proc/slabinfo | grep task_struct | awk '{print $3 * 40}'
If there is value in getting these two patches merged first, we can move
XFEATURE_MASK_CET_USER to XFEATURE_MASK_SUPERVISOR_UNSUPPORTED for now, until
CET is eventually merged. That way, there is no space wasted.
Yu-cheng
答复: 答复: 答复: [PATCH] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP
-邮件原件- 发件人: Mike Rapoport [mailto:r...@linux.ibm.com] 发送时间: 2020年7月23日 21:19 收件人: Catalin Marinas 抄送: liwei (CM) ; w...@kernel.org; Xiaqing (A) ; Chenfeng (puck) ; butao ; fengbaopeng ; nsaenzjulie...@suse.de; steve.cap...@arm.com; Song Bao Hua (Barry Song) ; linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; sujunfei ; zhaojiapeng 主题: Re: 答复: 答复: [PATCH] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP On Thu, Jul 23, 2020 at 12:29:26PM +0100, Catalin Marinas wrote: > On Wed, Jul 22, 2020 at 01:40:34PM +, liwei (CM) wrote: > > Catalin Marinas wrote: > > > On Wed, Jul 22, 2020 at 08:41:17AM +, liwei (CM) wrote: > > > > Mike Rapoport wrote: > > > > > On Tue, Jul 21, 2020 at 03:32:03PM +0800, Wei Li wrote: > > > > > > For the memory hole, sparse memory model that define > > > > > > SPARSEMEM_VMEMMAP do not free the reserved memory for the > > > > > > page map, this patch do it. > > > > > > > > > > Are there numbers showing how much memory is actually freed? > > > > > > > > > > The freeing of empty memmap would become rather complex with > > > > > these changes, do the memory savings justify it? > > > > > > > > In the sparse memory model, the size of a section is 1 GB > > > > (SECTION_SIZE_BITS 30) by default. > > > > > > Can we reduce SECTION_SIZE_BITS instead? Say 26? > > > > Yes, you are right, reduce SECTION_SIZE_BITS to 26 can save almost > > the same memory as the patch. > > > > 1) However, it is not clear whether changing the section size has > > any other impact. > > Well, we should analyse this. > > > 2) Just like the flat memory model and the sparse memory model that > > does not define VMEMMAP, both of them have their own ways to free > > unused memmap. I think we've given a similar way for sparse memory > > define VMEMMAP. > > I think we did it for flatmem initially (on arm32) and added support > for sparsemem later on, so free_unused_memmap() had to cope with > sparse sections. On arm64 we introduced vmemmap support and didn't > bother with the freeing at all because of the added complexity of the > vmemmap page tables. > > I wonder whether we should just disallow flatmem and non-vmemmap > sparsemem on arm64. Is there any value in keeping them around? FLATMEM is useful for UMA systems with a single memory bank, so probably it's worth keeping it for low end machines. Non-vmemmap sparsemem is essentially disable in arch/arm64/Kconfig, so for NUMA configurations SPARSEMEM_VMEMMAP is the only choice. > > 3) This explicit free unused memmap method does reduce unnecessary > > memory waste for users who do not notice the section size > > modification. > > But if we changed SECTION_SIZE_BITS in the mainline kernel, then we > wouldn't need additional code to free the unused memmap. Moreover if we reduce SECTION_SIZE_BITS, we can drop free_unused_memmap() and since the arm64 memory map for sparse will not differ from other arches we can drop custom pfn_valid() as well. Hi, Mike & Catalin Let's think and discuss together about the impact of directly reducing the section size： 1) Currently, the memory of PC or Mobile devices are increasing. If the section size is reduced, the consumption of the section structure will also increase. 2) If the section size is too small, memory hotplug may be affected. Hotplug add or remove a memblock means that you need to online or offline many sections. In this case, software consumption may increase. Currently, the page map is wasted when the default section size is used. In some cases, the waste is serious. Please help to check whether the section size reduction has other impacts and whether it meets the long-term evolution. Thanks. > -- > Catalin -- Sincerely yours, Mike.
Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state
Hi Nicholas, I love your patch! Perhaps something to improve: [auto build test WARNING on linux/master] [also build test WARNING on powerpc/next linus/master v5.8-rc6 next-20200723] [cannot apply to tip/locking/core] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/lockdep-improve-current-hard-soft-irqs_enabled-synchronisation-with-actual-irq-state/20200723-185938 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 config: i386-randconfig-s001-20200723 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) kernel/locking/spinlock.c:149:17: sparse: sparse: context imbalance in '_raw_spin_lock' - wrong count at exit kernel/locking/spinlock.c: note: in included file (through include/linux/preempt.h): >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_spin_lock_irqsave' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_spin_lock_irq' - wrong count at exit kernel/locking/spinlock.c:173:17: sparse: sparse: context imbalance in '_raw_spin_lock_bh' - wrong count at exit kernel/locking/spinlock.c:181:17: sparse: sparse: context imbalance in '_raw_spin_unlock' - unexpected unlock kernel/locking/spinlock.c:189:17: sparse: sparse: context imbalance in '_raw_spin_unlock_irqrestore' - unexpected unlock kernel/locking/spinlock.c:197:17: sparse: sparse: context imbalance in '_raw_spin_unlock_irq' - unexpected unlock kernel/locking/spinlock.c:205:17: sparse: sparse: context imbalance in '_raw_spin_unlock_bh' - unexpected unlock kernel/locking/spinlock.c:221:17: sparse: sparse: context imbalance in '_raw_read_lock' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_read_lock_irqsave' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_read_lock_irq' - wrong count at exit kernel/locking/spinlock.c:245:17: sparse: sparse: context imbalance in '_raw_read_lock_bh' - wrong count at exit kernel/locking/spinlock.c:253:17: sparse: sparse: context imbalance in '_raw_read_unlock' - unexpected unlock kernel/locking/spinlock.c:261:17: sparse: sparse: context imbalance in '_raw_read_unlock_irqrestore' - unexpected unlock kernel/locking/spinlock.c:269:17: sparse: sparse: context imbalance in '_raw_read_unlock_irq' - unexpected unlock kernel/locking/spinlock.c:277:17: sparse: sparse: context imbalance in '_raw_read_unlock_bh' - unexpected unlock kernel/locking/spinlock.c:293:17: sparse: sparse: context imbalance in '_raw_write_lock' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_write_lock_irqsave' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_write_lock_irq' - wrong count at exit kernel/locking/spinlock.c:317:17: sparse: sparse: context imbalance in '_raw_write_lock_bh' - wrong count at exit kernel/locking/spinlock.c:325:17: sparse: sparse: context imbalance in '_raw_write_unlock' - unexpected unlock kernel/locking/spinlock.c:333:17: sparse: sparse: context imbalance in '_raw_write_unlock_irqrestore' - unexpected unlock kernel/locking/spinlock.c:341:17: sparse: sparse: context imbalance in '_raw_write_unlock_irq' - unexpected unlock kernel/locking/spinlock.c:349:17: sparse: sparse: context imbalance in '_raw_write_unlock_bh' - unexpected unlock kernel/locking/spinlock.c:358:17: sparse: sparse: context imbalance in '_raw_spin_lock_nested' - wrong count at exit >> arch/x86/include/asm/preempt.h:79:9: sparse: sparse: context imbalance in >> '_raw_spin_lock_irqsave_nested' - wrong count at exit kernel/locking/spinlock.c:380:17: sparse: sparse: context imbalance in '_raw_spin_lock_nest_lock' - wrong count at exit -- kernel/trace/ring_buffer.c:699:32: sparse: sparse: incorrect type in return expression (different base
Re: [PATCH v2 0/4] Modularization of DFL private feature drivers
On Thu, Jul 23, 2020 at 08:03:52PM -0700, Randy Dunlap wrote: > On 7/23/20 7:09 PM, Xu Yilun wrote: > > This patchset makes it possible to develop independent driver modules > > for DFL private features. It also helps to leverage existing kernel > > drivers to enable some IP blocks in DFL. > > > > Patch #1: An improvement of feature id definition. The feature id will be > > used > > as the key field for dfl device/driver matching. > > Patch #2: Release the dfl mmio regions after enumeration, so that private > > feature drivers could request mmio region in their own drivers. > > Patch #3: Introduce the dfl bus, then dfl devices could be supported by > > independent dfl drivers. > > Patch #4: An example of the dfl driver for N3000 nios private feature. > > > > Hi, > What is "nios"? Is that explained or described anywhere? It is the NIOS2 soft processor mostly used in the FPGA. I see the there is an arch/nios2 folder in kernel. On Intel PAC N3000 card, the embedded NIOS2 core in FPGA does some Board initialization work (Mostly the configuration of ethernet retimer) on reboot. And the dfl-n3000-nios private feature in DFL is actually the handshake interfaces for host to communicate with the NIOS2 core, about what parameters to use, when the configuration is finished ... Thanks, Yilun > > > > > Main changes from v1: > > - Add the new Patch #1, to improve the feature id definition. > > - Change the dfl bus uevent format. > > - Change the dfl device's sysfs name format. > > - refactor dfl_dev_add() > > - Add the Patch #4 as an example of the dfl driver. > > - A lot of minor fixes for comments from Hao and Tom. > > thanks. > -- > ~Randy
Re: [PATCH 1/2] ALSA: hda/realtek: Fix headset mic on Loongson platform
On 07/20/2020 09:58 AM, Kaige Li wrote:
On 07/17/2020 02:57 PM, Takashi Iwai wrote:
On Fri, 17 Jul 2020 04:51:31 +0200,
Kaige Li wrote:
Add pin quirks to enable use of the headset mic on Loongson platform.
Signed-off-by: Kaige Li
@@ -7654,6 +7663,7 @@ static const struct snd_pci_quirk
alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1",
ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB",
ALC269_FIXUP_LENOVO_EAPD),
SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MACH-WX9",
ALC256_FIXUP_HUAWEI_MACH_WX9_PINS),
+SND_PCI_QUIRK(0x10ec, 0x0269, "Loongson HDA",
ALC269_FIXUP_LOONGSON_HDA),
This is basically Realtek ALC269 codec itself, so putting this here
may hit with many other machines.
Doesn't it has any proper PCI or codec SSID? The lack of them usually
means a bug of BIOS.
Ok, I will have a look. If there is any progress, I will reply to you
again.
Sorry for that, there is no proper PCI or codec SSID. We have fixed this
by writing the firmware. So this patch is useless.
Thank you for your time!
Kaige
Thank you!
Kaige
thanks,
Takashi
Re: [RFC PATCH] usb: dwc3: fix maximum_speed check for usb2.0-only core
Hi,
Thinh Nguyen wrote:
> Hi,
>
> Chunfeng Yun wrote:
>> The maximum_speed will be USB_SPEED_SUPER_PLUS, but the
>> maximum_speed check for usb2.0-only core doesn't consider it,
>> so fix it, and move the ckeck into dwc3_check_params().
>>
>> Signed-off-by: Chunfeng Yun
>> ---
>> Note:
>>
>> When I look at the code, find that this may be a problem, but no
>> platform to test it.
>> ---
>>drivers/usb/dwc3/core.c | 14 +++---
>>1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 25c686a7..ffd5ab3 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -930,13 +930,6 @@ static int dwc3_core_init(struct dwc3 *dwc)
>> */
>> dwc3_writel(dwc->regs, DWC3_GUID, LINUX_VERSION_CODE);
>>
>> -/* Handle USB2.0-only core configuration */
>> -if (DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
>> -DWC3_GHWPARAMS3_SSPHY_IFC_DIS) {
>> -if (dwc->maximum_speed == USB_SPEED_SUPER)
>> -dwc->maximum_speed = USB_SPEED_HIGH;
>> -}
>> -
>> ret = dwc3_phy_setup(dwc);
>> if (ret)
>> goto err0;
>> @@ -1426,6 +1419,13 @@ static void dwc3_check_params(struct dwc3 *dwc)
>>
>> break;
>> }
>> +
>> +/* Handle USB2.0-only core configuration */
>> +if (DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
>> +DWC3_GHWPARAMS3_SSPHY_IFC_DIS) {
>> +if (dwc->maximum_speed > USB_SPEED_HIGH)
>> +dwc->maximum_speed = USB_SPEED_HIGH;
>> +}
>>}
>>
>>static int dwc3_probe(struct platform_device *pdev)
> Actually, the dwc->maximum_speed captures the maximum speed device
> property value. It maybe be set based on the phy's capability if there's
> no property specifying it (i.e. maximum_speed is USB_SPEED_UNKNOWN).
>
> So, this code should be removed. The fix should be in the check of
> dwc3_check_params(). If maximum_speed = USB_SPEED_UNKNOWN and the phy's
> capability is only up to highspeed, then set the maximum_speed to
> highspeed only.
>
Are you going into update and resend this patch? If not I can create one
and add your "Reported-by"
BR,
Thinh
Re: [PATCH v2] mm/page_alloc: fix memalloc_nocma_{save/restore} APIs
2020년 7월 24일 (금) 오후 12:14, Andrew Morton 님이 작성:
>
> On Fri, 24 Jul 2020 12:04:02 +0900 Joonsoo Kim wrote:
>
> > 2020년 7월 24일 (금) 오전 11:36, Andrew Morton 님이 작성:
> > >
> > > On Fri, 24 Jul 2020 11:23:52 +0900 Joonsoo Kim wrote:
> > >
> > > > > > Second, clearing __GFP_MOVABLE in current_gfp_context() has a side
> > > > > > effect
> > > > > > to exclude the memory on the ZONE_MOVABLE for allocation target.
> > > > >
> > > > > More whoops.
> > > > >
> > > > > Could we please have a description of the end-user-visible effects of
> > > > > this change? Very much needed when proposing a -stable backport, I
> > > > > think.
> > > >
> > > > In fact, there is no noticeable end-user-visible effect since the
> > > > fallback would
> > > > cover the problematic case. It's mentioned in the commit description.
> > > > Perhap,
> > > > performance would be improved due to reduced retry and more available
> > > > memory
> > > > (we can use ZONE_MOVABLE with this patch) but it would be neglectable.
> > > >
> > > > > d7fefcc8de9147c is over a year old. Why did we only just discover
> > > > > this? This makes one wonder how serious those end-user-visible
> > > > > effects
> > > > > are?
> > > >
> > > > As mentioned above, there is no visible problem to the end-user.
> > >
> > > OK, thanks. In that case, I don't believe that a stable backport is
> > > appropriate?
> > >
> > > (Documentation/process/stable-kernel-rules.rst)
> >
> > Thanks for the pointer!
> >
> > Hmm... I'm not sure the correct way to handle this patch. I thought that
> > memalloc_nocma_{save,restore} is an API that is callable from the module.
> > If it is true, it's better to regard this patch as the stable candidate
> > since
> > out-of-tree modules could use it without the fallback and it would cause
> > a problem. But, yes, there is no visible problem to the end-user, at least,
> > within the mainline so it is possibly not a stable candidate.
> >
> > Please share your opinion about this situation.
>
> We tend not to care much about out-of-tree modules. I don't think a
> theoretical concern for out-of-tree code justifies risking the
> stability of -stable kernels.
Okay. It's appreciated if you remove the stable tag. Or, I will send it again
without the stable tag.
Thanks.
arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: sparse: incorrect type in argument 1 (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d15be546031cf65a0fc34879beca02fd90fe7ac7 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 5 weeks ago config: powerpc-randconfig-s032-20200723 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-93-g4c6cbe55-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: sparse: incorrect >> type in argument 1 (different base types) @@ expected unsigned int >> volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 >> [noderef] [usertype] __iomem * @@ >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: expected >> unsigned int volatile [noderef] [usertype] __iomem *addr >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: got restricted >> __be32 [noderef] [usertype] __iomem * >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: sparse: incorrect >> type in argument 1 (different base types) @@ expected unsigned int const >> volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 >> [noderef] [usertype] __iomem * @@ >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: expected >> unsigned int const volatile [noderef] [usertype] __iomem *addr >> arch/powerpc/platforms/82xx/mpc8272_ads.c:163:9: sparse: got restricted >> __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: got restricted __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/82xx/mpc8272_ads.c:164:9: sparse: got restricted __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: got restricted __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/82xx/mpc8272_ads.c:166:9: sparse: got restricted __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:167:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/powerpc/platforms/82xx/mpc8272_ads.c:167:9: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/82xx/mpc8272_ads.c:167:9: sparse: got restricted __be32 [noderef] [usertype] __iomem * arch/powerpc/platforms/82xx/mpc8272_ads.c:167:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] [usertype] __iomem * @@ arch/p
Re: [PATCH 2/2] lockdep: warn on redundant or incorrect irq state changes
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on linux/master]
[also build test ERROR on powerpc/next linus/master v5.8-rc6]
[cannot apply to tip/locking/core next-20200723]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Nicholas-Piggin/lockdep-improve-current-hard-soft-irqs_enabled-synchronisation-with-actual-irq-state/20200723-185938
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68
config: x86_64-randconfig-a002-20200723 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
kernel/locking/lockdep.c: In function 'lockdep_init':
>> kernel/locking/lockdep.c:5673:9: error: 'struct task_struct' has no member
>> named 'hardirqs_enabled'
5673 | current->hardirqs_enabled = 1;
| ^~
>> kernel/locking/lockdep.c:5674:9: error: 'struct task_struct' has no member
>> named 'softirqs_enabled'
5674 | current->softirqs_enabled = 1;
| ^~
In file included from kernel/locking/lockdep.c:60:
At top level:
kernel/locking/lockdep_internals.h:64:28: warning: 'LOCKF_USED_IN_IRQ_READ'
defined but not used [-Wunused-const-variable=]
64 | static const unsigned long LOCKF_USED_IN_IRQ_READ =
|^~
In file included from kernel/locking/lockdep.c:60:
kernel/locking/lockdep_internals.h:58:28: warning: 'LOCKF_ENABLED_IRQ_READ'
defined but not used [-Wunused-const-variable=]
58 | static const unsigned long LOCKF_ENABLED_IRQ_READ =
|^~
In file included from kernel/locking/lockdep.c:60:
kernel/locking/lockdep_internals.h:52:28: warning: 'LOCKF_USED_IN_IRQ'
defined but not used [-Wunused-const-variable=]
52 | static const unsigned long LOCKF_USED_IN_IRQ =
|^
In file included from kernel/locking/lockdep.c:60:
kernel/locking/lockdep_internals.h:46:28: warning: 'LOCKF_ENABLED_IRQ'
defined but not used [-Wunused-const-variable=]
46 | static const unsigned long LOCKF_ENABLED_IRQ =
|^
vim +5673 kernel/locking/lockdep.c
5667
5668 printk(" per task-struct memory footprint: %zu bytes\n",
5669 sizeof(((struct task_struct *)NULL)->held_locks));
5670
5671 WARN_ON(irqs_disabled());
5672
> 5673 current->hardirqs_enabled = 1;
> 5674 current->softirqs_enabled = 1;
5675 }
5676
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH V7 12/14] perf, tools, stat: Support new per thread TopDown metrics
> + if (topdown_metric_attrs[0] && str) {`
> + if (!stat_config.interval) {
> + fprintf(stat_config.output,
> + "Topdown accuracy may decreases when
> measuring long period.\n"
> + "Please print the result regularly,
> e.g. -I1000\n");
Can you disable this warning when --metrics-only is used? In this case it
doesn't matter
because the error is proportional to the percentage accuracy and should be
invisible.
You can only see a difference when looking at the expanded counts.
-andi
Re: INFO: rcu detected stall in netlink_sendmsg (4)
syzbot has bisected this issue to:
commit 5a781ccbd19e4664babcbe4b4ead7aa2b9283d22
Author: Vinicius Costa Gomes
Date: Sat Sep 29 00:59:43 2018 +
tc: Add support for configuring the taprio scheduler
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16d46e1b10
start commit: 7cc2a8ea Merge tag 'block-5.8-2020-07-01' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11d46e1b10
kernel config: https://syzkaller.appspot.com/x/.config?x=7be693511b29b338
dashboard link: https://syzkaller.appspot.com/bug?extid=0fb70e87d8e0ac278fe9
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1023588f10
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1647a88f10
Reported-by: syzbot+0fb70e87d8e0ac278...@syzkaller.appspotmail.com
Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH] tracing/uprobe: Remove dead code in trace_uprobe_register()
In the function trace_uprobe_register(), the statement "return 0;" out of switch case is dead code, remove it. Signed-off-by: Peng Fan --- kernel/trace/trace_uprobe.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c index fdd47f9..f4286c9 100644 --- a/kernel/trace/trace_uprobe.c +++ b/kernel/trace/trace_uprobe.c @@ -1456,7 +1456,6 @@ trace_uprobe_register(struct trace_event_call *event, enum trace_reg type, default: return 0; } - return 0; } static int uprobe_dispatcher(struct uprobe_consumer *con, struct pt_regs *regs) -- 2.1.0
Re: [PATCH for 5.9 1/3] futex: introduce FUTEX_SWAP operation
On Thu, Jul 23, 2020 at 8:00 PM Waiman Long wrote: > > On 7/23/20 8:25 PM, Peter Oskolkov wrote: > > On Thu, Jul 23, 2020 at 4:28 AM Peter Zijlstra wrote: > > > > Thanks a lot for your comments, Peter! My answers below. > > > >> On Wed, Jul 22, 2020 at 04:45:36PM -0700, Peter Oskolkov wrote: > >>> This patchset is the first step to open-source this work. As explained > >>> in the linked pdf and video, SwitchTo API has three core operations: wait, > >>> resume, and swap (=switch). So this patchset adds a FUTEX_SWAP operation > >>> that, in addition to FUTEX_WAIT and FUTEX_WAKE, will provide a foundation > >>> on top of which user-space threading libraries can be built. > >> The PDF and video can go pound sand; you get to fully explain things > >> here. > > Will do. Should I expand the cover letter or the commit message? (I'll > > probably > > split the first patch into two in the latter case). > > You should put it mostly in the commit message which will be part of the > git log history. The cover letter, on the other hand, is not part of the > git log. Ack. (Networking/David Miller usually includes the cover letter in the git log, so this is context dependent, I guess). > > > > > >> What worries me is how FUTEX_SWAP would interact with the future > >> FUTEX_LOCK / FUTEX_UNLOCK. When we implement pthread_mutex with those, > >> there's very few WAIT/WAKE left. > > [+cc Waiman Long] > > > > I've looked through the latest FUTEX_LOCK patchset I could find ( > > https://lore.kernel.org/patchwork/cover/772643/ and related), and it seems > > that FUTEX_SWAP and FUTEX_LOCK/FUTEX_UNLOCK patchsets > > address the same issue (slow wakeups) but for different use cases: > > > > FUTEX_LOCK/FUTEX_UNLOCK uses spinning and lock stealing to > > improve futex wake/wait performance in high contention situations; > > FUTEX_SWAP is designed to be used for fast context switching with > > _no_ contention by design: the waker that is going to sleep, and the wakee > > are using different futexes; the userspace will have a futex per > > thread/task, > > and when needed the thread/task will either simply sleep on its futex, > > or context switch (=FUTEX_SWAP) into a different thread/task. > > I agree that it is a different use case. I just hope that you keep the > possible future extension to support FUTEX_LOCK/UNLOCK in mind so that > they won't conflict with each other. Ack. Will do. :) Thanks, Peter > > Cheers, > Longman >
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:975:27: sparse: sparse: incorrect type in assignment (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d15be546031cf65a0fc34879beca02fd90fe7ac7
commit: ccfc639a94f25eb8639e8ffbecad2f6b60d22eb1 net: stmmac: selftests: Add a
selftest for Flexible RX Parser
date: 12 months ago
config: powerpc-randconfig-s032-20200723 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-93-g4c6cbe55-dirty
git checkout ccfc639a94f25eb8639e8ffbecad2f6b60d22eb1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:975:27: sparse:
>> sparse: incorrect type in assignment (different base types) @@ expected
>> restricted __be32 [usertype] mask @@ got int @@
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:975:27: sparse:
expected restricted __be32 [usertype] mask
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:975:27: sparse:
got int
vim +975 drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
916
917 #ifdef CONFIG_NET_CLS_ACT
918 static int stmmac_test_rxp(struct stmmac_priv *priv)
919 {
920 unsigned char addr[ETH_ALEN] = {0xde, 0xad, 0xbe, 0xef, 0x00,
0x00};
921 struct tc_cls_u32_offload cls_u32 = { };
922 struct stmmac_packet_attrs attr = { };
923 struct tc_action **actions, *act;
924 struct tc_u32_sel *sel;
925 struct tcf_exts *exts;
926 int ret, i, nk = 1;
927
928 if (!tc_can_offload(priv->dev))
929 return -EOPNOTSUPP;
930 if (!priv->dma_cap.frpsel)
931 return -EOPNOTSUPP;
932
933 sel = kzalloc(sizeof(*sel) + nk * sizeof(struct tc_u32_key),
GFP_KERNEL);
934 if (!sel)
935 return -ENOMEM;
936
937 exts = kzalloc(sizeof(*exts), GFP_KERNEL);
938 if (!exts) {
939 ret = -ENOMEM;
940 goto cleanup_sel;
941 }
942
943 actions = kzalloc(nk * sizeof(*actions), GFP_KERNEL);
944 if (!actions) {
945 ret = -ENOMEM;
946 goto cleanup_exts;
947 }
948
949 act = kzalloc(nk * sizeof(*act), GFP_KERNEL);
950 if (!act) {
951 ret = -ENOMEM;
952 goto cleanup_actions;
953 }
954
955 cls_u32.command = TC_CLSU32_NEW_KNODE;
956 cls_u32.common.chain_index = 0;
957 cls_u32.common.protocol = htons(ETH_P_ALL);
958 cls_u32.knode.exts = exts;
959 cls_u32.knode.sel = sel;
960 cls_u32.knode.handle = 0x123;
961
962 exts->nr_actions = nk;
963 exts->actions = actions;
964 for (i = 0; i < nk; i++) {
965 struct tcf_gact *gact = to_gact(&act[i]);
966
967 actions[i] = &act[i];
968 gact->tcf_action = TC_ACT_SHOT;
969 }
970
971 sel->nkeys = nk;
972 sel->offshift = 0;
973 sel->keys[0].off = 6;
974 sel->keys[0].val = htonl(0xdeadbeef);
> 975 sel->keys[0].mask = ~0x0;
976
977 ret = stmmac_tc_setup_cls_u32(priv, priv, &cls_u32);
978 if (ret)
979 goto cleanup_act;
980
981 attr.dst = priv->dev->dev_addr;
982 attr.src = addr;
983
984 ret = __stmmac_test_loopback(priv, &attr);
985 ret = !ret; /* Shall NOT receive packet */
986
987 cls_u32.command = TC_CLSU32_DELETE_KNODE;
988 stmmac_tc_setup_cls_u32(priv, priv, &cls_u32);
989
990 cleanup_act:
991 kfree(act);
992 cleanup_actions:
993 kfree(actions);
994 cleanup_exts:
995 kfree(exts);
996 cleanup_sel:
997 kfree(sel);
998 return ret;
999 }
1000 #else
1001 static int stmmac_test_rxp(struct stmmac_priv *priv)
1002 {
1003 return -EOPNOTSUPP;
1004 }
1005 #endif
1006
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2] mm/page_alloc: fix memalloc_nocma_{save/restore} APIs
On Fri, 24 Jul 2020 12:04:02 +0900 Joonsoo Kim wrote:
> 2020년 7월 24일 (금) 오전 11:36, Andrew Morton 님이 작성:
> >
> > On Fri, 24 Jul 2020 11:23:52 +0900 Joonsoo Kim wrote:
> >
> > > > > Second, clearing __GFP_MOVABLE in current_gfp_context() has a side
> > > > > effect
> > > > > to exclude the memory on the ZONE_MOVABLE for allocation target.
> > > >
> > > > More whoops.
> > > >
> > > > Could we please have a description of the end-user-visible effects of
> > > > this change? Very much needed when proposing a -stable backport, I
> > > > think.
> > >
> > > In fact, there is no noticeable end-user-visible effect since the
> > > fallback would
> > > cover the problematic case. It's mentioned in the commit description.
> > > Perhap,
> > > performance would be improved due to reduced retry and more available
> > > memory
> > > (we can use ZONE_MOVABLE with this patch) but it would be neglectable.
> > >
> > > > d7fefcc8de9147c is over a year old. Why did we only just discover
> > > > this? This makes one wonder how serious those end-user-visible effects
> > > > are?
> > >
> > > As mentioned above, there is no visible problem to the end-user.
> >
> > OK, thanks. In that case, I don't believe that a stable backport is
> > appropriate?
> >
> > (Documentation/process/stable-kernel-rules.rst)
>
> Thanks for the pointer!
>
> Hmm... I'm not sure the correct way to handle this patch. I thought that
> memalloc_nocma_{save,restore} is an API that is callable from the module.
> If it is true, it's better to regard this patch as the stable candidate since
> out-of-tree modules could use it without the fallback and it would cause
> a problem. But, yes, there is no visible problem to the end-user, at least,
> within the mainline so it is possibly not a stable candidate.
>
> Please share your opinion about this situation.
We tend not to care much about out-of-tree modules. I don't think a
theoretical concern for out-of-tree code justifies risking the
stability of -stable kernels.
