RE: [PATCH v9 01/12] perf/x86/intel/pt: Move Intel-PT MSRs bit definitions to a public header
> -Original Message- > From: Kang, Luwei > Sent: Tuesday, May 22, 2018 12:52 PM > To: k...@vger.kernel.org > Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org; > chao.p.p...@linux.intel.com; > thomas.lenda...@amd.com; b...@suse.de; Liang, Kan ; > janakarajan.natara...@amd.com; > d...@amazon.co.uk; linux-kernel@vger.kernel.org; > alexander.shish...@linux.intel.com; pet...@infradead.org; > mathieu.poir...@linaro.org; kstew...@linuxfoundation.org; > gre...@linuxfoundation.org; pbonz...@redhat.com; > rkrc...@redhat.com; da...@redhat.com; b...@redhat.com; > yu.c.zh...@linux.intel.com; j...@8bytes.org; Kang, Luwei > > Subject: [PATCH v9 01/12] perf/x86/intel/pt: Move Intel-PT MSRs bit > definitions to a public header > > From: Chao Peng > > Intel Processor Trace virtualization enabling in KVM guest need to access > these MSRs bit definitions, so move them to public header > file msr-index.h. > > Signed-off-by: Chao Peng > Signed-off-by: Luwei Kang > --- > arch/x86/events/intel/pt.h | 37 - > arch/x86/include/asm/msr-index.h | 33 + > 2 files changed, 33 insertions(+), 37 deletions(-) > > diff --git a/arch/x86/events/intel/pt.h b/arch/x86/events/intel/pt.h index > 0eb41d0..0050ca1 100644 > --- a/arch/x86/events/intel/pt.h > +++ b/arch/x86/events/intel/pt.h > @@ -20,43 +20,6 @@ > #define __INTEL_PT_H__ > > /* > - * PT MSR bit definitions > - */ > -#define RTIT_CTL_TRACEEN BIT(0) > -#define RTIT_CTL_CYCLEACCBIT(1) > -#define RTIT_CTL_OS BIT(2) > -#define RTIT_CTL_USR BIT(3) > -#define RTIT_CTL_PWR_EVT_EN BIT(4) > -#define RTIT_CTL_FUP_ON_PTW BIT(5) > -#define RTIT_CTL_CR3EN BIT(7) > -#define RTIT_CTL_TOPABIT(8) > -#define RTIT_CTL_MTC_EN BIT(9) > -#define RTIT_CTL_TSC_EN BIT(10) > -#define RTIT_CTL_DISRETC BIT(11) > -#define RTIT_CTL_PTW_EN BIT(12) > -#define RTIT_CTL_BRANCH_EN BIT(13) > -#define RTIT_CTL_MTC_RANGE_OFFSET14 > -#define RTIT_CTL_MTC_RANGE (0x0full << RTIT_CTL_MTC_RANGE_OFFSET) > -#define RTIT_CTL_CYC_THRESH_OFFSET 19 > -#define RTIT_CTL_CYC_THRESH (0x0full << RTIT_CTL_CYC_THRESH_OFFSET) > -#define RTIT_CTL_PSB_FREQ_OFFSET 24 > -#define RTIT_CTL_PSB_FREQ(0x0full << > RTIT_CTL_PSB_FREQ_OFFSET) > -#define RTIT_CTL_ADDR0_OFFSET32 > -#define RTIT_CTL_ADDR0 (0x0full << RTIT_CTL_ADDR0_OFFSET) > -#define RTIT_CTL_ADDR1_OFFSET36 > -#define RTIT_CTL_ADDR1 (0x0full << RTIT_CTL_ADDR1_OFFSET) > -#define RTIT_CTL_ADDR2_OFFSET40 > -#define RTIT_CTL_ADDR2 (0x0full << RTIT_CTL_ADDR2_OFFSET) > -#define RTIT_CTL_ADDR3_OFFSET44 > -#define RTIT_CTL_ADDR3 (0x0full << RTIT_CTL_ADDR3_OFFSET) > -#define RTIT_STATUS_FILTEREN BIT(0) > -#define RTIT_STATUS_CONTEXTENBIT(1) > -#define RTIT_STATUS_TRIGGERENBIT(2) > -#define RTIT_STATUS_BUFFOVF BIT(3) > -#define RTIT_STATUS_ERRORBIT(4) > -#define RTIT_STATUS_STOPPED BIT(5) > - > -/* > * Single-entry ToPA: when this close to region boundary, switch > * buffers to avoid losing data. > */ > diff --git a/arch/x86/include/asm/msr-index.h > b/arch/x86/include/asm/msr-index.h > index 53d5b1b..afe4e13 100644 > --- a/arch/x86/include/asm/msr-index.h > +++ b/arch/x86/include/asm/msr-index.h > @@ -106,7 +106,40 @@ > #define MSR_PEBS_LD_LAT_THRESHOLD0x03f6 > > #define MSR_IA32_RTIT_CTL0x0570 > +#define RTIT_CTL_TRACEEN BIT(0) > +#define RTIT_CTL_CYCLEACCBIT(1) > +#define RTIT_CTL_OS BIT(2) > +#define RTIT_CTL_USR BIT(3) > +#define RTIT_CTL_PWR_EVT_EN BIT(4) > +#define RTIT_CTL_FUP_ON_PTW BIT(5) > +#define RTIT_CTL_CR3EN BIT(7) > +#define RTIT_CTL_TOPABIT(8) > +#define RTIT_CTL_MTC_EN BIT(9) > +#define RTIT_CTL_TSC_EN BIT(10) > +#define RTIT_CTL_DISRETC BIT(11) > +#define RTIT_CTL_PTW_EN BIT(12) > +#define RTIT_CTL_BRANCH_EN BIT(13) > +#define RTIT_CTL_MTC_RANGE_OFFSET14 > +#define RTIT_CTL_MTC_RANGE (0x0full << RTIT_CTL_MTC_RANGE_OFFSET) > +#define RTIT_CTL_CYC_THRESH_OFFSET 19 > +#define RTIT_CTL_CYC_THRESH (0x0full << RTIT_CTL_CYC_THRESH_OFFSET) > +#define RTIT_CTL_PSB_FREQ_OFFSET 24 > +#define RTIT_CTL_PSB_FREQ(0x0full << RTIT_CTL_PSB_FREQ_OFFSET) > +#define RTIT_CTL_ADDR0_OFFSET32 > +#define RTIT_CTL_ADDR0 (0x0full << > RTIT_CTL_ADDR0_OFFSET) > +#define RTIT_CTL_ADDR1_OFFSET36 > +#define RTIT_CTL_AD
linux-next: Tree for Jun 7
Hi all, Note: please do *not* add any v4.19 material to your linux-next included branches until after v4.18-rc1 has been released. Changes since 20180606: The tip tree gained a conflict against Linus' tree. The nvdimm tree gained a conflict against the tip tree. Non-merge commits (relative to Linus' tree): 7370 7533 files changed, 283530 insertions(+), 509381 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 278 trees (counting Linus' and 64 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (311da4975894 Merge branch 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (b04e217704b7 Linux 4.17-rc7) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (82034c23fcbc arm64: Make sure permission updates happen for pmd/pud) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (faf37c44a105 powerpc/64s: Clear PCR on boot) Merging sparc/master (1c1ff29da6c8 sparc: fix compat siginfo ABI regression) CONFLICT (content): Merge conflict in arch/sparc/kernel/traps_64.c CONFLICT (content): Merge conflict in arch/sparc/kernel/traps_32.c Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging bpf/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging ipsec/master (38369f54d97d xfrm Fix potential error pointer dereference in xfrm_bundle_create.) Merging netfilter/master (82e20b44477f netfilter: nft_set_rbtree: fix parameter of __nft_rbtree_lookup()) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (ab1068d6866e iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs) Merging mac80211/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging rdma-fixes/for-rc (a840c93ca758 IB/core: Fix error code for invalid GID entry) Merging sound-current/for-linus (d4d5a1cd298e Merge tag 'asoc-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (2858e2cfc2ef Merge branch 'asoc-4.17' into asoc-linus) Merging regmap-fixes/for-linus (97fe106a8027 Merge branch 'regmap-4.17' into regmap-linus) Merging regulator-fixes/for-linus (f32fa2c67985 Merge branch 'regulator-4.17' into regulator-linus) Merging spi-fixes/for-linus (5d3257b8ea48 Merge branch 'spi-4.17' into spi-linus) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq) Merging tty.current/tty-linus (af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq) Merging usb.cur
[v2, 2/2] ASoC: AMD: Configure channel 1 or channel 0 for capture
ST/CZ SoC have 2 channels for capture in the I2SSP path.
The DMA though these channels is done using the same dma
descriptors.
We configure the channel and enable it on the basis of
channel selected by machine driver. Machine driver knows
which codec sits on which channel and thus sends the information
to dma driver.
Signed-off-by: Akshu Agrawal
---
v2: Split acp_dma_cap_channel into 2 functions.
This patch is dependent on ASoC: AMD: Change codec to channel link as per
hardware redesign
https://patchwork.kernel.org/patch/10388099/
sound/soc/amd/acp-da7219-max98357a.c | 43 +++---
sound/soc/amd/acp-pcm-dma.c | 71 +++-
sound/soc/amd/acp.h | 4 ++
3 files changed, 111 insertions(+), 7 deletions(-)
diff --git a/sound/soc/amd/acp-da7219-max98357a.c
b/sound/soc/amd/acp-da7219-max98357a.c
index 566bd26..f42606e 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -149,6 +149,7 @@ static int cz_da7219_startup(struct snd_pcm_substream
*substream)
&constraints_rates);
machine->i2s_instance = I2S_SP_INSTANCE;
+ machine->capture_channel = CAP_CHANNEL1;
return da7219_clk_enable(substream);
}
@@ -172,7 +173,7 @@ static void cz_max_shutdown(struct snd_pcm_substream
*substream)
da7219_clk_disable();
}
-static int cz_dmic_startup(struct snd_pcm_substream *substream)
+static int cz_dmic0_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct snd_soc_card *card = rtd->card;
@@ -182,6 +183,17 @@ static int cz_dmic_startup(struct snd_pcm_substream
*substream)
return da7219_clk_enable(substream);
}
+static int cz_dmic1_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_card *card = rtd->card;
+ struct acp_platform_info *machine = snd_soc_card_get_drvdata(card);
+
+ machine->i2s_instance = I2S_SP_INSTANCE;
+ machine->capture_channel = CAP_CHANNEL0;
+ return da7219_clk_enable(substream);
+}
+
static void cz_dmic_shutdown(struct snd_pcm_substream *substream)
{
da7219_clk_disable();
@@ -197,8 +209,13 @@ static void cz_dmic_shutdown(struct snd_pcm_substream
*substream)
.shutdown = cz_max_shutdown,
};
-static const struct snd_soc_ops cz_dmic_cap_ops = {
- .startup = cz_dmic_startup,
+static const struct snd_soc_ops cz_dmic0_cap_ops = {
+ .startup = cz_dmic0_startup,
+ .shutdown = cz_dmic_shutdown,
+};
+
+static const struct snd_soc_ops cz_dmic1_cap_ops = {
+ .startup = cz_dmic1_startup,
.shutdown = cz_dmic_shutdown,
};
@@ -241,8 +258,9 @@ static void cz_dmic_shutdown(struct snd_pcm_substream
*substream)
.ops = &cz_max_play_ops,
},
{
- .name = "dmic",
- .stream_name = "DMIC Capture",
+ /* C panel DMIC */
+ .name = "dmic0",
+ .stream_name = "DMIC0 Capture",
.platform_name = "acp_audio_dma.0.auto",
.cpu_dai_name = "designware-i2s.3.auto",
.codec_dai_name = "adau7002-hifi",
@@ -250,7 +268,20 @@ static void cz_dmic_shutdown(struct snd_pcm_substream
*substream)
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
| SND_SOC_DAIFMT_CBM_CFM,
.dpcm_capture = 1,
- .ops = &cz_dmic_cap_ops,
+ .ops = &cz_dmic0_cap_ops,
+ },
+ {
+ /* A/B panel DMIC */
+ .name = "dmic1",
+ .stream_name = "DMIC1 Capture",
+ .platform_name = "acp_audio_dma.0.auto",
+ .cpu_dai_name = "designware-i2s.2.auto",
+ .codec_dai_name = "adau7002-hifi",
+ .codec_name = "ADAU7002:00",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+ | SND_SOC_DAIFMT_CBM_CFM,
+ .dpcm_capture = 1,
+ .ops = &cz_dmic1_cap_ops,
},
};
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 1458b50..3c3d398 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -336,6 +336,61 @@ static void config_acp_dma(void __iomem *acp_mmio,
rtd->dma_dscr_idx_2, asic_type);
}
+static void acp_dma_cap_channel_enable(void __iomem *acp_mmio,
+ u16 cap_channel)
+{
+ u32 val, ch_reg, imr_reg, res_reg;
+
+ switch (cap_channel) {
+ case CAP_CHANNEL1:
+ ch_reg = mmACP_I2SMICSP_RER1;
+ res_reg = mmACP_I2SMICSP_RCR1;
+ imr_reg = mmACP_I2SMICSP_IMR1;
+ break;
+ case CAP_CHANNEL0:
+ default:
+ ch_reg = mmACP_I2SMICSP_RER0;
[PATCH 1/2] ASoC: AMD: Add NULL pointer check
Fix crash in those platforms whose machine driver does not expose
platform_info. For those platforms we rely on default value and
select I2SSP channel.
Signed-off-by: Akshu Agrawal
---
sound/soc/amd/acp-pcm-dma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 7720384..1458b50 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -773,7 +773,8 @@ static int acp_dma_hw_params(struct snd_pcm_substream
*substream,
if (WARN_ON(!rtd))
return -EINVAL;
- rtd->i2s_instance = pinfo->i2s_instance;
+ if (pinfo)
+ rtd->i2s_instance = pinfo->i2s_instance;
if (adata->asic_type == CHIP_STONEY) {
val = acp_reg_read(adata->acp_mmio,
mmACP_I2S_16BIT_RESOLUTION_EN);
--
1.9.1
Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
Hi Bjorn, On 6/7/2018 11:18 AM, Bjorn Andersson wrote: > On Wed 06 Jun 22:29 PDT 2018, Sricharan R wrote: > >> Hi Bjorn, >> >> On 6/7/2018 9:54 AM, Bjorn Andersson wrote: >>> On Wed 06 Jun 21:11 PDT 2018, Vinod wrote: >>> On 06-06-18, 09:17, Bjorn Andersson wrote: > On Tue 05 Jun 05:56 PDT 2018, Sricharan R wrote: > >> Hi Vinod, >> >> On 6/5/2018 11:49 AM, Vinod wrote: >>> On 05-06-18, 11:12, Sricharan R wrote: > [..] >>> If we ignore SMD for a while we have the following combinations: >>> >>> glink/wcss >>> y y - valid >>> y m - valid >>> y n - valid >>> m y - link failure (invalid) >>> m m - valid >>> m n - valid >>> n y - valid (platform uses wcss, but not glink) >>> n m - valid (-"-) >>> n n - valid >>> >>> So to distill this we have the two valid cases: >>> module/no if RPMSG_QCOM_GLINK_SMEM=m >>> yes/module/no if RPMSG_QCOM_GLINK_SMEM=y >>> >>> and the way you express that in Kconfig is the somewhat awkward >>> >>> depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n >>> >> >> ok, Having "depends on RPMSG_QCOM_GLINK_SMEM" takes care of the >> first 6 cases in the above list. >> >> But just was thinking that by allowing the last three combinations, >> there is a chance that some config that really needs GLINK_SMEM and WCSS, >> but selects only Q6V5_WCSS and misses to select GLINK_SMEM, >> would still built and make it non-functional, right ? >> > > It would allow you to compile a kernel with GLINk disabled that in > runtime loads a firmware that depends on GLINK being there. > > As it would be convenient to thereby state that "WCSS always depends on > GLINK" we can make the analog to 410 where "MSS always depends on SMD", > which isn't true when the same driver is reused on e.g. 845 - which > uses GLINK. > > > So my recommendation is that we stick with Kconfig options that > describes the build time dependencies of this particular driver, rather > than its runtime dependencies in a particular platform. > ok thanks. It sort of gave an impression that the last three combinations in the above list was only for "compile testing". Hence was thinking to have (COMPILE_TEST && RPMSG_QCOM_GLINK_SMEM=n). Anyways for WCSS, would drop the dependency on SMD and just have RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n. Regards, Sricharan -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [PATCH] percpu_counter: `percpu_counter_read_positive' should not return negative number
On Wed, Jun 6, 2018 at 9:57 PM Tejun Heo wrote: > > On Wed, Jun 06, 2018 at 09:39:40PM +0200, Mathieu Malaterre wrote: > > Since function `percpu_counter_add' may result in a signed integer overflow > > the result stored in `fbc->count' could be negative. Make sure that > > function `percpu_counter_read_positive' does not return a negative number > > in this case. This will match behavior when CONFIG_SMP=y. > > > > Detected wth CONFIG_UBSAN=y > > > > [76404.888450] > > > > [76404.888477] UBSAN: Undefined behaviour in > > ../include/linux/percpu_counter.h:136:13 > > [76404.888485] signed integer overflow: > > [76404.888490] 9223308017647617321 + 76624449492175 cannot be represented > > in type 'long long int' > > [76404.888501] CPU: 0 PID: 0 Comm: swapper Not tainted 4.17.0+ #50 > > [76404.888506] Call Trace: > > [76404.888523] [dffedd30] [c0478b90] ubsan_epilogue+0x18/0x4c (unreliable) > > [76404.888533] [dffedd40] [c0479530] handle_overflow+0xbc/0xdc > > [76404.888548] [dffeddc0] [c0439044] cfq_completed_request+0x560/0x1234 > > [76404.888557] [dffede40] [c03f3fc4] __blk_put_request+0xb0/0x2dc > > [76404.888570] [dffede80] [c05a81d0] scsi_end_request+0x19c/0x344 > > [76404.888579] [dffedeb0] [c05a9954] scsi_io_completion+0x4b4/0x854 > > [76404.888592] [dffedf10] [c04046b4] blk_done_softirq+0xe4/0x1e0 > > [76404.888605] [dffedf60] [c07ec1d4] __do_softirq+0x16c/0x5f0 > > [76404.888617] [dffedfd0] [c0065160] irq_exit+0x110/0x1a8 > > [76404.888629] [dffedff0] [c001646c] call_do_irq+0x24/0x3c > > [76404.888641] [c0cdbe80] [c0009a2c] do_IRQ+0x98/0x1a0 > > [76404.888649] [c0cdbeb0] [c001b93c] ret_from_except+0x0/0x14 > > [76404.888659] --- interrupt: 501 at arch_cpu_idle+0x30/0x78 > >LR = arch_cpu_idle+0x30/0x78 > > [76404.888667] [c0cdbf70] [c0cda000] 0xc0cda000 (unreliable) > > [76404.888679] [c0cdbf80] [c00a3844] do_idle+0xc4/0x158 > > [76404.888687] [c0cdbfb0] [c00a3a90] cpu_startup_entry+0x24/0x28 > > [76404.888696] [c0cdbfc0] [c097f820] start_kernel+0x47c/0x490 > > [76404.888703] [c0cdbff0] [3444] 0x3444 > > So, the _positive versions are there to deal with small negative reads > coming from percpu propagation delays. It's not there to protect > against actual counter overflow although it can't detect that on SMP. > It's just outright wrong to report 0 when the counter actually > overflowed and applying the suggested patch masks a real problem > undetectable. I see, thanks for the explanation. > I think the right thing to do is actually undersatnding what's going > on (why is a 64bit counter overflowing?) and fix the underlying issue. > > Thanks. > > -- > tejun
Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM
On Wed, Jun 06, 2018 at 09:24:05AM +, Horiguchi Naoya(堀口 直也) wrote:
> On Wed, Jun 06, 2018 at 09:06:30AM +, Horiguchi Naoya(堀口 直也) wrote:
> > On Wed, Jun 06, 2018 at 10:53:19AM +0200, Oscar Salvador wrote:
> > > On Wed, Jun 06, 2018 at 10:04:08AM +0200, Oscar Salvador wrote:
> > > > On Wed, Jun 06, 2018 at 05:16:24AM +, Naoya Horiguchi wrote:
> > > > > On Tue, Jun 05, 2018 at 07:35:01AM +, Horiguchi Naoya(堀口 直也)
> > > > > wrote:
> > > > > > On Mon, Jun 04, 2018 at 06:18:36PM -0700, Matthew Wilcox wrote:
> > > > > > > On Tue, Jun 05, 2018 at 12:54:03AM +, Naoya Horiguchi wrote:
> > > > > > > > Reproduction precedure is like this:
> > > > > > > > - enable RAM based PMEM (with a kernel boot parameter like
> > > > > > > > memmap=1G!4G)
> > > > > > > > - read /proc/kpageflags (or call tools/vm/page-types with no
> > > > > > > > arguments)
> > > > > > > > (- my kernel config is attached)
> > > > > > > >
> > > > > > > > I spent a few days on this, but didn't reach any solutions.
> > > > > > > > So let me report this with some details below ...
> > > > > > > >
> > > > > > > > In the critial page request, stable_page_flags() is called with
> > > > > > > > an argument
> > > > > > > > page whose ->compound_head was somehow filled with
> > > > > > > > '0x'.
> > > > > > > > And compound_head() returns (struct page *)(head - 1), which
> > > > > > > > explains the
> > > > > > > > address 0xfffe in the above message.
> > > > > > >
> > > > > > > Hm. compound_head shares with:
> > > > > > >
> > > > > > > struct list_head lru;
> > > > > > > struct list_head slab_list;
> > > > > > > /* uses lru */
> > > > > > > struct {/* Partial pages
> > > > > > > */
> > > > > > > struct page *next;
> > > > > > > unsigned long _compound_pad_1; /*
> > > > > > > compound_head */
> > > > > > > unsigned long _pt_pad_1;/*
> > > > > > > compound_head */
> > > > > > > struct dev_pagemap *pgmap;
> > > > > > > struct rcu_head rcu_head;
> > > > > > >
> > > > > > > None of them should be -1.
> > > > > > >
> > > > > > > > It seems that this kernel panic happens when reading kpageflags
> > > > > > > > of pfn range
> > > > > > > > [0xbffd7, 0xc), which coresponds to a 'reserved' range.
> > > > > > > >
> > > > > > > > [0.00] user-defined physical RAM map:
> > > > > > > > [0.00] user: [mem
> > > > > > > > 0x-0x0009fbff] usable
> > > > > > > > [0.00] user: [mem
> > > > > > > > 0x0009fc00-0x0009] reserved
> > > > > > > > [0.00] user: [mem
> > > > > > > > 0x000f-0x000f] reserved
> > > > > > > > [0.00] user: [mem
> > > > > > > > 0x0010-0xbffd6fff] usable
> > > > > > > > [0.00] user: [mem
> > > > > > > > 0xbffd7000-0xbfff] reserved
> > > > > > > > [0.00] user: [mem
> > > > > > > > 0xfeffc000-0xfeff] reserved
> > > > > > > > [0.00] user: [mem
> > > > > > > > 0xfffc-0x] reserved
> > > > > > > > [0.00] user: [mem
> > > > > > > > 0x0001-0x00013fff] persistent (type 12)
> > > > > > > >
> > > > > > > > So I guess 'memmap=' parameter might badly affect the memory
> > > > > > > > initialization process.
> > > > > > > >
> > > > > > > > This problem doesn't reproduce on v4.17, so some pre-released
> > > > > > > > patch introduces it.
> > > > > > > > I hope this info helps you find the solution/workaround.
> > > > > > >
> > > > > > > Can you try bisecting this? It could be one of my patches to
> > > > > > > reorder struct
> > > > > > > page, or it could be one of Pavel's deferred page initialisation
> > > > > > > patches.
> > > > > > > Or something else ;-)
> > > > > >
> > > > > > Thank you for the comment. I'm trying bisecting now, let you know
> > > > > > the result later.
> > > > > >
> > > > > > And I found that my statement "not reproduce on v4.17" was wrong (I
> > > > > > used
> > > > > > different kvm guests, which made some different test condition and
> > > > > > misguided me),
> > > > > > this seems an older (at least < 4.15) bug.
> > > > >
> > > > > (Cc: Pavel)
> > > > >
> > > > > Bisection showed that the following commit introduced this issue:
> > > > >
> > > > > commit f7f99100d8d95dbcf09e0216a143211e79418b9f
> > > > > Author: Pavel Tatashin
> > > > > Date: Wed Nov 15 17:36:44 2017 -0800
> > > > >
> > > > > mm: stop zeroing memory during allocation in vmemmap
> > > > >
> > > > > This patch postpones struct page zeroing to later stage of memory
> > > > > initialization.
> > > > > My kernel config disabled CONFIG_DEFERRED_STRUCT_PAGE_INIT so two
> > > > > callsites of
> > > > > __init_si
Re: [PATCH 01/10] perf tools: Uniquify the event name if there's no other matched event
On Wed, Jun 06, 2018 at 04:19:02PM -0700, Andi Kleen wrote: > On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote: > > Currently by default we try to match the user specified PMU > > name to all PMU units available and use them to aggregate > > all matched PMUs event counts into one 'pattern' event. > > > > While this is useful for uncore events, it screws up names > > for other events, where this is not desirable, like: > > > > Before: > > # perf stat -e cp/cpu-cycles/ kill > > I assume you mean cpU/cpu-cycles/ > > > >Performance counter stats for 'kill': > > > >1,573,757 cp/cpu-cycles/ > > > > Keeping the pattern matching logic, but making the name unique > > in case there's no other match found. That fixes the example > > above and hopefully does not screw up anything else. > > > > After: > > # perf stat -e cp/cpu-cycles/ kill > > > >Performance counter stats for 'kill': > > > >1,573,757 cpu/cpu-cycles/ > > > The output is 100% identical? nope, the U is actualy missing.. that's the thing, the patern matching allows you to put 'cp' instead of 'cpu' and the final output is screwed.. also the metrics won't match the proper event jirka
[PATCH NEXT 5/6] PCI/AER: Clear correctable status bits in device register
In case of correctable error Device Status Register sets Correctable Error Detected, which should be cleared after handling the error Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/aer/aerdrv_core.c b/drivers/pci/pcie/aer/aerdrv_core.c index 95e9828..0e4e99a 100644 --- a/drivers/pci/pcie/aer/aerdrv_core.c +++ b/drivers/pci/pcie/aer/aerdrv_core.c @@ -271,6 +271,7 @@ static void handle_error_source(struct pcie_device *aerdev, if (pos) pci_write_config_dword(dev, pos + PCI_ERR_COR_STATUS, info->status); + pci_cleanup_aer_error_device_status(dev); } else if (info->severity == AER_NONFATAL) pcie_do_nonfatal_recovery(dev); else if (info->severity == AER_FATAL) -- 2.7.4
[PATCH NEXT 2/6] PCI/AER: Clear uncorrectable fatal error status bits
During ERR_FATAL handling, AER calls pci_cleanup_aer_uncorrect_error_status
which should handle pci_channel_io_frozen case in order to determine if it
has to clear fatal bits or nonfatal bits.
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
index 309f3f5..6745e37 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -60,7 +60,12 @@ int pci_cleanup_aer_uncorrect_error_status(struct pci_dev
*dev)
pos = dev->aer_cap;
pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, &status);
pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_SEVER, &mask);
- status &= ~mask; /* Clear corresponding nonfatal bits */
+
+ if (dev->error_state == pci_channel_io_normal)
+ status &= ~mask; /* Clear corresponding nonfatal bits */
+ else
+ status &= mask; /* Clear corresponding fatal bits */
+
if (status)
pci_write_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, status);
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index f7ce0cb..00d2875 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -288,6 +288,7 @@ void pcie_do_fatal_recovery(struct pci_dev *dev, u32
service)
struct pci_dev *pdev, *temp;
pci_ers_result_t result;
+ dev->error_state = pci_channel_io_frozen;
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE)
udev = dev;
else
@@ -323,6 +324,7 @@ void pcie_do_fatal_recovery(struct pci_dev *dev, u32
service)
if (pcie_wait_for_link(udev, true))
pci_rescan_bus(udev->bus);
pci_info(dev, "Device recovery from fatal error successful\n");
+ dev->error_state = pci_channel_io_normal;
} else {
pci_uevent_ers(dev, PCI_ERS_RESULT_DISCONNECT);
pci_info(dev, "Device recovery from fatal error failed\n");
--
2.7.4
[PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()
We are handling ERR_FATAL by resetting the Link in software,skipping the
driver pci_error_handlers callbacks, removing the devices from the PCI
subsystem, and re-enumerating, as a result of that, no more calling
pcie_portdrv_slot_reset in ERR_FATAL case.
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index 973f1b8..92f5d330 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -42,17 +42,6 @@ __setup("pcie_ports=", pcie_port_setup);
/* global data */
-static int pcie_portdrv_restore_config(struct pci_dev *dev)
-{
- int retval;
-
- retval = pci_enable_device(dev);
- if (retval)
- return retval;
- pci_set_master(dev);
- return 0;
-}
-
#ifdef CONFIG_PM
static int pcie_port_runtime_suspend(struct device *dev)
{
@@ -162,14 +151,6 @@ static pci_ers_result_t pcie_portdrv_mmio_enabled(struct
pci_dev *dev)
static pci_ers_result_t pcie_portdrv_slot_reset(struct pci_dev *dev)
{
- /* If fatal, restore cfg space for possible link reset at upstream */
- if (dev->error_state == pci_channel_io_frozen) {
- dev->state_saved = true;
- pci_restore_state(dev);
- pcie_portdrv_restore_config(dev);
- pci_enable_pcie_error_reporting(dev);
- }
-
return PCI_ERS_RESULT_RECOVERED;
}
--
2.7.4
[PATCH NEXT 4/6] PCI/AER: Clear device status error bits during ERR_FATAL and ERR_NONFATAL
We are handling ERR_FATAL by resetting the Link in software,skipping the
driver pci_error_handlers callbacks, removing the devices from the PCI
subsystem, and re-enumerating, the device status has to be cleared,
which fixes BUG existed before.
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/aer/aerdrv.c b/drivers/pci/pcie/aer/aerdrv.c
index 8cbc62b..0d9eaba 100644
--- a/drivers/pci/pcie/aer/aerdrv.c
+++ b/drivers/pci/pcie/aer/aerdrv.c
@@ -341,12 +341,8 @@ static pci_ers_result_t aer_root_reset(struct pci_dev *dev)
*/
static void aer_error_resume(struct pci_dev *dev)
{
- u16 reg16;
-
/* Clean up Root device status */
- pcie_capability_read_word(dev, PCI_EXP_DEVSTA, ®16);
- pcie_capability_write_word(dev, PCI_EXP_DEVSTA, reg16);
-
+ pci_cleanup_aer_error_device_status(dev);
/* Clean AER Root Error Status */
pci_cleanup_aer_uncorrect_error_status(dev);
}
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
index 6745e37..95e9828 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -47,6 +47,17 @@ int pci_disable_pcie_error_reporting(struct pci_dev *dev)
}
EXPORT_SYMBOL_GPL(pci_disable_pcie_error_reporting);
+int pci_cleanup_aer_error_device_status(struct pci_dev *dev)
+{
+ u16 reg16;
+
+ /* Clean up Root device status */
+ pcie_capability_read_word(dev, PCI_EXP_DEVSTA, ®16);
+ pcie_capability_write_word(dev, PCI_EXP_DEVSTA, reg16);
+
+ return 0;
+}
+
int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev)
{
int pos;
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index 3998ed7..e1e642c 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -252,6 +252,7 @@ static pci_ers_result_t broadcast_error_message(struct
pci_dev *dev,
dev->error_state = state;
pci_walk_bus(dev->subordinate, cb, &result_data);
if (cb == report_resume) {
+ pci_cleanup_aer_error_device_status(dev);
pci_cleanup_aer_uncorrect_error_status(dev);
dev->error_state = pci_channel_io_normal;
}
@@ -312,6 +313,7 @@ void pcie_do_fatal_recovery(struct pci_dev *dev, u32
service)
* do error recovery on all subordinates of the bridge instead
* of the bridge and clear the error status of the bridge.
*/
+ pci_cleanup_aer_error_device_status(dev);
pci_cleanup_aer_uncorrect_error_status(dev);
}
diff --git a/include/linux/aer.h b/include/linux/aer.h
index 514bffa..165a147 100644
--- a/include/linux/aer.h
+++ b/include/linux/aer.h
@@ -44,6 +44,7 @@ struct aer_capability_regs {
/* PCIe port driver needs this function to enable AER */
int pci_enable_pcie_error_reporting(struct pci_dev *dev);
int pci_disable_pcie_error_reporting(struct pci_dev *dev);
+int pci_cleanup_aer_error_device_status(struct pci_dev *dev);
int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev);
int pci_cleanup_aer_error_status_regs(struct pci_dev *dev);
#else
@@ -55,6 +56,10 @@ static inline int pci_disable_pcie_error_reporting(struct
pci_dev *dev)
{
return -EINVAL;
}
+static inline int pci_cleanup_aer_error_device_status(struct pci_dev *dev)
+{
+ return -EINVAL;
+}
static inline int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev)
{
return -EINVAL;
--
2.7.4
[PATCH NEXT 3/6] PCI/ERR: Cleanup ERR_FATAL of error broadcast
ERR_FATAL is handled by resetting the Link in software, skipping the driver pci_error_handlers callbacks, removing the devices from the PCI subsystem, and re-enumerating, so now no more ERR_FATAL handling is required inside pci_broadcast_error_message() Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c index 00d2875..3998ed7 100644 --- a/drivers/pci/pcie/err.c +++ b/drivers/pci/pcie/err.c @@ -259,15 +259,10 @@ static pci_ers_result_t broadcast_error_message(struct pci_dev *dev, /* * If the error is reported by an end point, we think this * error is related to the upstream link of the end point. +* The error is non fatal so the bus is ok, just invoke +* the callback for the function that logged the error. */ - if (state == pci_channel_io_normal) - /* -* the error is non fatal so the bus is ok, just invoke -* the callback for the function that logged the error. -*/ - cb(dev, &result_data); - else - pci_walk_bus(dev->bus, cb, &result_data); + cb(dev, &result_data); } return result_data.result; -- 2.7.4
[PATCH NEXT 1/6] PCI/AER: Take mask into account while clearing error bits
PCIe ERR_NONFATAL and ERR_FATAL are uncorrectable errors, and clearing
uncorrectable error bits should take error mask into account.
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/aer/aerdrv.c b/drivers/pci/pcie/aer/aerdrv.c
index 377e576..8cbc62b 100644
--- a/drivers/pci/pcie/aer/aerdrv.c
+++ b/drivers/pci/pcie/aer/aerdrv.c
@@ -341,8 +341,6 @@ static pci_ers_result_t aer_root_reset(struct pci_dev *dev)
*/
static void aer_error_resume(struct pci_dev *dev)
{
- int pos;
- u32 status, mask;
u16 reg16;
/* Clean up Root device status */
@@ -350,11 +348,7 @@ static void aer_error_resume(struct pci_dev *dev)
pcie_capability_write_word(dev, PCI_EXP_DEVSTA, reg16);
/* Clean AER Root Error Status */
- pos = dev->aer_cap;
- pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, &status);
- pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_SEVER, &mask);
- status &= ~mask; /* Clear corresponding nonfatal bits */
- pci_write_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, status);
+ pci_cleanup_aer_uncorrect_error_status(dev);
}
/**
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
index 946f3f6..309f3f5 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -50,13 +50,17 @@ EXPORT_SYMBOL_GPL(pci_disable_pcie_error_reporting);
int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev)
{
int pos;
- u32 status;
+ u32 status, mask;
pos = dev->aer_cap;
if (!pos)
return -EIO;
+ /* Clean AER Root Error Status */
+ pos = dev->aer_cap;
pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, &status);
+ pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_SEVER, &mask);
+ status &= ~mask; /* Clear corresponding nonfatal bits */
if (status)
pci_write_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, status);
--
2.7.4
Re: [RFC 0/1] mconf: Emacs-like isearch
Masahiro Yamada writes: > 2018-06-07 8:54 GMT+09:00 Dirk Gouders : >> Randy Dunlap writes: >> >>> On 06/06/2018 03:32 PM, Dirk Gouders wrote: Randy Dunlap writes: > On 06/06/2018 02:56 PM, Dirk Gouders wrote: >> Hello, >> >> being an Emacs user, I frequently find myself pressing CTRL-s in mconf >> to search for some menu entry, especially in large menus. > > > I use Emacs, but I have never typed Ctrl-s in menuconfig. > > Is it important to use the same key pattern as in Emacs? > > You intercepted Ctrl-* > > Currently, Ctrl-C terminates the program, > but this patch makes it no-op. Yes, Segher also pointed out that I at least should have mentioned this in the cover letter. I simply forgot that, but I was aware that forced raw-mode probably is not acceptable. I'd say it's not important to start isearch with CTRL-s, I am just so used to it. So, I am open for suggestions. Meanwhile, in a V2 I will try to stay with CTRL-s (and probably another unused simpler key) but also create a possibility to toggle raw-mode with default off. >> I decided to implement a basic isearch in mconf and would like to hear >> if others find this functionality useful, as well. >> >> The new functionality is started with pressing CTRL-s followed by >> characters that form the search string. To search for further >> occurences of an entered string, press CTRL-s instead of further >> characters. >> >> For example: to navigate to the USB device drivers, press CTRL-s de >> ENTER ENTER usb ENTER ENTER > > Not being an emacs user, what is the "de" for above? "de" (with my .config) causes a match for "Device Drivers" -- no other menu entry matching the string "de" is befor that entry. >>> >>> Device Drivers is the first match for me also. >>> >>> To get to the USB drivers, I have to enter: >>> CTRL-s de ENTER ENTER CTRL-s usb ENTER ENTER >> >> Yes, I left out the second CTRL-s, thank you! >> >> Oh well, I shouldn't have sent this late at night, then I would probably >> have explained the needed input as: >> >> 1) CTRL-s // start isearch >> 2) de // substring that matches "Device Drivers" >> 3) ENTER // quit isearch >> 4) ENTER // enter Device Drivers menu >> 5) CTRL-s // start isearch >> 6) usb // navigate to USB support >> 7) ENTER // quit isearch >> 8) ENTER // enter USB support menu > > > Hmm. > > I tried this, but I was a bit annoyed. > > > I wonder if this could be more user-friendly. > > For example, I want KEY_UP/DOWN/LEFT/RIGHT > to quit the search mode without pressing ENTER. Thank you for testing it. Concerning annoyance, did you mean the isearch functionality itself or the incomplete implementation, i.e. the missing possibility to use above keys? I will handle the above keys in V2, additionally to fixing a problem with mismatches. Dirk
Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
On Wed 06 Jun 22:29 PDT 2018, Sricharan R wrote: > Hi Bjorn, > > On 6/7/2018 9:54 AM, Bjorn Andersson wrote: > > On Wed 06 Jun 21:11 PDT 2018, Vinod wrote: > > > >> On 06-06-18, 09:17, Bjorn Andersson wrote: > >>> On Tue 05 Jun 05:56 PDT 2018, Sricharan R wrote: > >>> > Hi Vinod, > > On 6/5/2018 11:49 AM, Vinod wrote: > > On 05-06-18, 11:12, Sricharan R wrote: [..] > > If we ignore SMD for a while we have the following combinations: > > > > glink/wcss > > y y - valid > > y m - valid > > y n - valid > > m y - link failure (invalid) > > m m - valid > > m n - valid > > n y - valid (platform uses wcss, but not glink) > > n m - valid (-"-) > > n n - valid > > > > So to distill this we have the two valid cases: > > module/no if RPMSG_QCOM_GLINK_SMEM=m > > yes/module/no if RPMSG_QCOM_GLINK_SMEM=y > > > > and the way you express that in Kconfig is the somewhat awkward > > > > depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n > > > > ok, Having "depends on RPMSG_QCOM_GLINK_SMEM" takes care of the > first 6 cases in the above list. > > But just was thinking that by allowing the last three combinations, > there is a chance that some config that really needs GLINK_SMEM and WCSS, > but selects only Q6V5_WCSS and misses to select GLINK_SMEM, > would still built and make it non-functional, right ? > It would allow you to compile a kernel with GLINk disabled that in runtime loads a firmware that depends on GLINK being there. As it would be convenient to thereby state that "WCSS always depends on GLINK" we can make the analog to 410 where "MSS always depends on SMD", which isn't true when the same driver is reused on e.g. 845 - which uses GLINK. So my recommendation is that we stick with Kconfig options that describes the build time dependencies of this particular driver, rather than its runtime dependencies in a particular platform. Regards, Bjorn
Re: [PATCH] printk/nmi: Prevent deadlock when serializing NMI backtraces
On (06/06/18 13:15), Petr Mladek wrote: > On Wed 2018-06-06 14:10:29, Sergey Senozhatsky wrote: > > On (06/05/18 14:47), Petr Mladek wrote: > > [..] > > > Grr, the ABBA deadlock is still there. NMIs are not sent to the other > > > CPUs atomically. Even if we detect that logbuf_lock is available > > > in printk_nmi_enter() on some CPUs, it might still get locked on > > > another CPU before the other CPU gets NMI. > > > > Can we do something about "B"? :) I mean - any chance we can rework > > locking in nmi_cpu_backtrace()? > > I can't think of any possibility at the moment. Well, it does not mean > that it does not exist. > > The irony is that we need the extra lock in nmi_cpu_backtrace() only > because we try to store the messages into the common log buffer. > If we always use the per-CPU buffers in NMI then the lock would > not cause any problems but it also won't be necessary. Yep. I think we can come up with something. It seems that the only problem is that we want in this particular case to avoid printk_nmi()->logbuf and instead we want to enforce per-CPU printk_nmi buffers. Then we can drop nmi_cpu_backtrace() spinlock, because the messages will be serialized by printk_safe flush spin_lock. That doesn't sound like an impossible thing to do. What am I missing? Could you please check my follow up email? > > > => I suggest to revert the commit 719f6a7040f1bdaf96fcc70 > > > "printk: Use the main logbuf in NMI when logbuf_lock is available" > > > for-4.18 and stable until we get a better solution. > > > > Just random thoughts. > > > > May be we need to revert it, but let's not "panic". I think [but don't > > insist on it] that the patch in question is *probably* "good enough". It > > addresses a bug report after all. > > It was a problem reported by me. I found it when testing other changes. > The patch improved the situation definitely. The question is if it is > enough in practice. Oh, certainly. But I was talking about 719f6a7040f1bdaf96fcc70. We introduced that change in response to a bug report from Steven. He would not be able to debug his kernel otherwise, because per-CPU printk_nmi was too limited in size. So on one hand we have the problem that you reported, which you found while you were hammering/testing NMI printk-s [a valid report on its own]; on the other hand we have the problem that Steven reported, which he triggered while he was debugging the kernel. It might be the case that Steven's problem is more likely to happen in real world. So that's why I proposed to keep 719f6a7040f1bda for the time being [until we come up with another fix]. I may be wrong. -ss
Re: [PATCH 42/46] perf script powerpc: Python script for hypervisor call statistics
Hi Paul,
On 06/06/2018 08:23 PM, Paul Clarke wrote:
> On 06/05/2018 12:50 PM, Arnaldo Carvalho de Melo wrote:
>> From: Ravi Bangoria
>>
>> Add python script to show hypervisor call statistics. Ex,
>>
>> # perf record -a -e "{powerpc:hcall_entry,powerpc:hcall_exit}"
>> # perf script -s scripts/python/powerpc-hcalls.py
>> hcallcount min(ns) max(ns) avg(ns)
>>
>> H_RANDOM82 838 1164 904
>> H_PUT_TCE 47 1078 5928 2003
>> H_EOI 266 1336 3546 1654
>> H_ENTER 28 1646 4038 1952
>> H_PUT_TCE_INDIRECT 230 2166 18168 6109
>> H_IPI 238 1072 3232 1688
>> H_SEND_LOGICAL_LAN 42 5488 21366 7694
>> H_STUFF_TCE294 986 6210 3591
>> H_XIRR 266 2286 6990 3783
>> H_PROTECT 10 2196 3556 2555
>> H_VIO_SIGNAL 294 1028 2784 1311
>> H_ADD_LOGICAL_LAN_BUFFER53 1978 3450 2600
>> H_SEND_CRQ 77 1762 7240 2447
>
> This translation from HCALL code to mnemonic is more generally useful. Is
> there a good way to make the "hcall_table_lookup" function more generally
> available, like "syscall_name" in
> scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py ? It's even simpler
> than the syscall ID-to-name mapping, because the HCALL codes are constant,
> unlike syscall IDs which vary between arches.
>
Right, but I don't see any other python script for hcalls. So, I thought
to add it in the script itself. Let me know if you are planning to add
any :) We will move it in a generic module.
Ravi
Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
Hi Bjorn, On 6/7/2018 9:54 AM, Bjorn Andersson wrote: > On Wed 06 Jun 21:11 PDT 2018, Vinod wrote: > >> On 06-06-18, 09:17, Bjorn Andersson wrote: >>> On Tue 05 Jun 05:56 PDT 2018, Sricharan R wrote: >>> Hi Vinod, On 6/5/2018 11:49 AM, Vinod wrote: > On 05-06-18, 11:12, Sricharan R wrote: > >> +config QCOM_Q6V5_WCSS >> +tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader" >> +depends on OF && ARCH_QCOM >> +depends on QCOM_SMEM >> +depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n) >> +depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n > > Is there a reason why it depends on RPMSG_QCOM_GLINK_SMEM=n? What would > happen if distro wants both this and RPMSG_QCOM_GLINK_SMEM > >>> >>> It says that QCOM_Q6V5_WCSS either must have a compatible state (i.e. >>> builtin vs builtin, module vs builtin, but not builtin vs module) or >>> that it's disabled, in which case we will hit the stub functions in >>> qcom_glink.h. >>> >>> I.e. this prevents QCOM_Q6V5_WCSS to be compiled builtin when >>> RPMSG_QCOM_GLINK_SMEM is module, as this would give us both stubs and >>> the module. >> >> IIUC, you want to have QCOM_Q6V5_WCSS and RPMSG_QCOM_GLINK_SMEM as >> modules or builtin >> > > RPMSG_QCOM_SMD, RPMSG_QCOM_GLINK_SMEM and QCOM_Q6V5_WCSS are all > tristate. > >> So, wouldn't Kconfig syntax something like where we say: >> M if RPMSG_QCOM_GLINK_SMEM=m >> bool if RPMSG_QCOM_GLINK_SMEM=y >> > > If we ignore SMD for a while we have the following combinations: > > glink/wcss > y y - valid > y m - valid > y n - valid > m y - link failure (invalid) > m m - valid > m n - valid > n y - valid (platform uses wcss, but not glink) > n m - valid (-"-) > n n - valid > > So to distill this we have the two valid cases: > module/no if RPMSG_QCOM_GLINK_SMEM=m > yes/module/no if RPMSG_QCOM_GLINK_SMEM=y > > and the way you express that in Kconfig is the somewhat awkward > > depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n > ok, Having "depends on RPMSG_QCOM_GLINK_SMEM" takes care of the first 6 cases in the above list. But just was thinking that by allowing the last three combinations, there is a chance that some config that really needs GLINK_SMEM and WCSS, but selects only Q6V5_WCSS and misses to select GLINK_SMEM, would still built and make it non-functional, right ? Regards, Sricharan >> Which makes it clear that both these have to be same type? >> > > They don't have to be of the same type, only of a compatible type. > -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [GIT PULL 00/46] perf/core fixes and improvements
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 7869e5889477e4e32e4024d665431b35e8b7b693: > > Merge remote-tracking branch 'tip/perf/urgent' into perf/core (2018-06-04 > 10:28:20 -0300) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo-4.18-20180605 > > for you to fetch changes up to 03ac4e71cd120d2c3411d106d00d266114575f74: > > perf intel-pt: Fix "Unexpected indirect branch" error (2018-06-05 12:28:52 > -0300) > > > perf/core improvements and fixes: > > perf stat: > > . Display user and system time for workload targets (Jiri Olsa) > > perf record: > > . Enable arbitrary event names thru name= modifier (Alexey Budankov) > > PowerPC: > > . Add a python script for hypervisor call statistics (Ravi Bangoria) > > Intel PT: (Adrian Hunter) > > . Fix sync_switch INTEL_PT_SS_NOT_TRACING > > . Fix decoding to accept CBR between FUP and corresponding TIP > > . Fix MTC timing after overflow > > . Fix "Unexpected indirect branch" error > > perf test: > > . record+probe_libc_inet_pton: > > . To get the symbol table for dynamic > shared objects on ubuntu we need to pass the -D/--dynamic command line > option, unlike with the fedora distros (Arnaldo Carvalho de Melo) > > . code-reading: > > . Fix perf_env setup for PTI entry trampolines (Adrian Hunter) > > . kmod-path: > > . Add tests for vdso32 and vdsox32 (Adrian Hunter) > > . Use header file util/debug.h (Thomas Richter) > > perf annotate: > > . Make the various UI backends (stdio, TUI, gtk) use more consistently > structs with annotation options as specified by the user (Arnaldo Carvalho > de Melo) > > . Move annotation specific knobs from the symbol_conf global kitchen > sink to the annotation option structs (Arnaldo Carvalho de Melo) > > Core: > > . Fix misleading error for some unparsable events mentioning PMUs when > those are not involved in the problem (Jiri Olsa) > > - Fix symbol and object code resolution for vdso32 and vdsox32 (Adrian Hunter) > > . No need to check for null when passing pointers to foo__get() style > refcount grabbing helpers, just like in the kernel and with free(), > its safe to pass a NULL pointer to avoid having to check it before > each and every foo__get() call (Arnaldo Carvalho de Melo) > > . Remove some dead code (quote.[ch]) (Arnaldo Carvalho de Melo) > > . Remove some needless globals, making them local (Arnaldo Carvalho de Melo) > > . Reduce usage of symbol_conf.use_callchain, using other means of > finding out if callchains are in use or available for specific events, > as we evolved this codebase to allow requesting callchains for just > a subset of the monitored events. In time it will help polish > recording and showing mixed sets accross the various tools: > > perf record -e > cycles/call-graph=fp/,cache-misses/call-graph=dwarf/,instructions > > (Arnaldo Carvalho de Melo) > > . Consider PTI entry trampolines in map__rip_2objdump() (Adrian Hunter) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Adrian Hunter (8): > perf tests kmod-path: Add tests for vdso32 and vdsox32 > perf tools: Fix symbol and object code resolution for vdso32 and vdsox32 > perf test code-reading: Fix perf_env setup for PTI entry trampolines > perf map: Consider PTI entry trampolines in rip_2objdump() > perf intel-pt: Fix sync_switch INTEL_PT_SS_NOT_TRACING > perf intel-pt: Fix decoding to accept CBR between FUP and corresponding > TIP > perf intel-pt: Fix MTC timing after overflow > perf intel-pt: Fix "Unexpected indirect branch" error > > Alexey Budankov (1): > perf record: Enable arbitrary event names thru name= modifier > > Arnaldo Carvalho de Melo (33): > perf tools: Remove dead quote.[ch] code > perf probe: Use return of map__get() to make code more compact > perf cgroup: Make evlist__find_cgroup() more compact > perf tools: No need to check if the argument to __get() function is NULL > perf annotate: Pass perf_evsel instead of just evsel->idx > perf annotate: __symbol__acount_cycles doesn't need notes > perf annotate: Split allocation of annotated_source struct > perf annotate: Introduce constructor/destructor for annotated_source > perf annotate: Introduce annotated_source__alloc_histograms > perf annotate: __symbol__inc_addr_samples() needs just annotated_source > perf annotate: Introduce symbol__hists() > perf annotate: Introduce symbol__cycle_hists() > perf annotate: Stop using symbol_conf.nr_events global in > symbol__hist
Re: possible deadlock in console_unlock
Cc-ing more people
Link: lkml.kernel.org/r/87008b056df8f...@google.com
On (06/06/18 06:17), syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.o..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=173d93ef80
> kernel config: https://syzkaller.appspot.com/x/.config?x=12ff770540994680
> dashboard link: https://syzkaller.appspot.com/bug?extid=43e93968b964e369db0b
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> userspace arch: i386
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=16e00bb780
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+43e93968b964e369d...@syzkaller.appspotmail.com
Thanks a ton!
So tty ioctl is known to be printk-deadlock prone and we don't know
how to handle this in printk, as of now.
ioctl
tty_ioctl
tty_port->lock
printk
call_console_driver
console_driver
uart_port->lock
The problem is that call_console_driver->console_driver also can do
this thing
uart_port->lock
tty_wakeup
tty_port->lock
So we can have the following:
ioctl
tty_ioctl
tty_port->lock
printk
call_console_driver
console_driver
uart_port->lock
tty_wakeup
tty_port->lock << deadlock
But lockdep is complaining about another scenario:
> the existing dependency chain (in reverse order) is:
>
> -> #2 (&(&port->lock)->rlock){-.-.}:
>__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
>tty_port_tty_get+0x20/0x80 drivers/tty/tty_port.c:288
>tty_port_default_wakeup+0x15/0x40 drivers/tty/tty_port.c:47
>tty_port_tty_wakeup+0x5d/0x70 drivers/tty/tty_port.c:390
>uart_write_wakeup+0x44/0x60 drivers/tty/serial/serial_core.c:103
>serial8250_tx_chars+0x4be/0xb60
> drivers/tty/serial/8250/8250_port.c:1808
>serial8250_handle_irq.part.25+0x1ee/0x280
> drivers/tty/serial/8250/8250_port.c:1881
>serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1867
> [inline]
>serial8250_default_handle_irq+0xc8/0x150
> drivers/tty/serial/8250/8250_port.c:1897
>serial8250_interrupt+0xfa/0x1d0
> drivers/tty/serial/8250/8250_core.c:125
>__handle_irq_event_percpu+0x1c0/0xad0 kernel/irq/handle.c:149
>handle_irq_event_percpu+0x98/0x1c0 kernel/irq/handle.c:189
>handle_irq_event+0xa7/0x135 kernel/irq/handle.c:206
>handle_edge_irq+0x20f/0x870 kernel/irq/chip.c:791
>generic_handle_irq_desc include/linux/irqdesc.h:159 [inline]
>handle_irq+0x18c/0x2e7 arch/x86/kernel/irq_64.c:77
>do_IRQ+0x78/0x190 arch/x86/kernel/irq.c:245
>ret_from_intr+0x0/0x1e
>native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
>arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
>default_idle+0xc2/0x440 arch/x86/kernel/process.c:500
>arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:491
>default_idle_call+0x6d/0x90 kernel/sched/idle.c:93
>cpuidle_idle_call kernel/sched/idle.c:153 [inline]
>do_idle+0x395/0x560 kernel/sched/idle.c:262
>cpu_startup_entry+0x104/0x120 kernel/sched/idle.c:368
>start_secondary+0x42b/0x5c0 arch/x86/kernel/smpboot.c:265
>secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
So this one is IRQ ==> uart_port->lock ==> tty_port->lock
> -> #1 (&port_lock_key){-.-.}:
>__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
>serial8250_console_write+0x8d5/0xb00
> drivers/tty/serial/8250/8250_port.c:3230
>univ8250_console_write+0x5f/0x70
> drivers/tty/serial/8250/8250_core.c:590
>call_console_drivers kernel/printk/printk.c:1718 [inline]
>console_unlock+0xac2/0x1100 kernel/printk/printk.c:2395
>vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
>vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
>vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
>printk+0x9e/0xba kernel/printk/printk.c:1980
>register_console+0x7e7/0xc00 kernel/printk/printk.c:2714
>univ8250_console_init+0x3f/0x4b
> drivers/tty/serial/8250/8250_core.c:685
>console_init+0x6d9/0xa38 kernel/printk/printk.c:2798
>start_kernel+0x608/0x92d init/main.c:661
>x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:452
>x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:433
>secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
This one is console_owner/console_sem ==> uart_port->lock
> -> #0 (console_owner){-...}:
>lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3924
>console_lock_spinning_enable kernel/printk/printk.c:1581 [
Re: [PATCH] pwm: stm32: enforce dependency on CONFIG_MFD_STM32_TIMERS
On Wed, 06 Jun 2018, Thierry Reding wrote:
> On Fri, May 25, 2018 at 06:04:54PM +0200, Arnd Bergmann wrote:
> > When compile-testing the pwm driver without also enabling the
> > stm32_timers MFD, we run into a link error:
> >
> > drivers/pwm/pwm-stm32.o: In function `stm32_pwm_raw_capture.isra.6':
> > pwm-stm32.c:(.text+0xcb0): undefined reference to
> > `stm32_timers_dma_burst_read'
> >
> > We don't need the '|| COMPILE_TEST' here, since stm32_timers itself
> > can be built with CONFIG_COMPILE_TEST on all architectures, so we do
> > get the coverage through allmodconfig and randconfig builds even
> > when we make it a hard dependency.
> >
> > Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm")
> > Signed-off-by: Arnd Bergmann
> > ---
> > drivers/pwm/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> I think Lee already picked up a patch by Fabrice that fixes this by
> adding a dummy implementation, see:
>
> http://patchwork.ozlabs.org/patch/916435/
>
> I prefer your solution, though, because the dummy is pretty redundant if
> we can just make this a hard-dependency and still get the same coverage.
The two patches aren't mutually exclusive. :)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] pwm: stm32: fix build warning with CONFIG_DMA_ENGINE disabled
On Wed, 06 Jun 2018, Thierry Reding wrote:
> On Fri, May 25, 2018 at 11:08:30PM +0200, Arnd Bergmann wrote:
> > Without dmaengine support, we get a harmless warning about an
> > unused function:
> >
> > drivers/pwm/pwm-stm32.c:166:12: error: 'stm32_pwm_capture' defined but not
> > used [-Werror=unused-function]
> >
> > Changing the #ifdef to an IS_ENABLED() check shuts up that warning
> > and is slightly nicer to read.
> >
> > Fixes: 53e38fe73f94 ("pwm: stm32: Add capture support")
> > Signed-off-by: Arnd Bergmann
> > ---
> > drivers/pwm/pwm-stm32.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
>
> Applied, thanks.
>
> Lee, I applied this on top of your immutable MFD/PWM branch because it
> depends on the capture support that you applied. I wasn't sure what your
> PR timing was going to be, so I thought I'd do it this way since I'm
> pulling in some last minute fixes for v4.18.
I don't see a problem with that.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
Hi. 2018-06-07 8:16 GMT+09:00 Jayant Chowdhary : > In order for static analysis tools to analyze each of the uapi headers, > we need to enable them to compile stand-alone. Some uapi headers were > missing dependencies which would not make them compile stand-alone in > user-land. This patch adds those dependencies. > > Test: make defconfig; make -j64 > > Test: make ARCH=arm64 defconfig; > ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j64 all > > Test: ran header-abi-dumper[1] on all the affected headers with > appropriate include paths[2] for arm64. eg: for drm_fourcc.h, > > $HEADER_ABI_DUMPER -o drm_fourcc.h.sdump \ > include/uapi/drm/drm_fourcc.h -- -target aarch64-linux-android -std=gnu99 \ > -isystem $CLANG_INCLUDE_PATH \ > -I include/uapi/ -I arch/arm64/include/generated/uapi \ > -I arch/arm64/include/uapi -I private-compiler-headers > -I include/generated/uapi \ > -I include/uapi/../../arch/arm/include/uapi First of all, is this check sensible? scripts/headers_install.sh manipulates exported headers. So, shouldn't you do this check after "make headers_install"? You are adding around to various UAPI headers. Could you tell me why it was added? The tool rips off anyway when exporting UAPI headers: https://github.com/torvalds/linux/blob/v4.17/scripts/headers_install.sh#L37 Also, you are adding to several headers. Please do not pull it in to the kernel space. The kernel space defines fixed-width types in its headers. For example, you added to include/uapi/scsi/scsi_netlink.h In my opinion, the correct fix is to replace uint8_t with __u8 or __uint8_t. > where > HEADER_ABI_DUMPER=\ > $ANDROID_BUILD_TOP/prebuilts/clang-tools/linux-x86/bin/header-abi-dumper > > CLANG_INCLUDE_PATH=\ > $ANDROID_BUILD_TOP/prebuilts/clang/host/linux-x86/clang-3289846/bin/../lib64/clang/3.8/include > > on a lunched aosp tree [3] > > [1] > header-abi-dumper is a clang based static analysis tool, used by android's > build > system which parses a C/C++ source file and emits information about the data > types included in the source. More information can be found at > https://android.googlesource.com/platform/development/+/master/vndk/tools/header-checker/README.md > > [2] > Some headers, eg: compiler_types.h, compiler.h, sys/socket.h are not in the > set of uapi headers, even though they are included by uapi headers( > include/uapi/linux/types.h, include/uapi/asm-generic/signal-defs.h etc). The > 'private-compiler-headers' in the test clause was included with private copies > of these headers. libc distributions (eg: bionic) often have their > copies of these headers as well. > > [3] > https://source.android.com/setup/build/downloading > > Cc: a...@linux-foundation.org > Cc: kernel-t...@android.com > Cc: linux-kbu...@vger.kernel.org > Signed-off-by: Jayant Chowdhary > --- > include/uapi/asm-generic/ipcbuf.h | 2 ++ > include/uapi/asm-generic/msgbuf.h | 3 +++ > include/uapi/asm-generic/sembuf.h | 2 ++ > include/uapi/asm-generic/shmbuf.h | 2 ++ > include/uapi/asm-generic/ucontext.h| 5 + > include/uapi/linux/agpgart.h | 1 - > include/uapi/linux/android/binder.h| 1 + > include/uapi/linux/chio.h | 6 ++ > include/uapi/linux/coda_psdev.h| 1 + > include/uapi/linux/dvb/dmx.h | 3 --- > include/uapi/linux/dvb/video.h | 3 --- > include/uapi/linux/errqueue.h | 1 + > include/uapi/linux/kexec.h | 1 + > include/uapi/linux/kfd_ioctl.h | 1 + > include/uapi/linux/lightnvm.h | 1 - > include/uapi/linux/ndctl.h | 1 + > include/uapi/linux/netfilter_bridge/ebtables.h | 1 + > include/uapi/linux/nfs4_mount.h| 3 +++ > include/uapi/linux/psp-sev.h | 1 + > include/uapi/linux/scc.h | 2 +- > include/uapi/linux/sctp.h | 3 +++ > include/uapi/linux/sdla.h | 2 ++ > include/uapi/linux/socket.h| 4 > include/uapi/linux/stddef.h| 5 + > include/uapi/linux/sysctl.h| 1 + > include/uapi/linux/types.h | 1 + > include/uapi/linux/vbox_vmmdev_types.h | 1 + > include/uapi/linux/vboxguest.h | 1 + > include/uapi/rdma/hfi/hfi1_user.h | 1 + > include/uapi/scsi/scsi_bsg_fc.h| 2 ++ > include/uapi/scsi/scsi_netlink.h | 1 + > include/uapi/sound/asound.h| 2 +- > 32 files changed, 55 insertions(+), 10 deletions(-) > > diff --git a/include/uapi/asm-generic/ipcbuf.h > b/include/uapi/asm-generic/ipcbuf.h > index 7d80dbd336fb..41a01b494fc7 100644 > --- a/include/uapi/asm-generic/ipcbuf.h > +++ b/include/uapi/asm-generic/ipcbuf.h > @@ -2,6 +2,8 @@ > #ifndef __ASM_GENERIC_IPCBUF_H > #define
Re: [PATCH][RFC] sched: cpufreq: Fix long idle judgement logic in load calculation
On 07-06-18, 11:17, Chen Yu wrote: > diff --git a/drivers/cpufreq/cpufreq_governor.c > b/drivers/cpufreq/cpufreq_governor.c > index 871bf9c..9792c80 100644 > --- a/drivers/cpufreq/cpufreq_governor.c > +++ b/drivers/cpufreq/cpufreq_governor.c > @@ -165,7 +165,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy) >* calls, so the previous load value can be used then. >*/ > load = j_cdbs->prev_load; > - } else if (unlikely(time_elapsed > 2 * sampling_rate && > + } else if (((int)idle_time > 0) && unlikely(idle_time > 2 * > sampling_rate && Yes the figures are insane, but if the idle time is around 36 minutes, the conversion to int will make a positive value look negative and we will exit the conditional block. And if we don't think that we will ever get such insane idle times or we don't want to care about them, then what about doing this instead: } else if ((unlikely((int)idle_time > 2 * sampling_rate && same below. -- viresh
Re: possible deadlock in console_unlock
syzbot has found a reproducer for the following crash on:
HEAD commit:0ad39cb3d70f Merge tag 'kconfig-v4.18' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1158868f80
kernel config: https://syzkaller.appspot.com/x/.config?x=b9a1f3aa8b8ddd16
dashboard link: https://syzkaller.appspot.com/bug?extid=43e93968b964e369db0b
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=14c89b9f80
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167f596f80
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+43e93968b964e369d...@syzkaller.appspotmail.com
R10: R11: 0246 R12:
R13: 7f3350380d80 R14: 0004 R15: 6d74702f7665642f
CPU: 1 PID: 4456 Comm: syz-executor589 Not tainted 4.17.0+ #87
==
WARNING: possible circular locking dependency detected
4.17.0+ #87 Not tainted
--
syz-executor589/4455 is trying to acquire lock:
(ptrval) (console_owner){-...}, at: log_next
kernel/printk/printk.c:496 [inline]
(ptrval) (console_owner){-...}, at: console_unlock+0x583/0x1100
kernel/printk/printk.c:2382
but task is already holding lock:
(ptrval) (&(&port->lock)->rlock){-.-.}, at: pty_write+0xf9/0x1f0
drivers/tty/pty.c:119
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&(&port->lock)->rlock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
tty_port_tty_get+0x20/0x80 drivers/tty/tty_port.c:288
tty_port_default_wakeup+0x15/0x40 drivers/tty/tty_port.c:47
tty_port_tty_wakeup+0x5d/0x70 drivers/tty/tty_port.c:390
uart_write_wakeup+0x44/0x60 drivers/tty/serial/serial_core.c:103
serial8250_tx_chars+0x4be/0xb60
drivers/tty/serial/8250/8250_port.c:1808
serial8250_handle_irq.part.25+0x1ee/0x280
drivers/tty/serial/8250/8250_port.c:1881
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1867
[inline]
serial8250_default_handle_irq+0xc8/0x150
drivers/tty/serial/8250/8250_port.c:1897
serial8250_interrupt+0xfa/0x1d0
drivers/tty/serial/8250/8250_core.c:125
__handle_irq_event_percpu+0x1c0/0xad0 kernel/irq/handle.c:149
handle_irq_event_percpu+0x98/0x1c0 kernel/irq/handle.c:189
handle_irq_event+0xa7/0x135 kernel/irq/handle.c:206
handle_edge_irq+0x20f/0x870 kernel/irq/chip.c:791
generic_handle_irq_desc include/linux/irqdesc.h:159 [inline]
handle_irq+0x18c/0x2e7 arch/x86/kernel/irq_64.c:77
do_IRQ+0x78/0x190 arch/x86/kernel/irq.c:245
ret_from_intr+0x0/0x1e
arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 [inline]
__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160
[inline]
_raw_spin_unlock_irqrestore+0xa1/0xc0 kernel/locking/spinlock.c:184
spin_unlock_irqrestore include/linux/spinlock.h:365 [inline]
uart_write+0x3df/0x620 drivers/tty/serial/serial_core.c:591
process_output_block drivers/tty/n_tty.c:579 [inline]
n_tty_write+0x6b9/0x1180 drivers/tty/n_tty.c:2308
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
redirected_tty_write+0xaf/0xc0 drivers/tty/tty_io.c:1063
__vfs_write+0x10b/0x960 fs/read_write.c:485
vfs_write+0x1f8/0x560 fs/read_write.c:549
ksys_write+0xf9/0x250 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (&port_lock_key){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
serial8250_console_write+0x8d5/0xb00
drivers/tty/serial/8250/8250_port.c:3230
univ8250_console_write+0x5f/0x70
drivers/tty/serial/8250/8250_core.c:590
call_console_drivers kernel/printk/printk.c:1718 [inline]
console_unlock+0xac2/0x1100 kernel/printk/printk.c:2395
vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
printk+0x9e/0xba kernel/printk/printk.c:1980
register_console+0x7e7/0xc00 kernel/printk/printk.c:2714
univ8250_console_init+0x3f/0x4b
drivers/tty/serial/8250/8250_core.c:685
console_init+0x6d9/0xa38 kernel/printk/printk.c:2798
start_kernel+0x608/0x92d init/main.c:661
x86_64_start_reservatio
Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
On Wed 06 Jun 21:11 PDT 2018, Vinod wrote: > On 06-06-18, 09:17, Bjorn Andersson wrote: > > On Tue 05 Jun 05:56 PDT 2018, Sricharan R wrote: > > > > > Hi Vinod, > > > > > > On 6/5/2018 11:49 AM, Vinod wrote: > > > > On 05-06-18, 11:12, Sricharan R wrote: > > > > > > > >> +config QCOM_Q6V5_WCSS > > > >> + tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader" > > > >> + depends on OF && ARCH_QCOM > > > >> + depends on QCOM_SMEM > > > >> + depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n) > > > >> + depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n > > > > > > > > Is there a reason why it depends on RPMSG_QCOM_GLINK_SMEM=n? What would > > > > happen if distro wants both this and RPMSG_QCOM_GLINK_SMEM > > > > > > > > It says that QCOM_Q6V5_WCSS either must have a compatible state (i.e. > > builtin vs builtin, module vs builtin, but not builtin vs module) or > > that it's disabled, in which case we will hit the stub functions in > > qcom_glink.h. > > > > I.e. this prevents QCOM_Q6V5_WCSS to be compiled builtin when > > RPMSG_QCOM_GLINK_SMEM is module, as this would give us both stubs and > > the module. > > IIUC, you want to have QCOM_Q6V5_WCSS and RPMSG_QCOM_GLINK_SMEM as > modules or builtin > RPMSG_QCOM_SMD, RPMSG_QCOM_GLINK_SMEM and QCOM_Q6V5_WCSS are all tristate. > So, wouldn't Kconfig syntax something like where we say: > M if RPMSG_QCOM_GLINK_SMEM=m > bool if RPMSG_QCOM_GLINK_SMEM=y > If we ignore SMD for a while we have the following combinations: glink/wcss y y - valid y m - valid y n - valid m y - link failure (invalid) m m - valid m n - valid n y - valid (platform uses wcss, but not glink) n m - valid (-"-) n n - valid So to distill this we have the two valid cases: module/no if RPMSG_QCOM_GLINK_SMEM=m yes/module/no if RPMSG_QCOM_GLINK_SMEM=y and the way you express that in Kconfig is the somewhat awkward depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n > Which makes it clear that both these have to be same type? > They don't have to be of the same type, only of a compatible type. Regards, Bjorn
linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
Today's linux-next merge of the nvdimm tree got a conflict in:
kernel/Makefile
between commit:
d7822b1e24f2 ("rseq: Introduce restartable sequences system call")
from the tip tree and commit:
5981690ddb8f ("memremap: split devm_memremap_pages() and memremap()
infrastructure")
from the nvdimm 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 kernel/Makefile
index 7085c841c413,9b9241361311..
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@@ -112,8 -112,8 +112,9 @@@ obj-$(CONFIG_JUMP_LABEL) += jump_label.
obj-$(CONFIG_CONTEXT_TRACKING) += context_tracking.o
obj-$(CONFIG_TORTURE_TEST) += torture.o
- obj-$(CONFIG_HAS_IOMEM) += memremap.o
+ obj-$(CONFIG_HAS_IOMEM) += iomem.o
+ obj-$(CONFIG_ZONE_DEVICE) += memremap.o
+obj-$(CONFIG_RSEQ) += rseq.o
$(obj)/configs.o: $(obj)/config_data.h
pgphsiKSy5d3l.pgp
Description: OpenPGP digital signature
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
+Greg/Alex, @Fegguang/build-bot: I do see mention of Greg and /me in your initial email's body saying TO: Viresh, CC: Greg, but I don't see any of us getting cc'd in your email. Bug ? On 06-06-18, 14:26, Steven Rostedt wrote: > On Wed, 6 Jun 2018 16:26:00 +0200 > Johan Hovold wrote: > > > Looks like the greybus code above is working as intended by checking for > > unterminated string after the strncpy, even if this does now triggers > > the truncation warning. So why exactly are we generating a warning here ? Is it because it is possible that the first n bytes of src may not have the null terminating byte and the dest may not be null terminated eventually ? Maybe I should just use memcpy here then ? But AFAIR, I used strncpy() specifically because it also sets all the remaining bytes after the null terminating byte with the null terminating byte. And so it is pretty easy for me to check if the final string is null terminated by checking [max - 1] byte against '\0', which the code is doing right now. I am not sure what would the best way to get around this incorrect-warning. And I am wondering on why buildbot reported the warning only for two instances in that file, while I have done the same thing at 4 places. > Ah, yes I now see that. Thanks for pointing it out. But perhaps it > should also add the "- 1" to the strncpy() so that gcc doesn't think > it's a mistake. The src string is passed on from a firmware entity and we need to make sure the protocol (greybus) is implemented properly by the other end. For example, in the current case if the firmware sends "HELLOWORLD", its an error as it should have sent "HELLWORLD\0". But with what you are saying we will forcefully make dest as "HELLWORLD\0", which wouldn't be the right thing to do as we will miss the bug present in firmware. -- viresh
Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
On 06-06-18, 09:17, Bjorn Andersson wrote: > On Tue 05 Jun 05:56 PDT 2018, Sricharan R wrote: > > > Hi Vinod, > > > > On 6/5/2018 11:49 AM, Vinod wrote: > > > On 05-06-18, 11:12, Sricharan R wrote: > > > > > >> +config QCOM_Q6V5_WCSS > > >> +tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader" > > >> +depends on OF && ARCH_QCOM > > >> +depends on QCOM_SMEM > > >> +depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n) > > >> +depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n > > > > > > Is there a reason why it depends on RPMSG_QCOM_GLINK_SMEM=n? What would > > > happen if distro wants both this and RPMSG_QCOM_GLINK_SMEM > > > > > It says that QCOM_Q6V5_WCSS either must have a compatible state (i.e. > builtin vs builtin, module vs builtin, but not builtin vs module) or > that it's disabled, in which case we will hit the stub functions in > qcom_glink.h. > > I.e. this prevents QCOM_Q6V5_WCSS to be compiled builtin when > RPMSG_QCOM_GLINK_SMEM is module, as this would give us both stubs and > the module. IIUC, you want to have QCOM_Q6V5_WCSS and RPMSG_QCOM_GLINK_SMEM as modules or builtin So, wouldn't Kconfig syntax something like where we say: M if RPMSG_QCOM_GLINK_SMEM=m bool if RPMSG_QCOM_GLINK_SMEM=y Which makes it clear that both these have to be same type? -- ~Vinod
[PATCH][RFC] sched: cpufreq: Fix long idle judgement logic in load calculation
According to current code implementation, detecting the long
idle period is done by checking if the interval between two
adjacent utilization update handers is long enough. Although
this mechanism can detect if the idle period is long enough
(no utilization hooks invoked during idle period), it might
not contain a corner case: if the task has occupied the cpu
for too long which causes no context switch during that
period, then no utilization handler will be launched until this
high prio task is switched out. As a result, the idle_periods
field might be calculated incorrectly because it regards the
100% load as 0% and makes the conservative governor who uses
this field confusing.
Change the judgement to compare the idle_time with sampling_rate
directly.
Reported-by: Artem S. Tashkinov
Cc: Artem S Tashkinov
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Chen Yu
---
drivers/cpufreq/cpufreq_governor.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 871bf9c..9792c80 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -165,7 +165,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
* calls, so the previous load value can be used then.
*/
load = j_cdbs->prev_load;
- } else if (unlikely(time_elapsed > 2 * sampling_rate &&
+ } else if (((int)idle_time > 0) && unlikely(idle_time > 2 *
sampling_rate &&
j_cdbs->prev_load)) {
/*
* If the CPU had gone completely idle and a task has
@@ -185,10 +185,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
* clear prev_load to guarantee that the load will be
* computed again next time.
*
-* Detecting this situation is easy: the governor's
-* utilization update handler would not have run during
-* CPU-idle periods. Hence, an unusually large
-* 'time_elapsed' (as compared to the sampling rate)
+* Detecting this situation is easy: an unusually large
+* 'idle_time' (as compared to the sampling rate)
* indicates this scenario.
*/
load = j_cdbs->prev_load;
@@ -217,8 +215,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
j_cdbs->prev_load = load;
}
- if (time_elapsed > 2 * sampling_rate) {
- unsigned int periods = time_elapsed / sampling_rate;
+ if (((int)idle_time > 0) && (idle_time > 2 * sampling_rate)) {
+ unsigned int periods = idle_time / sampling_rate;
if (periods < idle_periods)
idle_periods = periods;
--
2.7.4
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 2018/6/7 10:39, Andy Lutomirski wrote:
>
>
>> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown)
>> wrote:
>>
>>
>>
>>> On 2018/6/7 1:01, Andy Lutomirski wrote:
>>> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
>>> wrote:
I found that glibc has already dealt with this case. So this issue must
have been met before, should it be maintained by libc/user?
if (GLRO(dl_sysinfo_dso) == NULL)
{
kact.sa_flags |= SA_RESTORER;
kact.sa_restorer = ((act->sa_flags & SA_SIGINFO)
? &restore_rt : &restore);
}
> On 2018/6/6 15:52, Leizhen (ThunderTown) wrote:
>
>
>> On 2018/6/5 19:24, Leizhen (ThunderTown) wrote:
>> After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable vdso,
>> the rt_sigaction01 test case from ltp_2015 failed.
>> The test case source code please refer to the attachment, and the output
>> as blow:
>>
>> -
>> ./rt_sigaction01
>> rt_sigaction010 TINFO : signal: 34
>> rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
>> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
>> rt_sigaction010 TINFO : Signal Handler Called with signal number
>> 34
>>
>> Segmentation fault
>> --
>>
>>
>> Is this the desired result? In function ia32_setup_rt_frame, I found
>> below code:
>>
>> if (ksig->ka.sa.sa_flags & SA_RESTORER)
>> restorer = ksig->ka.sa.sa_restorer;
>> else
>> restorer = current->mm->context.vdso +
>> vdso_image_32.sym___kernel_rt_sigreturn;
>> put_user_ex(ptr_to_compat(restorer), &frame->pretcode);
>>
>> Because the vdso is disabled, so current->mm->context.vdso is NULL,
>> which cause the result of frame->pretcode invalid.
>>
>> I'm not sure whether this is a kernel bug or just an error of test case
>> itself. Can anyone help me?
>>
>
>>>
>>> I can't tell from your email what you're testing, what behavior you
>>> expect, and what you saw. A program that sets up a signal handler
>>> without supplying a restorer will not work if the vDSO is off, and
>>> this is by design.
>> OK, so that the user should take care whether the vDSO is disabled by itself
>> or not, and use different strategies to process it appropriately, like glibc.
>>
>>>
>>> (FWIW, there is a very longstanding libc bug that causes this case to
>>> get severely screwed up if the user's SS is not the expected value,
>>> and that bug was just fixed very recently. But I doubt this is what
>>> you're seeing.)
>>>
>>> I suppose we could improve the kernel to at least push NULL instead of
>>> some random address a bit above 0, but it'll still crash.
>> Should we add a warning? Which may help the user to aware this error in time.
>>
>
> It’s entirely valid to have a non working restorer if you never plan to
> return from a signal handler. And anyone who writes their own libc should be
> able to figure this out on their own, I think.
OK. Thanks a lot.
>
>>>
>>> .
>>>
>>
>> --
>> Thanks!
>> BestRegards
>>
>
> .
>
--
Thanks!
BestRegards
[lkp-robot] [x86] 1a39381d70: WARNING:at_kernel/locking/mutex.c:#__mutex_unlock_slowpath
FYI, we noticed the following commit (built with gcc-7):
commit: 1a39381d7f0097ec6e2ceb75812d6c00b2f1 ("x86: alternatives: macrofy
locks for better inlining")
url:
https://github.com/0day-ci/linux/commits/Nadav-Amit/x86-macrofying-inline-asm-for-better-compilation/20180605-124313
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -m 512M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+-+++
|
| 2c1316126e | 1a39381d70 |
+-+++
| boot_successes
| 0 | 0 |
| boot_failures
| 18 | 17 |
| WARNING:at_lib/debugobjects.c:#__debug_object_init
| 18 ||
| RIP:__debug_object_init
| 18 ||
| WARNING:at_kernel/locking/mutex.c:#__mutex_unlock_slowpath
| 0 | 17 |
| RIP:__mutex_unlock_slowpath
| 0 | 17 |
| WARNING:at_arch/x86/kernel/idt.c:#update_intr_gate
| 0 | 17 |
| RIP:update_intr_gate
| 0 | 17 |
| page_allocation_failure:order:#,mode:#(),nodemask=(null)
| 0 | 17 |
| Mem-Info
| 0 | 17 |
|
Kernel_panic-not_syncing:kmem_cache_create:Failed_to_create_slab'radix_tree_node'.Error
| 0 | 17 |
+-+++
[0.00] WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:1032
__mutex_unlock_slowpath+0x1ff/0x2a0
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.17.0-4-g1a39381 #2
[0.00] RIP: 0010:__mutex_unlock_slowpath+0x1ff/0x2a0
[0.00] RSP: :b4a03df0 EFLAGS: 00010082 ORIG_RAX:
[0.00] RAX: 0033 RBX: RCX: b4a797c0
[0.00] RDX: b36b41de RSI: 0001 RDI: 0046
[0.00] RBP: b4a03e30 R08: 0001 R09:
[0.00] R10: R11: R12: b4c789e0
[0.00] R13: b4a03df8 R14: b48dcfb0 R15:
[0.00] FS: () GS:b4a8e000()
knlGS:
[0.00] CS: 0010 DS: ES: CR0: 80050033
[0.00] CR2: a2951a312000 CR3: 18a74000 CR4: 000606b0
[0.00] Call Trace:
[0.00] mutex_unlock+0x12/0x20
[0.00] __clocksource_register_scale+0xda/0x120
[0.00] kvmclock_init+0x22d/0x23f
[0.00] setup_arch+0xa20/0xaf6
[0.00] start_kernel+0x6a/0x4dc
[0.00] ? copy_bootdata+0x1f/0xb8
[0.00] x86_64_start_reservations+0x24/0x26
[0.00] x86_64_start_kernel+0x73/0x76
[0.00] secondary_startup_64+0xa5/0xb0
[0.00] Code: 0f 0b e9 ae fe ff ff e8 d0 15 a5 ff 85 c0 74 1d 44 8b 15
1d 0c 8f 01 45 85 d2 75 11 4c 89 f6 48 c7 c7 53 b4 8c b4 e8 81 3a 5c ff <0f> 0b
44 8b 0d c0 b2 7c 01 45 85 c9 0f 84 6f fe ff ff e9 73 fe
[0.00] random: get_random_bytes called from
print_oops_end_marker+0x3f/0x60 with crng_init=0
[0.00] ---[ end trace a9c261981ad74140 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.17.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_
[PATCH v1 0/4] clk: rockchip: support clock controller for px30 SoC
Elaine Zhang (4): dt-bindings: add bindings for px30 clock controller clk: rockchip: add dt-binding header for px30 clk: rockchip: add support for half divider clk: rockchip: add clock controller for px30 .../bindings/clock/rockchip,px30-cru.txt | 67 ++ drivers/clk/rockchip/Makefile |2 + drivers/clk/rockchip/clk-half-divider.c| 235 + drivers/clk/rockchip/clk-px30.c| 1080 drivers/clk/rockchip/clk.c | 10 + drivers/clk/rockchip/clk.h | 86 +- include/dt-bindings/clock/px30-cru.h | 402 7 files changed, 1881 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt create mode 100644 drivers/clk/rockchip/clk-half-divider.c create mode 100644 drivers/clk/rockchip/clk-px30.c create mode 100644 include/dt-bindings/clock/px30-cru.h -- 1.9.1
[PATCH v1 2/4] clk: rockchip: add dt-binding header for px30
Add the dt-bindings header for the px30, that gets shared between the clock controller and the clock references in the dts. Add softreset ID for px30. Signed-off-by: Elaine Zhang --- include/dt-bindings/clock/px30-cru.h | 402 +++ 1 file changed, 402 insertions(+) create mode 100644 include/dt-bindings/clock/px30-cru.h diff --git a/include/dt-bindings/clock/px30-cru.h b/include/dt-bindings/clock/px30-cru.h new file mode 100644 index ..db9fc2a0bb21 --- /dev/null +++ b/include/dt-bindings/clock/px30-cru.h @@ -0,0 +1,402 @@ +/* + * Copyright (c) 2017 Rockchip Electronics Co. Ltd. + * Author: Elaine + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _DT_BINDINGS_CLK_ROCKCHIP_PX30_H +#define _DT_BINDINGS_CLK_ROCKCHIP_PX30_H + +/* core clocks */ +#define PLL_APLL 1 +#define PLL_DPLL 2 +#define PLL_CPLL 3 +#define PLL_NPLL 4 +#define APLL_BOOST_H 5 +#define APLL_BOOST_L 6 +#define ARMCLK 7 + +/* sclk gates (special clocks) */ +#define USB480M14 +#define SCLK_PDM 15 +#define SCLK_I2S0_TX 16 +#define SCLK_I2S0_TX_OUT 17 +#define SCLK_I2S0_RX 18 +#define SCLK_I2S0_RX_OUT 19 +#define SCLK_I2S1 20 +#define SCLK_I2S1_OUT 21 +#define SCLK_I2S2 22 +#define SCLK_I2S2_OUT 23 +#define SCLK_UART1 24 +#define SCLK_UART2 25 +#define SCLK_UART3 26 +#define SCLK_UART4 27 +#define SCLK_UART5 28 +#define SCLK_I2C0 29 +#define SCLK_I2C1 30 +#define SCLK_I2C2 31 +#define SCLK_I2C3 32 +#define SCLK_I2C4 33 +#define SCLK_PWM0 34 +#define SCLK_PWM1 35 +#define SCLK_SPI0 36 +#define SCLK_SPI1 37 +#define SCLK_TIMER038 +#define SCLK_TIMER139 +#define SCLK_TIMER240 +#define SCLK_TIMER341 +#define SCLK_TIMER442 +#define SCLK_TIMER543 +#define SCLK_TSADC 44 +#define SCLK_SARADC45 +#define SCLK_OTP 46 +#define SCLK_OTP_USR 47 +#define SCLK_CRYPTO48 +#define SCLK_CRYPTO_APK49 +#define SCLK_DDRC 50 +#define SCLK_ISP 51 +#define SCLK_CIF_OUT 52 +#define SCLK_RGA_CORE 53 +#define SCLK_VOPB_PWM 54 +#define SCLK_NANDC 55 +#define SCLK_SDIO 56 +#define SCLK_EMMC 57 +#define SCLK_SFC 58 +#define SCLK_SDMMC 59 +#define SCLK_OTG_ADP 60 +#define SCLK_GMAC_SRC 61 +#define SCLK_GMAC 62 +#define SCLK_GMAC_RX_TX63 +#define SCLK_MAC_REF 64 +#define SCLK_MAC_REFOUT65 +#define SCLK_MAC_OUT 66 +#define SCLK_SDMMC_DRV 67 +#define SCLK_SDMMC_SAMPLE 68 +#define SCLK_SDIO_DRV 69 +#define SCLK_SDIO_SAMPLE 70 +#define SCLK_EMMC_DRV 71 +#define SCLK_EMMC_SAMPLE 72 +#define SCLK_GPU 73 +#define SCLK_PVTM 74 +#define SCLK_CORE_VPU 75 +#define SCLK_GMAC_RMII 76 +#define SCLK_UART2_SRC 77 +#define SCLK_NANDC_DIV 78 +#define SCLK_NANDC_DIV50 79 +#define SCLK_SDIO_DIV 80 +#define SCLK_SDIO_DIV5081 +#define SCLK_EMMC_DIV 82 +#define SCLK_EMMC_DIV5083 +#define SCLK_DDRCLK84 +#define SCLK_UART1_SRC 85 + +/* dclk gates */ +#define DCLK_VOPB 150 +#define DCLK_VOPL 151 + +/* aclk gates */ +#define ACLK_GPU 170 +#define ACLK_BUS_PRE 171 +#define ACLK_CRYPTO172 +#define ACLK_VI_PRE173 +#define ACLK_VO_PRE174 +#define ACLK_VPU 175 +#define ACLK_PERI_PRE 176 +#define ACLK_GMAC 178 +#define ACLK_CIF 179 +#define ACLK_ISP 180 +#define ACLK_VOPB 181 +#define ACLK_VOPL 182 +#define ACLK_RGA 183 +#define ACLK_GIC 184 +#define ACLK_DCF 186 +#define ACLK_DMAC 187 +#define ACLK_BUS_SRC 188 +#define ACLK_PERI_SRC 189 + +/* hclk gates */ +#define HCLK_BUS_PRE 240 +#define HCLK_CRYPTO241 +#define HCLK_VI_PRE
[PATCH v1 3/4] clk: rockchip: add support for half divider
The new Rockchip socs have optional half divider,
so we use "branch_half_divider" + "COMPOSITE_NOMUX_HALFDIV \ DIV_HALF"
to hook that special divider clock-type into our clock-tree.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/Makefile | 1 +
drivers/clk/rockchip/clk-half-divider.c | 235
drivers/clk/rockchip/clk.c | 10 ++
drivers/clk/rockchip/clk.h | 45 ++
4 files changed, 291 insertions(+)
create mode 100644 drivers/clk/rockchip/clk-half-divider.c
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index 59b8d320960a..023f83ad3429 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -7,6 +7,7 @@ obj-y += clk-rockchip.o
obj-y += clk.o
obj-y += clk-pll.o
obj-y += clk-cpu.o
+obj-y += clk-half-divider.o
obj-y += clk-inverter.o
obj-y += clk-mmc-phase.o
obj-y += clk-muxgrf.o
diff --git a/drivers/clk/rockchip/clk-half-divider.c
b/drivers/clk/rockchip/clk-half-divider.c
new file mode 100644
index ..23830de254ec
--- /dev/null
+++ b/drivers/clk/rockchip/clk-half-divider.c
@@ -0,0 +1,235 @@
+/*
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "clk.h"
+
+#define div_mask(width)((1 << (width)) - 1)
+
+static bool _is_best_half_div(unsigned long rate, unsigned long now,
+ unsigned long best, unsigned long flags)
+{
+ if (flags & CLK_DIVIDER_ROUND_CLOSEST)
+ return abs(rate - now) < abs(rate - best);
+
+ return now <= rate && now > best;
+}
+
+static unsigned long clk_half_divider_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_divider *divider = to_clk_divider(hw);
+ unsigned int val;
+
+ val = clk_readl(divider->reg) >> divider->shift;
+ val &= div_mask(divider->width);
+ val = val * 2 + 3;
+
+ return DIV_ROUND_UP_ULL((u64)(parent_rate * 2), val);
+}
+
+static int clk_half_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
+ unsigned long *best_parent_rate, u8 width,
+ unsigned long flags)
+{
+ int i, bestdiv = 0;
+ unsigned long parent_rate, best = 0, now, maxdiv;
+ unsigned long parent_rate_saved = *best_parent_rate;
+
+ if (!rate)
+ rate = 1;
+
+ maxdiv = div_mask(width);
+
+ if (!(clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT)) {
+ parent_rate = *best_parent_rate;
+ bestdiv = DIV_ROUND_UP_ULL((u64)(parent_rate * 2), rate);
+ if (bestdiv < 3)
+ bestdiv = 0;
+ else
+ bestdiv = (bestdiv - 3) / 2;
+ bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv;
+ return bestdiv;
+ }
+
+ /*
+* The maximum divider we can use without overflowing
+* unsigned long in rate * i below
+*/
+ maxdiv = min(ULONG_MAX / rate, maxdiv);
+
+ for (i = 0; i <= maxdiv; i++) {
+ if ((rate * (i * 2 + 3)) == (parent_rate_saved * 2)) {
+ /*
+* It's the most ideal case if the requested rate can be
+* divided from parent clock without needing to change
+* parent rate, so return the divider immediately.
+*/
+ *best_parent_rate = parent_rate_saved;
+ return i;
+ }
+ parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw),
+ (rate * (i * 2 + 3)) / 2);
+ now = DIV_ROUND_UP_ULL((u64)(parent_rate * 2), (i * 2 + 3));
+ if (_is_best_half_div(rate, now, best, flags)) {
+ bestdiv = i;
+ best = now;
+ *best_parent_rate = parent_rate;
+ }
+ }
+
+ if (!bestdiv) {
+ bestdiv = div_mask(width);
+ *best_parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw), 1);
+ }
+
+ return bestdiv;
+}
+
+static long clk_half_divider_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ struct clk_divider *divider = to_clk_divider(hw);
+ int div;
+
+ div = clk_half_divider_bestdiv(hw, rate, prate,
+
[PATCH v1 4/4] clk: rockchip: add clock controller for px30
Add the clock tree definition for the new px30 SoC.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/Makefile |1 +
drivers/clk/rockchip/clk-px30.c | 1080 +++
drivers/clk/rockchip/clk.h | 41 +-
3 files changed, 1121 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/rockchip/clk-px30.c
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index 023f83ad3429..82ab6f515179 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -14,6 +14,7 @@ obj-y += clk-muxgrf.o
obj-y += clk-ddr.o
obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
+obj-y += clk-px30.o
obj-y += clk-rv1108.o
obj-y += clk-rk3036.o
obj-y += clk-rk3128.o
diff --git a/drivers/clk/rockchip/clk-px30.c b/drivers/clk/rockchip/clk-px30.c
new file mode 100644
index ..07105fe1ff6c
--- /dev/null
+++ b/drivers/clk/rockchip/clk-px30.c
@@ -0,0 +1,1080 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Elaine
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "clk.h"
+
+#define PX30_GRF_SOC_STATUS0 0x480
+
+enum px30_plls {
+ apll, dpll, cpll, npll, apll_b_h, apll_b_l,
+};
+
+enum px30_pmu_plls {
+ gpll,
+};
+
+static struct rockchip_pll_rate_table px30_pll_rates[] = {
+ /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
+ RK3036_PLL_RATE(160800, 1, 67, 1, 1, 1, 0),
+ RK3036_PLL_RATE(158400, 1, 66, 1, 1, 1, 0),
+ RK3036_PLL_RATE(156000, 1, 65, 1, 1, 1, 0),
+ RK3036_PLL_RATE(153600, 1, 64, 1, 1, 1, 0),
+ RK3036_PLL_RATE(151200, 1, 63, 1, 1, 1, 0),
+ RK3036_PLL_RATE(148800, 1, 62, 1, 1, 1, 0),
+ RK3036_PLL_RATE(146400, 1, 61, 1, 1, 1, 0),
+ RK3036_PLL_RATE(144000, 1, 60, 1, 1, 1, 0),
+ RK3036_PLL_RATE(141600, 1, 59, 1, 1, 1, 0),
+ RK3036_PLL_RATE(139200, 1, 58, 1, 1, 1, 0),
+ RK3036_PLL_RATE(136800, 1, 57, 1, 1, 1, 0),
+ RK3036_PLL_RATE(134400, 1, 56, 1, 1, 1, 0),
+ RK3036_PLL_RATE(132000, 1, 55, 1, 1, 1, 0),
+ RK3036_PLL_RATE(129600, 1, 54, 1, 1, 1, 0),
+ RK3036_PLL_RATE(127200, 1, 53, 1, 1, 1, 0),
+ RK3036_PLL_RATE(124800, 1, 52, 1, 1, 1, 0),
+ RK3036_PLL_RATE(12, 1, 50, 1, 1, 1, 0),
+ RK3036_PLL_RATE(118800, 2, 99, 1, 1, 1, 0),
+ RK3036_PLL_RATE(110400, 1, 46, 1, 1, 1, 0),
+ RK3036_PLL_RATE(11, 12, 550, 1, 1, 1, 0),
+ RK3036_PLL_RATE(100800, 1, 84, 2, 1, 1, 0),
+ RK3036_PLL_RATE(10, 6, 500, 2, 1, 1, 0),
+ RK3036_PLL_RATE(98400, 1, 82, 2, 1, 1, 0),
+ RK3036_PLL_RATE(96000, 1, 80, 2, 1, 1, 0),
+ RK3036_PLL_RATE(93600, 1, 78, 2, 1, 1, 0),
+ RK3036_PLL_RATE(91200, 1, 76, 2, 1, 1, 0),
+ RK3036_PLL_RATE(9, 4, 300, 2, 1, 1, 0),
+ RK3036_PLL_RATE(88800, 1, 74, 2, 1, 1, 0),
+ RK3036_PLL_RATE(86400, 1, 72, 2, 1, 1, 0),
+ RK3036_PLL_RATE(84000, 1, 70, 2, 1, 1, 0),
+ RK3036_PLL_RATE(81600, 1, 68, 2, 1, 1, 0),
+ RK3036_PLL_RATE(8, 6, 400, 2, 1, 1, 0),
+ RK3036_PLL_RATE(7, 6, 350, 2, 1, 1, 0),
+ RK3036_PLL_RATE(69600, 1, 58, 2, 1, 1, 0),
+ RK3036_PLL_RATE(62400, 1, 52, 2, 1, 1, 0),
+ RK3036_PLL_RATE(6, 1, 75, 3, 1, 1, 0),
+ RK3036_PLL_RATE(59400, 2, 99, 2, 1, 1, 0),
+ RK3036_PLL_RATE(50400, 1, 63, 3, 1, 1, 0),
+ RK3036_PLL_RATE(5, 6, 250, 2, 1, 1, 0),
+ RK3036_PLL_RATE(40800, 1, 68, 2, 2, 1, 0),
+ RK3036_PLL_RATE(31200, 1, 52, 2, 2, 1, 0),
+ RK3036_PLL_RATE(21600, 1, 72, 4, 2, 1, 0),
+ RK3036_PLL_RATE(9600, 1, 64, 4, 4, 1, 0),
+ { /* sentinel */ },
+};
+
+#define PX30_DIV_ACLKM_MASK0x7
+#define PX30_DIV_ACLKM_SHIFT 12
+#define PX30_DIV_PCLK_DBG_MASK 0xf
+#define PX30_DIV_PCLK_DBG_SHIFT8
+
+#define PX30_CLKSEL0(_aclk_core, _pclk_dbg)\
+{ \
+ .reg = PX30_CLKSEL_CON(0), \
+ .val = HIWORD_UPDATE(_aclk_core, PX30_DIV_ACLKM_MASK, \
+PX30_DIV_ACLKM_SHIFT) |\
+ HIWORD_UPDATE(_pclk_dbg, PX30_DIV_PCLK_DBG_MASK, \
+PX30_DIV_PCLK_DBG_
[PATCH v1 1/4] dt-bindings: add bindings for px30 clock controller
Add devicetree bindings for Rockchip cru which found on
Rockchip SoCs.
Signed-off-by: Elaine Zhang
---
.../bindings/clock/rockchip,px30-cru.txt | 67 ++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
diff --git a/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
new file mode 100644
index ..af5a45b680d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
@@ -0,0 +1,67 @@
+* Rockchip PX30 Clock and Reset Unit
+
+The PX30 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: PMU for CRU should be "rockchip,px30-pmu-cru"
+- compatible: CRU should be "rockchip,px30-cru"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+ If missing, pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/px30-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "i2sx_clkin" - external I2S clock - optional,
+ - "gmac_clkin" - external GMAC clock - optional
+
+Example: Clock controller node:
+
+ pmucru: pmu-clock-controller@ff2bc000 {
+ compatible = "rockchip,px30-pmucru";
+ reg = <0x0 0xff2bc000 0x0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ cru: clock-controller@ff2b {
+ compatible = "rockchip,px30-cru";
+ reg = <0x0 0xff2b 0x0 0x1000>;
+ rockchip,grf = <&grf>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller:
+
+ uart0: serial@ff03 {
+ compatible = "rockchip,px30-uart", "snps,dw-apb-uart";
+ reg = <0x0 0xff03 0x0 0x100>;
+ interrupts = ;
+ clocks = <&pmucru SCLK_UART0_PMU>, <&pmucru PCLK_UART0_PMU>;
+ clock-names = "baudclk", "apb_pclk";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
--
1.9.1
[GIT PULL] DeviceTree updates for 4.18
Hi Linus,
Please pull DT updates for 4.18. Details below.
Rob
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
tags/devicetree-for-4.18
for you to fetch changes up to 44acf10587907ff77c28fd97906220b2d8eb4f05:
dt-bindings: submitting-patches: add guidance on patch content and
subject (2018-06-05 16:37:47 -0600)
DeviceTree updates for v4.18:
- Sync dtc with upstream version v1.4.6-21-g84e414b0b5bc. This adds new
warnings which are either fixed or disabled by default (enabled with
W=1).
- Validate an untrusted offset in DT overlay function
update_usages_of_a_phandle_reference
- Fix a use after free error of_platform_device_destroy
- Fix an off by 1 string errors in unittest
- Avoid creating a struct device for OPP nodes
- Update DT specific submitting-patches.txt with patch content and
subject requirements.
- Move some bindings to their proper subsystem locations
- Add vendor prefixes for Kaohsiung, SiFive, Avnet, Wi2Wi, Logic PD, and
ArcherMind
- Add documentation for "no-gpio-delays" property in FSI bus GPIO master
- Add compatible for r8a77990 SoC ravb ethernet block
- More wack-a-mole removal of 'status' property in examples
Benjamin Herrenschmidt (1):
dt-bindings: fsi-master-gpio: Document "no-gpio-delays" property
Frank Rowand (2):
MAINTAINERS: add keyword for devicetree overlay notifiers
of: overlay: validate offset from property fixups
Geert Uytterhoeven (3):
dt-bindings: meson-uart: DT fix s/clocks-names/clock-names/
dt-bindings: mvebu-uart: DT fix s/interrupts-names/interrupt-names/
dt-bindings: panel: lvds: Fix path to display timing bindings
H. Nikolaus Schaller (1):
dt-bindings: define vendor prefix for Wi2Wi, Inc.
Jacopo Mondi (3):
dt-bindings: net: ravb: Add support for r8a77965 SoC
dt-bindings: serial: sh-sci: Add support for r8a77965 (H)SCIF
dt-bindings: dmaengine: rcar-dmac: document R8A77965 support
Jan Kiszka (1):
of: overlay: Stop leaking resources on overlay removal
Lukasz Majewski (2):
doc: Add vendor prefix for Kieback & Peter GmbH
doc: Add vendor prefix for Kaohsiung
Manivannan Sadhasivam (1):
dt-bindings: Add vendor prefix for ArcherMind
Matheus Castello (1):
dt-bindings: pinctrl: sunxi: Fix reference to driver
Michal Simek (1):
dt-bindings: Add vendor prefix for Avnet, Inc.
Niklas Söderlund (1):
dt-bindings: thermal: rcar-gen3-thermal: update register size in example
Rob Herring (12):
of/numa: drop export of of_node_to_nid
dt-bindings: more status property removal from examples
dtc: checks: drop warning for missing PCI bridge bus-range
dt-bindings: move various timer bindings to timer/ directory
dt-bindings: move various RNG bindings to rng/ directory
dt-bindings: powerpc/4xx: move 4xx NDFC and EMAC bindings to
subsystem directories
dt-bindings: exynos: move ADC binding to iio/adc/ directory
Merge tag 'devicetree-fixes-for-4.17' into dt/next to pick-up fixes
scripts/dtc: Update to upstream version v1.4.6-21-g84e414b0b5bc
kbuild: disable new dtc graph and unit-address warnings
drm: rcar-du: disable dtc graph-endpoint warnings on DT overlays
dt-bindings: submitting-patches: add guidance on patch content and subject
Srinivas Kandagatla (1):
of: platform: stop accessing invalid dev in of_platform_device_destroy
Stefan M Schaeckeler (1):
of: unittest: for strings, account for trailing \0 in property
length field
Thierry Reding (1):
dt-bindings: Relocate Tegra20 memory controller bindings
Viresh Kumar (1):
of: Don't create device for OPP tables
Vladimir Zapolskiy (1):
dt-bindings: Add vendor prefix for Logic PD
Wesley W. Terpstra (1):
dt-bindings: Add "sifive" vendor prefix
Yoshihiro Shimoda (1):
dt-bindings: net: ravb: Add support for r8a77990 SoC
.../devicetree/bindings/arm/ux500/boards.txt | 2 +-
.../bindings/display/panel/panel-common.txt| 2 +-
Documentation/devicetree/bindings/dma/k3dma.txt| 1 -
.../devicetree/bindings/dma/renesas,rcar-dmac.txt | 1 +
Documentation/devicetree/bindings/dma/ti-edma.txt | 1 -
.../devicetree/bindings/fsi/fsi-master-gpio.txt| 4 +
.../adc/samsung,exynos-adc.txt}| 0
.../nvidia,tegra20-mc.txt | 0
.../devicetree/bindings/mips/lantiq/rcu.txt| 2 -
Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 4 -
.../{powerpc/4xx/ndfc.txt => mtd/ibm,ndfc.txt} | 0
Documentation/devicetree/bindings/mtd/mtk-nand.txt | 4 -
.../{powerpc/4xx/emac.txt => net/ibm,emac.txt} | 0
.../devicetree/bi
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown)
> wrote:
>
>
>
>> On 2018/6/7 1:01, Andy Lutomirski wrote:
>> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
>> wrote:
>>>
>>> I found that glibc has already dealt with this case. So this issue must
>>> have been met before, should it be maintained by libc/user?
>>>
>>>if (GLRO(dl_sysinfo_dso) == NULL)
>>>{
>>>kact.sa_flags |= SA_RESTORER;
>>>
>>>kact.sa_restorer = ((act->sa_flags & SA_SIGINFO)
>>>? &restore_rt : &restore);
>>>}
>>>
>>>
On 2018/6/6 15:52, Leizhen (ThunderTown) wrote:
> On 2018/6/5 19:24, Leizhen (ThunderTown) wrote:
> After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable vdso, the
> rt_sigaction01 test case from ltp_2015 failed.
> The test case source code please refer to the attachment, and the output
> as blow:
>
> -
> ./rt_sigaction01
> rt_sigaction010 TINFO : signal: 34
> rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
> rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
> rt_sigaction010 TINFO : Signal Handler Called with signal number 34
>
> Segmentation fault
> --
>
>
> Is this the desired result? In function ia32_setup_rt_frame, I found
> below code:
>
> if (ksig->ka.sa.sa_flags & SA_RESTORER)
> restorer = ksig->ka.sa.sa_restorer;
> else
> restorer = current->mm->context.vdso +
> vdso_image_32.sym___kernel_rt_sigreturn;
> put_user_ex(ptr_to_compat(restorer), &frame->pretcode);
>
> Because the vdso is disabled, so current->mm->context.vdso is NULL, which
> cause the result of frame->pretcode invalid.
>
> I'm not sure whether this is a kernel bug or just an error of test case
> itself. Can anyone help me?
>
>>>
>>>
>>
>> I can't tell from your email what you're testing, what behavior you
>> expect, and what you saw. A program that sets up a signal handler
>> without supplying a restorer will not work if the vDSO is off, and
>> this is by design.
> OK, so that the user should take care whether the vDSO is disabled by itself
> or not, and use different strategies to process it appropriately, like glibc.
>
>>
>> (FWIW, there is a very longstanding libc bug that causes this case to
>> get severely screwed up if the user's SS is not the expected value,
>> and that bug was just fixed very recently. But I doubt this is what
>> you're seeing.)
>>
>> I suppose we could improve the kernel to at least push NULL instead of
>> some random address a bit above 0, but it'll still crash.
> Should we add a warning? Which may help the user to aware this error in time.
>
It’s entirely valid to have a non working restorer if you never plan to return
from a signal handler. And anyone who writes their own libc should be able to
figure this out on their own, I think.
>>
>> .
>>
>
> --
> Thanks!
> BestRegards
>
Re: [PATCH v5 01/28] docs: fpga: add a document for FPGA Device Feature List (DFL) Framework Overview
On Wed, Jun 06, 2018 at 11:16:03AM -0500, Alan Tull wrote: > On Tue, May 1, 2018 at 9:50 PM, Wu Hao wrote: > > Hi Hao, > > I've acked the remaining patches with some changes requested. In your > v6, please add a patch to add yourself to the MAINTAINERS file or > whoever is planning on maintaining fpga/drivers/*dfl* Hi Alan, Sure, I will fix these in the next version. Thanks a lot for the review. Hao > > > Add a document for FPGA Device Feature List (DFL) Framework Overview. > > > > Signed-off-by: Enno Luebbers > > Signed-off-by: Xiao Guangrong > > Signed-off-by: Wu Hao > Acked-by: Alan Tull > > Thanks, > Alan
Re: [PATCH 26/32] afs: Use fs_context to pass parameters over automount [ver #8]
On 05/24/2018 07:08 PM, David Howells wrote:
> Alter the AFS automounting code to create and modify an fs_context struct
> when parameterising a new mount triggered by an AFS mountpoint rather than
> constructing device name and option strings.
>
> Also remove the cell=, vol= and rwpath options as they are then redundant.
> The reason they existed is because the 'device name' may be derived
> literally from a mountpoint object in the filesystem, so default cell and
> parent-type information needed to be passed in by some other method from
> the automount routines. The vol= option didn't end up being used.
>
> Signed-off-by: David Howells
> cc: Eric W. Biederman
> ---
>
> fs/afs/internal.h |1
> fs/afs/mntpt.c| 148
> +++--
> fs/afs/super.c| 43 +--
> 3 files changed, 79 insertions(+), 113 deletions(-)
>
> diff --git a/fs/afs/internal.h b/fs/afs/internal.h
> index eb6e75e00181..90af5001f8c8 100644
> --- a/fs/afs/internal.h
> +++ b/fs/afs/internal.h
> @@ -35,7 +35,6 @@ struct pagevec;
> struct afs_call;
>
> struct afs_fs_context {
> - boolrwpath; /* T if the parent should be
> considered R/W */
> boolforce; /* T to force cell type */
> boolautocell; /* T if set auto mount
> operation */
> booldyn_root; /* T if dynamic root */
> diff --git a/fs/afs/mntpt.c b/fs/afs/mntpt.c
> index c45aa1776591..fc383d727552 100644
> --- a/fs/afs/mntpt.c
> +++ b/fs/afs/mntpt.c
> @@ -47,6 +47,8 @@ static DECLARE_DELAYED_WORK(afs_mntpt_expiry_timer,
> afs_mntpt_expiry_timed_out);
>
> static unsigned long afs_mntpt_expiry_timeout = 10 * 60;
>
> +static const char afs_root_volume[] = "root.cell";
> +
> /*
> * no valid lookup procedure on this sort of dir
> */
> @@ -68,107 +70,107 @@ static int afs_mntpt_open(struct inode *inode, struct
> file *file)
> }
>
> /*
> - * create a vfsmount to be automounted
> + * Set the parameters for the proposed superblock.
> */
> -static struct vfsmount *afs_mntpt_do_automount(struct dentry *mntpt)
> +static int afs_mntpt_set_params(struct fs_context *fc, struct dentry *mntpt)
> {
> - struct afs_super_info *as;
> - struct vfsmount *mnt;
> - struct afs_vnode *vnode;
> - struct page *page;
> - char *devname, *options;
> - bool rwpath = false;
> + struct afs_fs_context *ctx = fc->fs_private;
> + struct afs_vnode *vnode = AFS_FS_I(d_inode(mntpt));
> + struct afs_cell *cell;
> + const char *p;
> int ret;
>
> - _enter("{%pd}", mntpt);
> -
> - BUG_ON(!d_inode(mntpt));
> -
> - ret = -ENOMEM;
> - devname = (char *) get_zeroed_page(GFP_KERNEL);
> - if (!devname)
> - goto error_no_devname;
> -
> - options = (char *) get_zeroed_page(GFP_KERNEL);
> - if (!options)
> - goto error_no_options;
> -
> - vnode = AFS_FS_I(d_inode(mntpt));
> if (test_bit(AFS_VNODE_PSEUDODIR, &vnode->flags)) {
> /* if the directory is a pseudo directory, use the d_name */
> - static const char afs_root_cell[] = ":root.cell.";
> unsigned size = mntpt->d_name.len;
>
> - ret = -ENOENT;
> - if (size < 2 || size > AFS_MAXCELLNAME)
> - goto error_no_page;
> + if (size < 2)
> + return -ENOENT;
>
> + p = mntpt->d_name.name;
> if (mntpt->d_name.name[0] == '.') {
> - devname[0] = '%';
> - memcpy(devname + 1, mntpt->d_name.name + 1, size - 1);
> - memcpy(devname + size, afs_root_cell,
> -sizeof(afs_root_cell));
> - rwpath = true;
> - } else {
> - devname[0] = '#';
> - memcpy(devname + 1, mntpt->d_name.name, size);
> - memcpy(devname + size + 1, afs_root_cell,
> -sizeof(afs_root_cell));
> + size--;
> + p++;
> + ctx->type = AFSVL_RWVOL;
> + ctx->force = true;
> + }
> + if (size > AFS_MAXCELLNAME)
> + return -ENAMETOOLONG;
> +
> + cell = afs_lookup_cell(ctx->net, p, size, NULL, false);
> + if (IS_ERR(cell)) {
> + pr_err("kAFS: unable to lookup cell '%pd'\n", mntpt);
> + return PTR_ERR(cell);
> }
> + afs_put_cell(ctx->net, ctx->cell);
> + ctx->cell = cell;
> +
> + ctx->volname = afs_root_volume;
> + ctx->volnamesz = sizeof(afs_root_volume) - 1;
> } else {
> /* read the contents of the AFS special symlink */
> + struct page *page;
> loff_t size = i_size_read(d_inode(mn
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 2018/6/7 1:01, Andy Lutomirski wrote:
> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
> wrote:
>>
>> I found that glibc has already dealt with this case. So this issue must have
>> been met before, should it be maintained by libc/user?
>>
>> if (GLRO(dl_sysinfo_dso) == NULL)
>> {
>> kact.sa_flags |= SA_RESTORER;
>>
>> kact.sa_restorer = ((act->sa_flags & SA_SIGINFO)
>> ? &restore_rt : &restore);
>> }
>>
>>
>> On 2018/6/6 15:52, Leizhen (ThunderTown) wrote:
>>>
>>>
>>> On 2018/6/5 19:24, Leizhen (ThunderTown) wrote:
After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable vdso, the
rt_sigaction01 test case from ltp_2015 failed.
The test case source code please refer to the attachment, and the output
as blow:
-
./rt_sigaction01
rt_sigaction010 TINFO : signal: 34
rt_sigaction011 TPASS : rt_sigaction call succeeded: result = 0
rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
rt_sigaction010 TINFO : Signal Handler Called with signal number 34
Segmentation fault
--
Is this the desired result? In function ia32_setup_rt_frame, I found below
code:
if (ksig->ka.sa.sa_flags & SA_RESTORER)
restorer = ksig->ka.sa.sa_restorer;
else
restorer = current->mm->context.vdso +
vdso_image_32.sym___kernel_rt_sigreturn;
put_user_ex(ptr_to_compat(restorer), &frame->pretcode);
Because the vdso is disabled, so current->mm->context.vdso is NULL, which
cause the result of frame->pretcode invalid.
I'm not sure whether this is a kernel bug or just an error of test case
itself. Can anyone help me?
>>>
>>
>>
>
> I can't tell from your email what you're testing, what behavior you
> expect, and what you saw. A program that sets up a signal handler
> without supplying a restorer will not work if the vDSO is off, and
> this is by design.
OK, so that the user should take care whether the vDSO is disabled by itself or
not, and use different strategies to process it appropriately, like glibc.
>
> (FWIW, there is a very longstanding libc bug that causes this case to
> get severely screwed up if the user's SS is not the expected value,
> and that bug was just fixed very recently. But I doubt this is what
> you're seeing.)
>
> I suppose we could improve the kernel to at least push NULL instead of
> some random address a bit above 0, but it'll still crash.
Should we add a warning? Which may help the user to aware this error in time.
>
> .
>
--
Thanks!
BestRegards
Re: [RFC 0/1] mconf: Emacs-like isearch
2018-06-07 8:54 GMT+09:00 Dirk Gouders : > Randy Dunlap writes: > >> On 06/06/2018 03:32 PM, Dirk Gouders wrote: >>> Randy Dunlap writes: >>> On 06/06/2018 02:56 PM, Dirk Gouders wrote: > Hello, > > being an Emacs user, I frequently find myself pressing CTRL-s in mconf > to search for some menu entry, especially in large menus. I use Emacs, but I have never typed Ctrl-s in menuconfig. Is it important to use the same key pattern as in Emacs? You intercepted Ctrl-* Currently, Ctrl-C terminates the program, but this patch makes it no-op. > I decided to implement a basic isearch in mconf and would like to hear > if others find this functionality useful, as well. > > The new functionality is started with pressing CTRL-s followed by > characters that form the search string. To search for further > occurences of an entered string, press CTRL-s instead of further > characters. > > For example: to navigate to the USB device drivers, press CTRL-s de ENTER > ENTER usb ENTER ENTER Not being an emacs user, what is the "de" for above? >>> >>> "de" (with my .config) causes a match for "Device Drivers" -- >>> no other menu entry matching the string "de" is befor that entry. >>> >> >> Device Drivers is the first match for me also. >> >> To get to the USB drivers, I have to enter: >> CTRL-s de ENTER ENTER CTRL-s usb ENTER ENTER > > Yes, I left out the second CTRL-s, thank you! > > Oh well, I shouldn't have sent this late at night, then I would probably > have explained the needed input as: > > 1) CTRL-s // start isearch > 2) de // substring that matches "Device Drivers" > 3) ENTER // quit isearch > 4) ENTER // enter Device Drivers menu > 5) CTRL-s // start isearch > 6) usb // navigate to USB support > 7) ENTER // quit isearch > 8) ENTER // enter USB support menu Hmm. I tried this, but I was a bit annoyed. I wonder if this could be more user-friendly. For example, I want KEY_UP/DOWN/LEFT/RIGHT to quit the search mode without pressing ENTER. > Again, I'm really sorry for the confusion. > > Dirk > -- > To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html You in -- Best Regards Masahiro Yamada
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
tools/testing/selftests/Makefile
between commit:
a12ab9e125f1 ("selftests: move RTC tests to rtc subfolder")
from Linus' tree and commit:
ccba8b64452b ("rseq/selftests: Provide Makefile, scripts, gitignore")
from the tip 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 tools/testing/selftests/Makefile
index 4cd339b5366a,593fb44c9cd4..
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@@ -29,7 -28,7 +29,8 @@@ TARGETS += powerp
TARGETS += proc
TARGETS += pstore
TARGETS += ptrace
+ TARGETS += rseq
+TARGETS += rtc
TARGETS += seccomp
TARGETS += sigaltstack
TARGETS += size
pgp1EdnUyas_k.pgp
Description: OpenPGP digital signature
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 2018/6/7 1:48, h...@zytor.com wrote:
> On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)"
> wrote:
>> I found that glibc has already dealt with this case. So this issue must
>> have been met before, should it be maintained by libc/user?
>>
>> if (GLRO(dl_sysinfo_dso) == NULL)
>> {
>> kact.sa_flags |= SA_RESTORER;
>>
>> kact.sa_restorer = ((act->sa_flags & SA_SIGINFO)
>> ? &restore_rt : &restore);
>> }
>>
>>
>> On 2018/6/6 15:52, Leizhen (ThunderTown) wrote:
>>>
>>>
>>> On 2018/6/5 19:24, Leizhen (ThunderTown) wrote:
After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable
>> vdso, the rt_sigaction01 test case from ltp_2015 failed.
The test case source code please refer to the attachment, and the
>> output as blow:
-
./rt_sigaction01
rt_sigaction010 TINFO : signal: 34
rt_sigaction011 TPASS : rt_sigaction call succeeded: result =
>> 0
rt_sigaction010 TINFO : sa.sa_flags = SA_RESETHAND|SA_SIGINFO
rt_sigaction010 TINFO : Signal Handler Called with signal
>> number 34
Segmentation fault
--
Is this the desired result? In function ia32_setup_rt_frame, I found
>> below code:
if (ksig->ka.sa.sa_flags & SA_RESTORER)
restorer = ksig->ka.sa.sa_restorer;
else
restorer = current->mm->context.vdso +
vdso_image_32.sym___kernel_rt_sigreturn;
put_user_ex(ptr_to_compat(restorer), &frame->pretcode);
Because the vdso is disabled, so current->mm->context.vdso is NULL,
>> which cause the result of frame->pretcode invalid.
I'm not sure whether this is a kernel bug or just an error of test
>> case itself. Can anyone help me?
>>>
>
> The use of signals without SA_RESTORER is considered obsolete, but it's
> somewhat surprising that the vdso isn't there; it should be mapped even for
> static binaries esp. on i386 since it is the preferred way to do system calls
> (you don't need to parse the ELF for that.) Are you explicitly disabling the
> VDSO? If so, Don't Do That.
Yes, the vdso was explicitly disabled by the tester. Thanks.
>
--
Thanks!
BestRegards
Re: [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
Rob Herring writes:
> On Sat, Jun 02, 2018 at 04:40:09PM +0800, Levin Du wrote:
>>
>> Rob Herring writes:
>>
>> > On Thu, May 31, 2018 at 9:05 PM, Levin wrote:
>> > > Hi Rob,
>> > >
>> > >
>> > > On 2018-05-31 10:45 PM, Rob Herring wrote:
>> > > >
>> > > > On Wed, May 30, 2018 at 10:27 PM, wrote:
>> > > > >
>> > > > > From: Levin Du
>> > > > >
>> > > > > In Rockchip RK3328, the output only GPIO_MUTE pin,
>> > > > > originally for codec
>> > > > > mute control, can also be used for general purpose. It is
>> > > > > manipulated by
>> > > > > the GRF_SOC_CON10 register.
>> > > > >
>> > > > > Signed-off-by: Levin Du
>> > > > >
>> > > > > ---
>> > > > >
>> > > > > Changes in v3:
>> > > > > - Change from general gpio-syscon to specific
>> > > > > rk3328-gpio-mute
>> > > > >
>> > > > > Changes in v2:
>> > > > > - Rename gpio_syscon10 to gpio_mute in doc
>> > > > >
>> > > > > Changes in v1:
>> > > > > - Refactured for general gpio-syscon usage for Rockchip SoCs.
>> > > > > - Add doc rockchip,gpio-syscon.txt
>> > > > >
>> > > > > .../bindings/gpio/rockchip,rk3328-gpio-mute.txt| 28
>> > > > > +++
>> > > > > drivers/gpio/gpio-syscon.c | 31
>> > > > > ++
>> > > > > 2 files changed, 59 insertions(+)
>> > > > > create mode 100644
>> > > > > Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>> > > > >
>> > > > > diff --git
>> > > > > a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>> > > > > b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>> > > > > new file mode 100644
>> > > > > index 000..10bc632
>> > > > > --- /dev/null
>> > > > > +++
>> > > > > b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>> > > > > @@ -0,0 +1,28 @@
>> > > > > +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE
>> > > > > pin.
>> > > > > +
>> > > > > +In Rockchip RK3328, the output only GPIO_MUTE pin,
>> > > > > originally for codec
>> > > > > mute
>> > > > > +control, can also be used for general purpose. It is
>> > > > > manipulated by the
>> > > > > +GRF_SOC_CON10 register.
>> > > > > +
>> > > > > +Required properties:
>> > > > > +- compatible: Should contain "rockchip,rk3328-gpio-mute".
>> > > > > +- gpio-controller: Marks the device node as a gpio
>> > > > > controller.
>> > > > > +- #gpio-cells: Should be 2. The first cell is the pin
>> > > > > number and
>> > > > > + the second cell is used to specify the gpio polarity:
>> > > > > +0 = Active high,
>> > > > > +1 = Active low.
>> > > > > +
>> > > > > +Example:
>> > > > > +
>> > > > > + grf: syscon@ff10 {
>> > > > > + compatible = "rockchip,rk3328-grf", "syscon",
>> > > > > "simple-mfd";
>> > > > > +
>> > > > > + gpio_mute: gpio-mute {
>> > > >
>> > > > Node names should be generic:
>> > > >
>> > > > gpio {
>> > > >
>> > > > This also means you can't add another GPIO node in the future
>> > > > and
>> > > > you'll have to live with "rockchip,rk3328-gpio-mute" covering
>> > > > more
>> > > > than 1 GPIO if you do need to add more GPIOs.
>> > >
>> > >
>> > > As the first line describes, this GPIO controller is dedicated for
>> > > the
>> > > GPIO_MUTE pin.
>> > > There's only one GPIO pin in the GRF_SOC_CON10 register. Therefore
>> > > the
>> > > gpio_mute
>> > > name is proper IMHO.
>> >
>> > It's how many GPIOs in the GRF, not this register. What I'm saying is
>> > when you come along later to add another GPIO in the GRF, you had
>> > better just add it to this same node. I'm not going to accept another
>> > GPIO controller node within the GRF. You have the cells to support
>> > more than 1, so it would only be a driver change. The compatible
>> > string would then not be ideally named at that point. But compatible
>> > strings are just unique identifiers, so it doesn't really matter what
>> > the string is.
>> >
>>
>> I'll try my best to introduce the situation here. The GRF, GPIO0~GPIO3
>> are register blocks in the RK3328 Soc. The GPIO0~GPIO3 contain registers
>> for GPIO operations like reading/writing data, setting direction,
>> interruption etc, which corresponds to the GPIO banks (gpio0~gpio3)
>> defined in rk3328.dtsi:
>
> I'm only talking about GRF functions, not "regular" GPIOs.
>
>> pinctrl: pinctrl {
>> compatible = "rockchip,rk3328-pinctrl";
>> rockchip,grf = <&grf>;
>> #address-cells = <2>;
>> #size-cells = <2>;
>> ranges;
>>
>> gpio0: gpio0@ff21 {
>> compatible = "rockchip,gpio-bank";
>> reg = <0x0 0xff21 0x0 0x100>;
>> interrupts = > IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&cru PCLK_GPIO0>;
>>
>> gpio-controller;
>> #gpio-cells = <2>;
>>
>> interrupt-controller;
>> #interrupt-ce
Re: [RFC 2/2] x86, tsc: Enable clock for ealry printk timestamp
Hi Pavel,
Thanks for the revew.
On Wed, Jun 06, 2018 at 11:25:22AM -0400, Pavel Tatashin wrote:
> Hi Feng,
>
> Using a global variable for this is not going to work, because you are adding
> a conditional branch and a load to a very hot path for the live of the
> system, not only for the duration of the boot.
Exactly. As I explained, I wanted to use the "__use_tsc" and
"__sched_clock_stable" without creating new gloabl variables, but
the problem is jump_label_init() can't be called that early,
so I used "tsc_inited" temply just to show tsc_init() could be call
early, and the printk timestamp could work much earlier.
Thanks,
Feng
>
> Pavel
>
> >
> > +int tsc_inited;
> > /*
> > * TSC can be unstable due to cpufreq or due to unsynced TSCs
> > */
> > @@ -192,7 +193,7 @@ static void set_cyc2ns_scale(unsigned long khz, int
> > cpu, unsigned long long tsc_
> > */
> > u64 native_sched_clock(void)
> > {
> > - if (static_branch_likely(&__use_tsc)) {
> > + if (static_branch_likely(&__use_tsc) || tsc_inited) {
> > u64 tsc_now = rdtsc();
> >
> > /* return the value in ns */
> > @@ -1387,30 +1391,16 @@ static int __init init_tsc_clocksource(void)
> > */
> > device_initcall(init_tsc_clocksource);
> >
> > -void __init tsc_early_delay_calibrate(void)
> > -{
> > - unsigned long lpj;
> > -
> > - if (!boot_cpu_has(X86_FEATURE_TSC))
> > - return;
> > -
> > - cpu_khz = x86_platform.calibrate_cpu();
> > - tsc_khz = x86_platform.calibrate_tsc();
> > -
> > - tsc_khz = tsc_khz ? : cpu_khz;
> > - if (!tsc_khz)
> > - return;
> > -
> > - lpj = tsc_khz * 1000;
> > - do_div(lpj, HZ);
> > - loops_per_jiffy = lpj;
> > -}
> > -
> > void __init tsc_init(void)
> > {
> > u64 lpj, cyc;
> > int cpu;
> >
> > + if (tsc_inited)
> > + return;
> > +
> > + tsc_inited = 1;
> > +
> > if (!boot_cpu_has(X86_FEATURE_TSC)) {
> > setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
> > return;
> > @@ -1474,11 +1464,15 @@ void __init tsc_init(void)
> > lpj = ((u64)tsc_khz * 1000);
> > do_div(lpj, HZ);
> > lpj_fine = lpj;
> > + loops_per_jiffy = lpj;
> >
> > use_tsc_delay();
> >
> > check_system_tsc_reliable();
> >
> > + extern void early_set_sched_clock_stable(u64 sched_clock_offset);
> > + early_set_sched_clock_stable(div64_u64(rdtsc() * 1000, tsc_khz));
> > +
> > if (unsynchronized_tsc()) {
> > mark_tsc_unstable("TSCs unsynchronized");
> > return;
> > diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
> > index 10c83e7..6c5c22d 100644
> > --- a/kernel/sched/clock.c
> > +++ b/kernel/sched/clock.c
> > @@ -119,6 +119,13 @@ static void __scd_stamp(struct sched_clock_data *scd)
> > scd->tick_raw = sched_clock();
> > }
> >
> > +
> > +void early_set_sched_clock_stable(u64 sched_clock_offset)
> > +{
> > + __sched_clock_offset = sched_clock_offset;
> > + static_branch_enable(&__sched_clock_stable);
> > +}
> > +
> > static void __set_sched_clock_stable(void)
> > {
> > struct sched_clock_data *scd;
> > @@ -342,12 +349,14 @@ static u64 sched_clock_remote(struct sched_clock_data
> > *scd)
> > *
> > * See cpu_clock().
> > */
> > +
> > +extern int tsc_inited;
> > u64 sched_clock_cpu(int cpu)
> > {
> > struct sched_clock_data *scd;
> > u64 clock;
> >
> > - if (sched_clock_stable())
> > + if (sched_clock_stable() || tsc_inited)
> > return sched_clock() + __sched_clock_offset;
> >
> > if (unlikely(!sched_clock_running))
> >
> >
> >
> >
> >>>
> >>> If you have a dodgy part (sorry SKX), you'll just have to live with
> >>> sched_clock starting late(r).
> >>>
> >>> Do not cobble things on the side, try and get the normal things running
> >>> earlier.
Hi
Am a United State Army here in Afghanistan, am seeking your help to evacuate the sum of $ 7,000,000 to you as long as I am assured it will be safe That in your care Until I complete my service here in Afghanistan. This is not stolen money and there are no dangers involved. I count on your understanding. Please get back for more information :. rob322...@gmail.com
Re: [PATCH v4 1/7] interconnect: Add generic on-chip interconnect API
On Wed, Jun 6, 2018 at 11:09 AM Georgi Djakov wrote:
>
> Hi Evan,
>
> On 06/06/2018 05:59 PM, Georgi Djakov wrote:
> >>> +
> >>> +/**
> >>> + * icc_node_create() - create a node
> >>> + * @id: node id
> >>> + *
> >>> + * Return: icc_node pointer on success, or ERR_PTR() on error
> >>> + */
> >>> +struct icc_node *icc_node_create(int id)
> >>> +{
> >>> + struct icc_node *node;
> >>> +
> >>> + /* check if node already exists */
> >>> + node = node_find(id);
> >>> + if (node)
> >>> + return node;
> >>
> >> This is probably going to do more harm than good once icc_node_delete comes
> >> in, since it almost certainly indicates a programmer error or ID collision,
> >> and will likely result in a double free. We should probably fail with
> >> EEXIST instead.
> >
> > In the current approach we create the nodes one by one, and the linked
> > nodes are created when they are referenced. The other way around would
> > be to create first all the nodes and then populate the links to avoid
> > the "chicken and egg" problem.
> >
>
> Just to elaborate a bit more on that: We can't actually register all the
> nodes in advance, as we might have multiple interconnect providers
> probing in different order. Each provider may have nodes linking to
> nodes belonging to other providers (not probed yet). That's why we
> create the nodes on the first reference and then, when the actual
> provider driver is probed, the rest of the node data is filled.
>
Ah ok, the extra explanation helped a lot. This makes sense to me. Thanks.
-Evan
Re: [PATCH v3 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
Hi Phil,
On Wed, Jun 06, 2018 at 10:03:59AM +0800, Phil Reid wrote:
> On 2/06/2018 09:28, Brian Norris wrote:
> > drivers/power/supply/sbs-battery.c | 54 +-
> > 1 file changed, 46 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/power/supply/sbs-battery.c
> > b/drivers/power/supply/sbs-battery.c
> > index 83d7b4115857..a9691ea42f44 100644
> > --- a/drivers/power/supply/sbs-battery.c
> > +++ b/drivers/power/supply/sbs-battery.c
...
> > @@ -806,6 +837,7 @@ static int sbs_probe(struct i2c_client *client,
> > if (!chip)
> > return -ENOMEM;
> > + chip->flags = (u32)(uintptr_t)of_device_get_match_data(&client->dev);
> > chip->client = client;
> > chip->enable_detection = false;
> > psy_cfg.of_node = client->dev.of_node;
> > @@ -915,12 +947,15 @@ static int sbs_suspend(struct device *dev)
> > if (chip->poll_time > 0)
> > cancel_delayed_work_sync(&chip->work);
> > - /*
> > -* Write to manufacturer access with sleep command.
> > -* Support is manufacturer dependend, so ignore errors.
> > -*/
> > - sbs_write_word_data(client, sbs_data[REG_MANUFACTURER_DATA].addr,
> > - MANUFACTURER_ACCESS_SLEEP);
> > + if (chip->flags & SBS_FLAGS_TI_BQ20Z75) {
> > + /*
> > +* Write to manufacturer access with sleep command.
> > +* Support is manufacturer dependent, so ignore errors.
> > +*/
> > + sbs_write_word_data(client,
> > + sbs_data[REG_MANUFACTURER_DATA].addr,
> > + MANUFACTURER_ACCESS_SLEEP);
> > + }
>
> Now that this is only being done for only TI devices that support this I
> would think the comment
> about ignoring errors needs to go, and errors checks added.
> Ditto in the new sbs_get_ti_battery_presence_and_health()
Seems reasonable. I'll look at doing that and respinning.
> > return 0;
> > }
Thanks,
Brian
Re: [PATCH v2 2/3] perf script python: Add more PMU fields
On 6/7/2018 2:36 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Jun 01, 2018 at 05:01:02PM +0800, Jin Yao escreveu:
+static int get_symoff(struct symbol *sym, struct addr_location *al,
+ bool print_off, char *bf, int size)
+{
+ unsigned long offset;
+
+ if (!sym || !sym->name)
+ return scnprintf(bf, size, "%s", "[unknown]");
5254.22 ubuntu:17.04 : FAIL gcc (Ubuntu
6.3.0-12ubuntu2) 6.3.0 20170406
CC /tmp/build/perf/util/scripting-engines/trace-event-python.o
util/scripting-engines/trace-event-python.c:534:20: error: address of array
'sym->name' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
if (!sym || !sym->name)
~~^~~~
1 error generated.
mv: cannot stat
'/tmp/build/perf/util/scripting-engines/.trace-event-python.o.tmp': No such
file or directory
/git/linux/tools/build/Makefile.build:96: recipe for target
'/tmp/build/perf/util/scripting-engines/trace-event-python.o' failed
make[5]: *** [/tmp/build/perf/util/scripting-engines/trace-event-python.o]
Error 1
Because:
struct symbol {
struct rb_node rb_node;
u64 start;
u64 end;
u16 namelen;
charname[0];
};
It sym->name is not a pointer, in symbol's constructor we have:
struct symbol *symbol__new(u64 start, u64 len, u8 binding, u8 type, const char
*name)
{
size_t namelen = strlen(name) + 1;
struct symbol *sym = calloc(1, (symbol_conf.priv_size +
sizeof(*sym) + namelen));
if (sym == NULL)
return NULL;
sym->namelen = namelen - 1;
memcpy(sym->name, name, namelen);
return sym;
}
So it is at least 1 char long, the test above should be:
if (!sym || !sym->name[0])
return scnprintf(bf, size, "%s", "[unknown]");
I'm fixing this up here.
- Arnaldo
Oh, yes, my mistake, very sorry about that.
Thanks for helping me to fix this.
Thanks
Jin Yao
[PATCH] staging: rtl8723bs: drop test
The test selects between two identical values, so it doesn't look useful.
It turns out that the tested expression can only be true anyway, so drop
the test, the corresponding parameter, and the corresponding argument at
the only call site.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression e,e1;
@@
* e ? e1 : e1
//
Signed-off-by: Julia Lawall
---
drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c
b/drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c
index 2ee25b2..53d3bdf 100644
--- a/drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c
+++ b/drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c
@@ -1352,7 +1352,6 @@ static void _PHY_ReloadMACRegisters8723B(
static void _PHY_PathADDAOn8723B(
struct adapter *padapter,
u32 *ADDAReg,
- bool isPathAOn,
bool is2T
)
{
@@ -1363,7 +1362,7 @@ static void _PHY_PathADDAOn8723B(
ODM_RT_TRACE(pDM_Odm, ODM_COMP_CALIBRATION, ODM_DBG_LOUD, ("ADDA
ON.\n"));
- pathOn = isPathAOn ? 0x01c00014 : 0x01c00014;
+ pathOn = 0x01c00014;
if (false == is2T) {
pathOn = 0x01c00014;
PHY_SetBBReg(pDM_Odm->Adapter, ADDAReg[0], bMaskDWord,
0x01c00014);
@@ -1556,7 +1555,7 @@ static void phy_IQCalibrate_8723B(
}
ODM_RT_TRACE(pDM_Odm, ODM_COMP_CALIBRATION, ODM_DBG_LOUD, ("IQ
Calibration for %s for %d times\n", (is2T ? "2T2R" : "1T1R"), t));
- _PHY_PathADDAOn8723B(padapter, ADDA_REG, true, is2T);
+ _PHY_PathADDAOn8723B(padapter, ADDA_REG, is2T);
/* no serial mode */
Re: [RFC 0/1] mconf: Emacs-like isearch
Randy Dunlap writes: > On 06/06/2018 03:32 PM, Dirk Gouders wrote: >> Randy Dunlap writes: >> >>> On 06/06/2018 02:56 PM, Dirk Gouders wrote: Hello, being an Emacs user, I frequently find myself pressing CTRL-s in mconf to search for some menu entry, especially in large menus. I decided to implement a basic isearch in mconf and would like to hear if others find this functionality useful, as well. The new functionality is started with pressing CTRL-s followed by characters that form the search string. To search for further occurences of an entered string, press CTRL-s instead of further characters. For example: to navigate to the USB device drivers, press CTRL-s de ENTER ENTER usb ENTER ENTER >>> >>> Not being an emacs user, what is the "de" for above? >> >> "de" (with my .config) causes a match for "Device Drivers" -- >> no other menu entry matching the string "de" is befor that entry. >> > > Device Drivers is the first match for me also. > > To get to the USB drivers, I have to enter: > CTRL-s de ENTER ENTER CTRL-s usb ENTER ENTER Yes, I left out the second CTRL-s, thank you! Oh well, I shouldn't have sent this late at night, then I would probably have explained the needed input as: 1) CTRL-s // start isearch 2) de // substring that matches "Device Drivers" 3) ENTER // quit isearch 4) ENTER // enter Device Drivers menu 5) CTRL-s // start isearch 6) usb // navigate to USB support 7) ENTER // quit isearch 8) ENTER // enter USB support menu Again, I'm really sorry for the confusion. Dirk
Re: [PATCH] slab: Clean up the code comment in slab kmem_cache struct
On Wed, 6 Jun 2018, Baoquan He wrote:
> I am back porting Thomas's sl[a|u]b freelist randomization feature to
> our distros, need go through slab code for better understanding. From
> git log history, they were 'obj_offset' and 'obj_size'. Later on
> 'obj_size' was renamed to 'object_size' in commit 3b0efdfa1e("mm, sl[aou]b:
> Extract common fields from struct kmem_cache") which is from your patch.
> With my understanding, I guess you changed that on purpose because
> object_size is size of each object, obj_offset is for the whole cache,
> representing the offset the real object starts to be stored. And putting
> them separately is for better desribing them in code comment and
> distinction, e.g 'object_size' is in "4) cache creation/removal",
> while 'obj_offset' is put alone to indicate it's for the whole.
obj_offset only applies when CONFIG_SLAB_DEBUG is set. Ok so that screwy
name also indicates that something special goes on.
Re: [PATCH v4 0/6] Enhance support for the SP805 WDT
Hi Florian, On 6/6/2018 12:29 PM, Florian Fainelli wrote: On 05/28/2018 11:01 AM, Ray Jui wrote: This patch series enhances the support for the SP805 watchdog timer. First of all, 'timeout-sec' devicetree property is added. In addition, support is also added to allow the driver to reset the watchdog if it has been detected that watchdot has been started in the bootloader. In this case, the driver will initiate the ping service from the kernel watchdog subsystem, before a user mode daemon takes over. This series also enables SP805 in the default ARM64 defconfig This patch series is based off v4.17-rc5 and is available on GIHUB: repo: https://github.com/Broadcom/arm64-linux.git branch: sp805-wdt-v4 Changes since v3: - Improve description of 'timeout-sec' in the binding document, per recommendation from Guenter Roeck Changes since v2: - Fix indent and format to make them consistent within arm,sp805.txt Changes since v1: - Consolidate two duplicated SP805 binding documents into one - Slight change of the wdt_is_running implementation per discussion Ray Jui (6): Documentation: DT: Consolidate SP805 binding docs Documentation: DT: Add optional 'timeout-sec' property for sp805 watchdog: sp805: add 'timeout-sec' DT property support watchdog: sp805: set WDOG_HW_RUNNING when appropriate arm64: dt: set initial SR watchdog timeout to 60 seconds arm64: defconfig: add CONFIG_ARM_SP805_WATCHDOG I can take the last two patches and Guenter would take the first 4 or would you want to proceed differently? It looks like we still need to figure out how to proceed based on discussions with Rob and Guenter on 1/6? Thanks, Ray
Re: [PATCH v4 1/6] Documentation: DT: Consolidate SP805 binding docs
On 6/6/2018 9:33 AM, Rob Herring wrote: On Wed, Jun 6, 2018 at 11:19 AM, Guenter Roeck wrote: On 06/05/2018 12:41 PM, Rob Herring wrote: On Mon, May 28, 2018 at 11:01:32AM -0700, Ray Jui wrote: Consolidate two SP805 binding documents "arm,sp805.txt" and "sp805-wdt.txt" into "arm,sp805.txt" that matches the naming of the desired compatible string to be used Signed-off-by: Ray Jui --- .../devicetree/bindings/watchdog/arm,sp805.txt | 27 ++- .../devicetree/bindings/watchdog/sp805-wdt.txt | 31 -- 2 files changed, 20 insertions(+), 38 deletions(-) delete mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt Would be good to get a ACK from FSL/NXP person on this. It looks to me like the driver fetches the wrong clock as it gets the first one and the driver really wants 'wdog_clk'. In any case, their dts files should be updated. This is really confusing, since he deleted file lists apb_pclk first. Does the watchdog driver need apb_pclk or wdog_clk ? That isn't clear to me. arch/arm64/boot/dts/hisilicon/hi3660.dtsi only provides apb_pclk, or at least it says so. Note that that clock source is 32KHz. That is obviously a mistake because no one clocks their bus/register interface at 32KHz. Someone just filled in something that happened to work. The fsl dts files all have apb_pclk first. It's all kind of a mess, but fortunately one we should be able to clean-up. It is indeed a mess. Note the SP805 driver only derive one clock from DT, and that's not done based on name. As a result, the first clock defined in DT will be fetched and the rate calculation will be carried out based on that clock rate. I assumed the clock entries and their names defined in the binding document are just placeholders, at least for the 2nd clock. Based on how the current driver is, the first clock needs to be the WDOGCLK for things to work properly. According to the SP805 TRM, APB clock is the PCLK, that drives the bus for register access. The relationship between WDOGCLK and PCLK is defined as: - the rising edges of WDOGCLK must be synchronous and balanced with a rising edge of PCLK - the WDOGCLK frequency cannot be greater than the PCLK frequency The compatible string changes too, but AMBA bus devices don't actually use the compatible string as they use the ID registers to match. I suppose some other OS could do things differently. Worth the risk to clean-up IMO. Either case, why are two clocks asked for in the first place ? Are there situations where the second clock is actually used/useful ? For clocks, the bus needs "apb_pclk" and the driver just gets the first clock. The driver is obviously going to want the functional clock that determines the counter rate. That should Primecell peripherals are about the only ones that have clear specs WRT clock inputs. Yet we've still managed to screw them up. There are 2 clocks in the spec, so the DT has (or should have) 2 clocks. Rob Let me know how you guys want to proceed with this? Thanks, Ray
Re: [RFC 0/1] mconf: Emacs-like isearch
On 06/06/2018 03:32 PM, Dirk Gouders wrote: > Randy Dunlap writes: > >> On 06/06/2018 02:56 PM, Dirk Gouders wrote: >>> Hello, >>> >>> being an Emacs user, I frequently find myself pressing CTRL-s in mconf >>> to search for some menu entry, especially in large menus. >>> >>> I decided to implement a basic isearch in mconf and would like to hear >>> if others find this functionality useful, as well. >>> >>> The new functionality is started with pressing CTRL-s followed by >>> characters that form the search string. To search for further >>> occurences of an entered string, press CTRL-s instead of further >>> characters. >>> >>> For example: to navigate to the USB device drivers, press CTRL-s de ENTER >>> ENTER usb ENTER ENTER >> >> Not being an emacs user, what is the "de" for above? > > "de" (with my .config) causes a match for "Device Drivers" -- > no other menu entry matching the string "de" is befor that entry. > Device Drivers is the first match for me also. To get to the USB drivers, I have to enter: CTRL-s de ENTER ENTER CTRL-s usb ENTER ENTER >> >>> Pressing just CTRL-s subsequently results in line-by-line navigation >>> through the menu (search for empty strings). >>> >>> The isearch is terminated by pressing either ESC ESC or ENTER. >>> >>> Because I expect that errors are found in the code and changes are >>> requested, I >>> completely left out the documentation part and will add it to V2 >>> should anyone find this functionality useful. >> >> Hm, it seems to take 2 entries of Ctrl-s to begin the search?? >> No, it takes 2 entries of Ctrl-s to display the "isearch:" prompt, >> but entering one Ctrl-s + a string will display it also. >> >> Anyway, I am having trouble getting the USB drivers example to work. > > Yes, I should have stated that this example explains what _I_ have to do to > navigate to the USB device drivers. Probably, "de" in your case matches > some other menu entry and the navigation requires more or other input. > > I'm sorry for causing confusion. No problem. Thanks. > Dirk > >>> Thanks, >>> >>> Dirk >>> >>> Dirk Gouders (1): >>> Emacs-like isearch for mconf. >>> >>> scripts/kconfig/lxdialog/dialog.h | 5 ++ >>> scripts/kconfig/lxdialog/menubox.c | 140 >>> - >>> scripts/kconfig/lxdialog/util.c| 1 + >>> 3 files changed, 145 insertions(+), 1 deletion(-) >>> >> >> thanks, -- ~Randy
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Mon, May 28, 2018 at 09:59:15AM -0400, Theodore Y. Ts'o wrote: > On Mon, May 28, 2018 at 11:46:38AM +1000, Tobin C. Harding wrote: > > > > During the versions of this set I have been totally confused about which > > patches go through which tree. This version again puts all 4 patches > > together in the hope they will go through Andrew's tree. > > I'm also happy to take the whole patch series through the random tree > if everyone else is OK with it. > > Thoughts? Looks like every one is happy (or silent) now Ted, can you please take this version through your tree. thanks, Tobin.
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Wed, Jun 06, 2018 at 03:02:20PM +0200, Thomas Gleixner wrote: > On Mon, 28 May 2018, Tobin C. Harding wrote: > > > Currently printing pointers early in the boot sequence can result in a > > dummy string '(ptrval)' being printed. While resolving this > > issue it was noticed that we can use the hw RNG if available for hashing > > pointers. > > > > Patch one and two do the ground work to be able to use hw RNG removing > > from get_random_bytes_arch() the call to get_random_bytes() and > > returning the number of bytes of random material successfully returned. > > > > Patch three uses the hw RNG to get keying material if it is available. > > > > Patch four further assists debugging early in the boot sequence for > > machines that do not have a hw RNG by adding a command line option > > 'debug_boot_weak_hash'. If enabled, non-cryptographically secure hashing > > is used instead of siphash so we can hash at any time. > > > > During the versions of this set I have been totally confused about which > > patches go through which tree. This version again puts all 4 patches > > together in the hope they will go through Andrew's tree. > > > > > > Steve, > > > > Could you please take a quick squiz at the final 2 patches if you get a > > chance. I assumed we are in preemptible context during early_init based > > on your code (and code comment) and called static_branch_disable() > > directly if hw RNG returned keying material. It's a pretty simple > > change but I'd love to get someone else to check I've not noob'ed it. > > early_initcalls() are not that early :) They run in thread context fully > preemtible so calling static_branch_disable() is perfectly fine. Thanks for the explanation. Tobin.
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Wed, Jun 06, 2018 at 03:08:25PM +0200, Anna-Maria Gleixner wrote: > On Tue, 5 Jun 2018, Anna-Maria Gleixner wrote: > > > On Thu, 31 May 2018, Steven Rostedt wrote: > > > > > On Mon, 28 May 2018 11:46:38 +1000 > > > "Tobin C. Harding" wrote: > > > > > > > Steve, > > > > > > Hi Tobin, > > > > > > Sorry for the late reply, I'm currently at a conference and have had > > > little time to read email. > > > > > > > > > > > Could you please take a quick squiz at the final 2 patches if you get a > > > > chance. I assumed we are in preemptible context during early_init based > > > > on your code (and code comment) and called static_branch_disable() > > > > directly if hw RNG returned keying material. It's a pretty simple > > > > change but I'd love to get someone else to check I've not noob'ed it. > > > > > > I can take a look, and perhaps do some tests. But it was Anna-Maria > > > that originally triggered the issue. She's on Cc, perhaps she can try > > > this and see if it works. > > > > I'll test it today - sorry for the delay. > > > > I tested it with command line option enabled. This works early enough > because it works right after early_trace_init(). Awesome, thanks Anna-Maria! Tobin
Re: [PATCH] ACPI LID: increment wakeup count only when notified.
On Thu, Jun 7, 2018 at 1:11 AM, Benson Leung wrote: > Hi Rafael, > > On Wed, Jun 06, 2018 at 09:00:43AM +0200, Rafael J. Wysocki wrote: >> > @@ -417,6 +414,7 @@ static void acpi_button_notify(struct acpi_device >> > *device, u32 event) >> > /* fall through */ >> > case ACPI_BUTTON_NOTIFY_STATUS: >> > input = button->input; >> > + acpi_pm_wakeup_event(&device->dev); >> >> Not really. >> >> There already is an acpi_pm_wakeup_event() call in the else branch below. >> > > Ravi removes that other call below. OK, I missed that, not sure why, sorry. > The intent for this is to call > acpi_pm_wakeup_event() regardless if the button->type is ACPI_BUTTON_TYPE_LID, > in case that event is ACPI_BUTTON_NOTIFY_STATUS. Well, the patch really drops the acpi_pm_wakeup_event() call from acpi_lid_notify_state() and so it has to ensure that this function will be called here for ACPI_BUTTON_NOTIFY_STATUS regardless of the button->type value. That's fine, but still the changelog doesn't make it clear why the acpi_pm_wakeup_event() call in acpi_lid_notify_state() is not necessary in general. Thanks, Rafael
Re: [PATCH 01/10] perf tools: Uniquify the event name if there's no other matched event
On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote: > Currently by default we try to match the user specified PMU > name to all PMU units available and use them to aggregate > all matched PMUs event counts into one 'pattern' event. > > While this is useful for uncore events, it screws up names > for other events, where this is not desirable, like: > > Before: > # perf stat -e cp/cpu-cycles/ kill I assume you mean cpU/cpu-cycles/ > >Performance counter stats for 'kill': > >1,573,757 cp/cpu-cycles/ > > Keeping the pattern matching logic, but making the name unique > in case there's no other match found. That fixes the example > above and hopefully does not screw up anything else. > > After: > # perf stat -e cp/cpu-cycles/ kill > >Performance counter stats for 'kill': > >1,573,757 cpu/cpu-cycles/ The output is 100% identical? -Andi
Re: [RFC 00/10] perf: Add cputime events/metrics
> I had some issues with IDLE counter being miscounted due to stopping > of the idle tick. I tried to solve it in this patch (it's part of the > patchset): > perf/cputime: Don't stop idle tick if there's live cputime event > > but I'm pretty sure it's wrong and there's better solution. At least on intel we already have hardware counters for different idle states. You just would need to add them and convert to the same unit. But of course it's still useful when this is not available. > My current plan is now to read those counters in perf top/record/report > to show (at least) the idle percentage for the current profile. It's useful. Thanks for working on it. I was thinking about doing something similar for some time. -Andi
[PATCH] uapi: Make generic uapi headers compile standalone.
In order for static analysis tools to analyze each of the uapi headers, we need to enable them to compile stand-alone. Some uapi headers were missing dependencies which would not make them compile stand-alone in user-land. This patch adds those dependencies. Test: make defconfig; make -j64 Test: make ARCH=arm64 defconfig; ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j64 all Test: ran header-abi-dumper[1] on all the affected headers with appropriate include paths[2] for arm64. eg: for drm_fourcc.h, $HEADER_ABI_DUMPER -o drm_fourcc.h.sdump \ include/uapi/drm/drm_fourcc.h -- -target aarch64-linux-android -std=gnu99 \ -isystem $CLANG_INCLUDE_PATH \ -I include/uapi/ -I arch/arm64/include/generated/uapi \ -I arch/arm64/include/uapi -I private-compiler-headers -I include/generated/uapi \ -I include/uapi/../../arch/arm/include/uapi where HEADER_ABI_DUMPER=\ $ANDROID_BUILD_TOP/prebuilts/clang-tools/linux-x86/bin/header-abi-dumper CLANG_INCLUDE_PATH=\ $ANDROID_BUILD_TOP/prebuilts/clang/host/linux-x86/clang-3289846/bin/../lib64/clang/3.8/include on a lunched aosp tree [3] [1] header-abi-dumper is a clang based static analysis tool, used by android's build system which parses a C/C++ source file and emits information about the data types included in the source. More information can be found at https://android.googlesource.com/platform/development/+/master/vndk/tools/header-checker/README.md [2] Some headers, eg: compiler_types.h, compiler.h, sys/socket.h are not in the set of uapi headers, even though they are included by uapi headers( include/uapi/linux/types.h, include/uapi/asm-generic/signal-defs.h etc). The 'private-compiler-headers' in the test clause was included with private copies of these headers. libc distributions (eg: bionic) often have their copies of these headers as well. [3] https://source.android.com/setup/build/downloading Cc: a...@linux-foundation.org Cc: kernel-t...@android.com Cc: linux-kbu...@vger.kernel.org Signed-off-by: Jayant Chowdhary --- include/uapi/asm-generic/ipcbuf.h | 2 ++ include/uapi/asm-generic/msgbuf.h | 3 +++ include/uapi/asm-generic/sembuf.h | 2 ++ include/uapi/asm-generic/shmbuf.h | 2 ++ include/uapi/asm-generic/ucontext.h| 5 + include/uapi/linux/agpgart.h | 1 - include/uapi/linux/android/binder.h| 1 + include/uapi/linux/chio.h | 6 ++ include/uapi/linux/coda_psdev.h| 1 + include/uapi/linux/dvb/dmx.h | 3 --- include/uapi/linux/dvb/video.h | 3 --- include/uapi/linux/errqueue.h | 1 + include/uapi/linux/kexec.h | 1 + include/uapi/linux/kfd_ioctl.h | 1 + include/uapi/linux/lightnvm.h | 1 - include/uapi/linux/ndctl.h | 1 + include/uapi/linux/netfilter_bridge/ebtables.h | 1 + include/uapi/linux/nfs4_mount.h| 3 +++ include/uapi/linux/psp-sev.h | 1 + include/uapi/linux/scc.h | 2 +- include/uapi/linux/sctp.h | 3 +++ include/uapi/linux/sdla.h | 2 ++ include/uapi/linux/socket.h| 4 include/uapi/linux/stddef.h| 5 + include/uapi/linux/sysctl.h| 1 + include/uapi/linux/types.h | 1 + include/uapi/linux/vbox_vmmdev_types.h | 1 + include/uapi/linux/vboxguest.h | 1 + include/uapi/rdma/hfi/hfi1_user.h | 1 + include/uapi/scsi/scsi_bsg_fc.h| 2 ++ include/uapi/scsi/scsi_netlink.h | 1 + include/uapi/sound/asound.h| 2 +- 32 files changed, 55 insertions(+), 10 deletions(-) diff --git a/include/uapi/asm-generic/ipcbuf.h b/include/uapi/asm-generic/ipcbuf.h index 7d80dbd336fb..41a01b494fc7 100644 --- a/include/uapi/asm-generic/ipcbuf.h +++ b/include/uapi/asm-generic/ipcbuf.h @@ -2,6 +2,8 @@ #ifndef __ASM_GENERIC_IPCBUF_H #define __ASM_GENERIC_IPCBUF_H +#include + /* * The generic ipc64_perm structure: * Note extra padding because this structure is passed back and forth diff --git a/include/uapi/asm-generic/msgbuf.h b/include/uapi/asm-generic/msgbuf.h index fb306ebdb36f..8cdd7ca75df6 100644 --- a/include/uapi/asm-generic/msgbuf.h +++ b/include/uapi/asm-generic/msgbuf.h @@ -3,6 +3,9 @@ #define __ASM_GENERIC_MSGBUF_H #include +#include +#include + /* * generic msqid64_ds structure. * diff --git a/include/uapi/asm-generic/sembuf.h b/include/uapi/asm-generic/sembuf.h index cbf9cfe977d6..7f37edb95d9f 100644 --- a/include/uapi/asm-generic/sembuf.h +++ b/include/uapi/asm-generic/sembuf.h @@ -3,6 +3,8 @@ #define __ASM_GENERIC_SEMBUF_H #include +#include +#include /* * The semid64_ds structure for x86 architecture. diff --git a/include/uapi/asm-generic/shmbuf.h b/include/uapi/asm-generic/shm
[PATCH] checkpatch: Add --fix for CONCATENATED_STRING and STRING_FRAGMENTS
Add the ability to --fix these string issues.
e.g.:
printk(KERN_INFO"bar" "baz"QUX);
converts to
printk(KERN_INFO "barbaz" QUX);
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3f936b046213..3b28306dc9d4 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5334,15 +5334,28 @@ sub process {
}
# concatenated string without spaces between elements
- if ($line =~ /$String[A-Z_]/ || $line =~ /[A-Za-z0-9_]$String/)
{
- CHK("CONCATENATED_STRING",
- "Concatenated strings should use spaces between
elements\n" . $herecurr);
+ if ($line =~ /$String[A-Za-z0-9_]/ || $line =~
/[A-Za-z0-9_]$String/) {
+ if (CHK("CONCATENATED_STRING",
+ "Concatenated strings should use spaces between
elements\n" . $herecurr) &&
+ $fix) {
+ while ($line =~ /($String)/g) {
+ my $extracted_string = substr($rawline,
$-[0], $+[0] - $-[0]);
+ $fixed[$fixlinenr] =~
s/\Q$extracted_string\E([A-Za-z0-9_])/$extracted_string $1/;
+ $fixed[$fixlinenr] =~
s/([A-Za-z0-9_])\Q$extracted_string\E/$1 $extracted_string/;
+ }
+ }
}
# uncoalesced string fragments
if ($line =~ /$String\s*"/) {
- WARN("STRING_FRAGMENTS",
-"Consecutive strings are generally better as a
single string\n" . $herecurr);
+ if (WARN("STRING_FRAGMENTS",
+"Consecutive strings are generally better as a
single string\n" . $herecurr) &&
+ $fix) {
+ while ($line =~ /($String)(?=\s*")/g) {
+ my $extracted_string = substr($rawline,
$-[0], $+[0] - $-[0]);
+ $fixed[$fixlinenr] =~
s/\Q$extracted_string\E\s*"/substr($extracted_string, 0, -1)/e;
+ }
+ }
}
# check for non-standard and hex prefixed decimal printf formats
Re: [PATCH] ACPI LID: increment wakeup count only when notified.
Hi Rafael,
On Wed, Jun 06, 2018 at 09:00:43AM +0200, Rafael J. Wysocki wrote:
> > @@ -417,6 +414,7 @@ static void acpi_button_notify(struct acpi_device
> > *device, u32 event)
> > /* fall through */
> > case ACPI_BUTTON_NOTIFY_STATUS:
> > input = button->input;
> > + acpi_pm_wakeup_event(&device->dev);
>
> Not really.
>
> There already is an acpi_pm_wakeup_event() call in the else branch below.
>
Ravi removes that other call below. The intent for this is to call
acpi_pm_wakeup_event() regardless if the button->type is ACPI_BUTTON_TYPE_LID,
in case that event is ACPI_BUTTON_NOTIFY_STATUS.
> > if (button->type == ACPI_BUTTON_TYPE_LID) {
> > mutex_lock(&button->input->mutex);
> > users = button->input->users;
> > @@ -426,7 +424,6 @@ static void acpi_button_notify(struct acpi_device
> > *device, u32 event)
> > } else {
> > int keycode;
> >
> > - acpi_pm_wakeup_event(&device->dev);
> > if (button->suspended)
> > break;
> >
> > --
Thanks!
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [RFC 1/1] Emacs-like isearch for mconf.
Segher Boessenkool writes: > On Wed, Jun 06, 2018 at 11:58:55PM +0200, Dirk Gouders wrote: >> @@ -332,6 +332,7 @@ int init_dialog(const char *backtitle) >> >> keypad(stdscr, TRUE); >> cbreak(); >> +raw(); /* Enable CTRL-sequences*/ > > Is that a good idea? You probably should mention it in the patch > description, either way. Thanks for commenting on that. I planned to explicitely mention it in 0/1 when I coded that function call but forgot it when I finally sent the mail. Dirk > > Segher
Re: [PATCH v2 8/8] x86/vdso: Move out the CPU number store
> On Wed, Jun 6, 2018 at 10:25 AM Andy Lutomirski wrote:
>> On Wed, Jun 6, 2018 at 9:23 AM Chang S. Bae wrote:
>> +static inline void setup_cpu_number_segment(int cpu)
>> +{
>> +#ifdef CONFIG_NUMA
>> + unsigned long node = early_cpu_to_node(cpu);
>> +#else
>> + unsigned long node = 0;
>> +#endif
> This duplicates half the rdtscp_aux code. How about making this one
> function setup_cpu_number() that does all of it?
Looks like the segment setup done during early boot (single-threaded).
So, separating MSR TSC_AUX setup out to each CPU initialization seems
to be still reasonable to me.
Thanks,
Chang
Re: [PATCH v6 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Hi, On Mon, Jun 4, 2018 at 12:15 PM, David Collins wrote: > Introduce bindings for RPMh regulator devices found on some > Qualcomm Technlogies, Inc. SoCs. These devices allow a given > processor within the SoC to make PMIC regulator requests which > are aggregated within the RPMh hardware block along with requests > from other processors in the SoC to determine the final PMIC > regulator hardware state. > > Signed-off-by: David Collins > Reviewed-by: Rob Herring > --- > .../bindings/regulator/qcom,rpmh-regulator.txt | 160 > + > .../dt-bindings/regulator/qcom,rpmh-regulator.h| 36 + > 2 files changed, 196 insertions(+) Reviewed-by: Douglas Anderson
Re: [PATCH v6 2/2] regulator: add QCOM RPMh regulator driver
Hi, On Mon, Jun 4, 2018 at 12:15 PM, David Collins wrote: > Add the QCOM RPMh regulator driver to manage PMIC regulators > which are controlled via RPMh on some Qualcomm Technologies, Inc. > SoCs. RPMh is a hardware block which contains several > accelerators which are used to manage various hardware resources > that are shared between the processors of the SoC. The final > hardware state of a regulator is determined within RPMh by > performing max aggregation of the requests made by all of the > processors. > > Add support for PMIC regulator control via the voltage regulator > manager (VRM) and oscillator buffer (XOB) RPMh accelerators. > VRM supports manipulation of enable state, voltage, and mode. > XOB supports manipulation of enable state. > > Signed-off-by: David Collins > --- > drivers/regulator/Kconfig | 9 + > drivers/regulator/Makefile | 1 + > drivers/regulator/qcom-rpmh-regulator.c | 767 > > 3 files changed, 777 insertions(+) Assuming Mark is OK with this, it looks good to me now. My previous feedback is resolved and I'm OK with the hardcoded current loads in the driver for now until we come up with something better. Reviewed-by: Douglas Anderson NOTE: Presumably this can't actually land anywhere :( until the RPMh patchset lands somewhere and that's still sitting in limbo waiting for Qualcomm to spin the patches. Presumably once RPMh lands someone will need to put it somewhere that can be pulled into the relevant trees so we don't need to wait for a whole merge window... -Doug
Re: [PATCH v2 7/8] x86/segments/32: Introduce CPU_NUMBER segment
On June 6, 2018 12:07:15 PM PDT, Brian Gerst wrote: >On Wed, Jun 6, 2018 at 1:16 PM, Andy Lutomirski >wrote: >> On Wed, Jun 6, 2018 at 9:23 AM Chang S. Bae > wrote: >>> >>> The new entry will be equivalent to that of x86-64 which >>> stores CPU number. The entry is placed in segment 23 in GDT >>> by bumping down 23-28 by one, which are all kernel-internal >>> segments and so have no impact on user space. >>> >>> CPU_NUMBER segment will always be at '%ss (USER_DS) + 80' >>> for the default (flat, initial) user space %ss. >> >> No, it won't :( This is because, on Xen PV, user code very >frequently >> sees a different, Xen-supplied "flat" SS value. This is definitely >> true right now on 64-bit, and I'm reasonably confident it's also the >> case on 32-bit. >> >> As it stands, as far as I can tell, we don't have a "cpu number" >> segment on 32-bit kernels. I see no compelling reason to add one, >and >> we should definitely not add one as part of the FSGSBASE series. I >> think the right solution is to rename the 64-bit segment to >> "CPU_NUMBER" and then have the rearrangement of the initialization >> code as a followup patch. The goal is to make the patches >> individually reviewable. As it stands, this patch adds some #defines >> without making them work, which is extra confusing. >> >> Given how many times we screwed it up, I really want the patch that >> moves the initialization of the 64-bit CPU number to be obviously >> correct and to avoid changing the sematics of anything except the >> actual CPU number fields during boot. >> >> So NAK to this patch, at least as part of the FSGSBASE series. >> >> (My apologies -- a bunch of this is because I along with everyone >else >> misunderstood the existing code.) > >The sole purpose of this segment is for the getcpu() function in the >VDSO. No other userspace code can rely on its presence or location. > >-- >Brian Gerst Unfortunately that is not true in reality :( -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [RFC 1/1] Emacs-like isearch for mconf.
On Wed, Jun 06, 2018 at 11:58:55PM +0200, Dirk Gouders wrote: > @@ -332,6 +332,7 @@ int init_dialog(const char *backtitle) > > keypad(stdscr, TRUE); > cbreak(); > + raw(); /* Enable CTRL-sequences*/ Is that a good idea? You probably should mention it in the patch description, either way. Segher
RE: [PATCH] HV: Fix definition of struct hv_vp_assist_page.
+Allen
> -Original Message-
> From: Thomas Gleixner
> Sent: Wednesday, June 6, 2018 3:18 AM
> To: Tianyu Lan
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; mi...@redhat.com; h...@zytor.com;
> x...@kernel.org; vkuzn...@redhat.com; Alexander Grest
> ; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] HV: Fix definition of struct hv_vp_assist_page.
>
> On Mon, 21 May 2018, Tianyu Lan wrote:
>
> KY
I am looking at the published Hyper-V Top Level Functional Spec now; will get
back shortly.
>
> > The struct hv_vp_assist_page was defined incorrectly.
> > The "vtl_control" should be u64[3], "nested_enlightenments_control"
> > should be a u64 and there is 7 reserved bytes following
> "enlighten_vmentry".
> > This patch is to fix it.
> >
> > Signed-off-by: Lan Tianyu
> > ---
> > arch/x86/include/asm/hyperv-tlfs.h | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/hyperv-tlfs.h
> b/arch/x86/include/asm/hyperv-tlfs.h
> > index f7be6d03a310..fae0a5431cdd 100644
> > --- a/arch/x86/include/asm/hyperv-tlfs.h
> > +++ b/arch/x86/include/asm/hyperv-tlfs.h
> > @@ -496,10 +496,11 @@ struct hv_timer_message_payload {
> > /* Define virtual processor assist page structure. */
> > struct hv_vp_assist_page {
> > __u32 apic_assist;
> > - __u32 reserved;
> > - __u64 vtl_control[2];
> > - __u64 nested_enlightenments_control[2];
> > - __u32 enlighten_vmentry;
> > + __u32 reserved1;
> > + __u64 vtl_control[3];
> > + __u64 nested_enlightenments_control;
> > + __u8 enlighten_vmentry;
> > + __u8 reserved2[7];
> > __u64 current_nested_vmcs;
> > };
> >
> > --
> > 2.14.3
> >
Re: [RFC 0/1] mconf: Emacs-like isearch
Randy Dunlap writes: > On 06/06/2018 02:56 PM, Dirk Gouders wrote: >> Hello, >> >> being an Emacs user, I frequently find myself pressing CTRL-s in mconf >> to search for some menu entry, especially in large menus. >> >> I decided to implement a basic isearch in mconf and would like to hear >> if others find this functionality useful, as well. >> >> The new functionality is started with pressing CTRL-s followed by >> characters that form the search string. To search for further >> occurences of an entered string, press CTRL-s instead of further >> characters. >> >> For example: to navigate to the USB device drivers, press CTRL-s de ENTER >> ENTER usb ENTER ENTER > > Not being an emacs user, what is the "de" for above? "de" (with my .config) causes a match for "Device Drivers" -- no other menu entry matching the string "de" is befor that entry. > >> Pressing just CTRL-s subsequently results in line-by-line navigation >> through the menu (search for empty strings). >> >> The isearch is terminated by pressing either ESC ESC or ENTER. >> >> Because I expect that errors are found in the code and changes are >> requested, I >> completely left out the documentation part and will add it to V2 >> should anyone find this functionality useful. > > Hm, it seems to take 2 entries of Ctrl-s to begin the search?? > No, it takes 2 entries of Ctrl-s to display the "isearch:" prompt, > but entering one Ctrl-s + a string will display it also. > > Anyway, I am having trouble getting the USB drivers example to work. Yes, I should have stated that this example explains what _I_ have to do to navigate to the USB device drivers. Probably, "de" in your case matches some other menu entry and the navigation requires more or other input. I'm sorry for causing confusion. Dirk >> Thanks, >> >> Dirk >> >> Dirk Gouders (1): >> Emacs-like isearch for mconf. >> >> scripts/kconfig/lxdialog/dialog.h | 5 ++ >> scripts/kconfig/lxdialog/menubox.c | 140 >> - >> scripts/kconfig/lxdialog/util.c| 1 + >> 3 files changed, 145 insertions(+), 1 deletion(-) >> > > thanks,
Re: [PATCH 4.4 19/92] sctp: delay the authentication for the duplicated cookie-echo chunk
On Thu, 2018-05-24 at 11:37 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Xin Long
>
> [ Upstream commit 59d8d4434f429b4fa8a346fd889058bda427a837 ]
>
> Now sctp only delays the authentication for the normal cookie-echo
> chunk by setting chunk->auth_chunk in sctp_endpoint_bh_rcv(). But
> for the duplicated one with auth, in sctp_assoc_bh_rcv(), it does
> authentication first based on the old asoc, which will definitely
> fail due to the different auth info in the old asoc.
[...]
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -1000,9 +1000,10 @@ static void sctp_assoc_bh_rcv(struct wor
> struct sctp_endpoint *ep;
> struct sctp_chunk *chunk;
> struct sctp_inq *inqueue;
> - int state;
> sctp_subtype_t subtype;
> + int first_time = 1; /* is this the first time through the loop */
> int error = 0;
> + int state;
>
> /* The association should be held so we should be safe. */
> ep = asoc->ep;
> @@ -1013,6 +1014,30 @@ static void sctp_assoc_bh_rcv(struct wor
> state = asoc->state;
> subtype = SCTP_ST_CHUNK(chunk->chunk_hdr->type);
>
> + /* If the first chunk in the packet is AUTH, do special
> + * processing specified in Section 6.3 of SCTP-AUTH spec
> + */
> + if (first_time && subtype.chunk == SCTP_CID_AUTH) {
> + struct sctp_chunkhdr *next_hdr;
> +
> + next_hdr = sctp_inq_peek(inqueue);
> + if (!next_hdr)
> + goto normal;
> +
> + /* If the next chunk is COOKIE-ECHO, skip the AUTH
> + * chunk while saving a pointer to it so we can do
> + * Authentication later (during cookie-echo
> + * processing).
> + */
> + if (next_hdr->type == SCTP_CID_COOKIE_ECHO) {
> + chunk->auth_chunk = skb_clone(chunk->skb,
> + GFP_ATOMIC);
> + chunk->auth = 1;
Doesn't the first_time flag need to be cleared here (and before the
other continue statement in this loop)?
Ben.
> + continue;
> + }
> + }
> +
> +normal:
[...]
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
Re: [RFC 0/1] mconf: Emacs-like isearch
On 06/06/2018 02:56 PM, Dirk Gouders wrote: > Hello, > > being an Emacs user, I frequently find myself pressing CTRL-s in mconf > to search for some menu entry, especially in large menus. > > I decided to implement a basic isearch in mconf and would like to hear > if others find this functionality useful, as well. > > The new functionality is started with pressing CTRL-s followed by > characters that form the search string. To search for further > occurences of an entered string, press CTRL-s instead of further > characters. > > For example: to navigate to the USB device drivers, press CTRL-s de ENTER > ENTER usb ENTER ENTER Not being an emacs user, what is the "de" for above? > Pressing just CTRL-s subsequently results in line-by-line navigation > through the menu (search for empty strings). > > The isearch is terminated by pressing either ESC ESC or ENTER. > > Because I expect that errors are found in the code and changes are requested, > I > completely left out the documentation part and will add it to V2 > should anyone find this functionality useful. Hm, it seems to take 2 entries of Ctrl-s to begin the search?? No, it takes 2 entries of Ctrl-s to display the "isearch:" prompt, but entering one Ctrl-s + a string will display it also. Anyway, I am having trouble getting the USB drivers example to work. > Thanks, > > Dirk > > Dirk Gouders (1): > Emacs-like isearch for mconf. > > scripts/kconfig/lxdialog/dialog.h | 5 ++ > scripts/kconfig/lxdialog/menubox.c | 140 > - > scripts/kconfig/lxdialog/util.c| 1 + > 3 files changed, 145 insertions(+), 1 deletion(-) > thanks, -- ~Randy
[PATCH 03/10] perf stat: Add --interval-clear option
Adding --interval-clear option to clear the screen
before next interval.
Link: http://lkml.kernel.org/n/tip-8zobiwghr6t9f9a4o886c...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/Documentation/perf-stat.txt | 3 +++
tools/perf/builtin-stat.c | 11 +--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 5dfe102fb5b5..b10a90b6a718 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -178,6 +178,9 @@ Print count deltas for fixed number of times.
This option should be used together with "-I" option.
example: 'perf stat -I 1000 --interval-count 2 -e cycles -a'
+--interval-clear::
+Clear the screen before next interval.
+
--timeout msecs::
Stop the 'perf stat' session and print count deltas after N milliseconds
(minimum: 10 ms).
This option is not supported with the "-I" option.
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index fce46252f89c..067d8b5b2c83 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -65,6 +65,7 @@
#include "util/tool.h"
#include "util/string2.h"
#include "util/metricgroup.h"
+#include "util/top.h"
#include "asm/bug.h"
#include
@@ -173,6 +174,7 @@ static struct cpu_map *aggr_map;
static aggr_get_id_t aggr_get_id;
static boolappend_file;
static boolinterval_count;
+static boolinterval_clear;
static const char *output_name;
static int output_fd;
static int print_free_counters_hint;
@@ -1713,9 +1715,12 @@ static void print_interval(char *prefix, struct timespec
*ts)
FILE *output = stat_config.output;
static int num_print_interval;
+ if (interval_clear)
+ puts(CONSOLE_CLEAR);
+
sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec, csv_sep);
- if (num_print_interval == 0 && !csv_output) {
+ if ((num_print_interval == 0 && !csv_output) || interval_clear) {
switch (stat_config.aggr_mode) {
case AGGR_SOCKET:
fprintf(output, "# time socket cpus");
@@ -1747,7 +1752,7 @@ static void print_interval(char *prefix, struct timespec
*ts)
}
}
- if (num_print_interval == 0 && metric_only)
+ if ((num_print_interval == 0 && metric_only) || interval_clear)
print_metric_headers(" ", true);
if (++num_print_interval == 25)
num_print_interval = 0;
@@ -2066,6 +2071,8 @@ static const struct option stat_options[] = {
"(overhead is possible for values <= 100ms)"),
OPT_INTEGER(0, "interval-count", &stat_config.times,
"print counts for fixed number of times"),
+ OPT_BOOLEAN(0, "interval-clear", &interval_clear,
+ "clear screen in between new interval"),
OPT_UINTEGER(0, "timeout", &stat_config.timeout,
"stop workload and print counts after a timeout period in
ms (>= 10ms)"),
OPT_SET_UINT(0, "per-socket", &stat_config.aggr_mode,
--
2.13.6
[PATCH 09/10] perf/cputime: Don't stop idle tick if there's live cputime event
Disable stopping of the idle tick when having live cputime
event. When the tick is disabled, the idle counts are out
of date until next tick/update and perf cputime PMU provides
misleading counts.
Signed-off-by: Jiri Olsa
---
include/linux/perf_event.h | 1 +
kernel/events/cputime.c| 13 +
kernel/time/tick-sched.c | 4
3 files changed, 18 insertions(+)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index aa9eaab370be..ba61d2f9602a 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1407,4 +1407,5 @@ int perf_event_exit_cpu(unsigned int cpu);
#define perf_event_exit_cpuNULL
#endif
+bool has_cputime_event(int cpu);
#endif /* _LINUX_PERF_EVENT_H */
diff --git a/kernel/events/cputime.c b/kernel/events/cputime.c
index efad24543f13..32d3cde0047e 100644
--- a/kernel/events/cputime.c
+++ b/kernel/events/cputime.c
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
enum perf_cputime_id {
PERF_CPUTIME_USER,
@@ -16,6 +17,13 @@ enum perf_cputime_id {
PERF_CPUTIME_MAX,
};
+static DEFINE_PER_CPU(int, has_cputime);
+
+bool has_cputime_event(int cpu)
+{
+ return per_cpu(has_cputime, cpu) != 0;
+}
+
static enum cpu_usage_stat map[PERF_CPUTIME_MAX] = {
[PERF_CPUTIME_USER] = CPUTIME_USER,
[PERF_CPUTIME_NICE] = CPUTIME_NICE,
@@ -143,12 +151,17 @@ static int cputime_event_add(struct perf_event *event,
int flags)
if (flags & PERF_EF_START)
cputime_event_start(event, flags);
+ if (event->hw.config == PERF_CPUTIME_IDLE)
+ tick_nohz_idle_restart_tick();
+
+ this_cpu_inc(has_cputime);
return 0;
}
static void cputime_event_del(struct perf_event *event, int flags)
{
cputime_event_stop(event, PERF_EF_UPDATE);
+ this_cpu_dec(has_cputime);
}
static void perf_cputime_read(struct perf_event *event)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index da9455a6b42b..1c105bc2a92e 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
@@ -912,6 +913,9 @@ static bool can_stop_idle_tick(int cpu, struct tick_sched
*ts)
return false;
}
+ if (has_cputime_event(cpu))
+ return false;
+
return true;
}
--
2.13.6
[PATCH 05/10] perf stat: Fix metric column display
Make the metric only display aligned.
Before:
# perf stat --topdown -I 1000
# time core cpus retiring bad speculation
frontend bound backend bound
1.000394323 S0-C0 2 37.4% 12.0%
31.4% 19.2%
1.000394323 S0-C1 2 25.1%9.2%
43.8% 21.9%
2.001521204 S0-C0 2 36.4% 11.4%
32.4% 19.8%
2.001521204 S0-C1 2 26.2%9.4%
43.1% 21.3%
3.001930208 S0-C0 2 35.1% 10.7%
33.6% 20.6%
3.001930208 S0-C1 2 28.9% 10.0%
40.0% 21.1%
After:
# perf stat --topdown -I 1000
# time core cpus retiring bad speculation
frontend boundbackend bound
1.000303722 S0-C0 234.2% 7.6%
34.2%24.0%
1.000303722 S0-C1 233.1% 6.4%
36.9%23.6%
2.001281055 S0-C0 234.6% 6.7%
36.8%21.8%
2.001281055 S0-C1 232.8% 7.1%
38.1%22.0%
3.001546080 S0-C0 239.3% 5.5%
32.7%22.5%
3.001546080 S0-C1 237.8% 6.0%
33.1%23.1%
Link: http://lkml.kernel.org/n/tip-w26176oxgjojrub2z3hyt...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-stat.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 0b1ddd5ef05d..4e7bae4c98d2 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1001,19 +1001,20 @@ static void print_metric_only(void *ctx, const char
*color, const char *fmt,
{
struct outstate *os = ctx;
FILE *out = os->fh;
- int n;
- char buf[1024];
+ char buf[1024], str[1024];
unsigned mlen = METRIC_ONLY_LEN;
if (!valid_only_metric(unit))
return;
unit = fixunit(buf, os->evsel, unit);
- n = color_fprintf(out, color ?: "", fmt, val);
- if (n > METRIC_ONLY_LEN)
- n = METRIC_ONLY_LEN;
if (mlen < strlen(unit))
mlen = strlen(unit) + 1;
- fprintf(out, "%*s", mlen - n, "");
+
+ if (color)
+ mlen += strlen(color) + sizeof(PERF_COLOR_RESET) - 1;
+
+ color_snprintf(str, sizeof(str), color ?: "", fmt, val);
+ fprintf(out, "%*s ", mlen, str);
}
static void print_metric_only_csv(void *ctx, const char *color __maybe_unused,
@@ -1053,7 +1054,7 @@ static void print_metric_header(void *ctx, const char
*color __maybe_unused,
if (csv_output)
fprintf(os->fh, "%s%s", unit, csv_sep);
else
- fprintf(os->fh, "%-*s ", METRIC_ONLY_LEN, unit);
+ fprintf(os->fh, "%*s ", METRIC_ONLY_LEN, unit);
}
static void nsec_printout(int id, int nr, struct perf_evsel *evsel, double avg)
@@ -1730,7 +1731,7 @@ static void print_interval(char *prefix, struct timespec
*ts)
fprintf(output, " counts %*s
events\n", unit_width, "unit");
break;
case AGGR_NONE:
- fprintf(output, "# time CPU");
+ fprintf(output, "# time CPU");
if (!metric_only)
fprintf(output, "counts %*s
events\n", unit_width, "unit");
break;
--
2.13.6
[PATCH 08/10] perf/cputime: Add cputime pmu
The CPUTIME_* counters account the time for CPU runtimes.
Adding 'cputime' PMU, that provides perf interface to those
counters.
The 'cputime' interface is standard software PMU, that provides
following events, meassuring their CPUTIME counterparts:
PERF_CPUTIME_USER - CPUTIME_USER
PERF_CPUTIME_NICE - CPUTIME_NICE
PERF_CPUTIME_SYSTEM - CPUTIME_SYSTEM
PERF_CPUTIME_SOFTIRQ- CPUTIME_SOFTIRQ
PERF_CPUTIME_IRQ- CPUTIME_IRQ
PERF_CPUTIME_IDLE - CPUTIME_IDLE
PERF_CPUTIME_IOWAIT - CPUTIME_IOWAIT
PERF_CPUTIME_STEAL - CPUTIME_STEAL
PERF_CPUTIME_GUEST - CPUTIME_GUEST
PERF_CPUTIME_GUEST_NICE - CPUTIME_GUEST_NICE
The 'cputime' PMU adds 'events' and 'format' directory,
with above events specifics.
It can be used via perf tool like:
# perf stat -e cputime/system/,cputime/user/ yes > /dev/null
^Cyes: Interrupt
Performance counter stats for 'yes':
2,177,550,368 ns cputime/system/
567,029,895 ns cputime/user/
2.749451438 seconds time elapsed
0.567127000 seconds user
2.177924000 seconds sys
Signed-off-by: Jiri Olsa
---
include/linux/perf_event.h | 2 +
kernel/events/Makefile | 2 +-
kernel/events/core.c | 1 +
kernel/events/cputime.c| 198 +
4 files changed, 202 insertions(+), 1 deletion(-)
create mode 100644 kernel/events/cputime.c
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index bea0b0cd4bf7..aa9eaab370be 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1160,6 +1160,8 @@ static inline int perf_callchain_store(struct
perf_callchain_entry_ctx *ctx, u64
}
}
+extern int __init perf_cputime_register(void);
+
extern int sysctl_perf_event_paranoid;
extern int sysctl_perf_event_mlock;
extern int sysctl_perf_event_sample_rate;
diff --git a/kernel/events/Makefile b/kernel/events/Makefile
index 3c022e33c109..02271b8433a7 100644
--- a/kernel/events/Makefile
+++ b/kernel/events/Makefile
@@ -3,7 +3,7 @@ ifdef CONFIG_FUNCTION_TRACER
CFLAGS_REMOVE_core.o = $(CC_FLAGS_FTRACE)
endif
-obj-y := core.o ring_buffer.o callchain.o
+obj-y := core.o ring_buffer.o callchain.o cputime.o
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
obj-$(CONFIG_UPROBES) += uprobes.o
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 08f5e1b42b43..27a8459ce576 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11678,6 +11678,7 @@ void __init perf_event_init(void)
perf_pmu_register(&perf_cpu_clock, NULL, -1);
perf_pmu_register(&perf_task_clock, NULL, -1);
perf_tp_register();
+ perf_cputime_register();
perf_event_init_cpu(smp_processor_id());
register_reboot_notifier(&perf_reboot_notifier);
diff --git a/kernel/events/cputime.c b/kernel/events/cputime.c
new file mode 100644
index ..efad24543f13
--- /dev/null
+++ b/kernel/events/cputime.c
@@ -0,0 +1,198 @@
+#include
+#include
+#include
+
+enum perf_cputime_id {
+ PERF_CPUTIME_USER,
+ PERF_CPUTIME_NICE,
+ PERF_CPUTIME_SYSTEM,
+ PERF_CPUTIME_SOFTIRQ,
+ PERF_CPUTIME_IRQ,
+ PERF_CPUTIME_IDLE,
+ PERF_CPUTIME_IOWAIT,
+ PERF_CPUTIME_STEAL,
+ PERF_CPUTIME_GUEST,
+ PERF_CPUTIME_GUEST_NICE,
+ PERF_CPUTIME_MAX,
+};
+
+static enum cpu_usage_stat map[PERF_CPUTIME_MAX] = {
+ [PERF_CPUTIME_USER] = CPUTIME_USER,
+ [PERF_CPUTIME_NICE] = CPUTIME_NICE,
+ [PERF_CPUTIME_SYSTEM] = CPUTIME_SYSTEM,
+ [PERF_CPUTIME_SOFTIRQ] = CPUTIME_SOFTIRQ,
+ [PERF_CPUTIME_IRQ] = CPUTIME_IRQ,
+ [PERF_CPUTIME_IDLE] = CPUTIME_IDLE,
+ [PERF_CPUTIME_IOWAIT] = CPUTIME_IOWAIT,
+ [PERF_CPUTIME_STEAL]= CPUTIME_STEAL,
+ [PERF_CPUTIME_GUEST]= CPUTIME_GUEST,
+ [PERF_CPUTIME_GUEST_NICE] = CPUTIME_GUEST_NICE,
+};
+
+PMU_FORMAT_ATTR(event, "config:0-63");
+
+static struct attribute *cputime_format_attrs[] = {
+ &format_attr_event.attr,
+ NULL,
+};
+
+static struct attribute_group cputime_format_attr_group = {
+ .name = "format",
+ .attrs = cputime_format_attrs,
+};
+
+static ssize_t
+cputime_event_attr_show(struct device *dev, struct device_attribute *attr,
+ char *page)
+{
+ struct perf_pmu_events_attr *pmu_attr =
+ container_of(attr, struct perf_pmu_events_attr, attr);
+
+ return sprintf(page, "event=%llu\n", pmu_attr->id);
+}
+
+#define __A(__n, __e) \
+ PMU_EVENT_ATTR(__n, cputime_attr_##__n, \
+ __e, cputime_event_attr_show); \
+ PMU_EVENT_ATTR_STRING(__n.unit, \
+ cputime_attr_##__n##_unit, "ns");
+
+__A(user, PERF_CPUTIME_USER)
+__A(nice, PERF_CPUTIME_NICE)
+__A(system,PERF_CPUTIME_SY
[PATCH 06/10] perf stat: Allow to specify specific metric column len
Following change will introduce new metrics, that don't need
such wide hard coded spacing. Switching METRIC_ONLY_LEN macro
usage with metric_only_len variable.
Link: http://lkml.kernel.org/n/tip-bh0ke4fh2ygpj3yowna7o...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-stat.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 4e7bae4c98d2..a8f93885763a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -145,6 +145,8 @@ static struct target target = {
typedef int (*aggr_get_id_t)(struct cpu_map *m, int cpu);
+#define METRIC_ONLY_LEN 20
+
static int run_count = 1;
static boolno_inherit = false;
static volatile pid_t child_pid = -1;
@@ -182,6 +184,7 @@ static int print_mixed_hw_group_error;
static u64 *walltime_run;
static boolru_display = false;
static struct rusage ru_data;
+static unsigned intmetric_only_len =
METRIC_ONLY_LEN;
struct perf_stat {
bool record;
@@ -969,8 +972,6 @@ static void print_metric_csv(void *ctx,
fprintf(out, "%s%s%s%s", csv_sep, vals, csv_sep, unit);
}
-#define METRIC_ONLY_LEN 20
-
/* Filter out some columns that don't work well in metrics only mode */
static bool valid_only_metric(const char *unit)
@@ -1002,7 +1003,7 @@ static void print_metric_only(void *ctx, const char
*color, const char *fmt,
struct outstate *os = ctx;
FILE *out = os->fh;
char buf[1024], str[1024];
- unsigned mlen = METRIC_ONLY_LEN;
+ unsigned mlen = metric_only_len;
if (!valid_only_metric(unit))
return;
@@ -1054,7 +1055,7 @@ static void print_metric_header(void *ctx, const char
*color __maybe_unused,
if (csv_output)
fprintf(os->fh, "%s%s", unit, csv_sep);
else
- fprintf(os->fh, "%*s ", METRIC_ONLY_LEN, unit);
+ fprintf(os->fh, "%*s ", metric_only_len, unit);
}
static void nsec_printout(int id, int nr, struct perf_evsel *evsel, double avg)
--
2.13.6
[PATCH 04/10] perf stat: Use only color_fprintf call in print_metric_only
We can call color_fprintf also for non color case, it's handled properly. This change simplifies following patch. Link: http://lkml.kernel.org/n/tip-496k3c59ckl2z7yrhnv6l...@git.kernel.org Signed-off-by: Jiri Olsa --- tools/perf/builtin-stat.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c index 067d8b5b2c83..0b1ddd5ef05d 100644 --- a/tools/perf/builtin-stat.c +++ b/tools/perf/builtin-stat.c @@ -1008,10 +1008,7 @@ static void print_metric_only(void *ctx, const char *color, const char *fmt, if (!valid_only_metric(unit)) return; unit = fixunit(buf, os->evsel, unit); - if (color) - n = color_fprintf(out, color, fmt, val); - else - n = fprintf(out, fmt, val); + n = color_fprintf(out, color ?: "", fmt, val); if (n > METRIC_ONLY_LEN) n = METRIC_ONLY_LEN; if (mlen < strlen(unit)) -- 2.13.6
[PATCH 07/10] perf stat: Add event parsing error handling to add_default_attributes
Adding missing error handling for parse_events calls
in add_default_attributes functions. The error handler
displays error details, like for transactions (-T):
Before:
$ perf stat -T
Cannot set up transaction events
After:
$ perf stat -T
Cannot set up transaction events
event syntax error:
'..cycles,cpu/cycles-t/,cpu/tx-start/,cpu/el-start/,cpu/cycles-ct/}'
\___ unknown term
Link: http://lkml.kernel.org/n/tip-hmctifkfiaij47xb9en1h...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-stat.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index a8f93885763a..cc3dd85d5a60 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -2451,14 +2451,13 @@ static int add_default_attributes(void)
(PERF_COUNT_HW_CACHE_OP_PREFETCH<< 8) |
(PERF_COUNT_HW_CACHE_RESULT_MISS<< 16)
},
};
+ struct parse_events_error errinfo;
/* Set attrs if no event is selected and !null_run: */
if (null_run)
return 0;
if (transaction_run) {
- struct parse_events_error errinfo;
-
if (pmu_have_event("cpu", "cycles-ct") &&
pmu_have_event("cpu", "el-start"))
err = parse_events(evsel_list, transaction_attrs,
@@ -2469,6 +2468,7 @@ static int add_default_attributes(void)
&errinfo);
if (err) {
fprintf(stderr, "Cannot set up transaction events\n");
+ parse_events_print_error(&errinfo, transaction_attrs);
return -1;
}
return 0;
@@ -2494,10 +2494,11 @@ static int add_default_attributes(void)
pmu_have_event("msr", "smi")) {
if (!force_metric_only)
metric_only = true;
- err = parse_events(evsel_list, smi_cost_attrs, NULL);
+ err = parse_events(evsel_list, smi_cost_attrs,
&errinfo);
} else {
fprintf(stderr, "To measure SMI cost, it needs "
"msr/aperf/, msr/smi/ and cpu/cycles/
support\n");
+ parse_events_print_error(&errinfo, smi_cost_attrs);
return -1;
}
if (err) {
@@ -2532,12 +2533,13 @@ static int add_default_attributes(void)
if (topdown_attrs[0] && str) {
if (warn)
arch_topdown_group_warn();
- err = parse_events(evsel_list, str, NULL);
+ err = parse_events(evsel_list, str, &errinfo);
if (err) {
fprintf(stderr,
"Cannot set up top down events %s:
%d\n",
str, err);
free(str);
+ parse_events_print_error(&errinfo, str);
return -1;
}
} else {
--
2.13.6
[PATCH 10/10] perf stat: Add cputime metric support
Adding --top/--top-full options to provide metrics based on the cputime PMU events. Simply all the metrics are simple ratios of events to STAT_NSECS time to get their % value. The --top option provides basic subset of cputime metrics: # perf stat --top -I 1000 # time Idle System UserIrqSoftirqIO wait 1.001692690 100.0% 0.0% 0.0% 0.7% 0.2% 0.0% 2.002994039 98.9% 0.0% 0.0% 0.9% 0.2% 0.0% 3.004164038 98.5% 0.2% 0.2% 0.9% 0.2% 0.0% 4.005312773 98.9% 0.0% 0.0% 0.9% 0.2% 0.0% The --top-full option provides all cputime metrics: # perf stat --top-full -I 1000 # time Idle System UserIrqSoftirqIO wait Guest Guest nice Nice Steal 1.001750803 100.0% 0.0% 0.0% 0.7% 0.2% 0.0% 0.0% 0.0% 0.0% 0.0% 2.003159490 99.0% 0.0% 0.0% 0.9% 0.2% 0.0% 0.0% 0.0% 0.0% 0.0% 3.004358366 99.0% 0.0% 0.0% 0.9% 0.2% 0.0% 0.0% 0.0% 0.0% 0.0% 4.005592436 98.9% 0.0% 0.0% 0.9% 0.2% 0.0% 0.0% 0.0% 0.0% 0.0% Link: http://lkml.kernel.org/n/tip-zue4s78pxc1cybb954t52...@git.kernel.org Signed-off-by: Jiri Olsa --- tools/perf/Documentation/perf-stat.txt | 65 +++ tools/perf/builtin-stat.c | 47 +++ tools/perf/util/stat-shadow.c | 70 ++ tools/perf/util/stat.c | 10 + tools/perf/util/stat.h | 10 + 5 files changed, 202 insertions(+) diff --git a/tools/perf/Documentation/perf-stat.txt b/tools/perf/Documentation/perf-stat.txt index b10a90b6a718..9330765b7225 100644 --- a/tools/perf/Documentation/perf-stat.txt +++ b/tools/perf/Documentation/perf-stat.txt @@ -310,6 +310,71 @@ The output is SMI cycles%, equals to (aperf - unhalted core cycles) / aperf Users who wants to get the actual value can apply --no-metric-only. +--top:: +--top-full: +Measure cputime PMU events and display percentage of CPU utilization rates. + +The --top option displays rates for following events: + idle system user irq softirq iowait + +The --top-full option displays additional rates: + guest guest_nice nice steal + +Examples: + # perf stat --top + ^C + Performance counter stats for 'system wide': + +Idle System UserIrqSoftirqIO wait +1.3% 89.5% 7.4% 1.8% 0.1% 0.0% + + 7.282332605 seconds time elapsed + + # perf stat --top-full + ^C + Performance counter stats for 'system wide': + +Idle System UserIrqSoftirqIO wait Guest Guest nice Nice Steal +5.4% 85.4% 8.6% 0.5% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% + + 7.618359683 seconds time elapsed + + # perf stat --top -I 1000 + # time Idle System UserIrqSoftirq IO wait + 1.000525839 5.4% 85.3% 8.8% 0.4% 0.1% 0.0% + 2.001032632 5.1% 85.7% 8.7% 0.4% 0.1% 0.0% + 3.001388414 5.2% 85.7% 8.6% 0.4% 0.1% 0.0% + 4.001758697 5.7% 85.2% 8.6% 0.5% 0.1% 0.0% + + # perf stat --top -I 1000 -A + # time CPU Idle System UserIrq SoftirqIO wait + 1.000485174 CPU0 6.9% 84.0% 8.6% 0.5% 0.1% 0.0% + 1.000485174 CPU1 5.5% 84.8% 9.1% 0.5% 0.1% 0.0% + 1.000485174 CPU2 5.5% 86.6% 7.4% 0.5% 0.1% 0.0% + ... + + # perf stat --top -I 1000 --per-core + # time core cpus Idle System User IrqSoftirqIO wait + 1.000450719 S0-C0 2 4.6% 87.0% 7.9% 0.4% 0.1% 0.0% + 1.000450719 S0-C1 2 4.8% 86.3% 8.3% 0.4% 0.1% 0.0% + 1.000450719 S0-C2 2 5.3% 86.3% 7.8% 0.4% 0.1% 0.0% + 1.000450719 S0-C3 2 5.2% 85.5% 8.7% 0.4% 0.1% 0.0% + 1.000450719 S0-C4 2 4.5% 86.7% 8.3% 0.4% 0.1% 0.0% + + # perf stat --top ./perf bench sched messaging -l 1 + ... + Total time: 7.089 [sec] + + Performance counter stats for './perf bench sched messaging -l 1': + +Idle System UserIrq
[PATCH 02/10] perf tools: Fix error index for pmu event parser
For events we provide specific error message we need to set
error column index, PMU parser is missing that, adding it.
Before:
$ perf stat -e cycles,krava/cycles/ kill
event syntax error: 'cycles,krava/cycles/'
\___ Cannot find PMU `krava'. Missing kernel support?
After:
$ perf stat -e cycles,krava/cycles/ kill
event syntax error: 'cycles,krava/cycles/'
\___ Cannot find PMU `krava'. Missing kernel
support?
Link: http://lkml.kernel.org/n/tip-mhlal798evb07oo3rxs8s...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/parse-events.y | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 155d2570274f..da8fe57691b8 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -227,11 +227,16 @@ event_def: event_pmu |
event_pmu:
PE_NAME opt_pmu_config
{
+ struct parse_events_state *parse_state = _parse_state;
+ struct parse_events_error *error = parse_state->error;
struct list_head *list, *orig_terms, *terms;
if (parse_events_copy_term_list($2, &orig_terms))
YYABORT;
+ if (error)
+ error->idx = @1.first_column;
+
ALLOC_LIST(list);
if (parse_events_add_pmu(_parse_state, list, $1, $2, false, false)) {
struct perf_pmu *pmu = NULL;
--
2.13.6
[RFC 00/10] perf: Add cputime events/metrics
hi, so.. I failed to make work reliably the exclude_idle bit for cpu-clock event using the idle's process sum_exec_runtime as Peter outlined in his patch [1]. The time jumped up and down and I couldn't make it stable. But I noticed we actually have IDLE stats (and many more) available for each CPU (enum cpu_usage_stat), we just can't reach them by perf yet. So this patchset adds 'cputime' perf software PMU, that provides CPUTIME_* stats via events that mirrors their names: # perf list | grep cputime cputime/guest/ [Kernel PMU event] cputime/guest_nice/[Kernel PMU event] cputime/idle/ [Kernel PMU event] cputime/iowait/[Kernel PMU event] cputime/irq/ [Kernel PMU event] cputime/nice/ [Kernel PMU event] cputime/softirq/ [Kernel PMU event] cputime/steal/ [Kernel PMU event] cputime/system/[Kernel PMU event] cputime/user/ [Kernel PMU event] I had some issues with IDLE counter being miscounted due to stopping of the idle tick. I tried to solve it in this patch (it's part of the patchset): perf/cputime: Don't stop idle tick if there's live cputime event but I'm pretty sure it's wrong and there's better solution. However most of the counts look ok so far and here's few of my favorite commands I've been playing with: # perf stat --top -I 1000 # time Idle System UserIrqSoftirqIO wait 1.001692690 100.0% 0.0% 0.0% 0.7% 0.2% 0.0% 2.002994039 98.9% 0.0% 0.0% 0.9% 0.2% 0.0% 3.004164038 98.5% 0.2% 0.2% 0.9% 0.2% 0.0% 4.005312773 98.9% 0.0% 0.0% 0.9% 0.2% 0.0% # perf stat --top-full -I 1000 # time Idle System UserIrqSoftirqIO wait Guest Guest nice Nice Steal 1.001750803 100.0% 0.0% 0.0% 0.7% 0.2% 0.0% 0.0% 0.0% 0.0% 0.0% 2.003159490 99.0% 0.0% 0.0% 0.9% 0.2% 0.0% 0.0% 0.0% 0.0% 0.0% 3.004358366 99.0% 0.0% 0.0% 0.9% 0.2% 0.0% 0.0% 0.0% 0.0% 0.0% 4.005592436 98.9% 0.0% 0.0% 0.9% 0.2% 0.0% 0.0% 0.0% 0.0% 0.0% # perf stat -e cpu-clock,cputime/system/,cputime/user/,cputime/idle/ -a sleep 10 Performance counter stats for 'system wide': 240070.828221 cpu-clock (msec) # 23.999 CPUs utilized 208,910,979,120 ns cputime/system/ # 87.0% System 20,589,603,359 ns cputime/user/ # 8.6% User 8,813,416,821 ns cputime/idle/ # 3.7% Idle 10.003261054 seconds time elapsed # perf stat -e cpu-clock,cputime/system/,cputime/user/ yes > /dev/null ^Cyes: Interrupt Performance counter stats for 'yes': 3483.824364 cpu-clock (msec) #1.000 CPUs utilized 2,460,117,205 ns cputime/system/ # 70.6% System 1,018,360,669 ns cputime/user/ # 29.2% User 3.484554149 seconds time elapsed 1.018525000 seconds user 2.460515000 seconds sys # perf stat --top -I 1000 --interval-clear # perf stat --top -I 1000 --interval-clear --per-core # perf stat --top -I 1000 --interval-clear --per-socket # perf stat --top -I 1000 --interval-clear -A It's also available in here: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git perf/fixes My current plan is now to read those counters in perf top/record/report to show (at least) the idle percentage for the current profile. thoughts? ;-) thanks, jirka [1] https://marc.info/?l=linux-kernel&m=152397251027433&w=2 --- Jiri Olsa (10): perf tools: Uniquify the event name if there's no other matched event perf tools: Fix error index for pmu event parser perf stat: Add --interval-clear option perf stat: Use only color_fprintf call in print_metric_only perf stat: Fix metric column display perf stat: Allow to specify specific metric column len perf stat: Add event parsing error handling to add_default_attributes perf/cputime: Add cputime pmu perf/cputime: Don't stop idle tick if there's live cputime event perf stat: Add cputime metric support include/linux/perf_event.h
[PATCH 01/10] perf tools: Uniquify the event name if there's no other matched event
Currently by default we try to match the user specified PMU
name to all PMU units available and use them to aggregate
all matched PMUs event counts into one 'pattern' event.
While this is useful for uncore events, it screws up names
for other events, where this is not desirable, like:
Before:
# perf stat -e cp/cpu-cycles/ kill
Performance counter stats for 'kill':
1,573,757 cp/cpu-cycles/
Keeping the pattern matching logic, but making the name unique
in case there's no other match found. That fixes the example
above and hopefully does not screw up anything else.
After:
# perf stat -e cp/cpu-cycles/ kill
Performance counter stats for 'kill':
1,573,757 cpu/cpu-cycles/
Cc: Andi Kleen
Cc: Kan Liang
Cc: Agustin Vega-Frias
Link: http://lkml.kernel.org/n/tip-lpb7bmaj3szgmemf53yg4...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-stat.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 096ccb25c11f..fce46252f89c 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1323,6 +1323,7 @@ static void collect_all_aliases(struct perf_evsel
*counter,
void *data)
{
struct perf_evsel *alias;
+ int cnt = 0;
alias = list_prepare_entry(counter, &(evsel_list->entries), node);
list_for_each_entry_continue (alias, &evsel_list->entries, node) {
@@ -1334,7 +1335,15 @@ static void collect_all_aliases(struct perf_evsel
*counter,
break;
alias->merged_stat = true;
cb(alias, data, false);
+ cnt++;
}
+
+ /*
+* There's no matching event to aggregate
+* counts with, fix the event name
+*/
+ if (!cnt)
+ uniquify_event_name(counter);
}
static bool collect_data(struct perf_evsel *counter,
--
2.13.6
[RFC 1/1] Emacs-like isearch for mconf.
---
scripts/kconfig/lxdialog/dialog.h | 5 ++
scripts/kconfig/lxdialog/menubox.c | 140 -
scripts/kconfig/lxdialog/util.c| 1 +
3 files changed, 145 insertions(+), 1 deletion(-)
diff --git a/scripts/kconfig/lxdialog/dialog.h
b/scripts/kconfig/lxdialog/dialog.h
index fcffd5b41fb0..6b40a0f06b87 100644
--- a/scripts/kconfig/lxdialog/dialog.h
+++ b/scripts/kconfig/lxdialog/dialog.h
@@ -56,6 +56,8 @@
#define TR(params) _tracef params
#define KEY_ESC 27
+#define KEY_CTRL_S 19
+#define KEY_ENTR 10
#define TAB 9
#define MAX_LEN 2048
#define BUF_SIZE (10*1024)
@@ -244,6 +246,9 @@ int dialog_checklist(const char *title, const char *prompt,
int height,
int width, int list_height);
int dialog_inputbox(const char *title, const char *prompt, int height,
int width, const char *init);
+int do_isearch(char *str, int choice, int scroll);
+void dialog_isearch(WINDOW *menu, WINDOW *dialog, int *choice, int max_choice,
+ int box_x, int box_y, int menu_height, int *scroll);
/*
* This is the base for fictitious keys, which activate
diff --git a/scripts/kconfig/lxdialog/menubox.c
b/scripts/kconfig/lxdialog/menubox.c
index 11ae9ad7ac7b..531fd7364dd3 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -56,8 +56,13 @@
* fscanf would read in 'scroll', and eventually that value would get used.
*/
+#include
#include "dialog.h"
+#define ISEARCH_LEN 32
+#define ISEARCH_INDICATOR_LEN (ISEARCH_LEN + 8)
+static char isearch_str[ISEARCH_LEN] = "";
+
static int menu_width, item_x;
/*
@@ -105,6 +110,32 @@ do {
\
do_print_item(menu, item_str(), choice, selected, !item_is_tag(':')); \
} while (0)
+
+/*
+* Print the isearch indicator.
+*/
+static void print_isearch(WINDOW * win, int y, int x, int height, bool isearch)
+{
+ unsigned char i = 0;
+
+ wmove(win, y, x);
+
+ y = y + height + 1;
+ wmove(win, y, x);
+
+ if (isearch) {
+ wattrset(win, dlg.button_key_inactive.atr);
+ waddstr(win, "isearch: ");
+ waddstr(win, isearch_str);
+ i = ISEARCH_INDICATOR_LEN - strlen(isearch_str);
+ }
+
+ wattrset(win, dlg.menubox_border.atr);
+
+ for ( ; i < ISEARCH_INDICATOR_LEN; i++ )
+ waddch(win, ACS_HLINE);
+}
+
/*
* Print the scroll indicators.
*/
@@ -178,6 +209,110 @@ static void do_scroll(WINDOW *win, int *scroll, int n)
wrefresh(win);
}
+/*
+ * Incremental search for text in dialog menu entries.
+ * The search operates as a ring search, continuing at the top after
+ * the last entry has been visited.
+ */
+int do_isearch(char *str, int choice, int scroll)
+{
+ int i;
+
+ for (i = 0; i < item_count(); i++) {
+ item_set((choice + scroll + i)%item_count());
+ if (strcasestr(item_str(), str))
+ break;
+ }
+
+ return (choice + scroll + i)%item_count();
+}
+
+/*
+ * Incremental search in dialog menu
+ *
+ * This function is executed after CTRL-S has been pressed and it
+ * navigates to and highlights menu entries that match the string
+ * formed by subsequently entered characters. To find further matches
+ * of an entered string, CTRL-S has to be entered instead of further
+ * characters.
+ *
+ * Subsequently pressing just CTRL-S keys results in searches for empty
+ * strings (any line matches) and thus results in navigating through
+ * the menu, line by line.
+ *
+ * Incremental search is terminated by pressing either ESC or ENTER.
+ */
+void dialog_isearch(WINDOW *menu, WINDOW *dialog, int *choice, int max_choice,
+ int box_x, int box_y, int menu_height, int *scroll)
+{
+ int i;
+ int key = KEY_CTRL_S;
+
+ while (key != KEY_ESC) {
+ key = wgetch(menu);
+
+ if ((key == KEY_ESC || key == KEY_ENTR)) {
+ isearch_str[0] = '\0';
+ print_isearch(dialog, box_y, box_x + item_x + 5,
menu_height, false);
+ print_arrows(dialog, item_count(), *scroll,
+box_y, box_x + item_x + 1, menu_height);
+ print_item(*scroll + *choice, *choice, true);
+ return;
+ }
+
+ if (key == KEY_CTRL_S) {
+ /* Remove highligt of current item */
+ print_item(*scroll + *choice, *choice, FALSE);
+ *choice += 1;
+ i = do_isearch(isearch_str, *choice, *scroll);
+ } else {
+ if ( key == KEY_BACKSPACE && isearch_str[0] ) {
+ isearch_str[i = (strlen(isearch_str) - 1)] =
'\0';
+ } else {
+ if ( isalnum(key) ||
[RFC 0/1] mconf: Emacs-like isearch
Hello, being an Emacs user, I frequently find myself pressing CTRL-s in mconf to search for some menu entry, especially in large menus. I decided to implement a basic isearch in mconf and would like to hear if others find this functionality useful, as well. The new functionality is started with pressing CTRL-s followed by characters that form the search string. To search for further occurences of an entered string, press CTRL-s instead of further characters. For example: to navigate to the USB device drivers, press CTRL-s de ENTER ENTER usb ENTER ENTER Pressing just CTRL-s subsequently results in line-by-line navigation through the menu (search for empty strings). The isearch is terminated by pressing either ESC ESC or ENTER. Because I expect that errors are found in the code and changes are requested, I completely left out the documentation part and will add it to V2 should anyone find this functionality useful. Thanks, Dirk Dirk Gouders (1): Emacs-like isearch for mconf. scripts/kconfig/lxdialog/dialog.h | 5 ++ scripts/kconfig/lxdialog/menubox.c | 140 - scripts/kconfig/lxdialog/util.c| 1 + 3 files changed, 145 insertions(+), 1 deletion(-) -- 2.16.4
Re: [PATCH v5 00/10] track CPU utilization
Hi all, sorry; I missed the beginning of this thread... Anyway, below I add some comments: On Wed, 6 Jun 2018 15:05:58 +0200 Claudio Scordino wrote: [...] > >> Ok, I see ... Have you guys already tried something like my patch > >> above (keeping the freq >= this_bw) in real world use cases ? Is > >> this costing that much energy in practice ? If we fill the gaps > >> left by DL (when it > > > > IIRC, Claudio (now Cc-ed) did experiment a bit with both > > approaches, so he might add some numbers to my words above. I > > didn't (yet). But, please consider that I might be reserving (for > > example) 50% of bandwidth for my heavy and time sensitive task and > > then have that task wake up only once in a while (but I'll be > > keeping clock speed up for the whole time). :/ > > As far as I can remember, we never tested energy consumption of > running_bw vs this_bw, as at OSPM'17 we had already decided to use > running_bw implementing GRUB-PA. The rationale is that, as Juri > pointed out, the amount of spare (i.e. reclaimable) bandwidth in > this_bw is very user-dependent. Yes, I agree with this. The appropriateness of using this_bw or running_bw is highly workload-dependent... If a periodic task consumes much less than its runtime (or if a sporadic task has inter-activation times much larger than the SCHED_DEADLINE period), then running_bw has to be preferred. But if a periodic task consumes almost all of its runtime before blocking, then this_bw has to be preferred... But this also depends on the hardware: if the frequency switch time is small, then running_bw is more appropriate... On the other hand, this_bw works much better if the frequency switch time is high. (Talking about this, I remember Claudio measured frequency switch times large almost 3ms... Is this really due to hardware issues? Or maybe there is some software issue invoved? 3ms look like a lot of time...) Anyway, this is why I proposed to use some kind of /sys/... file to control the kind of deadline utilization used for frequency scaling: in this way, the system designer / administrator, who hopefully has the needed information about workload and hardware, can optimize the frequency scaling behaviour by deciding if running_bw or this_bw will be used. Luca > For example, the user can let this_bw > be much higher than the measured bandwidth, just to be sure that the > deadlines are met even in corner cases. In practice, this means that > the task executes for quite a short time and then blocks (with its > bandwidth reclaimed, hence the CPU frequency reduced, at the 0lag > time). Using this_bw rather than running_bw, the CPU frequency would > remain at the same fixed value even when the task is blocked. I > understand that on some cases it could even be better (i.e. no waste > of energy in frequency switch). However, IMHO, these are corner cases > and in the average case it is better to rely on running_bw and reduce > the CPU frequency accordingly. > > Best regards, > > Claudio
[GIT PULL] Please pull RDMA subsystem changes
Hi Linus,
Here are the RDMA patches for 4.18.
No merge conflicts this time, and as of this writing netdev's pull request has
not been merged so the merge diffstat shows a number of ethernet related files
from the various shared pull requests in the two trees.
There are a few more merge commits in this history than has been typical in
the past. Instead of choosing the net or RDMA tree to get certain patches,
Mellanox is now providing a 'shared branch' which is intended to carry all
commits to drivers/net/ethernet/mellanox/mlx5/core and is used to merge those
patches into both the net and rdma trees. This is expected to reduce the merge
conflicts by ensuring both trees have all commits related to mlx5/core and
related, and no rdma or netdev commit is left only in the others tree.
The following changes since commit 55ba49cbcef37053d973f9a45bc58818c333fe13:
RDMA/hns: Move the location for initializing tmp_len (2018-05-23 15:45:44
-0600)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus
for you to fetch changes up to c1191a19fecad92b73c25770a7f47174280ca564:
RDMA/mlx5: Update SPDX tags to show proper license (2018-06-05 14:04:20 -0600)
4.18 Merge window pull request
This has been a quiet cycle for RDMA, the big bulk is the usual smallish
driver updates and bug fixes. About four new uAPI related things. Not as much
Szykaller patches this time, the bugs it finds are getting harder to fix.
- More work cleaning up the RDMA CM code
- Usual driver bug fixes and cleanups for qedr, qib, hfi1, hns, i40iw,
iw_cxgb4, mlx5, rxe
- Driver specific resource tracking and reporting via netlink
- Continued work for name space support from Parav
- MPLS support for the verbs flow steering uAPI
- A few tricky IPoIB fixes improving robustness
- HFI1 driver support for the '16B' management packet format
- Some auditing to not print kernel pointers via %llx or similar
- Mark the entire 'UCM' user-space interface as BROKEN with the intent to
remove it
entirely. The user space side of this was long ago replaced with RDMA-CM and
syzkaller is finding bugs in the residual UCM interface nobody wishes to fix
because
nobody uses it.
- Purge more bogus BUG_ON's from Leon
- 'flow counters' verbs uAPI
- T10 fixups for iser/isert, these are Acked by Martin but going through the
RDMA
tree due to dependencies
Alex Estrin (3):
IB/hfi1: Complete check for locally terminated smp
IB/{hfi1, qib}: Add handling of kernel restart
IB/isert: Fix for lib/dma_debug check_sync warning
Ariel Levkovich (7):
IB/uverbs: Expose GRE flow spec to the user-kernel ABI header
IB/uverbs: Introduce a GRE steering match filter
IB/uverbs: Expose MPLS flow spec to the user-kernel ABI header
IB/uverbs: Introduce a MPLS steering match filter
IB/mlx5: Add support for GRE flow specification
IB/mlx5: Add support for MPLS flow specification
IB/mlx5: Expose MPLS related tunneling offloads
Arnd Bergmann (1):
iw_cxgb4: add INFINIBAND_ADDR_TRANS dependency
Ben Hutchings (1):
IB: Fix RDMA_RXE and INFINIBAND_RDMAVT dependencies for DMA_VIRT_OPS
Brian Welty (1):
IB/{hfi1, qib, rdmavt}: Move logic to allocate receive WQE into rdmavt
Christophe JAILLET (3):
net/mlx5: Vport, Use 'kvfree()' for memory allocated by 'kvzalloc()'
net/mlx5: Eswitch, Use 'kvfree()' for memory allocated by 'kvzalloc()'
IB/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'
Colin Ian King (4):
net/mlx5: remove some extraneous spaces in indentations
RDMA/qedr: fix spelling mistake: "failes" -> "fails"
net/mlx5: fix spelling mistake: "modfiy" -> "modify"
RDMA/qedr: fix spelling mistake: "adrresses" -> "addresses"
Cong Wang (1):
infiniband: fix a possible use-after-free bug
Don Hiatt (3):
IB/hfi1: Define 16B Management Packets
IB/hfi1: Add support for 16B Management Packets
IB/hfi1: Add 16B Management Packet trace support
Doug Ledford (7):
Merge branch 'k.o/for-rc' into k.o/wip/dl-for-next
Merge tag 'mlx5-updates-2018-05-07' of
git://git.kernel.org/.../mellanox/linux into k.o/wip/dl-for-next
RDMA/hfi1: Fix build error with debugfs disabled
RDMA/uapi: Fix uapi breakage
RDMA/ipoib: Update paths on CLIENT_REREG/SM_CHANGE events
Merge branch 'wip/dl-ipoib' into wip/dl-for-next
RDMA/hns_roce: Don't check return value of zap_vma_ptes()
Erez Shitrit (1):
IB/mlx5: Fetch soft WQE's on fatal error state
Evgenii Smirnov (1):
RDMA/ipoib: drop skb on path record lookup failure
Idan Burstein (1):
IB/mlx5: posting klm/mtt list inline in the send queue for reg_wr
Jack Morgenstein (2):
IB/core: Make testing MR flags for writability a static inline function
IB/mlx4: Mark user MR as
Re: [PATCH v6 2/5] efi: Add embedded peripheral firmware support
On Wed, Jun 06, 2018 at 08:39:15PM +0200, Hans de Goede wrote: > On 05-06-18 23:07, Luis R. Rodriguez wrote: > > > +To make request_firmware() fallback to trying EFI embedded firmwares > > > after this, > > > +the driver must set a boolean "efi-embedded-firmware" device-property on > > > the > > > +device before passing it to request_firmware(). > > > > No, as I have requested before I don't want this, it is silly to have such > > functionality always be considered as a fallback if we only have 2 drivers > > which need this. > Please add a call which only if used would then > > *evaluate* > > such fallback prospect. > > Ok, so I've a few questions about this: > > 1) You want me to add a: > > int firmware_request_with_system_firmware_fallback(struct device *device, > const char *name); > > function? The idea is correct, the name however is obviously terrible. This is functionality that is very specialized and only *two* device drivers need it that we are aware of which would be upstream. Experience has shown fallback mechanisms *can* be a pain, and if we add this we will be supporting this for *life*, as such I'd very much prefer to: a) *Clearly* reduce the scope of functionality clearly *beyond* what you have done. b) Have access to one simple call which folks can use to *clearly* and quickly grep for those oddball drivers using this new interface. We can do this by using a separate function for it. Before you claim something seems unreasonable from the above logic, please read the latest state of affairs with respect to data driven Vs functional API evolution discussion over the firmware API [0] as well as my latests recommendation for what to do for the async firmware API [1]. The skinny of it is that long ago I actually proposed having only *two* firmware API calls, an async and a sync call and having all functionality fleshed out through a structure of parameters. The issue with that strategy was it was *too* data driven, and as per Greg's request we'll instead be exposing new symbols per functionality for the firmware API with his justification that this is just what is traditionally done on Linux. Hence we have firmware_request_nowarn() now for just a slight variation for a sync call. Despite Greg's recommendation -- for the respective async functionality I suggested this is not going to scale well -- it is also just dumb to follow the same approach there for a few reasons. 1) We have only *one* async call and had decided to *not* provide a structure for that call since its inception 2) Over time have evolved this single async call each time we have a new feature, causing a slew of collateral evolutions. So, while we like it or not, it turns out the async call to the firmware API is already completely data driven. Extending it with just another argument would just be silly now. So refer to my recommendations to Andres for how to evolve the async API if you need it, however from a quick review you don't need async calls, so you won't have to address any of that. [0] https://lkml.kernel.org/r/20180421173650.gw14...@wotan.suse.de [1] https://lkml.kernel.org/r/20180422202609.gx14...@wotan.suse.de > Note I've deliberately named it with_system_firmware_fallback > and not with_efi_fallback to have the name be platform agnostic in > case we want something similar on other platforms in the future. firmware_request_platform() ? > And then have this pass a new FW_OPT_SYS_FW_FALLBACK flag to > _request_firmware(), right ? Yeap. > 2) Should this flag then be checked inside _request_firmware() before it > calls fw_get_efi_embedded_fw() (which may be an empty stub), You are the architect behind this call, so its up to you. To answer this you have to review the other flags and see if other users of the other flags may want your functionality. For instance the Android folks for instance rely on the FW_OPT_NOFALLBACK - the sysfs fallback mechanism to account for odd partition layouts. Could they ever want to use your fallback mechanism? Granted your mechanism is for x86, but they could eventually add support for it on ARM. Checking if the firmware is on the EFI platform firmware list is much faster than the fallback mechanism, that would be one gain for them, as such it may make sense to check for firmware_request_platform() before using the sysfs fallback mechanism. However if Android folks want to always override the platform firmware with the sysfs fallback interface we'd need another flag added and call to then change the order later if we checked for for the platform firmware first. If you however are 100% sure they won't need it, than checking firmware_request_platform() first would make sense now if you are certain these same devices won't need the sysfs fallback interface and don't want to use it to override the platform firmware. > or > inside fw_get_efi_embedded_fw()? You'll definitely want to check it there for sure to no-op if you don't have it
Re: [PATCH] uart: fix race between uart_put_char() and uart_shutdown()
On Mon, Jun 04, 2018 at 10:59:36PM -0500, Serge E. Hallyn wrote: > Quoting Tycho Andersen (ty...@tycho.ws): > > Unfortunately, I don't have any insightful thoughts about how to test this. > > Ideas are appreciated :) > > I wonder whether there is something we can do with qemu -serial pipe: ? Good idea. I couldn't get tty_put_char() to trigger nicely, but I just hard coded one to occur, so at least now I know that this doesn't deadlock when called normally. Another suggestion Serge gave off list was to write a kernel module that implemented a driver. I'll see about doing that to see if I can force the original crash. > > Signed-off-by: Tycho Andersen > > Acked-by: Serge Hallyn Thanks! Tycho
[PATCH] Documentation: update firmware loader fallback reference
The firmware loader has a fallback mechanism, and it now has some proper kdoc, but we forgot to update the Documentation to use the new kdoc. Fix that. Signed-off-by: Luis R. Rodriguez --- Documentation/driver-api/firmware/fallback-mechanisms.rst | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst index d35fed65eae9..8b041d0ab426 100644 --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst @@ -92,7 +92,7 @@ the loading file. The firmware device used to help load firmware using sysfs is only created if direct firmware loading fails and if the fallback mechanism is enabled for your -firmware request, this is set up with fw_load_from_user_helper(). It is +firmware request, this is set up with :c:func:`firmware_fallback_sysfs`. It is important to re-iterate that no device is created if a direct filesystem lookup succeeded. @@ -108,6 +108,11 @@ firmware_data_read() and firmware_loading_show() are just provided for the test_firmware driver for testing, they are not called in normal use or expected to be used regularly by userspace. +firmware_fallback_sysfs +--- +.. kernel-doc:: drivers/base/firmware_loader/fallback.c + :functions: firmware_fallback_sysfs + Firmware kobject uevent fallback mechanism == -- 2.16.3
[char-misc 0/2] mei; updates for 4.18-rc2
A bug for long lasting regression and trivial cleanup. Hope this can make its way to 4.18. Alexander Usyskin (2): mei: remove unused MEI_IAMTHIF_STALL_TIMER define mei: discard messages from not connected client during power down. drivers/misc/mei/hw.h| 2 -- drivers/misc/mei/interrupt.c | 5 - 2 files changed, 4 insertions(+), 3 deletions(-) -- 2.14.4
[char-misc 1/2] mei: remove unused MEI_IAMTHIF_STALL_TIMER define
From: Alexander Usyskin MEI_IAMTHIF_STALL_TIMER is unused now and can be safely removed. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler --- drivers/misc/mei/hw.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h index 5c8286b40b62..3b325d955fbe 100644 --- a/drivers/misc/mei/hw.h +++ b/drivers/misc/mei/hw.h @@ -28,8 +28,6 @@ #define MEI_CL_CONNECT_TIMEOUT 15 /* HPS: Client Connect Timeout */ #define MEI_CLIENTS_INIT_TIMEOUT 15 /* HPS: Clients Enumeration Timeout */ -#define MEI_IAMTHIF_STALL_TIMER12 /* HPS */ - #define MEI_PGI_TIMEOUT 1 /* PG Isolation time response 1 sec */ #define MEI_D0I3_TIMEOUT5 /* D0i3 set/unset max response time */ #define MEI_HBM_TIMEOUT 1 /* 1 second */ -- 2.14.4
[char-misc 2/2] mei: discard messages from not connected client during power down.
From: Alexander Usyskin
This fixes regression introduced by
commit 8d52af6795c0 ("mei: speed up the power down flow")
In power down or suspend flow a message can still be received
from the FW because the clients fake disconnection.
In normal case we interpret messages w/o destination as corrupted
and link reset is performed in order to clean the channel,
but during power down link reset is already in progress resulting
in endless loop. To resolve the issue under power down flow we
discard messages silently.
Cc: 4.16+
Fixes: 8d52af6795c0 ("mei: speed up the power down flow")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199541
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/interrupt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c
index b0b8f18a85e3..6649f0d56d2f 100644
--- a/drivers/misc/mei/interrupt.c
+++ b/drivers/misc/mei/interrupt.c
@@ -310,8 +310,11 @@ int mei_irq_read_handler(struct mei_device *dev,
if (&cl->link == &dev->file_list) {
/* A message for not connected fixed address clients
* should be silently discarded
+* On power down client may be force cleaned,
+* silently discard such messages
*/
- if (hdr_is_fixed(mei_hdr)) {
+ if (hdr_is_fixed(mei_hdr) ||
+ dev->dev_state == MEI_DEV_POWER_DOWN) {
mei_irq_discard_msg(dev, mei_hdr);
ret = 0;
goto reset_slots;
--
2.14.4
[PATCH] perf: xgene: Fix IOB SLOW PMU parser error
This patch fixes the below parser error of the IOB SLOW PMU. # perf stat -a -e iob-slow0/cycle-count/ sleep 1 evenf syntax error: 'iob-slow0/cycle-count/' \___ parser error It replaces the "-" character by "_" character inside the PMU name. Signed-off-by: Hoan Tran --- drivers/perf/xgene_pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c index 6bdb1da..0e31f13 100644 --- a/drivers/perf/xgene_pmu.c +++ b/drivers/perf/xgene_pmu.c @@ -1463,7 +1463,7 @@ static char *xgene_pmu_dev_name(struct device *dev, u32 type, int id) case PMU_TYPE_IOB: return devm_kasprintf(dev, GFP_KERNEL, "iob%d", id); case PMU_TYPE_IOB_SLOW: - return devm_kasprintf(dev, GFP_KERNEL, "iob-slow%d", id); + return devm_kasprintf(dev, GFP_KERNEL, "iob_slow%d", id); case PMU_TYPE_MCB: return devm_kasprintf(dev, GFP_KERNEL, "mcb%d", id); case PMU_TYPE_MC: -- 2.7.4
Re: [PATCH v5 00/10] track CPU utilization
Hi, On Wed, 6 Jun 2018 14:20:46 +0100 Quentin Perret wrote: [...] > > However, IMHO, these are corner cases and in the average case it is > > better to rely on running_bw and reduce the CPU frequency > > accordingly. > > My point was that accepting to go at a lower frequency than required > by this_bw is fundamentally unsafe. If you're at a low frequency when > a DL task starts, there are real situations where you won't be able > to increase the frequency immediately, which can eventually lead to > missing deadlines. Now, if this risk is known, has been discussed, > and is accepted, that's fair enough. I'm just too late for the > discussion :-) Well, our conclusion was that this issue can be addressed when designing the scheduling parameters: - If we do not consider frequency scaling, a task can respect its deadlines if the SCHED_DEADLINE runtime is larger than the task's execution time and the SCHED_DEADLINE period is smaller than the task's period (and if some kind of "global" admission test is respected) - Considering frequency scaling (and 0-time frequency switches), the SCHED_DEADLINE runtime must be larger than the task execution time at the highest frequency - If the frequency switch time is larger than 0, then the SCHED_DEADLINE runtime must be larger than the task execution time (at the highest frequency) plus the frequency switch time If this third condition is respected, I think that deadline misses can be avoided even if running_bw is used (and the CPU takes a considerable time to switch frequency). Of course, this requires an over-allocation of runtime (and the global admission test has more probabilities to fail)... Luca
