Re: [RESEND PATCH v3 08/20] mtd: spi-nor: Split spi_nor_init_params()
On 26/08/19 5:38 PM, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> Add functions to delimit what the chunks of code do:
>
> static void spi_nor_init_params()
> {
> spi_nor_info_init_params()
> spi_nor_manufacturer_init_params()
> spi_nor_sfdp_init_params()
> }
>
> Add descriptions to all methods.
>
> spi_nor_init_params() becomes of type void, as all its children
> return void.
>
> Signed-off-by: Tudor Ambarus
> Reviewed-by: Boris Brezillon
> ---
> v3: rename spi_nor_legacy_init_params() to spi_nor_info_init_params()
Reviewed-by: Vignesh Raghavendra
Minor nits below...
[...]
>
> +/**
> + * spi_nor_init_params() - Initialize the flash's parameters and settings.
> + * @nor: pointer to a 'struct spi-nor'.
> + *
> + * The flash parameters and settings are initialized based on a sequence of
> + * calls that are ordered by priority:
> + *
> + * 1/ Default flash parameters initialization. The initializations are done
> + *based on nor->info data:
> + * spi_nor_info_init_params()
> + *
> + * which can be overwritten by:
> + * 2/ Manufacturer flash parameters initialization. The initializations are
> + *done based on MFR register, or when the decisions can not be done
> solely
> + *based on MFR, by using specific flash_info tweeks, ->default_init():
> + * spi_nor_manufacturer_init_params()
> + *
> + * which can be overwritten by:
> + * 3/ SFDP flash parameters initialization. JESD216 SFDP is a standard and
> + *should be more accurate that the above.
> + * spi_nor_sfdp_init_params()
> + *
> + *Please not that there is a ->post_bfpt() fixup hook that can overwrite
> the
s/not/note
> + *flash parameters and settings imediately after parsing the Basic Flash
s/imediately/immediately
> + *Parameter Table.
> + */
> +static void spi_nor_init_params(struct spi_nor *nor)
> +{
> + spi_nor_info_init_params(nor);
>
> spi_nor_manufacturer_init_params(nor);
>
> - if ((info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) &&
> - !(info->flags & SPI_NOR_SKIP_SFDP)) {
> - struct spi_nor_flash_parameter sfdp_params;
> -
> - memcpy(_params, params, sizeof(sfdp_params));
> -
> - if (spi_nor_parse_sfdp(nor, _params)) {
> - nor->addr_width = 0;
> - nor->flags &= ~SNOR_F_4B_OPCODES;
> - } else {
> - memcpy(params, _params, sizeof(*params));
> - }
> - }
> -
> - return 0;
> + if ((nor->info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) &&
> + !(nor->info->flags & SPI_NOR_SKIP_SFDP))
> + spi_nor_sfdp_init_params(nor);
> }
>
> static int spi_nor_select_read(struct spi_nor *nor,
> @@ -4670,10 +4715,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> nor->info->flags & SPI_NOR_HAS_LOCK)
> nor->clear_sr_bp = spi_nor_clear_sr_bp;
>
> - /* Parse the Serial Flash Discoverable Parameters table. */
> - ret = spi_nor_init_params(nor);
> - if (ret)
> - return ret;
> + /* Init flash parameters based on flash_info struct and SFDP */
> + spi_nor_init_params(nor);
>
> if (!mtd->name)
> mtd->name = dev_name(dev);
>
--
Regards
Vignesh
Re: [linux-sunxi] [PATCH v6 1/3] ASoC: sun4i-i2s: incorrect regmap for A83T
On Tue, 27 Aug 2019 at 06:13, Chen-Yu Tsai wrote:
>
> On Tue, Aug 27, 2019 at 2:07 AM wrote:
> >
> > From: Marcus Cooper
> >
> > The regmap configuration is set up for the legacy block on the
> > A83T whereas it uses the new block with a larger register map.
>
> Looking at the code Allwinner previously released [1], that doesn't seem to be
> the case. Keep in mind that the register map shown in the user manual is for
> the TDM interface, which we don't actually support right now.
Should it matter what we support right now?, the block according to the user
manual shows the bigger range. I don't have a A83T device and from what I
gather not many users do. But the compatible for the H3 has been removed
and replaced with the settings for the A83T which also has default settings in
registers further up than SUNXI_RXCHMAP.
>
> The file shows the base address as 0x01c22800, and the last defined register
> is SUNXI_RXCHMAP at 0x3c.
>
> The I2S driver [2] also shows that it is the old register map size, but with
> TX_FIFO and INT_STA swapped around. This might mean that it would need a
> separate regmap_config, as the read/write callbacks need to be changed to
> fit the swapped registers.
>
> Finally, the TDM driver [3], which matches the TDM section in the manual,
> shows
> a larger register map.
>
> A83T is SUN8IW6, while SUN8IW7 refers to the H3.
Since when have we trusted Allwinner code?, the TDM labelled block
clearly supports
I2S. The biggest use case for this block is getting HDMI audio working
on the newer
devices(LibreELEC nightlies has a user base of over 300) and I've tested this on
numerous set ups over the last couple of years.
Failing that reverting (3e9acd7ac693: "ASoC: sun4i-i2s: Remove
duplicated quirks structure")
would help.
BR,
CK
>
> ChenYu
>
> [1]
> https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/hdmiaudio/sunxi-hdmipcm.h
> [2]
> https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/i2s0/sunxi-i2s0.h
> [3]
> https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/daudio0/sunxi-daudio0.h
>
> > Fixes: 21faaea1343f ("ASoC: sun4i-i2s: Add support for A83T")
> > Signed-off-by: Marcus Cooper
> > ---
> > sound/soc/sunxi/sun4i-i2s.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> > index 57bf2a33753e..34575a8aa9f6 100644
> > --- a/sound/soc/sunxi/sun4i-i2s.c
> > +++ b/sound/soc/sunxi/sun4i-i2s.c
> > @@ -1100,7 +1100,7 @@ static const struct sun4i_i2s_quirks
> > sun6i_a31_i2s_quirks = {
> > static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
> > .has_reset = true,
> > .reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
> > - .sun4i_i2s_regmap = _i2s_regmap_config,
> > + .sun4i_i2s_regmap = _i2s_regmap_config,
> > .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
> > .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
> > .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
> > --
> > 2.23.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to linux-sunxi+unsubscr...@googlegroups.com.
> > To view this discussion on the web, visit
> > https://groups.google.com/d/msgid/linux-sunxi/20190826180734.15801-2-codekipper%40gmail.com.
Re: [RESEND PATCH v3 07/20] mtd: spi_nor: Move manufacturer quad_enable() in ->default_init()
On 26/08/19 5:38 PM, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> The goal is to move the quad_enable manufacturer specific init in the
> nor->manufacturer->fixups->default_init()
>
> The legacy quad_enable() implementation is spansion_quad_enable(),
> select this method by default.
>
> Set specific manufacturer fixups->default_init() hooks to overwrite
> the default quad_enable() implementation when needed.
>
> Signed-off-by: Tudor Ambarus
> Reviewed-by: Boris Brezillon
> ---
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
> v3: collect R-b
>
> drivers/mtd/spi-nor/spi-nor.c | 48
> ++-
> 1 file changed, 29 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 3dbbfe34d1d2..2a239531704a 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -4150,13 +4150,38 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> return err;
> }
>
> +static void macronix_set_default_init(struct spi_nor *nor)
> +{
> + nor->params.quad_enable = macronix_quad_enable;
> +}
> +
> +static void st_micron_set_default_init(struct spi_nor *nor)
> +{
> + nor->params.quad_enable = NULL;
> +}
> +
> /**
> * spi_nor_manufacturer_init_params() - Initialize the flash's parameters and
> - * settings based on ->default_init() hook.
> + * settings based on MFR register and ->default_init() hook.
> * @nor: pointer to a 'struct spi-nor'.
> */
> static void spi_nor_manufacturer_init_params(struct spi_nor *nor)
> {
> + /* Init flash parameters based on MFR */
> + switch (JEDEC_MFR(nor->info)) {
> + case SNOR_MFR_MACRONIX:
> + macronix_set_default_init(nor);
> + break;
> +
> + case SNOR_MFR_ST:
> + case SNOR_MFR_MICRON:
> + st_micron_set_default_init(nor);
> + break;
> +
> + default:
> + break;
> + }
> +
> if (nor->info->fixups && nor->info->fixups->default_init)
> nor->info->fixups->default_init(nor);
> }
> @@ -4168,6 +4193,9 @@ static int spi_nor_init_params(struct spi_nor *nor)
> const struct flash_info *info = nor->info;
> u8 i, erase_mask;
>
> + /* Initialize legacy flash parameters and settings. */
> + params->quad_enable = spansion_quad_enable;
> +
> /* Set SPI NOR sizes. */
> params->size = (u64)info->sector_size * info->n_sectors;
> params->page_size = info->page_size;
> @@ -4233,24 +4261,6 @@ static int spi_nor_init_params(struct spi_nor *nor)
> SPINOR_OP_SE);
> spi_nor_init_uniform_erase_map(map, erase_mask, params->size);
>
> - /* Select the procedure to set the Quad Enable bit. */
> - if (params->hwcaps.mask & (SNOR_HWCAPS_READ_QUAD |
> -SNOR_HWCAPS_PP_QUAD)) {
> - switch (JEDEC_MFR(info)) {
> - case SNOR_MFR_MACRONIX:
> - params->quad_enable = macronix_quad_enable;
> - break;
> -
> - case SNOR_MFR_ST:
> - case SNOR_MFR_MICRON:
> - break;
> -
> - default:
> - /* Kept only for backward compatibility purpose. */
> - params->quad_enable = spansion_quad_enable;
> - break;
> - }
> - }
>
> spi_nor_manufacturer_init_params(nor);
>
>
--
Regards
Vignesh
Re: [RFC PATCH v2 1/3] x86/mm/tlb: Change __flush_tlb_one_user interface
On 26.08.19 18:38, Nadav Amit wrote:
On Aug 26, 2019, at 12:51 AM, Juergen Gross wrote:
On 24.08.19 00:52, Nadav Amit wrote:
__flush_tlb_one_user() currently flushes a single entry, and flushes it
both in the kernel and user page-tables, when PTI is enabled.
Change __flush_tlb_one_user() and related interfaces into
__flush_tlb_range() that flushes a range and does not flush the user
page-table.
This refactoring is needed for the next patch, but regardless makes
sense and has several advantages. First, only Xen-PV, which does not
use PTI, implements the paravirtual interface of flush_tlb_one_user() so
nothing is broken by separating the user and kernel page-table flushes,
and the interface is more intuitive.
Second, INVLPG can flush unrelated mappings, and it is also a
serializing instruction. It is better to have a tight loop that flushes
the entries.
Third, currently __flush_tlb_one_kernel() also flushes the user
page-tables, which is not needed. This allows to avoid this redundant
flush.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/paravirt.h | 5 ++--
arch/x86/include/asm/paravirt_types.h | 3 ++-
arch/x86/include/asm/tlbflush.h | 24 +
arch/x86/kernel/paravirt.c| 7 ++---
arch/x86/mm/tlb.c | 39 ++-
arch/x86/xen/mmu_pv.c | 21 +--
6 files changed, 62 insertions(+), 37 deletions(-)
...
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 48f7c7eb4dbc..ed68657f5e77 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -1325,22 +1325,27 @@ static noinline void xen_flush_tlb(void)
preempt_enable();
}
-static void xen_flush_tlb_one_user(unsigned long addr)
+static void xen_flush_tlb_range(unsigned long start, unsigned long end,
+ u8 stride_shift)
{
struct mmuext_op *op;
struct multicall_space mcs;
-
- trace_xen_mmu_flush_tlb_one_user(addr);
+ unsigned long addr;
preempt_disable();
mcs = xen_mc_entry(sizeof(*op));
op = mcs.args;
- op->cmd = MMUEXT_INVLPG_LOCAL;
- op->arg1.linear_addr = addr & PAGE_MASK;
- MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
- xen_mc_issue(PARAVIRT_LAZY_MMU);
+ for (addr = start; addr < end; addr += 1ul << stride_shift) {
+ trace_xen_mmu_flush_tlb_one_user(addr);
+
+ op->cmd = MMUEXT_INVLPG_LOCAL;
+ op->arg1.linear_addr = addr & PAGE_MASK;
+ MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
+
+ xen_mc_issue(PARAVIRT_LAZY_MMU);
+ }
For this kind of usage (a loop) you should:
- replace the call of xen_mc_entry() with xen_mc_batch()
- use xen_extend_mmuext_op() for each loop iteration
- call xen_mc_issue() after the loop
Additionally I'd like you to replace trace_xen_mmu_flush_tlb_one_user()
with trace_xen_mmu_flush_tlb_range() taking all three parameters and
keep it where it was (out of the loop).
The paravirt parts seem to be okay.
Thanks for the quick response. I don’t think the preempt_disable/enable() is
needed in this case, but I kept them. Does the following match what you had
in mind?
Yes, it does.
BTW, preempt_disable/enable() is needed as xen_mc_batch() ...
xen_mc_issue() is using a percpu buffer.
Juergen
---
arch/x86/xen/mmu_pv.c | 25 ++---
include/trace/events/xen.h | 18 --
2 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 48f7c7eb4dbc..faa01591df36 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -1325,20 +1325,23 @@ static noinline void xen_flush_tlb(void)
preempt_enable();
}
-static void xen_flush_tlb_one_user(unsigned long addr)
+static void xen_flush_tlb_range(unsigned long start, unsigned long end,
+ u8 stride_shift)
{
- struct mmuext_op *op;
- struct multicall_space mcs;
-
- trace_xen_mmu_flush_tlb_one_user(addr);
+ struct mmuext_op op;
+ unsigned long addr;
preempt_disable();
- mcs = xen_mc_entry(sizeof(*op));
- op = mcs.args;
- op->cmd = MMUEXT_INVLPG_LOCAL;
- op->arg1.linear_addr = addr & PAGE_MASK;
- MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
+ xen_mc_batch();
+ op.cmd = MMUEXT_INVLPG_LOCAL;
+
+ trace_xen_mmu_flush_tlb_range(start, end, stride_shift);
+
+ for (addr = start; addr < end; addr += 1ul << stride_shift) {
+ op.arg1.linear_addr = addr & PAGE_MASK;
+ xen_extend_mmuext_op();
+ }
xen_mc_issue(PARAVIRT_LAZY_MMU);
@@ -2394,7 +2397,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
.flush_tlb_user = xen_flush_tlb,
.flush_tlb_kernel = xen_flush_tlb,
linux-next: build failure after merge of the phy-next tree
Hi all,
After merging the phy-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "__arm_smccc_smc" [drivers/phy/marvell/phy-mvebu-cp110-comphy.ko]
undefined!
Caused by commit
ccee80654309 ("phy: mvebu-cp110-comphy: Add SMC call support")
I have used the phy-next tree from next-20190826 for today.
--
Cheers,
Stephen Rothwell
pgpcsCZMbwn6u.pgp
Description: OpenPGP digital signature
Re: [PATCH V5 1/3] riscv: Add perf callchain support
We need know the values of *regs, eg: regs->sepc, regs->ra, regs->fp,
regs->sp, regs->tp
void perf_callchain_kernel(struct perf_callchain_entry_ctx *entry,
struct pt_regs *regs)
{
...
walk_stackframe(, entry);
// May be we could detect error here and print the regs' value
}
On Mon, Aug 26, 2019 at 4:03 PM Greentime Hu wrote:
>
> Hi Guo,
>
> Guo Ren 於 2019年8月24日 週六 上午8:54寫道：
> >
> > Please check CONFIG_FRAME_POINTER
> >
> > 1 *frame = *((struct stackframe *)frame->fp - 1);
> > This code is origionally from riscv/kernel/stacktrace.c: walk_stackframe
> >
> > In linux/Makefile it'll involve the options for gcc to definitely
> > store ra & prev_fp in fp pointer.
> > ifdef CONFIG_FRAME_POINTER
> > KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
> >
> > So --call-graph fp need depends on CONFIG_FRAME_POINTER.
> >
>
> I am pretty sure CONFIG_FRAME_POINTER is Y
> # zcat /proc/config.gz |grep CONFIG_FRAME_POINTER
> CONFIG_FRAME_POINTER=y
>
> This is not going to go wrong every time, the probability of error is
> about one tenth or one quarter. randomly
> There may be some conditions that we have not considered.
>
> I add one more condition to check if it is a valid virtual address and
> it( ./perf record -e cpu-clock --call-graph fp ls) passes 1000 times
> without failure in Unleashed board based on 5.3-rc5.
> Here is my patch. Please have a look at it. I am not sure if it is a
> good solution.
>
> diff --git a/arch/riscv/kernel/perf_callchain.c
> b/arch/riscv/kernel/perf_callchain.c
> index d75d15c13dc7..4717942435df 100644
> --- a/arch/riscv/kernel/perf_callchain.c
> +++ b/arch/riscv/kernel/perf_callchain.c
> @@ -18,6 +18,8 @@ static int unwind_frame_kernel(struct stackframe *frame)
> return -EPERM;
> if (frame->fp < CONFIG_PAGE_OFFSET)
> return -EPERM;
> + if (!virt_addr_valid(frame->fp))
> + return -EPERM;
>
> *frame = *((struct stackframe *)frame->fp - 1);
> if (__kernel_text_address(frame->ra)) {
>
> It could catch cases called in this way.
>
> [ 1381.936586] frame->fp=:00547550
> [ 1382.038542] CPU: 1 PID: 135 Comm: ls Not tainted
> 5.3.0-rc5-3-gb008f6bcd67c-dirty #14
> [ 1382.307440] Call Trace:
> [ 1382.388947] [] walk_stackframe+0x0/0x9a
> [ 1382.568053] [] show_stack+0x2a/0x34
> [ 1382.735960] [] dump_stack+0x62/0x7c
> [ 1382.903863] [] perf_callchain_kernel+0xd8/0x102
> [ 1383.106558] [] get_perf_callchain+0x136/0x1f2
> [ 1383.303128] [] perf_callchain+0x52/0x6e
> [ 1383.482553] [] perf_prepare_sample+0x6e/0x476
> [ 1383.679357] [] perf_event_output_forward+0x1c/0x50
> [ 1383.890633] [] __perf_event_overflow+0x6a/0xa4
> [ 1384.090279] [] perf_swevent_hrtimer+0xba/0x106
> [ 1384.290094] [] __hrtimer_run_queues+0x84/0x108
> [ 1384.489694] [] hrtimer_interrupt+0xca/0x1ce
> [ 1384.680974] [] riscv_timer_interrupt+0x32/0x3a
> [ 1384.880449] [] do_IRQ+0x64/0xbe
> [ 1385.036698] [] ret_from_exception+0x0/0xc
>
> [13915.697989] frame->fp=:f000
> [13915.799937] CPU: 2 PID: 663 Comm: ls Not tainted
> 5.3.0-rc5-3-gb008f6bcd67c-dirty #14
> [13916.068832] Call Trace:
> [13916.150380] [] walk_stackframe+0x0/0x9a
> [13916.329450] [] show_stack+0x2a/0x34
> [13916.497360] [] dump_stack+0x62/0x7c
> [13916.665265] [] perf_callchain_kernel+0xd8/0x102
> [13916.867949] [] get_perf_callchain+0x136/0x1f2
> [13917.064526] [] perf_callchain+0x52/0x6e
> [13917.243950] [] perf_prepare_sample+0x6e/0x476
> [13917.440759] [] perf_event_output_forward+0x1c/0x50
> [13917.652021] [] __perf_event_overflow+0x6a/0xa4
> [13917.851683] [] perf_swevent_hrtimer+0xba/0x106
> [13918.051494] [] __hrtimer_run_queues+0x84/0x108
> [13918.251094] [] hrtimer_interrupt+0xca/0x1ce
> [13918.442379] [] riscv_timer_interrupt+0x32/0x3a
> [13918.641840] [] do_IRQ+0x64/0xbe
> [13918.798082] [] ret_from_exception+0x0/0xc
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
Re: [RESEND PATCH v3 05/20] mtd: spi-nor: Add default_init() hook to tweak flash parameters
On 26/08/19 5:38 PM, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> As of now, the flash parameters initialization logic is as following:
>
> a/ default flash parameters init in spi_nor_init_params()
> b/ manufacturer specific flash parameters updates, split across entire
>spi-nor core code
> c/ flash parameters updates based on SFDP tables
> d/ post BFPT flash parameter updates
>
> In the quest of removing the manufacturer specific code from the spi-nor
> core, we want to impose a timeline/priority on how the flash parameters
> are updated. The following sequence of calls is pursued:
>
> 1/ spi-nor core parameters init based on 'flash_info' struct:
> spi_nor_info_init_params()
>
> which can be overwritten by:
> 2/ MFR-based manufacturer flash parameters init:
> nor->manufacturer->fixups->default_init()
>
> which can be overwritten by:
> 3/ specific flash_info tweeks done when decisions can not be done just on
>MFR:
> nor->info->fixups->default_init()
>
> which can be overwritten by:
> 4/ SFDP tables flash parameters init - SFDP knows better:
> spi_nor_sfdp_init_params()
>
> which can be overwritten by:
> 5/ post SFDP tables flash parameters updates - in case manufacturers get
>the serial flash tables wrong or incomplete.
> nor->info->fixups->post_sfdp()
>The later can be extended to nor->manufacturer->fixups->post_sfdp() if
>needed.
>
> This patch opens doors for steps 2/ and 3/.
>
> Signed-off-by: Tudor Ambarus
> Reviewed-by: Boris Brezillon
> ---
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
> v3: reword description
>
> drivers/mtd/spi-nor/spi-nor.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 9dd6cd8cd13c..8fd60e1eebd2 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -154,12 +154,16 @@ struct sfdp_bfpt {
>
> /**
> * struct spi_nor_fixups - SPI NOR fixup hooks
> + * @default_init: called after default flash parameters init. Used to tweak
> + *flash parameters when information provided by the
> flash_info
> + *table is incomplete or wrong.
> * @post_bfpt: called after the BFPT table has been parsed
> *
> * Those hooks can be used to tweak the SPI NOR configuration when the SFDP
> * table is broken or not available.
> */
> struct spi_nor_fixups {
> + void (*default_init)(struct spi_nor *nor);
> int (*post_bfpt)(struct spi_nor *nor,
>const struct sfdp_parameter_header *bfpt_header,
>const struct sfdp_bfpt *bfpt,
> @@ -4133,6 +4137,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> return err;
> }
>
> +/**
> + * spi_nor_manufacturer_init_params() - Initialize the flash's parameters and
> + * settings based on ->default_init() hook.
> + * @nor: pointer to a 'struct spi-nor'.
> + */
> +static void spi_nor_manufacturer_init_params(struct spi_nor *nor)
> +{
> + if (nor->info->fixups && nor->info->fixups->default_init)
> + nor->info->fixups->default_init(nor);
> +}
> +
> static int spi_nor_init_params(struct spi_nor *nor)
> {
> struct spi_nor_flash_parameter *params = >params;
> @@ -4233,6 +4248,8 @@ static int spi_nor_init_params(struct spi_nor *nor)
> params->quad_enable = info->quad_enable;
> }
>
> + spi_nor_manufacturer_init_params(nor);
> +
> if ((info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) &&
> !(info->flags & SPI_NOR_SKIP_SFDP)) {
> struct spi_nor_flash_parameter sfdp_params;
>
--
Regards
Vignesh
Re: [RESEND PATCH v3 06/20] mtd: spi-nor: Add a default_init() fixup hook for gd25q256
On 26/08/19 5:38 PM, tudor.amba...@microchip.com wrote:
> From: Boris Brezillon
>
> gd25q256 needs to tweak the ->quad_enable() implementation and the
> ->default_init() fixup hook is the perfect place to do that. This way,
> if we ever need to tweak more things for this flash, we won't have to
> add new fields in flash_info.
>
> We can get rid of the flash_info->quad_enable field as gd25q256 was
> the only user.
>
> Signed-off-by: Boris Brezillon
> [tudor.amba...@microchip.com: use ->default_init() hook instead of
> ->post_sfdp()]
> Signed-off-by: Tudor Ambarus
> ---
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
> v3: no changes
> > drivers/mtd/spi-nor/spi-nor.c | 28
> 1 file changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 8fd60e1eebd2..3dbbfe34d1d2 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -222,8 +222,6 @@ struct flash_info {
>
> /* Part specific fixup hooks. */
> const struct spi_nor_fixups *fixups;
> -
> - int (*quad_enable)(struct spi_nor *nor);
> };
>
> #define JEDEC_MFR(info) ((info)->id[0])
> @@ -2126,6 +2124,21 @@ static struct spi_nor_fixups mx25l25635_fixups = {
> .post_bfpt = mx25l25635_post_bfpt_fixups,
> };
>
> +static void gd25q256_default_init(struct spi_nor *nor)
> +{
> + /*
> + * Some manufacturer like GigaDevice may use different
> + * bit to set QE on different memories, so the MFR can't
> + * indicate the quad_enable method for this case, we need
> + * to set it in the default_init fixup hook.
> + */
> + nor->params.quad_enable = macronix_quad_enable;
> +}
> +
> +static struct spi_nor_fixups gd25q256_fixups = {
> + .default_init = gd25q256_default_init,
> +};
> +
> /* NOTE: double check command sets and memory organization when you add
> * more nor chips. This current list focusses on newer chips, which
> * have been converging on command sets which including JEDEC ID.
> @@ -2218,7 +2231,7 @@ static const struct flash_info spi_nor_ids[] = {
> "gd25q256", INFO(0xc84019, 0, 64 * 1024, 512,
> SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
> - .quad_enable = macronix_quad_enable,
> + .fixups = _fixups,
> },
>
> /* Intel/Numonyx -- xxxs33b */
> @@ -4237,15 +4250,6 @@ static int spi_nor_init_params(struct spi_nor *nor)
> params->quad_enable = spansion_quad_enable;
> break;
> }
> -
> - /*
> - * Some manufacturer like GigaDevice may use different
> - * bit to set QE on different memories, so the MFR can't
> - * indicate the quad_enable method for this case, we need
> - * set it in flash info list.
> - */
> - if (info->quad_enable)
> - params->quad_enable = info->quad_enable;
> }
>
> spi_nor_manufacturer_init_params(nor);
>
--
Regards
Vignesh
Re: [PATCH] ext4: change the type of ext4 cache stats to percpu_counter to improve performance
Hi Theodore, On 2019/8/26 23:57, Theodore Y. Ts'o wrote: > On Mon, Aug 26, 2019 at 04:24:20PM +0800, Shaokun Zhang wrote: >>> The other problem with this patch is that it initializes >>> es_stats_cache_hits and es_stats_cache_miesses too late. They will >>> get used when the journal inode is loaded. This is mostly harmless, >> >> I have checked it again, @es_stats_cache_hits and @es_stats_cache_miesses >> have been initialized before the journal inode is loaded, Maybe I miss >> something else? > > No, sorry, that was my mistake. I misread things when I was looking > over your patch last night. > > Please resubmit your patch once you've fixed things up and tested it. > Sure, will do it soon. > I would recommend that you at least try running your patch using the > kvm-xfstests's smoke test[1] before submitting them. It will save you > and me time. > Ok, thanks your guidance. Shaokun, > [1] > https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md > > Thanks, > > - Ted > > > . >
Re: PageBlocks and Migrate Types
On Mon 26-08-19 22:35:08, Pankaj Suryawanshi wrote: > On Mon, Aug 26, 2019 at 12:34 PM Michal Hocko wrote: > > > > On Thu 22-08-19 23:54:19, Pankaj Suryawanshi wrote: > > > On Thu, Aug 22, 2019 at 6:22 PM Michal Hocko wrote: > > > > > > > > On Wed 21-08-19 22:23:44, Pankaj Suryawanshi wrote: > > > > > Hello, > > > > > > > > > > 1. What are Pageblocks and migrate types(MIGRATE_CMA) in Linux > memory ? > > > > > > > > Pageblocks are a simple grouping of physically contiguous pages with > > > > common set of flags. I haven't checked closely recently so I might > > > > misremember but my recollection is that only the migrate type is > stored > > > > there. Normally we would store that information into page flags but > > > > there is not enough room there. > > > > > > > > MIGRATE_CMA represent pages allocated for the CMA allocator. There are > > > > other migrate types denoting unmovable/movable allocations or pages > that > > > > are isolated from the page allocator. > > > > > > > > Very broadly speaking, the migrate type groups pages with similar > > > > movability properties to reduce fragmentation that compaction cannot > > > > do anything about because there are objects of different properti > > > > around. Please note that pageblock might contain objects of a > different > > > > migrate type in some cases (e.g. low on memory). > > > > > > > > Have a look at gfpflags_to_migratetype and how the gfp mask is > converted > > > > to a migratetype for the allocation. Also follow different > MIGRATE_$TYPE > > > > to see how it is used in the code. > > > > > > > > > How many movable/unmovable pages are defined by default? > > > > > > > > There is nothing like that. It depends on how many objects of a > specific > > > > type are allocated. > > > > > > > > > It means that it started creating pageblocks after allocation of > > > different objects, but from which block it allocate initially when > > > there is nothing like pageblocks ? (when memory subsystem up) > > > > Pageblocks are just a way to group physically contiguous pages. They > > just exist along with the physically contiguous memory. The migrate type > > for most of the memory is set to MIGRATE_MOVABLE. Portion of the memory > > might be reserved by CMA then that memory has MIGRATE_CMA. Following > > set_pageblock_migratetype call paths will give you a good picture. > > it means if i have 4096 continuous pages = 1 pageblock > then all the 4096 pages of same type. but if any one page is different than > block type then ? it changed the block type or something else ? That really depends on the specific migrate type. CMA, ISOLATE migrate types are all or nothing IIRC. I would have to check the code to tell exactly when MOVABLE/UNMOVABLE pageblocks transitions are done. steal_suitable_fallback sounds like a good start to look at. -- Michal Hocko SUSE Labs
Re: [RESEND PATCH v3 04/20] mtd: spi-nor: Move erase_map to 'struct spi_nor_flash_parameter'
On 26/08/19 5:38 PM, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> All flash parameters and settings should reside inside
> 'struct spi_nor_flash_parameter'. Move the SMPT parsed erase map
> from 'struct spi_nor' to 'struct spi_nor_flash_parameter'.
>
> Please note that there is a roll-back mechanism for the flash
> parameter and settings, for cases when SFDP parser fails. The SFDP
> parser receives a Stack allocated copy of nor->params, called
> sfdp_params, and uses it to retrieve the serial flash discoverable
> parameters. JESD216 SFDP is a standard and has a higher priority
> than the default initialized flash parameters, so will overwrite the
> sfdp_params data when needed. All SFDP code uses the local copy of
> nor->params, that will overwrite it in the end, if the parser succeds.
>
> Saving and restoring the nor->params.erase_map is no longer needed,
> since the SFDP code does not touch it.
>
> Signed-off-by: Tudor Ambarus
> ---
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
> v3: Collect R-b
>
> drivers/mtd/spi-nor/spi-nor.c | 40 +---
> include/linux/mtd/spi-nor.h | 8 +---
> 2 files changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index effda372cb33..9dd6cd8cd13c 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -600,7 +600,7 @@ static void spi_nor_set_4byte_opcodes(struct spi_nor *nor)
> nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
>
> if (!spi_nor_has_uniform_erase(nor)) {
> - struct spi_nor_erase_map *map = >erase_map;
> + struct spi_nor_erase_map *map = >params.erase_map;
> struct spi_nor_erase_type *erase;
> int i;
>
> @@ -1133,7 +1133,7 @@ static int spi_nor_init_erase_cmd_list(struct spi_nor
> *nor,
> struct list_head *erase_list,
> u64 addr, u32 len)
> {
> - const struct spi_nor_erase_map *map = >erase_map;
> + const struct spi_nor_erase_map *map = >params.erase_map;
> const struct spi_nor_erase_type *erase, *prev_erase = NULL;
> struct spi_nor_erase_region *region;
> struct spi_nor_erase_command *cmd = NULL;
> @@ -3328,7 +3328,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
> const struct sfdp_parameter_header *bfpt_header,
> struct spi_nor_flash_parameter *params)
> {
> - struct spi_nor_erase_map *map = >erase_map;
> + struct spi_nor_erase_map *map = >erase_map;
> struct spi_nor_erase_type *erase_type = map->erase_type;
> struct sfdp_bfpt bfpt;
> size_t len;
> @@ -3409,7 +3409,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
>* Erase Types defined in the bfpt table.
>*/
> erase_mask = 0;
> - memset(>erase_map, 0, sizeof(nor->erase_map));
> + memset(>erase_map, 0, sizeof(params->erase_map));
> for (i = 0; i < ARRAY_SIZE(sfdp_bfpt_erases); i++) {
> const struct sfdp_bfpt_erase *er = _bfpt_erases[i];
> u32 erasesize;
> @@ -3684,14 +3684,18 @@ spi_nor_region_check_overlay(struct
> spi_nor_erase_region *region,
> /**
> * spi_nor_init_non_uniform_erase_map() - initialize the non-uniform erase
> map
> * @nor: pointer to a 'struct spi_nor'
> + * @params: pointer to a duplicate 'struct spi_nor_flash_parameter' that
> is
> + * used for storing SFDP parsed data
> * @smpt:pointer to the sector map parameter table
> *
> * Return: 0 on success, -errno otherwise.
> */
> -static int spi_nor_init_non_uniform_erase_map(struct spi_nor *nor,
> - const u32 *smpt)
> +static int
> +spi_nor_init_non_uniform_erase_map(struct spi_nor *nor,
> +struct spi_nor_flash_parameter *params,
> +const u32 *smpt)
> {
> - struct spi_nor_erase_map *map = >erase_map;
> + struct spi_nor_erase_map *map = >erase_map;
> struct spi_nor_erase_type *erase = map->erase_type;
> struct spi_nor_erase_region *region;
> u64 offset;
> @@ -3770,6 +3774,8 @@ static int spi_nor_init_non_uniform_erase_map(struct
> spi_nor *nor,
> * spi_nor_parse_smpt() - parse Sector Map Parameter Table
> * @nor: pointer to a 'struct spi_nor'
> * @smpt_header: sector map parameter table header
> + * @params: pointer to a duplicate 'struct spi_nor_flash_parameter'
> + * that is used for storing SFDP parsed data
> *
> * This table is optional, but when available, we parse it to identify the
> * location and size of sectors within the main data array of the flash
> memory
> @@ -3778,7 +3784,8 @@ static int spi_nor_init_non_uniform_erase_map(struct
> spi_nor *nor,
> * Return: 0 on success, -errno
[PATCH 1/2] mm: Don't manually decrement num_poisoned_pages
From: Alastair D'Silva
Use the function written to do it instead.
Signed-off-by: Alastair D'Silva
---
mm/sparse.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 72f010d9bff5..e41917a7e844 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -11,6 +11,8 @@
#include
#include
#include
+#include
+#include
#include "internal.h"
#include
@@ -898,7 +900,7 @@ static void clear_hwpoisoned_pages(struct page *memmap, int
nr_pages)
for (i = 0; i < nr_pages; i++) {
if (PageHWPoison([i])) {
- atomic_long_sub(1, _poisoned_pages);
+ num_poisoned_pages_dec();
ClearPageHWPoison([i]);
}
}
--
2.21.0
[PATCH 2/2] mm: don't hide potentially null memmap pointer in sparse_remove_section
From: Alastair D'Silva
By adding offset to memmap before passing it in to clear_hwpoisoned_pages,
we hide a theoretically null memmap from the null check inside
clear_hwpoisoned_pages.
This patch passes the offset to clear_hwpoisoned_pages instead, allowing
memmap to successfully perform it's null check.
Signed-off-by: Alastair D'Silva
---
mm/sparse.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index e41917a7e844..3ff84e627e58 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -882,7 +882,7 @@ int __meminit sparse_add_section(int nid, unsigned long
start_pfn,
}
#ifdef CONFIG_MEMORY_FAILURE
-static void clear_hwpoisoned_pages(struct page *memmap, int nr_pages)
+static void clear_hwpoisoned_pages(struct page *memmap, int start, int count)
{
int i;
@@ -898,7 +898,7 @@ static void clear_hwpoisoned_pages(struct page *memmap, int
nr_pages)
if (atomic_long_read(_poisoned_pages) == 0)
return;
- for (i = 0; i < nr_pages; i++) {
+ for (i = start; i < start + count; i++) {
if (PageHWPoison([i])) {
num_poisoned_pages_dec();
ClearPageHWPoison([i]);
@@ -906,7 +906,8 @@ static void clear_hwpoisoned_pages(struct page *memmap, int
nr_pages)
}
}
#else
-static inline void clear_hwpoisoned_pages(struct page *memmap, int nr_pages)
+static inline void clear_hwpoisoned_pages(struct page *memmap, int start,
+ int count)
{
}
#endif
@@ -915,7 +916,7 @@ void sparse_remove_section(struct mem_section *ms, unsigned
long pfn,
unsigned long nr_pages, unsigned long map_offset,
struct vmem_altmap *altmap)
{
- clear_hwpoisoned_pages(pfn_to_page(pfn) + map_offset,
+ clear_hwpoisoned_pages(pfn_to_page(pfn), map_offset,
nr_pages - map_offset);
section_deactivate(pfn, nr_pages, altmap);
}
--
2.21.0
[PATCH 0/2] mm: Minor cleanup
From: Alastair D'Silva This series addresses some minor issues & obsoletes: mm: Cleanup & allow modules to hotplug memory Alastair D'Silva (2): mm: Don't manually decrement num_poisoned_pages mm: don't hide potentially null memmap pointer in sparse_remove_section mm/sparse.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) -- 2.21.0
Re: [RESEND PATCH v3 00/20] mtd: spi-nor: move manuf out of the core
On 26/08/19 5:38 PM, tudor.amba...@microchip.com wrote: > From: Tudor Ambarus [...] > > Tested on sst26vf064b with atmel-quadspi SPIMEM driver. > Tested s25fl256s, mx66l51235l with ti-qspi and s25fl512s with cadence-quadspi. n25q128a13 with legacy 1 bit SPI controller. > Boris Brezillon (7): > mtd: spi-nor: Add a default_init() fixup hook for gd25q256 > mtd: spi-nor: Create a ->set_4byte() method > mtd: spi-nor: Rework the SPI NOR lock/unlock logic > mtd: spi-nor: Add post_sfdp() hook to tweak flash config > mtd: spi-nor: Add spansion_post_sfdp_fixups() > mtd: spi-nor: Add a ->convert_addr() method > mtd: spi-nor: Add the SPI_NOR_XSR_RDY flag > > Tudor Ambarus (13): > mtd: spi-nor: Regroup flash parameter and settings > mtd: spi-nor: Use nor->params > mtd: spi-nor: Drop quad_enable() from 'struct spi-nor' > mtd: spi-nor: Move erase_map to 'struct spi_nor_flash_parameter' > mtd: spi-nor: Add default_init() hook to tweak flash parameters > mtd: spi_nor: Move manufacturer quad_enable() in ->default_init() > mtd: spi-nor: Split spi_nor_init_params() > mtd: spi_nor: Add a ->setup() method > mtd: spi-nor: Add s3an_post_sfdp_fixups() > mtd: spi-nor: Bring flash params init together > mtd: spi_nor: Introduce spi_nor_set_addr_width() > mtd: spi-nor: Introduce spi_nor_get_flash_info() > mtd: spi-nor: Rework the disabling of block write protection > > drivers/mtd/spi-nor/spi-nor.c | 1304 > +++-- > include/linux/mtd/spi-nor.h | 298 +++--- > 2 files changed, 927 insertions(+), 675 deletions(-) > -- Regards Vignesh
[PATCH] powerpc: Perform a bounds check in arch_add_memory
From: Alastair D'Silva It is possible for firmware to allocate memory ranges outside the range of physical memory that we support (MAX_PHYSMEM_BITS). This patch adds a bounds check to ensure that any hotplugged memory is addressable. Signed-off-by: Alastair D'Silva --- arch/powerpc/mm/mem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 9191a66b3bc5..de18fb73de30 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -111,6 +111,9 @@ int __ref arch_add_memory(int nid, u64 start, u64 size, unsigned long nr_pages = size >> PAGE_SHIFT; int rc; + if ((start + size - 1) >> MAX_PHYSMEM_BITS) + return -EINVAL; + resize_hpt_for_hotplug(memblock_phys_mem_size()); start = (unsigned long)__va(start); -- 2.21.0
Re: [PATCH] riscv: add arch/riscv/Kbuild
On Mon, Aug 26, 2019 at 8:35 PM Christoph Hellwig wrote: > > On Wed, Aug 21, 2019 at 06:26:58PM +0900, Masahiro Yamada wrote: > > Use the standard obj-y form to specify the sub-directories under > > arch/riscv/. No functional change intended. > > > > Signed-off-by: Masahiro Yamada > > Do you have a document what the grand scheme here is? There is a small documentation about "Makefile" vs "Kbuild" in Documentation/kbuild/modules.rst section 3.2 It is talking about external modules, but the benefit applies to arch/$(SRCARCH)/Kbuild as well. arch/$(SRCARCH)/Makefile is included by the top Makefile to specify arch-specific compiler flags, etc. On the other hand, arch/$(SRCARCH)/Kbuild, if exists, is included when Kbuild actually descends into arch/$(SRCARCH)/. This allows you to hierarchize the sub-directories to visit instead of specifying everything in flat in arch/$(SRCARCH)/Makefile. Major architectures are already doing this. See arch/x86/Kbuild arch/sparc/Kbuild arch/powerpc/Kbuild etc. (and arm64 also adopted this recently) The trick is "Kbuild" has precedence over "Makefile". If you are interested in the actual code, see line 41 of scripts/Makefile.build > Less of the magic > in arch/$(ARCH)/Makefile sounds like a good idea, but unless we have > a very specific split between the kbuild makefile and various override > I fear just splitting things up into two files doesn't really help much. Why not? -- Best Regards Masahiro Yamada
Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote: > Hi Bjorn, > Hi Suman > On 10/23/18 8:19 PM, Suman Anna wrote: > > The virtio_rpmsg_bus driver uses the "%p" format-specifier for > > printing the vring buffer address. This prints only a hashed > > pointer even for previliged users. Use "%pK" instead so that > > the address can be printed during debug using kptr_restrict > > sysctl. > > Seems to have been lost among the patches, can you pick up this trivial > patch for 5.4? Should apply cleanly on the latest HEAD as well. > I share Andrew's question regarding what benefit you have from knowing this value. Should we not just remove the va from the print? Or do you actually have a use case for it? Regards, Bjorn > regards > Suman > > > > > Signed-off-by: Suman Anna > > --- > > drivers/rpmsg/virtio_rpmsg_bus.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c > > b/drivers/rpmsg/virtio_rpmsg_bus.c > > index f29dee731026..1345f373a1a0 100644 > > --- a/drivers/rpmsg/virtio_rpmsg_bus.c > > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c > > @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev) > > goto vqs_del; > > } > > > > - dev_dbg(>dev, "buffers: va %p, dma %pad\n", > > + dev_dbg(>dev, "buffers: va %pK, dma %pad\n", > > bufs_va, >bufs_dma); > > > > /* half of the buffers is dedicated for RX */ > > >
[PATCH v2 2/2] macb: Update compatibility string for SiFive FU540-C000
Update the compatibility string for SiFive FU540-C000 as per the new
string updated in the binding doc.
Reference:
https://lore.kernel.org/netdev/caj2_jofevzqat0yprg4hem4jrrqkb72fkseqj4p8p5ka-+r...@mail.gmail.com/
Signed-off-by: Yash Shah
Acked-by: Nicolas Ferre
Reviewed-by: Paul Walmsley
Tested-by: Paul Walmsley
---
drivers/net/ethernet/cadence/macb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
index 5ca17e6..35b59b5 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -4154,7 +4154,7 @@ static int fu540_c000_init(struct platform_device *pdev)
{ .compatible = "cdns,emac", .data = _config },
{ .compatible = "cdns,zynqmp-gem", .data = _config},
{ .compatible = "cdns,zynq-gem", .data = _config },
- { .compatible = "sifive,fu540-macb", .data = _c000_config },
+ { .compatible = "sifive,fu540-c000-gem", .data = _c000_config },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, macb_dt_ids);
--
1.9.1
[PATCH v2 1/2] macb: bindings doc: update sifive fu540-c000 binding
As per the discussion with Nicolas Ferre[0], rename the compatible property to a more appropriate and specific string. [0] https://lore.kernel.org/netdev/caj2_jofevzqat0yprg4hem4jrrqkb72fkseqj4p8p5ka-+r...@mail.gmail.com/ Signed-off-by: Yash Shah Acked-by: Nicolas Ferre Reviewed-by: Paul Walmsley Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/net/macb.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index 63c73fa..0b61a90 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -15,10 +15,10 @@ Required properties: Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4 SoCs. Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC. Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC. - Use "sifive,fu540-macb" for SiFive FU540-C000 SoC. + Use "sifive,fu540-c000-gem" for SiFive FU540-C000 SoC. Or the generic form: "cdns,emac". - reg: Address and length of the register set for the device - For "sifive,fu540-macb", second range is required to specify the + For "sifive,fu540-c000-gem", second range is required to specify the address and length of the registers for GEMGXL Management block. - interrupts: Should contain macb interrupt - phy-mode: See ethernet.txt file in the same directory. -- 1.9.1
[PATCH v2 0/2] Update ethernet compatible string for SiFive FU540
This patch series renames the compatible property to a more appropriate string. The patchset is based on Linux-5.3-rc6 and tested on SiFive Unleashed board Change history: Since v1: - Dropped PATCH3 because it's already merged - Change the reference url in the patch descriptions to point to a 'lore.kernel.org' link instead of 'lkml.org' Yash Shah (2): macb: bindings doc: update sifive fu540-c000 binding macb: Update compatibility string for SiFive FU540-C000 Documentation/devicetree/bindings/net/macb.txt | 4 ++-- drivers/net/ethernet/cadence/macb_main.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- 1.9.1
Re: [PATCH v6 4/4] media: venus: Update core selection
Hi,
On 2019-07-29 15:16, Stanimir Varbanov wrote:
Hi,
On 7/22/19 12:07 PM, Aniket Masule wrote:
Present core assignment is static. Introduced load balancing
across the cores. Load on earch core is calculated and core
with minimum load is assigned to given instance.
Signed-off-by: Aniket Masule
---
drivers/media/platform/qcom/venus/helpers.c| 69
+++---
drivers/media/platform/qcom/venus/helpers.h| 2 +-
drivers/media/platform/qcom/venus/hfi_helper.h | 1 +
drivers/media/platform/qcom/venus/hfi_parser.h | 5 ++
drivers/media/platform/qcom/venus/vdec.c | 2 +-
drivers/media/platform/qcom/venus/venc.c | 2 +-
6 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index edf403d..3b6cbbf 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -26,6 +26,7 @@
#include "helpers.h"
#include "hfi_helper.h"
#include "hfi_venus_io.h"
+#include "hfi_parser.h"
struct intbuf {
struct list_head list;
@@ -331,6 +332,24 @@ static u32 load_per_instance(struct venus_inst
*inst)
return mbs * inst->fps;
}
+static u32 load_per_core(struct venus_core *core, u32 core_id)
+{
+ struct venus_inst *inst = NULL;
+ u32 mbs_per_sec = 0, load = 0;
+
+ mutex_lock(>lock);
+ list_for_each_entry(inst, >instances, list) {
+ if (inst->clk_data.core_id != core_id)
+ continue;
+
+ mbs_per_sec = load_per_instance(inst);
+ load += mbs_per_sec * inst->clk_data.codec_freq_data->vpp_freq;
+ }
+ mutex_unlock(>lock);
+
+ return load;
+}
+
static u32 load_per_type(struct venus_core *core, u32 session_type)
{
struct venus_inst *inst = NULL;
@@ -505,6 +524,16 @@ static int load_scale_clocks(struct venus_inst
*inst)
return scale_clocks(inst);
}
+int set_core_usage(struct venus_inst *inst, u32 usage)
+{
+ const u32 ptype = HFI_PROPERTY_CONFIG_VIDEOCORES_USAGE;
+ struct hfi_videocores_usage_type cu;
+
+ cu.video_core_enable_mask = usage;
+
+ return hfi_session_set_property(inst, ptype, );
+}
+
static void fill_buffer_desc(const struct venus_buffer *buf,
struct hfi_buffer_desc *bd, bool response)
{
@@ -808,19 +837,47 @@ int venus_helper_set_work_mode(struct venus_inst
*inst, u32 mode)
}
EXPORT_SYMBOL_GPL(venus_helper_set_work_mode);
-int venus_helper_set_core_usage(struct venus_inst *inst, u32 usage)
+int venus_helper_set_core(struct venus_inst *inst)
{
- const u32 ptype = HFI_PROPERTY_CONFIG_VIDEOCORES_USAGE;
- struct hfi_videocores_usage_type cu;
+ struct venus_core *core = inst->core;
+ u32 min_core_id = 0, core1_load = 0, core2_load = 0;
+ unsigned long min_load, max_freq, cur_inst_load;
+ u32 cores_max;
+ int ret;
if (!IS_V4(inst->core))
return 0;
- cu.video_core_enable_mask = usage;
+ core1_load = load_per_core(core, VIDC_CORE_ID_1);
+ core2_load = load_per_core(core, VIDC_CORE_ID_2);
+ min_core_id = core1_load < core2_load ? VIDC_CORE_ID_1 :
VIDC_CORE_ID_2;
+ min_load = min(core1_load, core2_load);
+ cores_max = core_num_max(inst);
- return hfi_session_set_property(inst, ptype, );
+ if (cores_max < VIDC_CORE_ID_2) {
+ min_core_id = VIDC_CORE_ID_1;
+ min_load = core1_load;
+ }
+
+ cur_inst_load = load_per_instance(inst) *
+ inst->clk_data.codec_freq_data->vpp_freq;
+ max_freq = core->res->freq_tbl[0].freq;
+
+ if ((cur_inst_load + min_load) > max_freq) {
+ dev_warn(core->dev, "HW is overloaded, needed: %lu max: %lu\n",
+cur_inst_load, max_freq);
+ return -EINVAL;
+ }
+
+ ret = set_core_usage(inst, min_core_id);
We have a problem here. Lets assume that we have only one running
decoder session and the code above decides that it should be handled by
core2, but core2 clocks presently are enabled only if there is an
encoder session (see DT subnodes), thus we select core2 but without
enabling core2 clocks and power domain.
I will send a separate patch for core selection, once power domain issue
is fixed.
+ if (ret)
+ return ret;
+
+ inst->clk_data.core_id = min_core_id;
+
+ return 0;
}
-EXPORT_SYMBOL_GPL(venus_helper_set_core_usage);
+EXPORT_SYMBOL_GPL(venus_helper_set_core);
Regards,
Aniket
Re: [PATCH v6 3/4] media: venus: Update to bitrate based clock scaling
Hi Stan,
On 2019-07-29 17:08, Stanimir Varbanov wrote:
Hi,
On 7/22/19 12:07 PM, Aniket Masule wrote:
Introduced clock scaling using bitrate, preavious
calculations consider only the cycles per mb.
Also, clock scaling is now triggered before every
buffer being queued to the device. This helps in
deciding precise clock cycles required.
Signed-off-by: Aniket Masule
---
drivers/media/platform/qcom/venus/helpers.c | 33
+
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index 2c976e4..edf403d 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -399,17 +399,26 @@ static int scale_clocks(struct venus_inst *inst)
return ret;
}
-static unsigned long calculate_vpp_freq(struct venus_inst *inst)
+static unsigned long calculate_inst_freq(struct venus_inst *inst,
+unsigned long filled_len)
{
- unsigned long vpp_freq = 0;
+ unsigned long vpp_freq = 0, vsp_freq = 0;
+ u64 fps = inst->fps;
u32 mbs_per_sec;
mbs_per_sec = load_per_instance(inst);
vpp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vpp_freq;
/* 21 / 20 is overhead factor */
vpp_freq += vpp_freq / 20;
+ vsp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vsp_freq;
- return vpp_freq;
+ /* 10 / 7 is overhead factor */
+ if (inst->session_type == VIDC_SESSION_TYPE_ENC)
+ vsp_freq += (inst->controls.enc.bitrate * 10) / 7;
+ else
+ vsp_freq += ((fps * filled_len * 8) * 10) / 7;
load_per_instance() already taken into account fps, thus I think fps
should be excluded from calculation.
I will correct this, fps is needed for stream processor frequency
calculations,
also fps is not needed for vpp.
+
+ return max(vpp_freq, vsp_freq);
}
Regards,
Aniket
Re: [PATCH v6 2/4] media: venus: Update clock scaling
Hi Stan,
On 2019-07-29 14:05, Stanimir Varbanov wrote:
Hi Aniket,
On 7/22/19 12:07 PM, Aniket Masule wrote:
Current clock scaling calculations are same for vpu4 and
previous versions. For vpu4, Clock scaling calculations
are updated with cycles/mb. This helps in getting precise
clock required.
Signed-off-by: Aniket Masule
---
drivers/media/platform/qcom/venus/helpers.c | 91
+++--
1 file changed, 87 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index 7492373..2c976e4 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -348,8 +348,9 @@ static u32 load_per_type(struct venus_core *core,
u32 session_type)
return mbs_per_sec;
}
-static int load_scale_clocks(struct venus_core *core)
+static int scale_clocks(struct venus_inst *inst)
{
+ struct venus_core *core = inst->core;
const struct freq_tbl *table = core->res->freq_tbl;
unsigned int num_rows = core->res->freq_tbl_size;
unsigned long freq = table[0].freq;
@@ -398,6 +399,89 @@ static int load_scale_clocks(struct venus_core
*core)
return ret;
}
+static unsigned long calculate_vpp_freq(struct venus_inst *inst)
+{
+ unsigned long vpp_freq = 0;
+ u32 mbs_per_sec;
+
+ mbs_per_sec = load_per_instance(inst);
+ vpp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vpp_freq;
+ /* 21 / 20 is overhead factor */
+ vpp_freq += vpp_freq / 20;
+
+ return vpp_freq;
+}
+
+static int scale_clocks_v4(struct venus_inst *inst)
+{
+ struct venus_core *core = inst->core;
+ const struct freq_tbl *table = core->res->freq_tbl;
+ unsigned int num_rows = core->res->freq_tbl_size;
+ struct clk *clk = core->clks[0];
+ struct device *dev = core->dev;
+ unsigned int i;
+ unsigned long freq = 0, freq_core1 = 0, freq_core2 = 0;
+ int ret;
+
+ freq = calculate_vpp_freq(inst);
+
+ if (freq > table[0].freq)
+ dev_warn(dev, "HW is overloaded, needed: %lu max: %lu\n",
+freq, table[0].freq);
+
...
+ for (i = 0; i < num_rows; i++) {
+ if (freq > table[i].freq)
+ break;
+ freq = table[i].freq;
+ }
The above code snippet will select the biggest table[0].freq always.
Infact do we need to "normalize" the calculated freq to the table of
possible clock rates? I think tjat should be made after sum all needed
frequencies for all cores.
Will correct this. Normalizing after sum of all needed frequencies
would be more precise.
+
+ inst->clk_data.freq = freq;
+
+ mutex_lock(>lock);
+ list_for_each_entry(inst, >instances, list) {
+ if (inst->clk_data.core_id == VIDC_CORE_ID_1) {
+ freq_core1 += inst->clk_data.freq;
+ } else if (inst->clk_data.core_id == VIDC_CORE_ID_2) {
+ freq_core2 += inst->clk_data.freq;
+ } else if (inst->clk_data.core_id == VIDC_CORE_ID_3) {
+ freq_core1 += inst->clk_data.freq;
+ freq_core2 += inst->clk_data.freq;
+ }
+ }
+ mutex_unlock(>lock);
+
+ freq = max(freq_core1, freq_core2);
+
+ ret = clk_set_rate(clk, freq);
+ if (ret)
+ goto err;
+
+ ret = clk_set_rate(core->core0_clk, freq);
+ if (ret)
+ goto err;
+
+ ret = clk_set_rate(core->core1_clk, freq);
+ if (ret)
+ goto err;
This is duplicated in both scale_clocks and scale_clocks_v4, and could
be a common function.
I will move this to common function.
+
+ return 0;
+
+err:
+ dev_err(dev, "failed to set clock rate %lu (%d)\n", freq, ret);
+ return ret;
+}
+
+static int load_scale_clocks(struct venus_inst *inst)
+{
+ if (IS_V4(inst->core))
+ return scale_clocks_v4(inst);
+
+ if (inst->state == INST_START)
+ return 0;
I'm still not sure about this check of the instance state.
If we look into load_per_instance() it already doing similar check :
!(inst->state >= INST_INIT && inst->state < INST_STOP)
This check would just make sure instance state for scaling,
not a mandatory check. I can remove the check.
+
+ return scale_clocks(inst);
+}
+
static void fill_buffer_desc(const struct venus_buffer *buf,
struct hfi_buffer_desc *bd, bool response)
{
@@ -1053,7 +1137,7 @@ void venus_helper_vb2_stop_streaming(struct
vb2_queue *q)
venus_helper_free_dpb_bufs(inst);
- load_scale_clocks(core);
+ load_scale_clocks(inst);
INIT_LIST_HEAD(>registeredbufs);
}
@@ -1070,7 +1154,6 @@ void venus_helper_vb2_stop_streaming(struct
vb2_queue *q)
int venus_helper_vb2_start_streaming(struct
[v4] rtc: pcf85363/pcf85263: fix error that failed to run hwclock -w
Issue: - # hwclock -w hwclock: RTC_SET_TIME: Invalid argument Why: - Relative commit: 8b9f9d4dc511309918c4f6793bae7387c0c638af, this patch will always check for unwritable registers, it will compare reg with max_register in regmap_writeable. - In drivers/rtc/rtc-pcf85363.c, CTRL_STOP_EN is 0x2e, but DT_100THS is 0, max_regiter is 0x2f, then reg will be equal to 0x30, '0x30 < 0x2f' is false,so regmap_writeable will return false. - The pcf85363/pcf85263 has the capability of address wrapping which means if you access a continuous address range across a certain boundary(max_register of struct regmap_config) the hardware actually wraps the access to a lower address. But the address violation check of regmap rejects such access. How: - Split of writing regs to two parts, first part writes control registers about stop_enable and resets, second part writes RTC time and date registers. Signed-off-by: Biwen Li --- Change in v4: - use old scheme - replace link to lkml.org with commit - add proper explanation Change in v3: - replace old scheme with new scheme: increase max_register. Change in v2: - add Why and How into commit message. drivers/rtc/rtc-pcf85363.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c index a075e77617dc..3450d615974d 100644 --- a/drivers/rtc/rtc-pcf85363.c +++ b/drivers/rtc/rtc-pcf85363.c @@ -166,7 +166,12 @@ static int pcf85363_rtc_set_time(struct device *dev, struct rtc_time *tm) buf[DT_YEARS] = bin2bcd(tm->tm_year % 100); ret = regmap_bulk_write(pcf85363->regmap, CTRL_STOP_EN, - tmp, sizeof(tmp)); + tmp, 2); + if (ret) + return ret; + + ret = regmap_bulk_write(pcf85363->regmap, DT_100THS, + buf, sizeof(tmp) - 2); if (ret) return ret; -- 2.17.1
Re: [RESEND PATCH v3 03/20] mtd: spi-nor: Drop quad_enable() from 'struct spi-nor'
On 26/08/19 5:38 PM, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> All flash parameters and settings should reside inside
> 'struct spi_nor_flash_parameter'. Drop the local copy of
> quad_enable() and use the one from 'struct spi_nor_flash_parameter'.
>
> Signed-off-by: Tudor Ambarus
> Reviewed-by: Boris Brezillon
> ---
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
> v3: Collect R-b
>
> drivers/mtd/spi-nor/spi-nor.c | 40 +++-
> include/linux/mtd/spi-nor.h | 2 --
> 2 files changed, 23 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index e9b9cd70a999..effda372cb33 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -4403,7 +4403,6 @@ static int spi_nor_setup(struct spi_nor *nor,
> {
> struct spi_nor_flash_parameter *params = >params;
> u32 ignored_mask, shared_mask;
> - bool enable_quad_io;
> int err;
>
> /*
> @@ -4457,23 +4456,33 @@ static int spi_nor_setup(struct spi_nor *nor,
> return err;
> }
>
> - /* Enable Quad I/O if needed. */
> - enable_quad_io = (spi_nor_get_protocol_width(nor->read_proto) == 4 ||
> - spi_nor_get_protocol_width(nor->write_proto) == 4);
> - if (enable_quad_io && params->quad_enable)
> - nor->quad_enable = params->quad_enable;
> - else
> - nor->quad_enable = NULL;
> -
> return 0;
> }
>
> +/**
> + * spi_nor_quad_enable() - enable Quad I/O if needed.
> + * @nor:pointer to a 'struct spi_nor'
> + *
> + * Return: 0 on success, -errno otherwise.
> + */
> +static int spi_nor_quad_enable(struct spi_nor *nor)
> +{
> + if (!nor->params.quad_enable)
> + return 0;
> +
> + if (!(spi_nor_get_protocol_width(nor->read_proto) == 4 ||
> + spi_nor_get_protocol_width(nor->write_proto) == 4))
> + return 0;
> +
> + return nor->params.quad_enable(nor);
> +}
> +
> static int spi_nor_init(struct spi_nor *nor)
> {
> int err;
>
> if (nor->clear_sr_bp) {
> - if (nor->quad_enable == spansion_quad_enable)
> + if (nor->params.quad_enable == spansion_quad_enable)
> nor->clear_sr_bp = spi_nor_spansion_clear_sr_bp;
>
> err = nor->clear_sr_bp(nor);
> @@ -4484,12 +4493,10 @@ static int spi_nor_init(struct spi_nor *nor)
> }
> }
>
> - if (nor->quad_enable) {
> - err = nor->quad_enable(nor);
> - if (err) {
> - dev_err(nor->dev, "quad mode not supported\n");
> - return err;
> - }
> + err = spi_nor_quad_enable(nor);
> + if (err) {
> + dev_err(nor->dev, "quad mode not supported\n");
> + return err;
> }
>
> if (nor->addr_width == 4 && !(nor->flags & SNOR_F_4B_OPCODES)) {
> @@ -4706,7 +4713,6 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
>* - select op codes for (Fast) Read, Page Program and Sector Erase.
>* - set the number of dummy cycles (mode cycles + wait states).
>* - set the SPI protocols for register and memory accesses.
> - * - set the Quad Enable bit if needed (required by SPI x-y-4 protos).
>*/
> ret = spi_nor_setup(nor, hwcaps);
> if (ret)
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 77ba692d9348..17787238f0e9 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -535,7 +535,6 @@ struct flash_info;
> * @flash_unlock:[FLASH-SPECIFIC] unlock a region of the SPI NOR
> * @flash_is_locked: [FLASH-SPECIFIC] check if a region of the SPI NOR is
> * completely locked
> - * @quad_enable: [FLASH-SPECIFIC] enables SPI NOR quad mode
> * @clear_sr_bp: [FLASH-SPECIFIC] clears the Block Protection Bits from
> * the SPI NOR Status Register.
> * @params: [FLASH-SPECIFIC] SPI-NOR flash parameters and settings.
> @@ -579,7 +578,6 @@ struct spi_nor {
> int (*flash_lock)(struct spi_nor *nor, loff_t ofs, uint64_t len);
> int (*flash_unlock)(struct spi_nor *nor, loff_t ofs, uint64_t len);
> int (*flash_is_locked)(struct spi_nor *nor, loff_t ofs, uint64_t len);
> - int (*quad_enable)(struct spi_nor *nor);
> int (*clear_sr_bp)(struct spi_nor *nor);
> struct spi_nor_flash_parameter params;
>
>
--
Regards
Vignesh
Re: [PATCH v2 2/2] arm: Add DRM_MSM to defconfigs with ARCH_QCOM
On Thu 22 Aug 23:52 PDT 2019, Linus Walleij wrote: > On Tue, Aug 13, 2019 at 4:46 PM Jordan Crouse wrote: > > > Now that CONFIG_DRM_MSM is no longer default 'y' add it as a module to all > > ARCH_QCOM enabled defconfigs to restore the previous expected build > > behavior. > > > > Signed-off-by: Jordan Crouse > > Reviewed-by: Linus Walleij > > I suppose Andy will pick this up? > Not sure why, but this patch isn't in any of my mailboxes. So thanks for the reminder, I've picked it from patchworks for 5.4. Regards, Bjorn
Re: [RESEND PATCH v3 02/20] mtd: spi-nor: Use nor->params
On 26/08/19 5:38 PM, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> The Flash parameters and settings are now stored in 'struct spi_nor'.
> Use this instead of the stack allocated params.
>
> Few functions stop passing pointer to params, as they can get it from
> 'struct spi_nor'. spi_nor_parse_sfdp() and children will keep passing
> pointer to params because of the roll-back mechanism: in case the
> parsing of SFDP fails, the legacy flash parameter and settings will be
> restored.
>
> Zeroing params is no longer needed because all SPI NOR users kzalloc
> 'struct spi_nor'.
>
> Signed-off-by: Tudor Ambarus
> Reviewed-by: Boris Brezillon
> ---
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
> v3: collect R-b
>
> drivers/mtd/spi-nor/spi-nor.c | 46
> ++-
> 1 file changed, 19 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index d35dc6a97521..e9b9cd70a999 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2974,16 +2974,13 @@ static int spi_nor_spimem_check_pp(struct spi_nor
> *nor,
> * spi_nor_spimem_adjust_hwcaps - Find optimal Read/Write protocol
> *based on SPI controller capabilities
> * @nor:pointer to a 'struct spi_nor'
> - * @params: pointer to the 'struct spi_nor_flash_parameter'
> - * representing SPI NOR flash capabilities
> * @hwcaps: pointer to resulting capabilities after adjusting
> * according to controller and flash's capability
> */
> static void
> -spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor,
> - const struct spi_nor_flash_parameter *params,
> - u32 *hwcaps)
> +spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps)
> {
> + struct spi_nor_flash_parameter *params = >params;
> unsigned int cap;
>
> /* DTR modes are not supported yet, mask them all. */
> @@ -4129,16 +4126,13 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> return err;
> }
>
> -static int spi_nor_init_params(struct spi_nor *nor,
> -struct spi_nor_flash_parameter *params)
> +static int spi_nor_init_params(struct spi_nor *nor)
> {
> + struct spi_nor_flash_parameter *params = >params;
> struct spi_nor_erase_map *map = >erase_map;
> const struct flash_info *info = nor->info;
> u8 i, erase_mask;
>
> - /* Set legacy flash parameters as default. */
> - memset(params, 0, sizeof(*params));
> -
> /* Set SPI NOR sizes. */
> params->size = (u64)info->sector_size * info->n_sectors;
> params->page_size = info->page_size;
> @@ -4255,7 +4249,6 @@ static int spi_nor_init_params(struct spi_nor *nor,
> }
>
> static int spi_nor_select_read(struct spi_nor *nor,
> -const struct spi_nor_flash_parameter *params,
> u32 shared_hwcaps)
> {
> int cmd, best_match = fls(shared_hwcaps & SNOR_HWCAPS_READ_MASK) - 1;
> @@ -4268,7 +4261,7 @@ static int spi_nor_select_read(struct spi_nor *nor,
> if (cmd < 0)
> return -EINVAL;
>
> - read = >reads[cmd];
> + read = >params.reads[cmd];
> nor->read_opcode = read->opcode;
> nor->read_proto = read->proto;
>
> @@ -4287,7 +4280,6 @@ static int spi_nor_select_read(struct spi_nor *nor,
> }
>
> static int spi_nor_select_pp(struct spi_nor *nor,
> - const struct spi_nor_flash_parameter *params,
>u32 shared_hwcaps)
> {
> int cmd, best_match = fls(shared_hwcaps & SNOR_HWCAPS_PP_MASK) - 1;
> @@ -4300,7 +4292,7 @@ static int spi_nor_select_pp(struct spi_nor *nor,
> if (cmd < 0)
> return -EINVAL;
>
> - pp = >page_programs[cmd];
> + pp = >params.page_programs[cmd];
> nor->program_opcode = pp->opcode;
> nor->write_proto = pp->proto;
> return 0;
> @@ -4407,9 +4399,9 @@ static int spi_nor_select_erase(struct spi_nor *nor,
> u32 wanted_size)
> }
>
> static int spi_nor_setup(struct spi_nor *nor,
> - const struct spi_nor_flash_parameter *params,
>const struct spi_nor_hwcaps *hwcaps)
> {
> + struct spi_nor_flash_parameter *params = >params;
> u32 ignored_mask, shared_mask;
> bool enable_quad_io;
> int err;
> @@ -4426,7 +4418,7 @@ static int spi_nor_setup(struct spi_nor *nor,
>* need to discard some of them based on what the SPI
>* controller actually supports (using spi_mem_supports_op()).
>*/
> - spi_nor_spimem_adjust_hwcaps(nor, params, _mask);
> + spi_nor_spimem_adjust_hwcaps(nor, _mask);
> } else {
> /*
>* SPI n-n-n protocols are not supported when the SPI
> @@ -4442,7 +4434,7 @@ static int
RE: [PATCH 2/4] mdev: Make mdev alias unique among all mdevs
Hi Mark,
> -Original Message-
> From: Mark Bloch
> Sent: Tuesday, August 27, 2019 4:32 AM
> To: Parav Pandit ; alex.william...@redhat.com; Jiri
> Pirko ; kwankh...@nvidia.com; coh...@redhat.com;
> da...@davemloft.net
> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org;
> net...@vger.kernel.org
> Subject: Re: [PATCH 2/4] mdev: Make mdev alias unique among all mdevs
>
>
>
> On 8/26/19 1:41 PM, Parav Pandit wrote:
> > Mdev alias should be unique among all the mdevs, so that when such
> > alias is used by the mdev users to derive other objects, there is no
> > collision in a given system.
> >
> > Signed-off-by: Parav Pandit
> > ---
> > drivers/vfio/mdev/mdev_core.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/vfio/mdev/mdev_core.c
> > b/drivers/vfio/mdev/mdev_core.c index e825ff38b037..6eb37f0c6369
> > 100644
> > --- a/drivers/vfio/mdev/mdev_core.c
> > +++ b/drivers/vfio/mdev/mdev_core.c
> > @@ -375,6 +375,11 @@ int mdev_device_create(struct kobject *kobj,
> struct device *dev,
> > ret = -EEXIST;
> > goto mdev_fail;
> > }
> > + if (tmp->alias && strcmp(tmp->alias, alias) == 0) {
>
> alias can be NULL here no?
>
If alias is NULL, tmp->alias would also be null because for given parent either
we have alias or we don’t.
So its not possible to have tmp->alias as null and alias as non null.
But it may be good/defensive to add check for both.
> > + mutex_unlock(_list_lock);
> > + ret = -EEXIST;
> > + goto mdev_fail;
> > + }
> > }
> >
> > mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
> >
>
> Mark
Re: [PATCH v5 2/4] clk: qcom: clk-rpmh: Convert to parent data scheme
On Mon 26 Aug 10:31 PDT 2019, Vinod Koul wrote:
> Convert the rpmh clock driver to use the new parent data scheme by
> specifying the parent data for board clock.
>
> Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
> ---
> drivers/clk/qcom/clk-rpmh.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c
> index c3fd632af119..35d55aee6a01 100644
> --- a/drivers/clk/qcom/clk-rpmh.c
> +++ b/drivers/clk/qcom/clk-rpmh.c
> @@ -95,7 +95,10 @@ static DEFINE_MUTEX(rpmh_clk_lock);
> .hw.init = &(struct clk_init_data){ \
> .ops = _rpmh_ops, \
> .name = #_name, \
> - .parent_names = (const char *[]){ "xo_board" }, \
> + .parent_data = &(const struct clk_parent_data){ \
> + .fw_name = "xo",\
> + .name = "xo_board", \
> + }, \
> .num_parents = 1, \
> }, \
> }; \
> @@ -110,7 +113,10 @@ static DEFINE_MUTEX(rpmh_clk_lock);
> .hw.init = &(struct clk_init_data){ \
> .ops = _rpmh_ops, \
> .name = #_name_active, \
> - .parent_names = (const char *[]){ "xo_board" }, \
> + .parent_data = &(const struct clk_parent_data){ \
> + .fw_name = "xo",\
> + .name = "xo_board", \
> + }, \
> .num_parents = 1, \
> }, \
> }
> --
> 2.20.1
>
Re: [v2 PATCH -mm] mm: account deferred split THPs into MemAvailable
On 8/26/19 12:43 AM, Michal Hocko wrote: On Thu 22-08-19 08:33:40, Yang Shi wrote: On 8/22/19 1:04 AM, Michal Hocko wrote: On Thu 22-08-19 01:55:25, Yang Shi wrote: [...] And, they seems very common with the common workloads when THP is enabled. A simple run with MariaDB test of mmtest with THP enabled as always shows it could generate over fifteen thousand deferred split THPs (accumulated around 30G in one hour run, 75% of 40G memory for my VM). It looks worth accounting in MemAvailable. OK, this makes sense. But your above numbers are really worrying. Accumulating such a large amount of pages that are likely not going to be used is really bad. They are essentially blocking any higher order allocations and also push the system towards more memory pressure. That is accumulated number, during the running of the test, some of them were freed by shrinker already. IOW, it should not reach that much at any given time. Then the above description is highly misleading. What is the actual number of lingering THPs that wait for the memory pressure in the peak? By rerunning sysbench mariadb test of mmtest, I didn't see too many THPs in the peak. I saw around 2K THPs sometimes on my VM with 40G memory. But they were short-lived (should be freed when the test exit). And, the number of accumulated THPs are variable. And, this reminded me to go back double check our internal bug report which lead to the "make deferred split shrinker memcg aware" patchset. In that case, a mysql instance with real production load was running in a memcg with ~86G limit, the number of deferred split THPs may reach to ~68G (~34K deferred split THPs) in a few hours. The deferred split THP shrinker was not invoked since global memory pressure is still fine since the host has 256G memory, but memcg limit reclaim was triggered. And, I can't tell if all those deferred split THPs came from mysql or not since there were some other processes run in that container too according to the oom log. I will update the commit log with the more solid data from production environment. IIUC deferred splitting is mostly a workaround for nasty locking issues during splitting, right? This is not really an optimization to cache THPs for reuse or something like that. What is the reason this is not done from a worker context? At least THPs which would be freed completely sound like a good candidate for kworker tear down, no? Yes, deferred split THP was introduced to avoid locking issues according to the document. Memcg awareness would help to trigger the shrinker more often. I think it could be done in a worker context, but when to trigger to worker is a subtle problem. Why? What is the problem to trigger it after unmap of a batch worth of THPs? This leads to another question, how many THPs are "a batch of worth"? And, they may be short-lived as showed by Kirill's example, we can't tell in advance how long the THPs life time is. We may waste cpu cycles to do something unneeded.
RE: [PATCH 1/4] mdev: Introduce sha1 based mdev alias
> -Original Message-
> From: Alex Williamson
> Sent: Tuesday, August 27, 2019 7:15 AM
> To: Parav Pandit
> Cc: Jiri Pirko ; kwankh...@nvidia.com;
> coh...@redhat.com; da...@davemloft.net; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH 1/4] mdev: Introduce sha1 based mdev alias
>
> On Mon, 26 Aug 2019 15:41:16 -0500
> Parav Pandit wrote:
>
> > Whenever a parent requests to generate mdev alias, generate a mdev
> > alias.
> > It is an optional attribute that parent can request to generate for
> > each of its child mdev.
> > mdev alias is generated using sha1 from the mdev name.
> >
> > Signed-off-by: Parav Pandit
> > ---
> > drivers/vfio/mdev/mdev_core.c| 98
> +++-
> > drivers/vfio/mdev/mdev_private.h | 5 +-
> > drivers/vfio/mdev/mdev_sysfs.c | 13 +++--
> > include/linux/mdev.h | 4 ++
> > 4 files changed, 111 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/vfio/mdev/mdev_core.c
> > b/drivers/vfio/mdev/mdev_core.c index b558d4cfd082..e825ff38b037
> > 100644
> > --- a/drivers/vfio/mdev/mdev_core.c
> > +++ b/drivers/vfio/mdev/mdev_core.c
> > @@ -10,9 +10,11 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "mdev_private.h"
> >
> > @@ -27,6 +29,8 @@ static struct class_compat *mdev_bus_compat_class;
> > static LIST_HEAD(mdev_list); static DEFINE_MUTEX(mdev_list_lock);
> >
> > +static struct crypto_shash *alias_hash;
> > +
> > struct device *mdev_parent_dev(struct mdev_device *mdev) {
> > return mdev->parent->dev;
> > @@ -164,6 +168,18 @@ int mdev_register_device(struct device *dev, const
> struct mdev_parent_ops *ops)
> > goto add_dev_err;
> > }
> >
> > + if (ops->get_alias_length) {
> > + unsigned int digest_size;
> > + unsigned int aligned_len;
> > +
> > + aligned_len = roundup(ops->get_alias_length(), 2);
> > + digest_size = crypto_shash_digestsize(alias_hash);
> > + if (aligned_len / 2 > digest_size) {
> > + ret = -EINVAL;
> > + goto add_dev_err;
> > + }
> > + }
>
> This looks like a sanity check, it could be done outside of the
> parent_list_lock, even before we get a parent device reference.
>
Yes.
> I think we're using a callback for get_alias_length() rather than a fixed
> field
> to support the mtty module option added in patch 4, right?
Right.
I will move the check outside.
> Its utility is rather limited with no args. I could imagine that if a parent
> wanted to generate an alias that could be incorporated into a string with the
> parent device name that it would be useful to call this with the parent
> device as an arg. I guess we can save that until a user comes along though.
>
Right. We save until user arrives.
I suggest you review the extra complexity I added here for vendor driven alias
length, which I think we should do when an actual user comes along.
> There doesn't seem to be anything serializing use of alias_hash.
>
Each sha1 calculation is happening on the new descriptor allocated and
initialized using crypto_shash_init().
So it appears to me that each hash calculation can occur in parallel on the
individual desc.
> > +
> > parent = kzalloc(sizeof(*parent), GFP_KERNEL);
> > if (!parent) {
> > ret = -ENOMEM;
> > @@ -259,6 +275,7 @@ static void mdev_device_free(struct mdev_device
> *mdev)
> > mutex_unlock(_list_lock);
> >
> > dev_dbg(>dev, "MDEV: destroying\n");
> > + kvfree(mdev->alias);
> > kfree(mdev);
> > }
> >
> > @@ -269,18 +286,86 @@ static void mdev_device_release(struct device
> *dev)
> > mdev_device_free(mdev);
> > }
> >
> > -int mdev_device_create(struct kobject *kobj,
> > - struct device *dev, const guid_t *uuid)
> > +static const char *
> > +generate_alias(const char *uuid, unsigned int max_alias_len) {
> > + struct shash_desc *hash_desc;
> > + unsigned int digest_size;
> > + unsigned char *digest;
> > + unsigned int alias_len;
> > + char *alias;
> > + int ret = 0;
> > +
> > + /* Align to multiple of 2 as bin2hex will generate
> > +* even number of bytes.
> > +*/
>
> Comment style for non-networking code please.
Ack.
>
> > + alias_len = roundup(max_alias_len, 2);
> > + alias = kvzalloc(alias_len + 1, GFP_KERNEL);
>
> The size we're generating here should be small enough to just use kzalloc(),
Ack.
> probably below too.
>
Descriptor size is 96 bytes long. kvzalloc is more optimal.
> > + if (!alias)
> > + return NULL;
> > +
> > + /* Allocate and init descriptor */
> > + hash_desc = kvzalloc(sizeof(*hash_desc) +
> > +crypto_shash_descsize(alias_hash),
> > +GFP_KERNEL);
> > + if (!hash_desc)
> > + goto desc_err;
> > +
> > + hash_desc->tfm = alias_hash;
> > +
> > +
Re: [RESEND PATCH v3 01/20] mtd: spi-nor: Regroup flash parameter and settings
On 26/08/19 5:38 PM, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> The scope is to move all [FLASH-SPECIFIC] parameters and settings
> from 'struct spi_nor' to 'struct spi_nor_flash_parameter'.
>
> 'struct spi_nor_flash_parameter' describes the hardware capabilities
> and associated settings of the SPI NOR flash memory. It includes
> legacy flash parameters and settings that can be overwritten by the
> spi_nor_fixups hooks, or dynamically when parsing the JESD216
> Serial Flash Discoverable Parameters (SFDP) tables. All SFDP params
> and settings will fit inside 'struct spi_nor_flash_parameter'.
>
> Move spi_nor_hwcaps related code to avoid forward declarations.
> Add a forward declaration that we can't avoid: 'struct spi_nor' will
> be used in 'struct spi_nor_flash_parameter'.
>
> Signed-off-by: Tudor Ambarus
> Reviewed-by: Boris Brezillon
> ---
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
> v3: collect R-b
>
> drivers/mtd/spi-nor/spi-nor.c | 65
> include/linux/mtd/spi-nor.h | 239
> +-
> 2 files changed, 164 insertions(+), 140 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 0597cb8257b0..d35dc6a97521 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -40,71 +40,6 @@
> #define SPI_NOR_MAX_ID_LEN 6
> #define SPI_NOR_MAX_ADDR_WIDTH 4
>
> -struct spi_nor_read_command {
> - u8 num_mode_clocks;
> - u8 num_wait_states;
> - u8 opcode;
> - enum spi_nor_protocol proto;
> -};
> -
> -struct spi_nor_pp_command {
> - u8 opcode;
> - enum spi_nor_protocol proto;
> -};
> -
> -enum spi_nor_read_command_index {
> - SNOR_CMD_READ,
> - SNOR_CMD_READ_FAST,
> - SNOR_CMD_READ_1_1_1_DTR,
> -
> - /* Dual SPI */
> - SNOR_CMD_READ_1_1_2,
> - SNOR_CMD_READ_1_2_2,
> - SNOR_CMD_READ_2_2_2,
> - SNOR_CMD_READ_1_2_2_DTR,
> -
> - /* Quad SPI */
> - SNOR_CMD_READ_1_1_4,
> - SNOR_CMD_READ_1_4_4,
> - SNOR_CMD_READ_4_4_4,
> - SNOR_CMD_READ_1_4_4_DTR,
> -
> - /* Octal SPI */
> - SNOR_CMD_READ_1_1_8,
> - SNOR_CMD_READ_1_8_8,
> - SNOR_CMD_READ_8_8_8,
> - SNOR_CMD_READ_1_8_8_DTR,
> -
> - SNOR_CMD_READ_MAX
> -};
> -
> -enum spi_nor_pp_command_index {
> - SNOR_CMD_PP,
> -
> - /* Quad SPI */
> - SNOR_CMD_PP_1_1_4,
> - SNOR_CMD_PP_1_4_4,
> - SNOR_CMD_PP_4_4_4,
> -
> - /* Octal SPI */
> - SNOR_CMD_PP_1_1_8,
> - SNOR_CMD_PP_1_8_8,
> - SNOR_CMD_PP_8_8_8,
> -
> - SNOR_CMD_PP_MAX
> -};
> -
> -struct spi_nor_flash_parameter {
> - u64 size;
> - u32 page_size;
> -
> - struct spi_nor_hwcaps hwcaps;
> - struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
> - struct spi_nor_pp_command page_programs[SNOR_CMD_PP_MAX];
> -
> - int (*quad_enable)(struct spi_nor *nor);
> -};
> -
> struct sfdp_parameter_header {
> u8 id_lsb;
> u8 minor;
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 3075ac73b171..77ba692d9348 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -334,6 +334,165 @@ struct spi_nor_erase_map {
> };
>
> /**
> + * struct spi_nor_hwcaps - Structure for describing the hardware capabilies
> + * supported by the SPI controller (bus master).
> + * @mask:the bitmask listing all the supported hw capabilies
> + */
> +struct spi_nor_hwcaps {
> + u32 mask;
> +};
> +
> +/*
> + *(Fast) Read capabilities.
> + * MUST be ordered by priority: the higher bit position, the higher priority.
> + * As a matter of performances, it is relevant to use Octal SPI protocols
> first,
> + * then Quad SPI protocols before Dual SPI protocols, Fast Read and lastly
> + * (Slow) Read.
> + */
> +#define SNOR_HWCAPS_READ_MASKGENMASK(14, 0)
> +#define SNOR_HWCAPS_READ BIT(0)
> +#define SNOR_HWCAPS_READ_FASTBIT(1)
> +#define SNOR_HWCAPS_READ_1_1_1_DTR BIT(2)
> +
> +#define SNOR_HWCAPS_READ_DUALGENMASK(6, 3)
> +#define SNOR_HWCAPS_READ_1_1_2 BIT(3)
> +#define SNOR_HWCAPS_READ_1_2_2 BIT(4)
> +#define SNOR_HWCAPS_READ_2_2_2 BIT(5)
> +#define SNOR_HWCAPS_READ_1_2_2_DTR BIT(6)
> +
> +#define SNOR_HWCAPS_READ_QUADGENMASK(10, 7)
> +#define SNOR_HWCAPS_READ_1_1_4 BIT(7)
> +#define SNOR_HWCAPS_READ_1_4_4 BIT(8)
> +#define SNOR_HWCAPS_READ_4_4_4 BIT(9)
> +#define SNOR_HWCAPS_READ_1_4_4_DTR BIT(10)
> +
> +#define SNOR_HWCAPS_READ_OCTAL GENMASK(14, 11)
> +#define SNOR_HWCAPS_READ_1_1_8 BIT(11)
> +#define SNOR_HWCAPS_READ_1_8_8 BIT(12)
> +#define
Re: [linux-sunxi] [PATCH v6 1/3] ASoC: sun4i-i2s: incorrect regmap for A83T
On Tue, Aug 27, 2019 at 2:07 AM wrote:
>
> From: Marcus Cooper
>
> The regmap configuration is set up for the legacy block on the
> A83T whereas it uses the new block with a larger register map.
Looking at the code Allwinner previously released [1], that doesn't seem to be
the case. Keep in mind that the register map shown in the user manual is for
the TDM interface, which we don't actually support right now.
The file shows the base address as 0x01c22800, and the last defined register
is SUNXI_RXCHMAP at 0x3c.
The I2S driver [2] also shows that it is the old register map size, but with
TX_FIFO and INT_STA swapped around. This might mean that it would need a
separate regmap_config, as the read/write callbacks need to be changed to
fit the swapped registers.
Finally, the TDM driver [3], which matches the TDM section in the manual, shows
a larger register map.
A83T is SUN8IW6, while SUN8IW7 refers to the H3.
ChenYu
[1]
https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/hdmiaudio/sunxi-hdmipcm.h
[2]
https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/i2s0/sunxi-i2s0.h
[3]
https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/daudio0/sunxi-daudio0.h
> Fixes: 21faaea1343f ("ASoC: sun4i-i2s: Add support for A83T")
> Signed-off-by: Marcus Cooper
> ---
> sound/soc/sunxi/sun4i-i2s.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 57bf2a33753e..34575a8aa9f6 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -1100,7 +1100,7 @@ static const struct sun4i_i2s_quirks
> sun6i_a31_i2s_quirks = {
> static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
> .has_reset = true,
> .reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
> - .sun4i_i2s_regmap = _i2s_regmap_config,
> + .sun4i_i2s_regmap = _i2s_regmap_config,
> .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
> .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
> .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
> --
> 2.23.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/linux-sunxi/20190826180734.15801-2-codekipper%40gmail.com.
Re: [RESEND, PATCH v13 09/12] soc: mediatek: cmdq: define the instruction struct
On Fri, 2019-08-23 at 15:50 +0200, Matthias Brugger wrote:
>
> On 20/08/2019 10:49, Bibby Hsieh wrote:
> > Define an instruction structure for gce driver to append command.
> > This structure can make the client's code more readability.
> >
> > Signed-off-by: Bibby Hsieh
> > Reviewed-by: CK Hu
> > ---
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 106 +++
> > include/linux/mailbox/mtk-cmdq-mailbox.h | 2 +
> > 2 files changed, 74 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index 7aa0517ff2f3..e3d5b0be8e79 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -9,12 +9,24 @@
> > #include
> > #include
> >
> > -#define CMDQ_ARG_A_WRITE_MASK 0x
> > #define CMDQ_WRITE_ENABLE_MASK BIT(0)
> > #define CMDQ_EOC_IRQ_ENBIT(0)
> > #define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC <<
> > CMDQ_OP_CODE_SHIFT)) \
> > << 32 | CMDQ_EOC_IRQ_EN)
> >
> > +struct cmdq_instruction {
> > + union {
> > + u32 value;
> > + u32 mask;
> > + };
> > + union {
> > + u16 offset;
> > + u16 event;
> > + };
> > + u8 subsys;
> > + u8 op;
> > +};
> > +
> > static void cmdq_client_timeout(struct timer_list *t)
> > {
> > struct cmdq_client *client = from_timer(client, t, timer);
> > @@ -110,10 +122,8 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> > }
> > EXPORT_SYMBOL(cmdq_pkt_destroy);
> >
> > -static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code
> > code,
> > - u32 arg_a, u32 arg_b)
> > +static struct cmdq_instruction *cmdq_pkt_append_command(struct cmdq_pkt
> > *pkt)
> > {
> > - u64 *cmd_ptr;
> >
> > if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
> > /*
> > @@ -127,81 +137,109 @@ static int cmdq_pkt_append_command(struct cmdq_pkt
> > *pkt, enum cmdq_code code,
> > pkt->cmd_buf_size += CMDQ_INST_SIZE;
> > WARN_ONCE(1, "%s: buffer size %u is too small !\n",
> > __func__, (u32)pkt->buf_size);
> > - return -ENOMEM;
> > + return NULL;
> > }
> > - cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
> > - (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
> > +
> > + *(u64 *)(pkt->va_base + pkt->cmd_buf_size) = 0;>
> > pkt->cmd_buf_size += CMDQ_INST_SIZE;
> >
> > - return 0;
> > + return pkt->va_base + pkt->cmd_buf_size - CMDQ_INST_SIZE;
> > }
> >
> > int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
> > {
> > - u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> > - (subsys << CMDQ_SUBSYS_SHIFT);
> > + struct cmdq_instruction *inst;
> > +
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_WRITE;
> > + inst->value = value;
> > + inst->offset = offset;
> > + inst->subsys = subsys;
> >
>
> I can see that using cmdq_instruction will make the code more readable, but I
> dislike the approach that cmdq_pkt_append_command returns a pointer where we
> write the instruction to. Better we pass inst to cmdq_pkt_append_command() and
> write it there to cmd_ptr.
>
> I think this way we can get rid of explicitly setting the memory to zero:
> *(u64 *)(pkt->va_base + pkt->cmd_buf_size) = 0;
>
> And if we pass the inst to the append_command we don't have to change the
> return
> value handling of cmdq_pkt_append_command(), which makes the patch easier to
> understand.
Ok, I will change and resend it.
>
> > - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
> > + return 0;
> > }
> > EXPORT_SYMBOL(cmdq_pkt_write);
> >
> > int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> > u16 offset, u32 value, u32 mask)
> > {
> > - u32 offset_mask = offset;
> > - int err = 0;
> > + struct cmdq_instruction *inst;
> > + u16 offset_mask = offset;
> >
> > if (mask != 0x) {
> > - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_MASK;
> > + inst->mask = ~mask;
> > offset_mask |= CMDQ_WRITE_ENABLE_MASK;
> > }
> > - err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
> >
> > - return err;
> > + return cmdq_pkt_write(pkt, subsys, offset_mask, value);
> > }
> > EXPORT_SYMBOL(cmdq_pkt_write_mask);
> >
> > int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> > {
> > - u32 arg_b;
> > + struct cmdq_instruction *inst;
> >
> > if (event >= CMDQ_MAX_EVENT)
> > return -EINVAL;
> >
> > - /*
> > -* WFE arg_b
> > -* bit 0-11:
Re: [RESEND, PATCH v13 10/12] soc: mediatek: cmdq: add polling function
On Fri, 2019-08-23 at 16:05 +0200, Matthias Brugger wrote:
>
> On 20/08/2019 10:49, Bibby Hsieh wrote:
> > add polling function in cmdq helper functions
> >
> > Signed-off-by: Bibby Hsieh
> > Reviewed-by: CK Hu
> > ---
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 28
> > include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
> > include/linux/soc/mediatek/mtk-cmdq.h| 15 +
> > 3 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index e3d5b0be8e79..c53f8476c68d 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -221,6 +221,34 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16
> > event)
> > }
> > EXPORT_SYMBOL(cmdq_pkt_clear_event);
> >
> > +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> > + u16 offset, u32 value, u32 mask)
> > +{
> > + struct cmdq_instruction *inst;
> > +
> > + if (mask != 0x) {
>
> Is this necessary? Can't we just always set the mask, even if it's 0x?
>
> Regarding interfaces, depending on how often you expect the mask being ~0 we
> might think of adding a cmdq_pkt_poll_mask call.
> What I want to say, if in the end most of the callers will use the mask with
> 0x, then we should add a call cmdq_pkt_poll_mask which actually allows
> to set the mask and let cmdq_pkt_poll set the mask in it's function body.
> As I already said, this depends on how often you think a caller will
> use/not-use
> the mask.
> Does this make sense?
It's better to have two function: cmdq_pkt_poll_mask and cmdq_pkt_poll,
client can choose which they need by themselves.
Thanks for the comments.
Bibby
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_MASK;
> > + inst->value = ~mask;
> > + offset = offset | 0x1;
> > + }
> > +
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_POLL;
> > + inst->value = value;
> > + inst->offset = offset;
> > + inst->subsys = subsys;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(cmdq_pkt_poll);
> > +
> > static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> > {
> > struct cmdq_instruction *inst;
> > diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> > b/include/linux/mailbox/mtk-cmdq-mailbox.h
> > index c8adedefaf42..9e3502945bc1 100644
> > --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> > +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> > @@ -46,6 +46,7 @@
> > enum cmdq_code {
> > CMDQ_CODE_MASK = 0x02,
> > CMDQ_CODE_WRITE = 0x04,
> > + CMDQ_CODE_POLL = 0x08,
> > CMDQ_CODE_JUMP = 0x10,
> > CMDQ_CODE_WFE = 0x20,
> > CMDQ_CODE_EOC = 0x40,
> > diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> > b/include/linux/soc/mediatek/mtk-cmdq.h
> > index 9618debb9ceb..a345870a6d10 100644
> > --- a/include/linux/soc/mediatek/mtk-cmdq.h
> > +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> > @@ -99,6 +99,21 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
> > */
> > int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
> >
> > +/**
> > + * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
> > + * execute an instruction that wait for a specified hardware
> > + * register to check for the value. All GCE hardware
> > + * threads will be blocked by this instruction.
> > + * @pkt: the CMDQ packet
> > + * @subsys:the CMDQ sub system code
> > + * @offset:register offset from CMDQ sub system
> > + * @value: the specified target register value
> > + * @mask: the specified target register mask
> > + *
> > + * Return: 0 for success; else the error code is returned
> > + */
> > +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> > + u16 offset, u32 value, u32 mask);
> > /**
> > * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> > * packet and call back at the end of done packet
> >
Re: [PATCH] platform/chrome: cros_ec_rpmsg: Add host command AP sleep state support
Tested that with this patch, SCP does receive host command from AP
while AP goes to suspend and back.
Tested-by: Pi-Hsun Shih
On Fri, Aug 23, 2019 at 3:36 AM Enric Balletbo i Serra
wrote:
>
> Hi,
>
> On 14/8/19 10:17, Yilun Lin wrote:
> > Add EC host command to inform EC of AP suspend/resume status.
> >
> > Signed-off-by: Yilun Lin
>
> The patch looks good to me but as I don't have the hardware to test this,
> could
> I get a Tested-by Pi-Hsun if possible before queuing in chrome-platform-5.4
>
> Thanks,
> Enric
>
> > ---
> >
> > drivers/platform/chrome/cros_ec_rpmsg.c | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_rpmsg.c
> > b/drivers/platform/chrome/cros_ec_rpmsg.c
> > index 5d3fb2abad1d..6f34fe629e2c 100644
> > --- a/drivers/platform/chrome/cros_ec_rpmsg.c
> > +++ b/drivers/platform/chrome/cros_ec_rpmsg.c
> > @@ -236,6 +236,25 @@ static void cros_ec_rpmsg_remove(struct rpmsg_device
> > *rpdev)
> > cancel_work_sync(_rpmsg->host_event_work);
> > }
> >
> > +#ifdef CONFIG_PM_SLEEP
> > +static int cros_ec_rpmsg_suspend(struct device *dev)
> > +{
> > + struct cros_ec_device *ec_dev = dev_get_drvdata(dev);
> > +
> > + return cros_ec_suspend(ec_dev);
> > +}
> > +
> > +static int cros_ec_rpmsg_resume(struct device *dev)
> > +{
> > + struct cros_ec_device *ec_dev = dev_get_drvdata(dev);
> > +
> > + return cros_ec_resume(ec_dev);
> > +}
> > +#endif
> > +
> > +static SIMPLE_DEV_PM_OPS(cros_ec_rpmsg_pm_ops, cros_ec_rpmsg_suspend,
> > + cros_ec_rpmsg_resume);
> > +
> > static const struct of_device_id cros_ec_rpmsg_of_match[] = {
> > { .compatible = "google,cros-ec-rpmsg", },
> > { }
> > @@ -246,6 +265,7 @@ static struct rpmsg_driver cros_ec_driver_rpmsg = {
> > .drv = {
> > .name = "cros-ec-rpmsg",
> > .of_match_table = cros_ec_rpmsg_of_match,
> > + .pm = _ec_rpmsg_pm_ops,
> > },
> > .probe = cros_ec_rpmsg_probe,
> > .remove = cros_ec_rpmsg_remove,
> >
[PATCH v2 2/3] mtd: spi-nor: cadence-quadspi: disable DMA and DAC for Intel LGM
From: Ramuthevar Vadivel Murugan
on Intel's Lightning Mountain(LGM) SoCs QSPI controller do not use
Direct Memory Access(DMA) and Direct Access Controller(DAC).
This patch introduces to properly disable the DMA and DAC
for data transfer instead it uses indirect data transfer.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/mtd/spi-nor/Kconfig | 2 +-
drivers/mtd/spi-nor/cadence-quadspi.c | 21 ++---
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 6de83277ce8b..ba2e372ae514 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -34,7 +34,7 @@ config SPI_ASPEED_SMC
config SPI_CADENCE_QUADSPI
tristate "Cadence Quad SPI controller"
- depends on OF && (ARM || ARM64 || COMPILE_TEST)
+ depends on OF && (ARM || ARM64 || COMPILE_TEST || X86)
help
Enable support for the Cadence Quad SPI Flash controller.
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 67f15a1f16fd..69fa13e95110 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -517,12 +517,16 @@ static int cqspi_indirect_read_execute(struct spi_nor
*nor, u8 *rxbuf,
struct cqspi_st *cqspi = f_pdata->cqspi;
void __iomem *reg_base = cqspi->iobase;
void __iomem *ahb_base = cqspi->ahb_base;
+ u32 trigger_address = cqspi->trigger_address;
unsigned int remaining = n_rx;
unsigned int mod_bytes = n_rx % 4;
unsigned int bytes_to_read = 0;
u8 *rxbuf_end = rxbuf + n_rx;
int ret = 0;
+ if (!f_pdata->use_direct_mode)
+ writel(trigger_address, reg_base + CQSPI_REG_INDIRECTTRIGGER);
+
writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR);
writel(remaining, reg_base + CQSPI_REG_INDIRECTRDBYTES);
@@ -609,6 +613,14 @@ static int cqspi_write_setup(struct spi_nor *nor)
struct cqspi_st *cqspi = f_pdata->cqspi;
void __iomem *reg_base = cqspi->iobase;
+ /* Disable the DMA and direct access controller */
+ if (!f_pdata->use_direct_mode) {
+ reg = readl(reg_base + CQSPI_REG_CONFIG);
+ reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ reg &= ~CQSPI_REG_CONFIG_DMA_MASK;
+ writel(reg, reg_base + CQSPI_REG_CONFIG);
+ }
+
/* Set opcode. */
reg = nor->program_opcode << CQSPI_REG_WR_INSTR_OPCODE_LSB;
writel(reg, reg_base + CQSPI_REG_WR_INSTR);
@@ -1171,7 +1183,8 @@ static int cqspi_of_get_pdata(struct platform_device
*pdev)
return -ENXIO;
}
- cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en");
+ if (!of_device_is_compatible(np, "intel,lgm-qspi"))
+ cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en");
return 0;
}
@@ -1301,7 +1314,8 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
struct device_node *np)
f_pdata->registered = true;
if (mtd->size <= cqspi->ahb_size) {
- f_pdata->use_direct_mode = true;
+ f_pdata->use_direct_mode =
+ !(of_device_is_compatible(np,
"intel,lgm-qspi"));
dev_dbg(nor->dev, "using direct mode for %s\n",
mtd->name);
@@ -1347,7 +1361,7 @@ static int cqspi_probe(struct platform_device *pdev)
}
/* Obtain QSPI clock. */
- cqspi->clk = devm_clk_get(dev, NULL);
+ cqspi->clk = devm_clk_get(dev, "qspi");
if (IS_ERR(cqspi->clk)) {
dev_err(dev, "Cannot claim QSPI clock.\n");
return PTR_ERR(cqspi->clk);
@@ -1369,6 +1383,7 @@ static int cqspi_probe(struct platform_device *pdev)
return PTR_ERR(cqspi->ahb_base);
}
cqspi->mmap_phys_base = (dma_addr_t)res_ahb->start;
+ cqspi->trigger_address = res_ahb->start;
cqspi->ahb_size = resource_size(res_ahb);
init_completion(>transfer_complete);
--
2.11.0
[PATCH v2 3/3] mtd: spi-nor: cadence-quadspi: disable the auto-poll for Intel LGM
From: Ramuthevar Vadivel Murugan
On Intel's Lightning Mountain(LGM) SoC QSPI controller do not auto-poll.
This patch introduces to properly disable the auto-polling feature to
improve the performance of cadence-quadspi.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/mtd/spi-nor/cadence-quadspi.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 69fa13e95110..94aa40e868a1 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -134,6 +134,8 @@ struct cqspi_driver_platdata {
#define CQSPI_REG_RD_INSTR_TYPE_DATA_MASK 0x3
#define CQSPI_REG_RD_INSTR_DUMMY_MASK 0x1F
+#define CQSPI_REG_WR_COMPLETION_CTRL 0x38
+#define CQSPI_REG_WR_COMPLETION_DISABLE_AUTO_POLL BIT(14)
#define CQSPI_REG_WR_INSTR 0x08
#define CQSPI_REG_WR_INSTR_OPCODE_LSB 0
#define CQSPI_REG_WR_INSTR_TYPE_ADDR_LSB 12
@@ -470,6 +472,18 @@ static int cqspi_command_write_addr(struct spi_nor *nor,
return cqspi_exec_flash_cmd(cqspi, reg);
}
+static int cqspi_disable_auto_poll(struct cqspi_st *cqspi)
+{
+ void __iomem *reg_base = cqspi->iobase;
+ unsigned int reg;
+
+ reg = readl(reg_base + CQSPI_REG_WR_COMPLETION_CTRL);
+ reg |= CQSPI_REG_WR_COMPLETION_DISABLE_AUTO_POLL;
+ writel(reg, reg_base + CQSPI_REG_WR_COMPLETION_CTRL);
+
+ return 0;
+}
+
static int cqspi_read_setup(struct spi_nor *nor)
{
struct cqspi_flash_pdata *f_pdata = nor->priv;
@@ -507,6 +521,11 @@ static int cqspi_read_setup(struct spi_nor *nor)
reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
reg |= (nor->addr_width - 1);
writel(reg, reg_base + CQSPI_REG_SIZE);
+
+ /* Disable auto-polling */
+ if (!f_pdata->use_direct_mode)
+ cqspi_disable_auto_poll(cqspi);
+
return 0;
}
@@ -631,6 +650,11 @@ static int cqspi_write_setup(struct spi_nor *nor)
reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
reg |= (nor->addr_width - 1);
writel(reg, reg_base + CQSPI_REG_SIZE);
+
+ /* Disable auto-polling */
+ if (!f_pdata->use_direct_mode)
+ cqspi_disable_auto_poll(cqspi);
+
return 0;
}
--
2.11.0
Re: [RESEND, PATCH v13 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
On Fri, 2019-08-23 at 16:21 +0200, Matthias Brugger wrote:
>
> On 20/08/2019 10:49, Bibby Hsieh wrote:
> > GCE cannot know the register base address, this function
> > can help cmdq client to get the cmdq_client_reg structure.
> >
> > Signed-off-by: Bibby Hsieh
> > Reviewed-by: CK Hu
> > ---
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++
> > include/linux/soc/mediatek/mtk-cmdq.h | 21 +++
> > 2 files changed, 50 insertions(+)
> >
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index c53f8476c68d..80f75a1075b4 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -27,6 +27,35 @@ struct cmdq_instruction {
> > u8 op;
> > };
> >
> > +int cmdq_dev_get_client_reg(struct device *dev,
> > + struct cmdq_client_reg *client_reg, int idx)
> > +{
>
> Can't we do/call this in cmdq_mbox_create parsing the number of gce-client-reg
> properties we have and allocating these using a pointer to cmdq_client_reg in
> cmdq_client?
> We will have to free the pointer then in cmdq_mbox_destroy.
>
> Regards,
> Matthias
I don't think we need to keep the cmdq_client_reg in cmdq_client
structure.
Because our client will have own data structure, they will copy the
client_reg information into their own structure.
In the design now, we do not allocate the cmdq_client_reg, client pass
the cmdq_client_reg pointer into this API.
Client will destroy the pointer after they get the information they
want.
Thanks for the comments so much.
Bibby
>
> > + struct of_phandle_args spec;
> > + int err;
> > +
> > + if (!client_reg)
> > + return -ENOENT;
> > +
> > + err = of_parse_phandle_with_fixed_args(dev->of_node,
> > + "mediatek,gce-client-reg",
> > + 3, idx, );
> > + if (err < 0) {
> > + dev_err(dev,
> > + "error %d can't parse gce-client-reg property (%d)",
> > + err, idx);
> > +
> > + return err;
> > + }
> > +
> > + client_reg->subsys = (u8)spec.args[0];
> > + client_reg->offset = (u16)spec.args[1];
> > + client_reg->size = (u16)spec.args[2];
> > + of_node_put(spec.np);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(cmdq_dev_get_client_reg);
> > +
> > static void cmdq_client_timeout(struct timer_list *t)
> > {
> > struct cmdq_client *client = from_timer(client, t, timer);
> > diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> > b/include/linux/soc/mediatek/mtk-cmdq.h
> > index a345870a6d10..02ddd60b212f 100644
> > --- a/include/linux/soc/mediatek/mtk-cmdq.h
> > +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> > @@ -15,6 +15,12 @@
> >
> > struct cmdq_pkt;
> >
> > +struct cmdq_client_reg {
> > + u8 subsys;
> > + u16 offset;
> > + u16 size;
> > +};
> > +
> > struct cmdq_client {
> > spinlock_t lock;
> > u32 pkt_cnt;
> > @@ -24,6 +30,21 @@ struct cmdq_client {
> > u32 timeout_ms; /* in unit of microsecond */
> > };
> >
> > +/**
> > + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
> > + *node of CMDQ client
> > + * @dev: device of CMDQ mailbox client
> > + * @client_reg: CMDQ client reg pointer
> > + * @idx: the index of desired reg
> > + *
> > + * Return: 0 for success; else the error code is returned
> > + *
> > + * Help CMDQ client parsing the cmdq client reg
> > + * from the device node of CMDQ client.
> > + */
> > +int cmdq_dev_get_client_reg(struct device *dev,
> > + struct cmdq_client_reg *client_reg, int idx);
> > +
> > /**
> > * cmdq_mbox_create() - create CMDQ mailbox client and channel
> > * @dev: device of CMDQ mailbox client
> >
[PATCH v2 1/3] dt-bindings: mtd: cadence-qspi:add support for Intel lgm-qspi
From: Ramuthevar Vadivel Murugan Add new vendor specific compatible string to check Intel's Lightning Mountain(LGM) QSPI features enablement in cadence-quadspi driver. Signed-off-by: Ramuthevar Vadivel Murugan --- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index 945be7d5b236..8ace832a2d80 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -5,6 +5,7 @@ Required properties: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". + For Intel LGM SoC - "intel,lgm-qspi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.11.0
[PATCH v2 0/3] dt-bindings: mtd: cadence-qspi:add support for Intel lgm-qspi
mtd: spi-nor: cadence-quadspi: disable DMA and DAC for Intel LGM mtd: spi-nor: cadence-quadspi: disable the auto-poll for Intel LGM changes from V1: - many thanks to Vignesh for review comments. - split 2 patches one for DMA and DAC and other one is disable the auto-poll - removed ahb_phy_addr and used existing trigger_address - trigger_address property used. Ramuthevar Vadivel Murugan (3): dt-bindings: mtd: cadence-qspi:add support for Intel lgm-qspi mtd: spi-nor: cadence-quadspi: disable DMA and DAC for Intel LGM mtd: spi-nor: cadence-quadspi: disable the auto-poll for Intel LGM .../devicetree/bindings/mtd/cadence-quadspi.txt| 1 + drivers/mtd/spi-nor/Kconfig| 2 +- drivers/mtd/spi-nor/cadence-quadspi.c | 45 -- 3 files changed, 44 insertions(+), 4 deletions(-) -- 2.11.0
[PATCH] ASoC: imx-audmix: register the card on a proper dev
This platform device is registered from "fsl_audmix", which is
its parent device. If use pdev->dev.parent for the priv->card.dev,
the value set by dev_set_drvdata in parent device will be covered
by the value in child device.
Fixes: b86ef5367761 ("ASoC: fsl: Add Audio Mixer machine driver")
Signed-off-by: Viorel Suman
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/imx-audmix.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
index 9e1cb18859ce..71590ca6394b 100644
--- a/sound/soc/fsl/imx-audmix.c
+++ b/sound/soc/fsl/imx-audmix.c
@@ -325,14 +325,14 @@ static int imx_audmix_probe(struct platform_device *pdev)
priv->card.num_configs = priv->num_dai_conf;
priv->card.dapm_routes = priv->dapm_routes;
priv->card.num_dapm_routes = priv->num_dapm_routes;
- priv->card.dev = pdev->dev.parent;
+ priv->card.dev = >dev;
priv->card.owner = THIS_MODULE;
priv->card.name = "imx-audmix";
platform_set_drvdata(pdev, >card);
snd_soc_card_set_drvdata(>card, priv);
- ret = devm_snd_soc_register_card(pdev->dev.parent, >card);
+ ret = devm_snd_soc_register_card(>dev, >card);
if (ret) {
dev_err(>dev, "snd_soc_register_card failed\n");
return ret;
--
2.21.0
Re: [PATCH 4/4] iio: adc: ina2xx: Use label proper for device identification
On 26/08/2019 02:07, Jonathan Cameron wrote: On Wed, 21 Aug 2019 11:12:00 +0200 Michal Simek wrote: On 21. 08. 19 4:11, Phil Reid wrote: On 20/08/2019 22:11, Michal Simek wrote: Add support for using label property for easier device identification via iio framework. Signed-off-by: Michal Simek --- drivers/iio/adc/ina2xx-adc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c index 7c7c63677bf4..077c54915f70 100644 --- a/drivers/iio/adc/ina2xx-adc.c +++ b/drivers/iio/adc/ina2xx-adc.c @@ -1033,7 +1033,7 @@ static int ina2xx_probe(struct i2c_client *client, snprintf(chip->name, sizeof(chip->name), "%s-%s", client->name, dev_name(>dev)); - indio_dev->name = chip->name; + indio_dev->name = of_get_property(np, "label", NULL) ? : chip->name; indio_dev->setup_ops = _setup_ops; buffer = devm_iio_kfifo_allocate(_dev->dev); I like this personally. It'd be nice if it was a core function so it could be an opt in to any iio device. Don't know how well received that'd be thou. I'm not particularly keen on changing the semantics of existing ABI, but how about adding new ABI to provide this? /sys/bus/iio/devices/iio\:device0/label for example? I haven't thought about it in depth yet though. If you spin a patch with that and the DT docs we'll be more likely to get a view from DT maintainers if this is acceptable use of label. I've sent "iio: core: Add optional symbolic label to device attributes" for further discussion. Thanks Jonathan Something like this? diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index 524a686077ca..d21b495d36a1 100644 --- a/drivers/iio/industrialio-core.c +++ b/drivers/iio/industrialio-core.c @@ -1647,6 +1647,9 @@ int __iio_device_register(struct iio_dev *indio_dev, struct module *this_mod) if (!indio_dev->dev.of_node && indio_dev->dev.parent) indio_dev->dev.of_node = indio_dev->dev.parent->of_node; + indio_dev->name = of_get_property(indio_dev->dev.of_node, "label", NULL) ? : + indio_dev->name; + ret = iio_check_unique_scan_index(indio_dev); if (ret < 0) return ret; M -- Regards Phil Reid ElectroMagnetic Imaging Technology Pty Ltd Development of Geophysical Instrumentation & Software www.electromag.com.au 3 The Avenue, Midland WA 6056, AUSTRALIA Ph: +61 8 9250 8100 Fax: +61 8 9250 7100 Email: pr...@electromag.com.au
Re: [PATCH] net: intel: Cleanup e1000 - add space between }}
On Mon, 2019-08-26 at 01:03 -0700, Jeff Kirsher wrote:
> On Fri, 2019-08-23 at 19:14 +, Forrest Fleming wrote:
> > suggested by checkpatch
> >
> > Signed-off-by: Forrest Fleming
> > ---
> > .../net/ethernet/intel/e1000/e1000_param.c| 28 +--
> > 1 file changed, 14 insertions(+), 14 deletions(-)
>
> While I do not see an issue with this change, I wonder how important it is
> to make such a change. Especially since most of the hardware supported by
> this driver is not available for testing. In addition, this is one
> suggested change by checkpatch.pl that I personally do not agree with.
I think checkpatch should allow consecutive }}.
Maybe:
---
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 287fe73688f0..ac5e0f06e1af 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4687,7 +4687,7 @@ sub process {
# closing brace should have a space following it when it has anything
# on the line
- if ($line =~ /}(?!(?:,|;|\)))\S/) {
+ if ($line =~ /}(?!(?:,|;|\)|\}))\S/) {
if (ERROR("SPACING",
"space required after that close brace '}'\n"
. $herecurr) &&
$fix) {
Re: [PATCH] clk: Evict unregistered clks from parent caches
On 2019-08-27 05:13, Stephen Boyd wrote:
We leave a dangling pointer in each clk_core::parents array that has an
unregistered clk as a potential parent when that clk_core pointer is
freed by clk{_hw}_unregister(). It is impossible for the true parent of
a clk to be set with clk_set_parent() once the dangling pointer is left
in the cache because we compare parent pointers in
clk_fetch_parent_index() instead of checking for a matching clk name or
clk_hw pointer.
Before commit ede77858473a ("clk: Remove global clk traversal on fetch
parent index"), we would check clk_hw pointers, which has a higher
chance of being the same between registration and unregistration, but
it
can still be allocated and freed by the clk provider. In fact, this has
been a long standing problem since commit da0f0b2c3ad2 ("clk: Correct
lookup logic in clk_fetch_parent_index()") where we stopped trying to
compare clk names and skipped over entries in the cache that weren't
NULL.
There are good (performance) reasons to not do the global tree lookup
in
cases where the cache holds dangling pointers to parents that have been
unregistered. Let's take the performance hit on the uncommon
registration path instead. Loop through all the clk_core::parents
arrays
when a clk is unregistered and set the entry to NULL when the parent
cache entry and clk being unregistered are the same pointer. This will
fix this problem and avoid the overhead for the "normal" case.
Based on a patch by Bjorn Andersson.
Fixes: da0f0b2c3ad2 ("clk: Correct lookup logic in
clk_fetch_parent_index()")
Cc: Bjorn Andersson
Cc: Sai Prakash Ranjan
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index c0990703ce54..f3982bfa39d6 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3737,6 +3737,34 @@ static const struct clk_ops clk_nodrv_ops = {
.set_parent = clk_nodrv_set_parent,
};
+static void clk_core_evict_parent_cache_subtree(struct clk_core *root,
+ struct clk_core *target)
+{
+ int i;
+ struct clk_core *child;
+
+ for (i = 0; i < root->num_parents; i++)
+ if (root->parents[i].core == target)
+ root->parents[i].core = NULL;
+
+ hlist_for_each_entry(child, >children, child_node)
+ clk_core_evict_parent_cache_subtree(child, target);
+}
+
+/* Remove this clk from all parent caches */
+static void clk_core_evict_parent_cache(struct clk_core *core)
+{
+ struct hlist_head **lists;
+ struct clk_core *root;
+
+ lockdep_assert_held(_lock);
+
+ for (lists = all_lists; *lists; lists++)
+ hlist_for_each_entry(root, *lists, child_node)
+ clk_core_evict_parent_cache_subtree(root, core);
+
+}
+
/**
* clk_unregister - unregister a currently registered clock
* @clk: clock to unregister
@@ -3775,6 +3803,8 @@ void clk_unregister(struct clk *clk)
clk_core_set_parent_nolock(child, NULL);
}
+ clk_core_evict_parent_cache(clk->core);
+
hlist_del_init(>core->child_node);
if (clk->core->prepare_count)
Thanks Stephen. Tested this on cheza now and the issue is not seen
anymore.
Tested-by: Sai Prakash Ranjan
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
RE: [PATCH 3/4] mdev: Expose mdev alias in sysfs tree
> -Original Message-
> From: Alex Williamson
> Sent: Tuesday, August 27, 2019 7:24 AM
> To: Parav Pandit
> Cc: Jiri Pirko ; kwankh...@nvidia.com;
> coh...@redhat.com; da...@davemloft.net; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH 3/4] mdev: Expose mdev alias in sysfs tree
>
> On Mon, 26 Aug 2019 15:41:18 -0500
> Parav Pandit wrote:
>
> > Expose mdev alias as string in a sysfs tree so that such attribute can
> > be used to generate netdevice name by systemd/udev or can be used to
> > match other kernel objects based on the alias of the mdev.
> >
> > Signed-off-by: Parav Pandit
> > ---
> > drivers/vfio/mdev/mdev_sysfs.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/vfio/mdev/mdev_sysfs.c
> > b/drivers/vfio/mdev/mdev_sysfs.c index 43afe0e80b76..59f4e3cc5233
> > 100644
> > --- a/drivers/vfio/mdev/mdev_sysfs.c
> > +++ b/drivers/vfio/mdev/mdev_sysfs.c
> > @@ -246,7 +246,20 @@ static ssize_t remove_store(struct device *dev,
> > struct device_attribute *attr,
> >
> > static DEVICE_ATTR_WO(remove);
> >
> > +static ssize_t alias_show(struct device *device,
> > + struct device_attribute *attr, char *buf) {
> > + struct mdev_device *dev = mdev_from_dev(device);
> > +
> > + if (!dev->alias)
> > + return -EOPNOTSUPP;
>
> Wouldn't it be better to not create the alias at all? Thanks,
>
In other subsystem such as netdev sysfs files are always created that returns
either returns EOPNOTSUPP or attribute value.
I guess overhead of create multiple groups or creating individual sysfs files
outweigh the simplify of single group.
I think its ok to keep it simple this way.
> Alex
>
> > +
> > + return sprintf(buf, "%s\n", dev->alias); } static
> > +DEVICE_ATTR_RO(alias);
> > +
> > static const struct attribute *mdev_device_attrs[] = {
> > + _attr_alias.attr,
> > _attr_remove.attr,
> > NULL,
> > };
RE: [PATCH V3 1/5] thermal: qoriq: Add clock operations
Hi, Rui
> On Tue, 2019-08-27 at 01:51 +, Anson Huang wrote:
> > > On 7/30/2019 5:31 AM, anson.hu...@nxp.com wrote:
> > > > From: Anson Huang
> > > >
> > > > Some platforms like i.MX8MQ has clock control for this module,
> > > > need to add clock operations to make sure the driver is working
> > > > properly.
> > > >
> > > > Signed-off-by: Anson Huang
> > > > Reviewed-by: Guido Günther
> > >
> > > This series looks good, do you think it can be merged in time for
> > > v5.4?
> > > Today was v5.3-rc6.
> >
> > If the question is for me, then I am NOT sure, the thermal patches are
> > pending there for almost half year and I did NOT receive any response,
>
> which patch series you're referring to?
Below i.MX8QXP patch series, I meant I started it from last year, the latest
resend
version is 2 months ago:
https://patchwork.kernel.org/patch/11000809/
>
> > looks like no one
> > is maintaining the thermal sub-system?
Below two patch series are also pending there for some time:
https://patchwork.kernel.org/patch/11032777/
https://patchwork.kernel.org/patch/11031297/
> >
>
> Eduardo is maintaining all the thermal-soc driver changes. Thus I usually
> filtered out the soc driver patches in my mailbox.
>
> The last email from Eduardo is that he is offline during this July and will be
> back and taking patches in August.
>
> I will double check with Eduardo anyway.
Thanks, especially our i.MX8QXP thermal driver patch, I started it from last
year and
due to some different opinion from different reviewers, this patch series
version is
up to v15, but I did NOT receive response since June, appreciated if you guys
can take
a look at this, I ping it many times but no feedback. Thanks!
https://patchwork.kernel.org/patch/11000809/
Anson.
>
> thanks,
> rui
>
>
> > >
> > > In an earlier series the CLK_IS_CRITICAL flags was removed from the
> > > TMU clock so if the thermal driver doesn't explicitly enable it the
> > > system will hang on probe. This is what happens in linux-next right
> > > now!
> >
> > The thermal driver should be built with module, so default kernel
> > should can boot up, do you modify the thermal driver as built-in?
> >
> > >
> > > Unless this patches is merged soon we'll end up with a 5.4-rc1 that
> > > doesn't boot on imx8mq. An easy fix would be to drop/revert commit
> > > 951c1aef9691 ("clk: imx8mq: Remove CLK_IS_CRITICAL flag for
> > > IMX8MQ_CLK_TMU_ROOT") until the thermal patches are accepted.
> >
> > If the thermal driver is built as module, I think no need to revert
> > the commit, but if by default thermal driver is built-in or mod
> > probed, then yes, it should NOT break kernel boot up.
> >
> > Anson.
> >
> > >
> > > Merging patches out-of-order when they have hard (boot-breaking)
> > > dependencies also breaks bisect.
> > >
> > > --
> > > Regards,
> > > Leonard
Re: NVME timeout causing system hangs
I tried looking around for the firmware online but couldn't find it, contacting adata ended up dead ending me, they said I can't find it because there hasn't ever been an firmware updates for this drive and am recommending I RMA it. Is there anything I can do to further troubleshoot this and make sure it is/isn't a hardware issue before I RMA it? On 8/22/19 10:28 AM, Keith Busch wrote: On Mon, Aug 19, 2019 at 04:33:45PM -0700, Ashton Holmes wrote: When playing certain games on my PC dmesg will start spitting out NVME timeout messages, this eventually results in BTRFS throwing errors and remounting itself as read only. The drive passes smart's health check and works fine when not playing games. The really weird part is this will happen even if the game I'm playing isn't installed on that drive. I wanted to bisect this but it happens on every kernel version I've tried. I've attached my dmesg log. This was originally reported here https://bugzilla.kernel.org/show_bug.cgi?id=202633 but no response was ever given. In that report I state that 4.19.24 for whatever reason doesn't trigger this however that doesn't seem to be the case anymore. I've updated my UEFI since then, I wouldn't expect that to make a difference but I'm not sure what else would have changed that. This really looks like your nvme controller has gotten itself in an unresponsive state: it is not responding to IO, admin, or reset requests. The only recommendation I have at the moment is to verify you have the most current firmware from your vendor installed on this controller, and update if not. [ 170.678837] nvme nvme0: I/O 128 QID 2 timeout, aborting [ 170.678845] nvme nvme0: I/O 129 QID 2 timeout, aborting [ 170.678850] nvme nvme0: I/O 167 QID 2 timeout, aborting [ 170.678853] nvme nvme0: I/O 168 QID 2 timeout, aborting [ 170.678856] nvme nvme0: I/O 169 QID 2 timeout, aborting [ 201.657527] nvme nvme0: I/O 128 QID 2 timeout, reset controller [ 232.372876] nvme nvme0: I/O 8 QID 0 timeout, reset controller [ 323.643688] nvme nvme0: Device not ready; aborting reset [ 323.675893] print_req_error: I/O error, dev nvme0n1, sector 1088653384 flags 80700 [ 323.675902] print_req_error: I/O error, dev nvme0n1, sector 1001346664 flags 80700 [ 323.675915] print_req_error: I/O error, dev nvme0n1, sector 1088646984 flags 84700 [ 323.675920] print_req_error: I/O error, dev nvme0n1, sector 1088647240 flags 84700 [ 323.675923] print_req_error: I/O error, dev nvme0n1, sector 1088647496 flags 84700 [ 323.675927] print_req_error: I/O error, dev nvme0n1, sector 1088647752 flags 84700 [ 323.675931] print_req_error: I/O error, dev nvme0n1, sector 1088648008 flags 84700 [ 323.675935] print_req_error: I/O error, dev nvme0n1, sector 1088648264 flags 84700 [ 323.675938] print_req_error: I/O error, dev nvme0n1, sector 1088648520 flags 84700 [ 323.675942] print_req_error: I/O error, dev nvme0n1, sector 1088648776 flags 84700 [ 323.675993] nvme nvme0: Abort status: 0x7 [ 323.675995] nvme nvme0: Abort status: 0x7 [ 323.675996] nvme nvme0: Abort status: 0x7 [ 323.675998] nvme nvme0: Abort status: 0x7 [ 323.675999] nvme nvme0: Abort status: 0x7
[GIT PULL] SOC: TI soc updates for 5.4
The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b: Linux 5.3-rc2 (2019-07-28 12:47:02 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/drivers_soc_for_5.4 for you to fetch changes up to 23013399a2252e9f592c2c52a62b213d3ef09217: soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access (2019-08-26 20:00:41 -0700) soc: TI soc updates for 5.4 - Update firmware to support PM domain shared and exclusive support - Update driver and dt binding docs for the same. Lokesh Vutla (3): firmware: ti_sci: Allow for device shared and exclusive requests dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared access soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 11 +- MAINTAINERS| 1 + drivers/firmware/ti_sci.c | 45 +- drivers/soc/ti/ti_sci_pm_domains.c | 23 ++- include/dt-bindings/soc/ti,sci_pm_domain.h | 9 + include/linux/soc/ti/ti_sci_protocol.h | 3 ++ 6 files changed, 86 insertions(+), 6 deletions(-) create mode 100644 include/dt-bindings/soc/ti,sci_pm_domain.h -- 1.9.1
[PATCH -next] net: mlx5: Kconfig: Fix MLX5_CORE_EN dependencies
When MLX5_CORE_EN=y and PCI_HYPERV_INTERFACE is not set, below errors are found:
drivers/net/ethernet/mellanox/mlx5/core/en_main.o: In function
`mlx5e_nic_enable':
en_main.c:(.text+0xb649): undefined reference to `mlx5e_hv_vhca_stats_create'
drivers/net/ethernet/mellanox/mlx5/core/en_main.o: In function
`mlx5e_nic_disable':
en_main.c:(.text+0xb8c4): undefined reference to `mlx5e_hv_vhca_stats_destroy'
This because CONFIG_PCI_HYPERV_INTERFACE is newly introduced by 'commit
348dd93e40c1
("PCI: hv: Add a Hyper-V PCI interface driver for software backchannel
interface"),
Fix this by making MLX5_CORE_EN imply PCI_HYPERV_INTERFACE.
Fixes: cef35af34d6d ("net/mlx5e: Add mlx5e HV VHCA stats agent")
Signed-off-by: Mao Wenan
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index 37fef8c..a6a70ce 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -35,6 +35,7 @@ config MLX5_CORE_EN
depends on IPV6=y || IPV6=n || MLX5_CORE=m
select PAGE_POOL
select DIMLIB
+ imply PCI_HYPERV_INTERFACE
default n
---help---
Ethernet support in Mellanox Technologies ConnectX-4 NIC.
--
2.7.4
Re: [PATCH v2 3/3] dwc: PCI: intel: Intel PCIe RC controller driver
Hi Martin, Thanks for your feedback. Please check the comments below. On 8/27/2019 5:15 AM, Martin Blumenstingl wrote: Hello, On Mon, Aug 26, 2019 at 5:31 AM Chuan Hua, Lei wrote: Hi Martin, Thanks for your valuable comments. I reply some of them as below. you're welcome [...] +config PCIE_INTEL_AXI +bool "Intel AHB/AXI PCIe host controller support" I believe that this is mostly the same IP block as it's used in Lantiq (xDSL) VRX200 SoCs (with MIPS cores) which was introduced in 2010 (before Intel acquired Lantiq). This is why I would have personally called the driver PCIE_LANTIQ VRX200 SoC(internally called VR9) was the first PCIe SoC product which was using synopsys controller v3.30a. It only supports PCIe Gen1.1/1.0. The phy is internal phy from infineon. thank you for these details I wasn't aware that the PCIe PHY on these SoCs was developed by Infineon nor is the DWC version documented anywhere VRX200/ARX300 PHY is internal value. There are a lot of hardcode which was from hardware people. From XRX500, we switch to synopsis PHY. However, later comboPHY is coming to the picture. Even though we have one same controller with different versions, we most likely will have three different phy drivers. [...] +#define PCIE_CCRID 0x8 + +#define PCIE_LCAP 0x7C +#define PCIE_LCAP_MAX_LINK_SPEEDGENMASK(3, 0) +#define PCIE_LCAP_MAX_LENGTH_WIDTH GENMASK(9, 4) + +/* Link Control and Status Register */ +#define PCIE_LCTLSTS0x80 +#define PCIE_LCTLSTS_ASPM_ENABLEGENMASK(1, 0) +#define PCIE_LCTLSTS_RCB128 BIT(3) +#define PCIE_LCTLSTS_LINK_DISABLE BIT(4) +#define PCIE_LCTLSTS_COM_CLK_CFGBIT(6) +#define PCIE_LCTLSTS_HW_AW_DIS BIT(9) +#define PCIE_LCTLSTS_LINK_SPEED GENMASK(19, 16) +#define PCIE_LCTLSTS_NEGOTIATED_LINK_WIDTH GENMASK(25, 20) +#define PCIE_LCTLSTS_SLOT_CLK_CFG BIT(28) + +#define PCIE_LCTLSTS2 0xA0 +#define PCIE_LCTLSTS2_TGT_LINK_SPEEDGENMASK(3, 0) +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_25GT 0x1 +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_5GT0x2 +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_8GT0x3 +#define PCIE_LCTLSTS2_TGT_LINK_SPEED_16GT 0x4 +#define PCIE_LCTLSTS2_HW_AUTO_DIS BIT(5) + +/* Ack Frequency Register */ +#define PCIE_AFR0x70C +#define PCIE_AFR_FTS_NUMGENMASK(15, 8) +#define PCIE_AFR_COM_FTS_NUMGENMASK(23, 16) +#define PCIE_AFR_GEN12_FTS_NUM_DFT (SZ_128 - 1) +#define PCIE_AFR_GEN3_FTS_NUM_DFT 180 +#define PCIE_AFR_GEN4_FTS_NUM_DFT 196 + +#define PCIE_PLCR_DLL_LINK_EN BIT(5) +#define PCIE_PORT_LOGIC_FTS GENMASK(7, 0) +#define PCIE_PORT_LOGIC_DFT_FTS_NUM (SZ_128 - 1) + +#define PCIE_MISC_CTRL 0x8BC +#define PCIE_MISC_CTRL_DBI_RO_WR_EN BIT(0) + +#define PCIE_MULTI_LANE_CTRL0x8C0 +#define PCIE_UPCONFIG_SUPPORT BIT(7) +#define PCIE_DIRECT_LINK_WIDTH_CHANGE BIT(6) +#define PCIE_TARGET_LINK_WIDTH GENMASK(5, 0) + +#define PCIE_IOP_CTRL 0x8C4 +#define PCIE_IOP_RX_STANDBY_CTRLGENMASK(6, 0) no need for IOP with "are you sure that you need any of the registers above?" I really meant all registers above (including, but not limited to IOP) [...] As I mentioned, VRX200 was a very old PCIe Gen1.1 product. In our latest SoC Lightning Mountain, we are using synopsys controller 5.20/5.50a. We support Gen2(XRX350/550), Gen3(PRX300) and GEN4(X86 based SoC). We also supported dual lane and single lane. Some of the above registers are needed to control FTS, link width and link speed. only now I noticed that I didn't explain why I was asking whether all these registers are needed my understanding of the DWC PCIe controller driver "library" is that: - all functionality which is provided by the DesignWare PCIe core should be added to drivers/pci/controller/dwc/pcie-designware* - functionality which is built on top/around the DWC PCIe core should be added to the link width and link speed settings (I don't know about "FTS") don't seem Intel/Lantiq controller specific to me so the register setup for these bits should be moved to drivers/pci/controller/dwc/pcie-designware* FTS means fast training sequence. Different generations will have different FTS. Common DWC drivers have default number for all generations which are not optimized. DWC driver handles link speed and link width during the initialization. Then left link speed change and link width to device (EP) according to PCIe spec. Not sure if other vendors or customers have this kind of requirement. We implemented this due to customer's requirement. We can check
Re: [PATCH V3 1/5] thermal: qoriq: Add clock operations
On Tue, 2019-08-27 at 01:51 +, Anson Huang wrote:
> > On 7/30/2019 5:31 AM, anson.hu...@nxp.com wrote:
> > > From: Anson Huang
> > >
> > > Some platforms like i.MX8MQ has clock control for this module,
> > > need to
> > > add clock operations to make sure the driver is working properly.
> > >
> > > Signed-off-by: Anson Huang
> > > Reviewed-by: Guido Günther
> >
> > This series looks good, do you think it can be merged in time for
> > v5.4?
> > Today was v5.3-rc6.
>
> If the question is for me, then I am NOT sure, the thermal patches
> are pending
> there for almost half year and I did NOT receive any response,
which patch series you're referring to?
> looks like no one
> is maintaining the thermal sub-system?
>
Eduardo is maintaining all the thermal-soc driver changes. Thus I
usually filtered out the soc driver patches in my mailbox.
The last email from Eduardo is that he is offline during this July and
will be back and taking patches in August.
I will double check with Eduardo anyway.
thanks,
rui
> >
> > In an earlier series the CLK_IS_CRITICAL flags was removed from the
> > TMU
> > clock so if the thermal driver doesn't explicitly enable it the
> > system will hang
> > on probe. This is what happens in linux-next right now!
>
> The thermal driver should be built with module, so default kernel
> should can boot
> up, do you modify the thermal driver as built-in?
>
> >
> > Unless this patches is merged soon we'll end up with a 5.4-rc1 that
> > doesn't
> > boot on imx8mq. An easy fix would be to drop/revert commit
> > 951c1aef9691 ("clk: imx8mq: Remove CLK_IS_CRITICAL flag for
> > IMX8MQ_CLK_TMU_ROOT") until the thermal patches are accepted.
>
> If the thermal driver is built as module, I think no need to revert
> the commit, but
> if by default thermal driver is built-in or mod probed, then yes, it
> should NOT break
> kernel boot up.
>
> Anson.
>
> >
> > Merging patches out-of-order when they have hard (boot-breaking)
> > dependencies also breaks bisect.
> >
> > --
> > Regards,
> > Leonard
Re: [tip: x86/cpu] x86/cpu/intel: Fix rename fallout
Hi tip-bot2, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc6 next-20190826] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/tip-bot2-for-Ingo-Molnar/x86-cpu-intel-Fix-rename-fallout/20190827-083739 config: x86_64-randconfig-s2-08250055 (attached as .config) compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): In file included from drivers/platform/x86/intel_pmc_core.c:27:0: >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_SKYLAKE_L' >> undeclared here (not in a function) INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^ drivers/platform/x86/intel_pmc_core.c:809:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(SKYLAKE_L, spt_reg_map), ^ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_SKYLAKE' >> undeclared here (not in a function) INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^ drivers/platform/x86/intel_pmc_core.c:810:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(SKYLAKE, spt_reg_map), ^ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_KABYLAKE_L' >> undeclared here (not in a function) INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^ drivers/platform/x86/intel_pmc_core.c:811:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(KABYLAKE_L, spt_reg_map), ^ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_KABYLAKE' >> undeclared here (not in a function) INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^ drivers/platform/x86/intel_pmc_core.c:812:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(KABYLAKE, spt_reg_map), ^ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_CANNONLAKE_L' >> undeclared here (not in a function) INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^ drivers/platform/x86/intel_pmc_core.c:813:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(CANNONLAKE_L, cnp_reg_map), ^ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_ICELAKE_L' >> undeclared here (not in a function) INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^ drivers/platform/x86/intel_pmc_core.c:814:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(ICELAKE_L, icl_reg_map), ^ -- In file included from drivers/platform/x86/intel_pmc_core_pltdrv.c:19:0: >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_SKYLAKE_L' >> undeclared here (not in a function) INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^ drivers/platform/x86/intel_pmc_core_pltdrv.c:33:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(SKYLAKE_L, pmc_core_device), ^ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_SKYLAKE' >> undeclared here (not in a function) INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^ drivers/platform/x86/intel_pmc_core_pltdrv.c:34:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(SKYLAKE, pmc_core_device), ^ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_KAB
[PATCH 2/2] reiserfs: remove set but not used variable in do_balan.c
Fix the following gcc warning:
fs/reiserfs/do_balan.c: In function balance_leaf_insert_right:
fs/reiserfs/do_balan.c:629:6: warning: variable ret set but not used
[-Wunused-but-set-variable]
Signed-off-by: Jason Yan
---
fs/reiserfs/do_balan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/reiserfs/do_balan.c b/fs/reiserfs/do_balan.c
index ffb6d7f0da94..4075e41408b4 100644
--- a/fs/reiserfs/do_balan.c
+++ b/fs/reiserfs/do_balan.c
@@ -626,7 +626,6 @@ static void balance_leaf_insert_right(struct tree_balance
*tb,
struct buffer_head *tbS0 = PATH_PLAST_BUFFER(tb->tb_path);
int n = B_NR_ITEMS(tbS0);
struct buffer_info bi;
- int ret;
/* new item or part of it doesn't fall into R[0] */
if (n - tb->rnum[0] >= tb->item_pos) {
@@ -690,7 +689,7 @@ static void balance_leaf_insert_right(struct tree_balance
*tb,
/* whole new item falls into R[0] */
/* Shift rnum[0]-1 items to R[0] */
- ret = leaf_shift_right(tb, tb->rnum[0] - 1, tb->rbytes);
+ leaf_shift_right(tb, tb->rnum[0] - 1, tb->rbytes);
/* Insert new item into R[0] */
buffer_info_init_right(tb, );
--
2.17.2
[PATCH 1/2] reiserfs: remove set but not used variable in journal.c
Fix the following gcc warning:
fs/reiserfs/journal.c: In function flush_used_journal_lists:
fs/reiserfs/journal.c:1791:6: warning: variable ret set but not used
[-Wunused-but-set-variable]
Signed-off-by: Jason Yan
---
fs/reiserfs/journal.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
index 75d9d52d489f..4b3e3e73b512 100644
--- a/fs/reiserfs/journal.c
+++ b/fs/reiserfs/journal.c
@@ -1788,7 +1788,6 @@ static int flush_used_journal_lists(struct super_block *s,
{
unsigned long len = 0;
unsigned long cur_len;
- int ret;
int i;
int limit = 256;
struct reiserfs_journal_list *tjl;
@@ -1825,9 +1824,9 @@ static int flush_used_journal_lists(struct super_block *s,
* transactions, but only bother if we've actually spanned
* across multiple lists
*/
- if (flush_jl != jl) {
- ret = kupdate_transactions(s, jl, , _id, len, i);
- }
+ if (flush_jl != jl)
+ kupdate_transactions(s, jl, , _id, len, i);
+
flush_journal_list(s, flush_jl, 1);
put_journal_list(s, flush_jl);
put_journal_list(s, jl);
--
2.17.2
[PATCH] dt-bindings: Clarify interrupts-extended usage
Reading the description about when to use interrupts-extended leads some developers to think that it shouldn't be used unless a device has interrupts from more than one interrupt controller. This isn't true. We should encourage devicetree writers to use this property in situations where it isn't the inherited interrupt-parent so that we have less properties in a DT node by virtue of not having to specify an interrupt-parent and an interrupts property. Reported-by: Alexandru M Stan Signed-off-by: Stephen Boyd --- .../bindings/interrupt-controller/interrupts.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt index 8a3c40829899..4a3ee253f7f0 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt @@ -22,10 +22,10 @@ controller node. This property is inherited, so it may be specified in an interrupt client node or in any of its parent nodes. Interrupts listed in the "interrupts" property are always in reference to the node's interrupt parent. -The "interrupts-extended" property is a special form for use when a node needs -to reference multiple interrupt parents. Each entry in this property contains -both the parent phandle and the interrupt specifier. "interrupts-extended" -should only be used when a device has multiple interrupt parents. +The "interrupts-extended" property is a special form; useful when a node needs +to reference multiple interrupt parents or a different interrupt parent than +the inherited one. Each entry in this property contains both the parent phandle +and the interrupt specifier. Example: interrupts-extended = < 5 1>, < 1 0>; base-commit: 609488bc979f99f805f34e9a32c1e3b71179d10b -- Sent by a computer through tubes
Re: kernel/bpf/core.o: warning: objtool: ___bpf_prog_run.cold()+0x7: call without frame pointer save/setup
On 8/26/19 11:11 PM, Greg KH wrote:
> On Mon, Aug 26, 2019 at 10:42:53PM +0800, He Zhe wrote:
>> Hi All,
>>
>> Since 3193c0836f20 ("bpf: Disable GCC -fgcse optimization for
>> ___bpf_prog_run()"),
>> We have got the following warning,
>> kernel/bpf/core.o: warning: objtool: ___bpf_prog_run.cold()+0x7: call
>> without frame pointer save/setup
>>
>> If reverting the above commit, we will get the following warning,
>> kernel/bpf/core.o: warning: objtool: ___bpf_prog_run()+0x8b9: sibling call
>> from callable instruction with modified stack frame
>> if CONFIG_RETPOLINE=n, and no warning if CONFIG_RETPOLINE=y
> Do you see this same problem on 5.3-rc6?
>
> And what version of gcc are you using?
Sorry for missing such information.
Here is the .config along with kernel and GCC version.
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 5.3.0-rc6 Kernel Configuration
#
#
# Compiler: x86_64-wrs-linux-gcc (GCC) 9.1.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=90100
CONFIG_CLANG_VERSION=0
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
# CONFIG_HEADER_TEST is not set
CONFIG_LOCALVERSION="dev"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
# end of IRQ subsystem
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# end of Timers subsystem
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_PSI is not set
# end of CPU/Task time and stats accounting
CONFIG_CPU_ISOLATION=y
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_RCU_NOCB_CPU=y
# end of RCU Subsystem
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_IKHEADERS is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
#
# Scheduler features
#
# end of Scheduler features
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_MEMCG_KMEM=y
CONFIG_BLK_CGROUP=y
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_BPF=y
CONFIG_CGROUP_DEBUG=y
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
Re: [PATCH] sched/fair: don't assign runtime for throttled cfs_rq
On 19/8/27 上午1:38, bseg...@google.com wrote:
Valentin Schneider writes:
On 23/08/2019 21:00, bseg...@google.com wrote:
[...]
Could you mention in the message that this a throttled cfs_rq can have
account_cfs_rq_runtime called on it because it is throttled before
idle_balance, and the idle_balance calls update_rq_clock to add time
that is accounted to the task.
Mayhaps even a comment for the extra condition.
I think this solution is less risky than unthrottling
in this area, so other than that:
Reviewed-by: Ben Segall
If you don't mind squashing this in:
-8<-
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b1d9cec9b1ed..b47b0bcf56bc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4630,6 +4630,10 @@ static u64 distribute_cfs_runtime(struct cfs_bandwidth
*cfs_b, u64 remaining)
if (!cfs_rq_throttled(cfs_rq))
goto next;
+ /* By the above check, this should never be true */
+ WARN_ON(cfs_rq->runtime_remaining > 0);
+
+ /* Pick the minimum amount to return to a positive quota state
*/
runtime = -cfs_rq->runtime_remaining + 1;
if (runtime > remaining)
runtime = remaining;
->8-
I'm not adamant about the extra comment, but the WARN_ON would be nice IMO.
@Ben, do you reckon we want to strap
Cc:
Fixes: ec12cb7f31e2 ("sched: Accumulate per-cfs_rq cpu usage and charge against
bandwidth")
to the thing? AFAICT the pick_next_task_fair() + idle_balance() dance you
described should still be possible on that commit.
I'm not sure about stable policy in general, but it seems reasonable.
The WARN_ON might want to be WARN_ON_ONCE, and it seems fine to have it
or not.
Thanks Ben and Valentin for all of the comments. Per Xunlei's
suggestion, I used SCHED_WARN_ON instead in v3. Regarding whether cc
stable, I'm also not sure.
Other than that,
Reviewed-by: Valentin Schneider
[...]
[PATCH] tracing: Fix histogram referencing a variable
From: Steven Rostedt (VMware)
I performed a three way histogram with the following commands:
echo 'irq_lat u64 lat pid_t pid' > synthetic_events
echo 'wake_lat u64 lat u64 irqlat pid_t pid' >> synthetic_events
echo 'hist:keys=common_pid:irqts=common_timestamp.usecs if function ==
0x81200580' > events/timer/hrtimer_start/trigger
echo
'hist:keys=common_pid:lat=common_timestamp.usecs-$irqts:onmatch(timer.hrtimer_start).irq_lat($lat,pid)
if common_flags & 1' > events/sched/sched_waking/trigger
echo 'hist:keys=pid:wakets=common_timestamp.usecs,irqlat=lat' >
events/synthetic/irq_lat/trigger
echo
'hist:keys=next_pid:lat=common_timestamp.usecs-$wakets,irqlat=$irqlat:onmatch(synthetic.irq_lat).wake_lat($lat,$irqlat,next_pid)'
> events/sched/sched_switch/trigger
echo 1 > events/synthetic/wake_lat/enable
Basically I wanted to see:
hrtimer_start (calling function tick_sched_timer)
Note:
# grep tick_sched_timer /proc/kallsyms
81200580 t tick_sched_timer
And save the time of that, and then record sched_waking if it is called
in interrupt context and with the same pid as the hrtimer_start, it
will record the latency between that and the waking event.
I then look at when the task that is woken is scheduled in, and record
the latency between the wakeup and the task running.
At the end, the wake_lat synthetic event will show the wakeup to
scheduled latency, as well as the irq latency in from hritmer_start to
the wakeup. The problem is that I found this:
-0 [007] d... 190.485261: wake_lat: lat=27
irqlat=190485230 pid=698
-0 [005] d... 190.485283: wake_lat: lat=40
irqlat=190485239 pid=10
-0 [002] d... 190.488327: wake_lat: lat=56
irqlat=190488266 pid=335
-0 [005] d... 190.489330: wake_lat: lat=64
irqlat=190489262 pid=10
-0 [003] d... 190.490312: wake_lat: lat=43
irqlat=190490265 pid=77
-0 [005] d... 190.493322: wake_lat: lat=54
irqlat=190493262 pid=10
-0 [005] d... 190.497305: wake_lat: lat=35
irqlat=190497267 pid=10
-0 [005] d... 190.501319: wake_lat: lat=50
irqlat=190501264 pid=10
The irqlat seemed quite large! Investigating this further, if I had
enabled the irq_lat synthetic event, I noticed this:
-0 [002] d.s. 249.429308: irq_lat: lat=164968 pid=335
-0 [002] d... 249.429369: wake_lat: lat=55
irqlat=249429308 pid=335
Notice that the timestamp of the irq_lat "249.429308" is awfully
similar to the reported irqlat variable. In fact, all instances were
like this. It appeared that:
irqlat=$irqlat
Wasn't assigning the old $irqlat to the new irqlat variable, but
instead was assigning the $irqts to it.
The issue is that hist_field_var_ref() is using hist_field->var_ref_idx
(the ref of the var being assigned) and not the ref of the var that is
the value (hist_field->var.idx).
Cc: sta...@vger.kernel.org
Fixes: 067fe038e70f6 ("tracing: Add variable reference handling to hist
triggers")
Signed-off-by: Steven Rostedt (VMware)
---
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 65e7d071ed28..329488aeb9dd 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -1858,7 +1858,7 @@ static u64 hist_field_var_ref(struct hist_field
*hist_field,
return var_val;
elt_data = elt->private_data;
- var_val = elt_data->var_ref_vals[hist_field->var_ref_idx];
+ var_val = elt_data->var_ref_vals[hist_field->var.idx];
return var_val;
}
Re: [PATCH v2 1/2] ASoC: es8316: fix headphone mixer volume table
On Mon, Aug 26, 2019 at 11:39 PM Katsuhiro Suzuki wrote: > > This patch fix setting table of Headphone mixer volume. > Current code uses 4 ... 7 values but these values are prohibited. > > Correct settings are the following: > -12dB > 0001 -10.5dB > 0010 -9dB > 0011 -7.5dB > 0100 -6dB > 1000 -4.5dB > 1001 -3dB > 1010 -1.5dB > 1011 0dB > > Signed-off-by: Katsuhiro Suzuki Reviewed-by: Daniel Drake
Re: [PATCH v2 2/2] ASoC: es8316: fix inverted L/R of headphone mixer volume
On Mon, Aug 26, 2019 at 11:39 PM Katsuhiro Suzuki wrote: > > This patch fixes inverted Left-Right channel of headphone mixer > volume by wrong shift_left, shift_right values. > > Signed-off-by: Katsuhiro Suzuki Agrees with the spec Reviewed-by: Daniel Drake
Re: [PATCH v2] RISC-V: Fix FIXMAP area corruption on RV32 systems
On Tue, Aug 27, 2019 at 5:43 AM Paul Walmsley wrote:
>
> Hello Anup,
>
> On Mon, 19 Aug 2019, Anup Patel wrote:
>
> > Currently, various virtual memory areas of Linux RISC-V are organized
> > in increasing order of their virtual addresses is as follows:
> > 1. User space area (This is lowest area and starts at 0x0)
> > 2. FIXMAP area
> > 3. VMALLOC area
> > 4. Kernel area (This is highest area and starts at PAGE_OFFSET)
> >
> > The maximum size of user space aread is represented by TASK_SIZE.
> >
> > On RV32 systems, TASK_SIZE is defined as VMALLOC_START which causes the
> > user space area to overlap the FIXMAP area. This allows user space apps
> > to potentially corrupt the FIXMAP area and kernel OF APIs will crash
> > whenever they access corrupted FDT in the FIXMAP area.
> >
> > On RV64 systems, TASK_SIZE is set to fixed 256GB and no other areas
> > happen to overlap so we don't see any FIXMAP area corruptions.
> >
> > This patch fixes FIXMAP area corruption on RV32 systems by setting
> > TASK_SIZE to FIXADDR_START.
>
> This part -- the TASK_SIZE change -- makes sense to me.
>
> However, the patch also changes FIXADDR_SIZE to be defined in terms of
> page table-related constants. Previously, FIXADDR_SIZE was based on
> __end_of_fixed_addresses, as it is for most other architectures. The part
> of the patch that changes FIXADDR_SIZE seems unrelated to the actual fix.
>
> If that's indeed the case -- that the change to FIXADDR_SIZE is unrelated
> from the fix -- could you please split that into a separate patch, with a
> description of the rationale? I think I understand why you're proposing
> it, but it seems odd to explicitly connect it to page table-related
> constants, rather than the contents of "enum fixed_addresses", and I'm
> reluctant to merge that part of this patch without a bit more discussion.
The FIXADDR_SIZE change is related to the TASK_SIZE requirement and
it is not a separate change because:
1. TASK_SIZE must be evenly divisible by PGDIR_SIZE. The FIXADDR_START
is defined as (FIXADDR_TOP - FIXADDR_SIZE). The original FIXADDR_SIZE
defined in-terms of __end_of_fixed_addresses is not a multiple of PGDIR_SIZE
hence it makes sense to make FIXADDR_SIZE as PGDIR_SIZE.
2. Let say we ignore point1 above then still we cannot continue to express
FIXADDR_SIZE in-terms of __end_of_fixed_addresses because of cyclic
header dependency where asm/fixmap.h includes asm/pgtable.h and
__end_of_fixed_addresses is defined in asm/fixmap.h. We certainly need
to move FIXADDR_TOP, FIXADDR_START, and FIXADDR_SIZE to
asm/pgtable.h so that we can express TASK_SIZE as FIXADDR_START
for RV32. If we don't simplify FIXADDR_SIZE then it will result in compile
errors.
Regards,
Anup
>
>
> > We also move FIXADDR_TOP, FIXADDR_SIZE, and FIXADDR_START defines to
> > asm/pgtable.h so that we can avoid cyclic header includes.
> >
> > Signed-off-by: Anup Patel
> > Tested-by: Alistair Francis
> > Reviewed-by: Christoph Hellwig
> > ---
> > Changes since v1:
> > - Drop braces from "#define FIXADDR_TOP"
> > ---
> > arch/riscv/include/asm/fixmap.h | 4
> > arch/riscv/include/asm/pgtable.h | 12 ++--
> > 2 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/fixmap.h
> > b/arch/riscv/include/asm/fixmap.h
> > index 9c66033c3a54..161f28d04a07 100644
> > --- a/arch/riscv/include/asm/fixmap.h
> > +++ b/arch/riscv/include/asm/fixmap.h
> > @@ -30,10 +30,6 @@ enum fixed_addresses {
> > __end_of_fixed_addresses
> > };
> >
> > -#define FIXADDR_SIZE (__end_of_fixed_addresses * PAGE_SIZE)
> > -#define FIXADDR_TOP (VMALLOC_START)
> > -#define FIXADDR_START(FIXADDR_TOP - FIXADDR_SIZE)
> > -
> > #define FIXMAP_PAGE_IO PAGE_KERNEL
> >
> > #define __early_set_fixmap __set_fixmap
> > diff --git a/arch/riscv/include/asm/pgtable.h
> > b/arch/riscv/include/asm/pgtable.h
> > index a364aba23d55..c24a083b3e12 100644
> > --- a/arch/riscv/include/asm/pgtable.h
> > +++ b/arch/riscv/include/asm/pgtable.h
> > @@ -420,14 +420,22 @@ static inline void pgtable_cache_init(void)
> > #define VMALLOC_END (PAGE_OFFSET - 1)
> > #define VMALLOC_START(PAGE_OFFSET - VMALLOC_SIZE)
> >
> > +#define FIXADDR_TOP VMALLOC_START
> > +#ifdef CONFIG_64BIT
> > +#define FIXADDR_SIZE PMD_SIZE
> > +#else
> > +#define FIXADDR_SIZE PGDIR_SIZE
> > +#endif
> > +#define FIXADDR_START(FIXADDR_TOP - FIXADDR_SIZE)
> > +
> > /*
> > - * Task size is 0x40 for RV64 or 0xb80 for RV32.
> > + * Task size is 0x40 for RV64 or 0x9fc0 for RV32.
> > * Note that PGDIR_SIZE must evenly divide TASK_SIZE.
> > */
> > #ifdef CONFIG_64BIT
> > #define TASK_SIZE (PGDIR_SIZE * PTRS_PER_PGD / 2)
> > #else
> > -#define TASK_SIZE VMALLOC_START
> > +#define TASK_SIZE FIXADDR_START
> > #endif
> >
> > #include
> > --
> > 2.17.1
> >
>
>
> - Paul
Re: [PATCH v2] ACPI / CPPC: do not require the _PSD method when using CPPC
On 8/26/19 5:02 PM, Rafael J. Wysocki wrote:
> On Tue, Aug 27, 2019 at 12:30 AM Al Stone wrote:
>>
>> According to the ACPI 6.3 specification, the _PSD method is optional
>> when using CPPC. The underlying assumption is that each CPU can change
>> frequency independently from all other CPUs; _PSD is provided to tell
>> the OS that some processors can NOT do that.
>>
>> However, the acpi_get_psd() function returns ENODEV if there is no _PSD
>> method present, or an ACPI error status if an error occurs when evaluating
>> _PSD, if present. This makes _PSD mandatory when using CPPC, in violation
>> of the specification, and only on Linux.
>>
>> This has forced some firmware writers to provide a dummy _PSD, even though
>> it is irrelevant, but only because Linux requires it; other OSPMs follow
>> the spec. We really do not want to have OS specific ACPI tables, though.
>>
>> So, correct acpi_get_psd() so that it does not return an error if there
>> is no _PSD method present, but does return a failure when the method can
>> not be executed properly. This allows _PSD to be optional as it should
>> be.
>>
>> v2:
>>-- verified simple check for AE_NOT_FOUND was sufficient
>>-- simplified return status check per Rafael's suggestion
>>
>> Signed-off-by: Al Stone
>> Cc: Rafael J. Wysocki
>> Cc: Len Brown
>> ---
>> drivers/acpi/cppc_acpi.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
>> index 15f103d7532b..7a946f1944ab 100644
>> --- a/drivers/acpi/cppc_acpi.c
>> +++ b/drivers/acpi/cppc_acpi.c
>> @@ -365,10 +365,12 @@ static int acpi_get_psd(struct cpc_desc *cpc_ptr,
>> acpi_handle handle)
>> union acpi_object *psd = NULL;
>> struct acpi_psd_package *pdomain;
>>
>> - status = acpi_evaluate_object_typed(handle, "_PSD", NULL, ,
>> - ACPI_TYPE_PACKAGE);
>> - if (ACPI_FAILURE(status))
>> - return -ENODEV;
>> + if (acpi_has_method(handle, "_PSD")) {
>
> This doesn't look necessary any more.
Probably true. I'll look back through acpi_evaluate_object_typed().
>> + status = acpi_evaluate_object_typed(handle, "_PSD", NULL,
>> + ,
>> ACPI_TYPE_PACKAGE);
>> + if (status == AE_NOT_FOUND) /* _PSD is optional */
>> + return 0;
>
> And what about the other possible errors?
Argh. My apologies. I was not paying attention. I'll correct
this and send proper code tomorrow. Really sorry for the noise :(...
>> + }
>>
>> psd = buffer.pointer;
>> if (!psd || psd->package.count != 1) {
>> --
>> 2.21.0
>>
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
Re: [PATCH v2 2/2] reset: Reset controller driver for Intel LGM SoC
Hi Martin,
Please check the reply below.
On 8/27/2019 5:49 AM, Martin Blumenstingl wrote:
Hi,
On Mon, Aug 26, 2019 at 6:01 AM Chuan Hua, Lei
wrote:
Hi Martin,
Thanks for your comment.
thank you for the quick reply
On 8/25/2019 5:11 AM, Martin Blumenstingl wrote:
Hi Dilip,
Add driver for the reset controller present on Intel
Lightening Mountain (LGM) SoC for performing reset
management of the devices present on the SoC. Driver also
registers a reset handler to peform the entire device reset.
[...]
+static const struct of_device_id intel_reset_match[] = {
+{ .compatible = "intel,rcu-lgm" },
+{}
+};
how is this IP block differnet from the one used in many Lantiq SoCs?
there is already an upstream driver for the RCU IP block on the Lantiq
SoCs: drivers/reset/reset-lantiq.c
some background:
Lantiq was started as a spinoff from Infineon in 2009. Intel then
acquired Lantiq in 2015. source: [0]
Intel is re-using some of the IP blocks from the MIPS Lantiq SoCs
(Intel even has some own MIPS SoCs as part of the Lantiq acquisition,
typically used for PON/GPON/ADSL/VDSL capable network devices).
Thus I think it is likely that the new "Lightening Mountain" SoCs use
an updated version of the Lantiq RCU IP.
I would not say there is a fundamental difference since reset is a
really simple
stuff from all reset drivers. However, it did have some difference
from existing reset-lantiq.c since SoC becomes more and more complex.
OK, let me go through your detailed list
1. reset-lantiq.c use index instead of register offset + bit position.
index reset is good for a small system (< 64). However, it will become very
difficult to use if you have > 100 reset. So we use register offset +
bit position
reset-lantiq uses bit bit positions for specifying the reset line.
for example this is from OpenWrt's vr9.dtsi:
reset0: reset-controller@10 {
...
reg = <0x10 4>, <0x14 4>;
#reset-cells = <2>;
};
gphy0: gphy@20 {
...
resets = < 31 30>, < 7 7>;
reset-names = "gphy", "gphy2";
};
in my own words this means:
- all reset0 reset bits are at offset 0x10 (parent is RCU)
- all reset0 status bits are at offset 0x14 (parent is RCU)
- the first reset line uses reset bit 31 and status bit 30
- the second reset line uses reset bit 7 and status bit 7
- there can be multiple reset-controller instances, each taking the
reset and status offsets (OpenWrt's vr9.dtsi specifies the second RCU
reset controller "reset1" with reset offset 0x48 and status offset
0x24)
in reset-lantiq.c, we split each reset request /status pair into one
reset controller.
Each reset controller handles up to 32 resets. It will create up to 9
even more
reset controllers in the new SoCs. In reality, there is only one RCU
controller for all
SoCs. These designs worked but did not follow what hardware implemented.
After checking the existing code and referring to other implementation,
we decided to
use register offset + bit position method. It can support all SoCs with
this methods
without code change(device tree change only).
2. reset-lantiq.c does not support device restart which is part of the
reset in
old lantiq SoC. It moved this part into arch/mips/lantiq directory.
it was moved to the .dts instead of the arch code. again from
OpenWrt's vr9.dtsi [0]:
reboot {
compatible = "syscon-reboot";
regmap = <>;
offset = <0x10>;
mask = <0xe000>;
};
this sets the reset0 reset bits 31, 30 and 29 at reboot
ok. but not sure why we need to reset bit 31 and 29. global softwre
reset is bit 30.
3. reset-lantiqc reset callback doesn't implement what hardware implemented
function. In old SoCs, some bits in the same register can be hardware
reset clear.
It just call assert + assert. For these SoCs, we should only call
assert, hardware will auto deassert.
I didn't know that. so to confirm I understand this correctly:
- some reset lines must be asserted and de-asserted manually (setting
and clearing the bit manually). the _assert and _deassert functions
should be used in this case
Yes. We call software managed reset. callers call assert, deassert and delay
duration according to their specific requirement.
- other reset lines only support reset pulses. the _reset function
should be used in this case
- the _reset function should only assert the reset line, then wait
until the hardware automatically de-asserts it (without any further
write)
Yes, this is called hardware reset. We can't control reset duration.
is this the same for all, old and new SoCs?
New SoCs have removed support for hardware reset after software's feedback.
Old SoCs such as VRX200/ARX300 has both software/hardware resets
only two mainline Lantiq drivers are using reset lines - both are
using the _assert and _deassert variants:
- drivers/net/dsa/lantiq_gswip.c
- drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
It means migration will be very easy:)
4. Code not optimized and intel internal review not
Re: [PATCH] powerpc/time: use feature fixup in __USE_RTC() instead of cpu feature.
Christophe Leroy writes: > Le 26/08/2019 à 13:41, Michael Ellerman a écrit : >> Christophe Leroy writes: >>> sched_clock(), used by printk(), calls __USE_RTC() to know >>> whether to use realtime clock or timebase. >>> >>> __USE_RTC() uses cpu_has_feature() which is initialised by >>> machine_init(). Before machine_init(), __USE_RTC() returns true, >>> leading to a program check exception on CPUs not having realtime >>> clock. >>> >>> In order to be able to use printk() earlier, use feature fixup. >>> Feature fixups are applies in early_init(), enabling the use of >>> printk() earlier. >>> >>> Signed-off-by: Christophe Leroy >>> --- >>> arch/powerpc/include/asm/time.h | 9 - >>> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> The other option would be just to make this a compile time decision, eg. >> add CONFIG_PPC_601 and use that to gate whether we use RTC. > > Euh ... yes OK, why not. And that would help simplify many places in the > code. I can propose something in that direction, but it will be a bigger > change. Thanks. >> Given how many 601 users there are, maybe 1?, I think that would be a >> simpler option and avoids complicating the code / binary for everyone >> else. > > However this patch doesn't complicate things more than it was with > cpu_has_feature() which does exactly the same but using static keys, > does it ? It's more complicated in that it's not using cpu_has_feature() it's doing some custom thing that is not used anywhere else. But yeah I guess it's not much extra complication. cheers
Re: [PATCH] powerpc/time: use feature fixup in __USE_RTC() instead of cpu feature.
Benjamin Herrenschmidt writes: > On Mon, 2019-08-26 at 21:41 +1000, Michael Ellerman wrote: >> Christophe Leroy writes: >> > sched_clock(), used by printk(), calls __USE_RTC() to know >> > whether to use realtime clock or timebase. >> > >> > __USE_RTC() uses cpu_has_feature() which is initialised by >> > machine_init(). Before machine_init(), __USE_RTC() returns true, >> > leading to a program check exception on CPUs not having realtime >> > clock. >> > >> > In order to be able to use printk() earlier, use feature fixup. >> > Feature fixups are applies in early_init(), enabling the use of >> > printk() earlier. >> > >> > Signed-off-by: Christophe Leroy >> > --- >> > arch/powerpc/include/asm/time.h | 9 - >> > 1 file changed, 8 insertions(+), 1 deletion(-) >> >> The other option would be just to make this a compile time decision, eg. >> add CONFIG_PPC_601 and use that to gate whether we use RTC. >> >> Given how many 601 users there are, maybe 1?, I think that would be a >> simpler option and avoids complicating the code / binary for everyone >> else. > > Didn't we ditch 601 support years ago anyway ? We had workaround we > threw out I think... Paul said his still booted recently. cheers
Re: [PATCH] media: uvcvideo: Use streaming DMA APIs to transfer buffers
On Fri, Aug 2, 2019 at 10:12 PM Shik Chen wrote:
>
> Similar to the commit 1161db6776bd ("media: usb: pwc: Don't use coherent
> DMA buffers for ISO transfer") [1] for the pwc driver. Use streaming DMA
> APIs to transfer buffers and sync them explicitly, because accessing
> buffers allocated by usb_alloc_coherent() is slow on platforms without
> hardware coherent DMA.
>
> Tested on x86-64 (Intel Celeron 4305U) and armv7l (Rockchip RK3288) with
> Logitech Brio 4K camera at 1920x1080 using the WebRTC sample site [3].
>
> | | URB (us) | Decode (Gbps) | CPU (%) |
> |--||---|-|
> | x86-64 coherent | 53 +- 20 | 50.6 |0.24 |
> | x86-64 streaming | 55 +- 19 | 50.1 |0.25 |
> | armv7l coherent | 342 +- 379 | 1.8 |2.16 |
> | armv7l streaming | 99 +- 98 | 11.0 |0.36 |
>
> The performance characteristics are improved a lot on armv7l, and
> remained (almost) unchanged on x86-64. The code used for measurement can
> be found at [2].
>
> [1] https://git.kernel.org/torvalds/c/1161db6776bd
> [2] https://crrev.com/c/1729133
> [3] https://webrtc.github.io/samples/src/content/getusermedia/resolution/
>
> Signed-off-by: Shik Chen
> ---
> The allocated buffer could be as large as 768K when streaming 4K video.
> Ideally we should use some generic helper to allocate non-coherent
> memory in a more efficient way, such as https://lwn.net/Articles/774429/
> ("make the non-consistent DMA allocator more userful").
>
> But I cannot find any existing helper so a simple kzalloc() is used in
> this patch. The logic to figure out the DMA addressable GFP flags is
> similar to __dma_direct_alloc_pages() without the optimistic retries:
> https://elixir.bootlin.com/linux/v5.2.5/source/kernel/dma/direct.c#L96
>
> drivers/media/usb/uvc/uvc_video.c | 65 +--
> 1 file changed, 45 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c
> index 8fa77a81dd7f2c..962c35478896c4 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -1539,6 +1539,8 @@ static void uvc_video_complete(struct urb *urb)
> * Process the URB headers, and optionally queue expensive memcpy
> tasks
> * to be deferred to a work queue.
> */
> + dma_sync_single_for_cpu(>dev->dev, urb->transfer_dma,
> + urb->transfer_buffer_length, DMA_FROM_DEVICE);
> stream->decode(uvc_urb, buf, buf_meta);
>
> /* If no async work is needed, resubmit the URB immediately. */
> @@ -1565,18 +1567,51 @@ static void uvc_free_urb_buffers(struct uvc_streaming
> *stream)
> if (!uvc_urb->buffer)
> continue;
>
> -#ifndef CONFIG_DMA_NONCOHERENT
> - usb_free_coherent(stream->dev->udev, stream->urb_size,
> - uvc_urb->buffer, uvc_urb->dma);
> -#else
> + dma_unmap_single(>dev->udev->dev, uvc_urb->dma,
> +stream->urb_size, DMA_FROM_DEVICE);
> kfree(uvc_urb->buffer);
> -#endif
> - uvc_urb->buffer = NULL;
> }
>
> stream->urb_size = 0;
> }
>
> +static gfp_t uvc_alloc_gfp_flags(struct device *dev)
> +{
> + u64 mask = dma_get_mask(dev);
> +
> + if (dev->bus_dma_mask)
> + mask &= dev->bus_dma_mask;
> +
> + if (mask < DMA_BIT_MASK(32) && IS_ENABLED(CONFIG_ZONE_DMA))
> + return GFP_DMA;
> +
> + if (mask < DMA_BIT_MASK(64)) {
> + if (IS_ENABLED(CONFIG_ZONE_DMA32))
> + return GFP_DMA32;
> + if (IS_ENABLED(CONFIG_ZONE_DMA))
> + return GFP_DMA;
> + }
> +
> + return 0;
> +}
> +
> +static char *uvc_alloc_urb_buffer(struct device *dev, size_t size,
> + gfp_t gfp_flags, dma_addr_t *dma_handle)
> +{
> + void *buffer = kzalloc(size, gfp_flags | uvc_alloc_gfp_flags(dev));
> +
> + if (!buffer)
> + return NULL;
> +
> + *dma_handle = dma_map_single(dev, buffer, size, DMA_FROM_DEVICE);
> + if (dma_mapping_error(dev, *dma_handle)) {
> + kfree(buffer);
> + return NULL;
> + }
> +
> + return buffer;
> +}
> +
> /*
> * Allocate transfer buffers. This function can be called with buffers
> * already allocated when resuming from suspend, in which case it will
> @@ -1607,18 +1642,14 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming
> *stream,
>
> /* Retry allocations until one succeed. */
> for (; npackets > 1; npackets /= 2) {
> + stream->urb_size = psize * npackets;
> +
> for (i = 0; i < UVC_URBS; ++i) {
> struct uvc_urb *uvc_urb = >uvc_urb[i];
>
> - stream->urb_size = psize * npackets;
>
Re: [tip: x86/cpu] x86/cpu/intel: Fix rename fallout
Hi tip-bot2, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc6 next-20190826] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/tip-bot2-for-Ingo-Molnar/x86-cpu-intel-Fix-rename-fallout/20190827-083739 config: x86_64-lkp (attached as .config) compiler: gcc-7 (Debian 7.4.0-10) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): In file included from drivers/idle/intel_idle.c:53:0: >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_HASWELL' >> undeclared here (not in a function); did you mean 'INTEL_FAM6_HASWELL_X'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/idle/intel_idle.c:1075:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(HASWELL, idle_cpu_hsw), ^~ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_HASWELL_L' >> undeclared here (not in a function); did you mean 'INTEL_FAM6_HASWELL_X'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/idle/intel_idle.c:1077:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(HASWELL_L, idle_cpu_hsw), ^~ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_HASWELL_G' >> undeclared here (not in a function); did you mean 'INTEL_FAM6_HASWELL_L'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/idle/intel_idle.c:1078:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(HASWELL_G, idle_cpu_hsw), ^~ >> arch/x86/include/asm/intel-family.h:114:23: error: >> 'INTEL_FAM6_ATOM_SILVERMONT_D' undeclared here (not in a function); did you >> mean 'INTEL_FAM6_ATOM_SILVERMONT_X'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/idle/intel_idle.c:1079:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(ATOM_SILVERMONT_D, idle_cpu_avn), ^~ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_BROADWELL' >> undeclared here (not in a function); did you mean 'INTEL_FAM6_BROADWELL_X'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/idle/intel_idle.c:1080:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(BROADWELL, idle_cpu_bdw), ^~ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_BROADWELL_G' >> undeclared here (not in a function); did you mean 'INTEL_FAM6_BROADWELL_X'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/idle/intel_idle.c:1081:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(BROADWELL_G, idle_cpu_bdw), ^~ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_BROADWELL_D' >> undeclared here (not in a function); did you mean 'INTEL_FAM6_BROADWELL_G'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/idle/intel_idle.c:1083:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(BROADWELL_D, idle_cpu_bdw), ^~ >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_SKYLAKE_L' >> undeclared here (not in a function); did you mean 'INTEL_FAM6_SKYLAKE_X'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_AN
RE: [PATCH v3 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
On Tue, August 20, 2019 at 1:14 PM Arnaldo Carvalho de Melo wrote: > > Arnaldo, once we decide what the right fix is, I am happy to post the > update (options 1, 1+2) as a patch series. > > I think you should get the checks for ref_reloc_sym in place so as to make the > code overall more robust, and also go on continuing to make the checks in > tools/perf/ to match what is checked on the other side of the mirror, i.e. by > the kernel, so from a quick read, please put first the robustness patches > (check ref_reloc_sym) do your other suggestions and update the warnings, > then refresh the two patches that still are not in my perf/core branch: > > [acme@quaco perf]$ git rebase perf/core > First, rewinding head to replay your work on top of it... > Applying: perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks > Applying: perf symbols: Use CAP_SYSLOG with kptr_restrict checks > [acme@quaco perf]$ > > I've pushed out perf/cap, so you can go from there as it is rebased on my > current perf/core. > > Then test all these cases: with/without libcap, with euid==0 and different > than zero, with capabilities, etc, patch by patch so that we don't break > bisection nor regress, All done. I've posted the update as a new follow-up series: https://lkml.kernel.org/lkml/1566869956-7154-1-git-send-email-iluba...@akamai.com/ rebased on your perf/core. I've tested 336 permutations (see the new cover). In particular, I was able to reproduce the crash on perf/cap and confirm that no permutation can cause such crashes for any of the patches in the series. > Thanks and keep up the good work! > > - Arnaldo - Igor
Re: [PATCH 3/4] mdev: Expose mdev alias in sysfs tree
On Mon, 26 Aug 2019 15:41:18 -0500
Parav Pandit wrote:
> Expose mdev alias as string in a sysfs tree so that such attribute can
> be used to generate netdevice name by systemd/udev or can be used to
> match other kernel objects based on the alias of the mdev.
>
> Signed-off-by: Parav Pandit
> ---
> drivers/vfio/mdev/mdev_sysfs.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/vfio/mdev/mdev_sysfs.c b/drivers/vfio/mdev/mdev_sysfs.c
> index 43afe0e80b76..59f4e3cc5233 100644
> --- a/drivers/vfio/mdev/mdev_sysfs.c
> +++ b/drivers/vfio/mdev/mdev_sysfs.c
> @@ -246,7 +246,20 @@ static ssize_t remove_store(struct device *dev, struct
> device_attribute *attr,
>
> static DEVICE_ATTR_WO(remove);
>
> +static ssize_t alias_show(struct device *device,
> + struct device_attribute *attr, char *buf)
> +{
> + struct mdev_device *dev = mdev_from_dev(device);
> +
> + if (!dev->alias)
> + return -EOPNOTSUPP;
Wouldn't it be better to not create the alias at all? Thanks,
Alex
> +
> + return sprintf(buf, "%s\n", dev->alias);
> +}
> +static DEVICE_ATTR_RO(alias);
> +
> static const struct attribute *mdev_device_attrs[] = {
> + _attr_alias.attr,
> _attr_remove.attr,
> NULL,
> };
Re: [tip: x86/cpu] x86/cpu/intel: Aggregate big core client naming
Hi tip-bot2, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc6 next-20190826] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/tip-bot2-for-Peter-Zijlstra/x86-cpu-intel-Aggregate-big-core-client-naming/20190827-055636 config: x86_64-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.4.0-10) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): In file included from drivers/powercap/intel_rapl_common.c:27:0: >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_HASWELL_CORE' >> undeclared here (not in a function); did you mean 'INTEL_FAM6_HASWELL_GT3E'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/powercap/intel_rapl_common.c:960:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(HASWELL_CORE, rapl_defaults_core), ^~ >> arch/x86/include/asm/intel-family.h:114:23: error: >> 'INTEL_FAM6_BROADWELL_CORE' undeclared here (not in a function); did you >> mean 'INTEL_FAM6_BROADWELL_GT3E'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/powercap/intel_rapl_common.c:965:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(BROADWELL_CORE, rapl_defaults_core), ^~ arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_SKYLAKE_DESKTOP' undeclared here (not in a function); did you mean 'INTEL_FAM6_SKYLAKE_X'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/powercap/intel_rapl_common.c:970:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core), ^~ arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_KABYLAKE_DESKTOP' undeclared here (not in a function); did you mean 'INTEL_FAM6_SKYLAKE_DESKTOP'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/powercap/intel_rapl_common.c:974:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(KABYLAKE_DESKTOP, rapl_defaults_core), ^~ arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_ICELAKE_DESKTOP' undeclared here (not in a function); did you mean 'INTEL_FAM6_SKYLAKE_DESKTOP'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/powercap/intel_rapl_common.c:977:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(ICELAKE_DESKTOP, rapl_defaults_core), ^~ -- In file included from drivers/idle/intel_idle.c:53:0: >> arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_HASWELL_CORE' >> undeclared here (not in a function); did you mean 'INTEL_FAM6_HASWELL_GT3E'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/idle/intel_idle.c:1075:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(HASWELL_CORE, idle_cpu_hsw), ^~ >> arch/x86/include/asm/intel-family.h:114:23: error: >> 'INTEL_FAM6_BROADWELL_CORE' undeclared here (not in a function); did you >> mean 'INTEL_FAM6_BROADWELL_GT3E'? INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data) ^ arch/x86/include/asm/intel-family.h:108:12: note: in definition of macro 'INTEL_CPU_FAM_ANY' .model = _model,\ ^~ drivers/idle/intel_idle.c:1080:2: note: in expansion of macro 'INTEL_CPU_FAM6' INTEL_CPU_FAM6(BROADWELL_CORE, idle_cpu_bdw), ^~ arch/x86/include/asm/intel-family.h:114:23: error: 'INTEL_FAM6_SKYLAKE_DESKTOP' undeclared here (not in a function); did you mean 'INTEL_F
Re: [PATCH 1/4] mdev: Introduce sha1 based mdev alias
On Mon, 26 Aug 2019 19:44:56 -0600
Alex Williamson wrote:
> On Mon, 26 Aug 2019 15:41:16 -0500
> Parav Pandit wrote:
>
> > Whenever a parent requests to generate mdev alias, generate a mdev
> > alias.
> > It is an optional attribute that parent can request to generate
> > for each of its child mdev.
> > mdev alias is generated using sha1 from the mdev name.
> >
> > Signed-off-by: Parav Pandit
> > ---
> > drivers/vfio/mdev/mdev_core.c| 98 +++-
> > drivers/vfio/mdev/mdev_private.h | 5 +-
> > drivers/vfio/mdev/mdev_sysfs.c | 13 +++--
> > include/linux/mdev.h | 4 ++
> > 4 files changed, 111 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> > index b558d4cfd082..e825ff38b037 100644
> > --- a/drivers/vfio/mdev/mdev_core.c
> > +++ b/drivers/vfio/mdev/mdev_core.c
> > @@ -10,9 +10,11 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "mdev_private.h"
> >
> > @@ -27,6 +29,8 @@ static struct class_compat *mdev_bus_compat_class;
> > static LIST_HEAD(mdev_list);
> > static DEFINE_MUTEX(mdev_list_lock);
> >
> > +static struct crypto_shash *alias_hash;
> > +
> > struct device *mdev_parent_dev(struct mdev_device *mdev)
> > {
> > return mdev->parent->dev;
> > @@ -164,6 +168,18 @@ int mdev_register_device(struct device *dev, const
> > struct mdev_parent_ops *ops)
> > goto add_dev_err;
> > }
> >
> > + if (ops->get_alias_length) {
> > + unsigned int digest_size;
> > + unsigned int aligned_len;
> > +
> > + aligned_len = roundup(ops->get_alias_length(), 2);
> > + digest_size = crypto_shash_digestsize(alias_hash);
> > + if (aligned_len / 2 > digest_size) {
> > + ret = -EINVAL;
> > + goto add_dev_err;
> > + }
> > + }
>
> This looks like a sanity check, it could be done outside of the
> parent_list_lock, even before we get a parent device reference.
>
> I think we're using a callback for get_alias_length() rather than a
> fixed field to support the mtty module option added in patch 4, right?
> Its utility is rather limited with no args. I could imagine that if a
> parent wanted to generate an alias that could be incorporated into a
> string with the parent device name that it would be useful to call this
> with the parent device as an arg. I guess we can save that until a
> user comes along though.
>
> There doesn't seem to be anything serializing use of alias_hash.
>
> > +
> > parent = kzalloc(sizeof(*parent), GFP_KERNEL);
> > if (!parent) {
> > ret = -ENOMEM;
> > @@ -259,6 +275,7 @@ static void mdev_device_free(struct mdev_device *mdev)
> > mutex_unlock(_list_lock);
> >
> > dev_dbg(>dev, "MDEV: destroying\n");
> > + kvfree(mdev->alias);
> > kfree(mdev);
> > }
> >
> > @@ -269,18 +286,86 @@ static void mdev_device_release(struct device *dev)
> > mdev_device_free(mdev);
> > }
> >
> > -int mdev_device_create(struct kobject *kobj,
> > - struct device *dev, const guid_t *uuid)
> > +static const char *
> > +generate_alias(const char *uuid, unsigned int max_alias_len)
> > +{
> > + struct shash_desc *hash_desc;
> > + unsigned int digest_size;
> > + unsigned char *digest;
> > + unsigned int alias_len;
> > + char *alias;
> > + int ret = 0;
> > +
> > + /* Align to multiple of 2 as bin2hex will generate
> > +* even number of bytes.
> > +*/
>
> Comment style for non-networking code please.
>
> > + alias_len = roundup(max_alias_len, 2);
> > + alias = kvzalloc(alias_len + 1, GFP_KERNEL);
Oops, here's the null termination of alias for the even case (+ 1),
ignore the comment below about odd/even. Thanks,
Alex
>
> The size we're generating here should be small enough to just use
> kzalloc(), probably below too.
>
> > + if (!alias)
> > + return NULL;
> > +
> > + /* Allocate and init descriptor */
> > + hash_desc = kvzalloc(sizeof(*hash_desc) +
> > +crypto_shash_descsize(alias_hash),
> > +GFP_KERNEL);
> > + if (!hash_desc)
> > + goto desc_err;
> > +
> > + hash_desc->tfm = alias_hash;
> > +
> > + digest_size = crypto_shash_digestsize(alias_hash);
> > +
> > + digest = kvzalloc(digest_size, GFP_KERNEL);
> > + if (!digest) {
> > + ret = -ENOMEM;
> > + goto digest_err;
> > + }
> > + crypto_shash_init(hash_desc);
> > + crypto_shash_update(hash_desc, uuid, UUID_STRING_LEN);
> > + crypto_shash_final(hash_desc, digest);
> > + bin2hex([0], digest,
>
> [0], ie. alias
>
> > + min_t(unsigned int, digest_size, alias_len / 2));
> > + /* When alias length is odd, zero out and additional last byte
> > +* that bin2hex has copied.
> > +*/
> > + if (max_alias_len % 2)
> > +
RE: [PATCH V3 1/5] thermal: qoriq: Add clock operations
> On 7/30/2019 5:31 AM, anson.hu...@nxp.com wrote:
> > From: Anson Huang
> >
> > Some platforms like i.MX8MQ has clock control for this module, need to
> > add clock operations to make sure the driver is working properly.
> >
> > Signed-off-by: Anson Huang
> > Reviewed-by: Guido Günther
>
> This series looks good, do you think it can be merged in time for v5.4?
> Today was v5.3-rc6.
If the question is for me, then I am NOT sure, the thermal patches are pending
there for almost half year and I did NOT receive any response, looks like no one
is maintaining the thermal sub-system?
>
> In an earlier series the CLK_IS_CRITICAL flags was removed from the TMU
> clock so if the thermal driver doesn't explicitly enable it the system will
> hang
> on probe. This is what happens in linux-next right now!
The thermal driver should be built with module, so default kernel should can
boot
up, do you modify the thermal driver as built-in?
>
> Unless this patches is merged soon we'll end up with a 5.4-rc1 that doesn't
> boot on imx8mq. An easy fix would be to drop/revert commit
> 951c1aef9691 ("clk: imx8mq: Remove CLK_IS_CRITICAL flag for
> IMX8MQ_CLK_TMU_ROOT") until the thermal patches are accepted.
If the thermal driver is built as module, I think no need to revert the commit,
but
if by default thermal driver is built-in or mod probed, then yes, it should NOT
break
kernel boot up.
Anson.
>
> Merging patches out-of-order when they have hard (boot-breaking)
> dependencies also breaks bisect.
>
> --
> Regards,
> Leonard
Re: [PATCH v2] powerpc: Allow flush_(inval_)dcache_range to work across ranges >4GB
"Alastair D'Silva" writes:
> From: Alastair D'Silva
>
> The upstream commit:
> 22e9c88d486a ("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
> has a similar effect, but since it is a rewrite of the assembler to C, is
> too invasive for stable. This patch is a minimal fix to address the issue in
> assembler.
>
> This patch applies cleanly to v5.2, v4.19 & v4.14.
>
> When calling flush_(inval_)dcache_range with a size >4GB, we were masking
> off the upper 32 bits, so we would incorrectly flush a range smaller
> than intended.
>
> This patch replaces the 32 bit shifts with 64 bit ones, so that
> the full size is accounted for.
>
> Changelog:
> v2
> - Add related upstream commit
>
> Signed-off-by: Alastair D'Silva
> ---
> arch/powerpc/kernel/misc_64.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Michael Ellerman
cheers
> diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
> index 1ad4089dd110..d4d096f80f4b 100644
> --- a/arch/powerpc/kernel/misc_64.S
> +++ b/arch/powerpc/kernel/misc_64.S
> @@ -130,7 +130,7 @@ _GLOBAL_TOC(flush_dcache_range)
> subfr8,r6,r4/* compute length */
> add r8,r8,r5/* ensure we get enough */
> lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of dcache block
> size */
> - srw.r8,r8,r9/* compute line count */
> + srd.r8,r8,r9/* compute line count */
> beqlr /* nothing to do? */
> mtctr r8
> 0: dcbst 0,r6
> @@ -148,7 +148,7 @@ _GLOBAL(flush_inval_dcache_range)
> subfr8,r6,r4/* compute length */
> add r8,r8,r5/* ensure we get enough */
> lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of dcache block size */
> - srw.r8,r8,r9/* compute line count */
> + srd.r8,r8,r9/* compute line count */
> beqlr /* nothing to do? */
> sync
> isync
> --
> 2.21.0
Re: [PATCH 1/4] mdev: Introduce sha1 based mdev alias
On Mon, 26 Aug 2019 15:41:16 -0500
Parav Pandit wrote:
> Whenever a parent requests to generate mdev alias, generate a mdev
> alias.
> It is an optional attribute that parent can request to generate
> for each of its child mdev.
> mdev alias is generated using sha1 from the mdev name.
>
> Signed-off-by: Parav Pandit
> ---
> drivers/vfio/mdev/mdev_core.c| 98 +++-
> drivers/vfio/mdev/mdev_private.h | 5 +-
> drivers/vfio/mdev/mdev_sysfs.c | 13 +++--
> include/linux/mdev.h | 4 ++
> 4 files changed, 111 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index b558d4cfd082..e825ff38b037 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -10,9 +10,11 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
>
> #include "mdev_private.h"
>
> @@ -27,6 +29,8 @@ static struct class_compat *mdev_bus_compat_class;
> static LIST_HEAD(mdev_list);
> static DEFINE_MUTEX(mdev_list_lock);
>
> +static struct crypto_shash *alias_hash;
> +
> struct device *mdev_parent_dev(struct mdev_device *mdev)
> {
> return mdev->parent->dev;
> @@ -164,6 +168,18 @@ int mdev_register_device(struct device *dev, const
> struct mdev_parent_ops *ops)
> goto add_dev_err;
> }
>
> + if (ops->get_alias_length) {
> + unsigned int digest_size;
> + unsigned int aligned_len;
> +
> + aligned_len = roundup(ops->get_alias_length(), 2);
> + digest_size = crypto_shash_digestsize(alias_hash);
> + if (aligned_len / 2 > digest_size) {
> + ret = -EINVAL;
> + goto add_dev_err;
> + }
> + }
This looks like a sanity check, it could be done outside of the
parent_list_lock, even before we get a parent device reference.
I think we're using a callback for get_alias_length() rather than a
fixed field to support the mtty module option added in patch 4, right?
Its utility is rather limited with no args. I could imagine that if a
parent wanted to generate an alias that could be incorporated into a
string with the parent device name that it would be useful to call this
with the parent device as an arg. I guess we can save that until a
user comes along though.
There doesn't seem to be anything serializing use of alias_hash.
> +
> parent = kzalloc(sizeof(*parent), GFP_KERNEL);
> if (!parent) {
> ret = -ENOMEM;
> @@ -259,6 +275,7 @@ static void mdev_device_free(struct mdev_device *mdev)
> mutex_unlock(_list_lock);
>
> dev_dbg(>dev, "MDEV: destroying\n");
> + kvfree(mdev->alias);
> kfree(mdev);
> }
>
> @@ -269,18 +286,86 @@ static void mdev_device_release(struct device *dev)
> mdev_device_free(mdev);
> }
>
> -int mdev_device_create(struct kobject *kobj,
> -struct device *dev, const guid_t *uuid)
> +static const char *
> +generate_alias(const char *uuid, unsigned int max_alias_len)
> +{
> + struct shash_desc *hash_desc;
> + unsigned int digest_size;
> + unsigned char *digest;
> + unsigned int alias_len;
> + char *alias;
> + int ret = 0;
> +
> + /* Align to multiple of 2 as bin2hex will generate
> + * even number of bytes.
> + */
Comment style for non-networking code please.
> + alias_len = roundup(max_alias_len, 2);
> + alias = kvzalloc(alias_len + 1, GFP_KERNEL);
The size we're generating here should be small enough to just use
kzalloc(), probably below too.
> + if (!alias)
> + return NULL;
> +
> + /* Allocate and init descriptor */
> + hash_desc = kvzalloc(sizeof(*hash_desc) +
> + crypto_shash_descsize(alias_hash),
> + GFP_KERNEL);
> + if (!hash_desc)
> + goto desc_err;
> +
> + hash_desc->tfm = alias_hash;
> +
> + digest_size = crypto_shash_digestsize(alias_hash);
> +
> + digest = kvzalloc(digest_size, GFP_KERNEL);
> + if (!digest) {
> + ret = -ENOMEM;
> + goto digest_err;
> + }
> + crypto_shash_init(hash_desc);
> + crypto_shash_update(hash_desc, uuid, UUID_STRING_LEN);
> + crypto_shash_final(hash_desc, digest);
> + bin2hex([0], digest,
[0], ie. alias
> + min_t(unsigned int, digest_size, alias_len / 2));
> + /* When alias length is odd, zero out and additional last byte
> + * that bin2hex has copied.
> + */
> + if (max_alias_len % 2)
> + alias[max_alias_len] = 0;
Doesn't this give us a null terminated string for odd numbers but not
even numbers? Probably best to define that we always provide a null
terminated string then we could do this unconditionally.
> +
> + kvfree(digest);
> + kvfree(hash_desc);
> + return alias;
> +
> +digest_err:
> + kvfree(hash_desc);
> +desc_err:
> +
Re: poisoned pages do not play well in the buddy allocator
On Mon, Aug 26, 2019 at 12:41:50PM +0200, Oscar Salvador wrote:
> Hi,
>
> When analyzing a problem reported by one of our customers, I stumbbled upon
> an issue
> that origins from the fact that poisoned pages end up in the buddy allocator.
>
> Let me break down the stepts that lie to the problem:
>
> 1) We soft-offline a page
> 2) Page gets flagged as HWPoison and is being sent to the buddy allocator.
>This is done through set_hwpoison_free_buddy_page().
> 3) Kcompactd wakes up in order to perform some compaction.
> 4) compact_zone() will call migrate_pages()
> 5) migrate_pages() will try to get a new page from compaction_alloc() to
> migrate to
> 6) if cc->freelist is empty, compaction_alloc() will call
> isolate_free_pagesblock()
> 7) isolate_free_pagesblock only checks for PageBuddy() to assume that a page
> is OK
>to be used to migrate to. Since HWPoisoned page are also PageBuddy, we add
>the page to the list. (same problem exists in fast_isolate_freepages()).
>
> The outcome of that is that we end up happily handing poisoned pages in
> compaction_alloc,
> so if we ever got a fault on that page through *_fault, we will return
> VM_FAULT_HWPOISON,
> and the process will be killed.
>
> I first though that I could get away with it by checking PageHWPoison in
> {fast_isolate_freepages/isolate_free_pagesblock}, but not really.
> It might be that the page we are checking is an order > 0 page, so the first
> page
> might not be poisoned, but the one the follows might be, and we end up in the
> same situation.
Yes, this is a whole point of the current implementation.
>
> After some more thought, I really came to the conclusion that HWPoison pages
> should not
> really be in the buddy allocator, as this is only asking for problems.
> In this case it is only compaction code, but it could be happening somewhere
> else,
> and one would expect that the pages you got from the buddy allocator are
> __ready__ to use.
>
> I __think__ that we thought we were safe to put HWPoison pages in the buddy
> allocator as we
> perform healthy checks when getting a page from there, so we skip poisoned
> pages
>
> Of course, this is not the end of the story, now that someone got a page, if
> he frees it,
> there is a high chance that this page ends up in a pcplist (I saw that).
> Unless we are on CONFIG_VM_DEBUG, we do not check for the health of pages got
> from pcplist,
> as we do when getting a page from the buddy allocator.
>
> I checked [1], and it seems that [2] was going towards fixing this kind of
> issue.
>
> I think it is about time to revamp the whole thing.
>
> @Naoya: I could give it a try if you are busy.
Thanks for raising hand. That's really wonderful. I think that the series [1]
is not
merge yet but not rejected yet, so feel free to reuse/update/revamp it.
>
> [1]
> https://lore.kernel.org/linux-mm/1541746035-13408-1-git-send-email-n-horigu...@ah.jp.nec.com/
> [2]
> https://lore.kernel.org/linux-mm/1541746035-13408-9-git-send-email-n-horigu...@ah.jp.nec.com/
>
> --
> Oscar Salvador
> SUSE L3
>
[PATCH 0/5] perf: Treat perf_event_paranoid and kptr_restrict like the kernel does it
This is a follow up series to the ensure perf treats perf_event_paranoid and kptr_restrict in a way that is similar to the kernel's. That includes use of capabilities instead of euid==0, when possible, as well as adjusting the logic and fixing bugs. Prior discussion: https://lkml.kernel.org/lkml/cover.1565188228.git.iluba...@akamai.com === Testing notes === I have tested on x86 with perf binary installed according to Documentation/admin-guide/perf-security.rst (cap_sys_admin, cap_sys_ptrace, cap_syslog assigned to the perf executable). I tested each permutation of: * 7 commits: 1. HEAD of perf/core 2. patch 01 on top of perf/core 3. patches 01-02 on top of perf/core 4. patches 01-03 on top of perf/core 5. patches 01-04 on top of perf/core 6. patches 01-05 on top of perf/core 7. HEAD of perf/cap (with known bug fixed by patch 01 of this series) * 2 build environments: with and without libcap-dev * 3 kernel.kptr_restrict values: 0, 1, 2 * 4 kernel.perf_event_paranoid values: -1, 0, 1, 2 * 2 users: root and non-root Total: 336 permutations Each permutation consisted of: perf test perf record -e instructions -- sleep 1 All test runs were expected. Also, as expected, the following permutation (just that permutation) resulted in segmentation failure: commit: perf/cap build: no libcap-dev kernel.kptr_restrict: 0 kernel.perf_event_paranoid: 2 user: non-root The perf/cap commit was included in the test to ensure that we can reproduce the crash and hence test that the patch series fixes the crash, while retaining the desired behavior of perf/cap. === Series Contents === 01: perf event: Check ref_reloc_sym before using it Fix the pre-existing cause of the crash above: use of ref_reloc_sym without a check for NULL 02: perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks Replace the use of euid==0 with a check for CAP_SYS_ADMIN whenever perf_event_paranoid level is verified. * This patch has been reviewed previously and is unchanged. * I kept Acks and Sign-offs. 03: perf util: kernel profiling is disallowed only when perf_event_paranoid>1 Align perf logic regarding perf_event_paranoid to match kernel's. This has been reported by Arnaldo. 04: perf symbols: Use CAP_SYSLOG with kptr_restrict checks Replace the use of uid and euid with a check for CAP_SYSLOG when kptr_restrict is verified (similar to kernel/kallsyms.c and lib/vsprintf.c). Consult perf_event_paranoid when kptr_restrict==0 (see kernel/kallsyms.c). * A previous version of this patch has been reviewed previously, but I * modified it in a non-trivial way, so I removed Acks. 05: perf: warn perf_event_paranoid restrict kernel symbols Warn that /proc/sys/kernel/perf_event_paranoid can also restrict kernel symbols. Igor Lubashev (5): perf event: Check ref_reloc_sym before using it perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks perf util: kernel profiling is disallowed only when perf_event_paranoid > 1 perf symbols: Use CAP_SYSLOG with kptr_restrict checks perf: warn that perf_event_paranoid can restrict kernel symbols tools/perf/arch/arm/util/cs-etm.c| 3 ++- tools/perf/arch/arm64/util/arm-spe.c | 3 ++- tools/perf/arch/x86/util/intel-bts.c | 3 ++- tools/perf/arch/x86/util/intel-pt.c | 2 +- tools/perf/builtin-record.c | 2 +- tools/perf/builtin-top.c | 2 +- tools/perf/builtin-trace.c | 2 +- tools/perf/util/event.c | 7 --- tools/perf/util/evsel.c | 2 +- tools/perf/util/symbol.c | 15 --- 10 files changed, 27 insertions(+), 14 deletions(-) -- 2.7.4
[PATCH 1/5] perf event: Check ref_reloc_sym before using it
Check for ref_reloc_sym before using it instead of checking symbol_conf.kptr_restrict and relying solely on that check. Signed-off-by: Igor Lubashev Reported-by: Mathieu Poirier --- tools/perf/util/event.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c index f440fdc3e953..b84f5f3c9651 100644 --- a/tools/perf/util/event.c +++ b/tools/perf/util/event.c @@ -913,11 +913,13 @@ static int __perf_event__synthesize_kernel_mmap(struct perf_tool *tool, int err; union perf_event *event; - if (symbol_conf.kptr_restrict) - return -1; if (map == NULL) return -1; + kmap = map__kmap(map); + if (!kmap->ref_reloc_sym) + return -1; + /* * We should get this from /sys/kernel/sections/.text, but till that is * available use this, and after it is use this as a fallback for older @@ -940,7 +942,6 @@ static int __perf_event__synthesize_kernel_mmap(struct perf_tool *tool, event->header.misc = PERF_RECORD_MISC_GUEST_KERNEL; } - kmap = map__kmap(map); size = snprintf(event->mmap.filename, sizeof(event->mmap.filename), "%s%s", machine->mmap_name, kmap->ref_reloc_sym->name) + 1; size = PERF_ALIGN(size, sizeof(u64)); -- 2.7.4
[PATCH 3/5] perf util: kernel profiling is disallowed only when perf_event_paranoid > 1
Perf was too restrictive about sysctl kernel.perf_event_paranoid. The
kernel only disallows profiling when perf_event_paranoid > 1. Make perf do
the same.
Signed-off-by: Igor Lubashev
---
tools/perf/util/evsel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 0b3b5af33954..bfe6ed2abcc2 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -279,7 +279,7 @@ struct evsel *perf_evsel__new_idx(struct perf_event_attr
*attr, int idx)
static bool perf_event_can_profile_kernel(void)
{
- return perf_event_paranoid_check(-1);
+ return perf_event_paranoid_check(1);
}
struct evsel *perf_evsel__new_cycles(bool precise)
--
2.7.4
[PATCH 2/5] perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
The kernel is using CAP_SYS_ADMIN instead of euid==0 to override
perf_event_paranoid check. Make perf do the same.
Signed-off-by: Igor Lubashev
Acked-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Alexey Budankov
Cc: James Morris
Cc: Mathieu Poirier
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Suzuki Poulouse
Cc: linux-arm-ker...@lists.infradead.org
Link:
http://lkml.kernel.org/r/ad56df5452eeafb99dda9fc3d30f0f487aace503.1565188228.git.iluba...@akamai.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/arm/util/cs-etm.c| 3 ++-
tools/perf/arch/arm64/util/arm-spe.c | 3 ++-
tools/perf/arch/x86/util/intel-bts.c | 3 ++-
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/util/evsel.c | 2 +-
5 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/tools/perf/arch/arm/util/cs-etm.c
b/tools/perf/arch/arm/util/cs-etm.c
index 5cb07e8cb296..b87a1ca2968f 100644
--- a/tools/perf/arch/arm/util/cs-etm.c
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -18,6 +18,7 @@
#include "../../perf.h"
#include "../../util/auxtrace.h"
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evlist.h"
#include "../../util/evsel.h"
#include "../../util/pmu.h"
@@ -254,7 +255,7 @@ static int cs_etm_recording_options(struct auxtrace_record
*itr,
struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
struct evsel *evsel, *cs_etm_evsel = NULL;
struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = (geteuid() == 0 || perf_event_paranoid() < 0);
+ bool privileged = perf_event_paranoid_check(-1);
int err = 0;
ptr->evlist = evlist;
diff --git a/tools/perf/arch/arm64/util/arm-spe.c
b/tools/perf/arch/arm64/util/arm-spe.c
index 00915b8fd05b..29275a0544cd 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -12,6 +12,7 @@
#include
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -66,7 +67,7 @@ static int arm_spe_recording_options(struct auxtrace_record
*itr,
container_of(itr, struct arm_spe_recording, itr);
struct perf_pmu *arm_spe_pmu = sper->arm_spe_pmu;
struct evsel *evsel, *arm_spe_evsel = NULL;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
struct evsel *tracking_evsel;
int err;
diff --git a/tools/perf/arch/x86/util/intel-bts.c
b/tools/perf/arch/x86/util/intel-bts.c
index 7b23318ebd7b..56a76142e9fd 100644
--- a/tools/perf/arch/x86/util/intel-bts.c
+++ b/tools/perf/arch/x86/util/intel-bts.c
@@ -12,6 +12,7 @@
#include
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -107,7 +108,7 @@ static int intel_bts_recording_options(struct
auxtrace_record *itr,
struct perf_pmu *intel_bts_pmu = btsr->intel_bts_pmu;
struct evsel *evsel, *intel_bts_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
btsr->evlist = evlist;
btsr->snapshot_mode = opts->auxtrace_snapshot_mode;
diff --git a/tools/perf/arch/x86/util/intel-pt.c
b/tools/perf/arch/x86/util/intel-pt.c
index a8e633aa278a..7abccc0b0dc0 100644
--- a/tools/perf/arch/x86/util/intel-pt.c
+++ b/tools/perf/arch/x86/util/intel-pt.c
@@ -578,7 +578,7 @@ static int intel_pt_recording_options(struct
auxtrace_record *itr,
bool have_timing_info, need_immediate = false;
struct evsel *evsel, *intel_pt_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
u64 tsc_bit;
int err;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 0a33f7322ecc..0b3b5af33954 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -279,7 +279,7 @@ struct evsel *perf_evsel__new_idx(struct perf_event_attr
*attr, int idx)
static bool perf_event_can_profile_kernel(void)
{
- return geteuid() == 0 || perf_event_paranoid() == -1;
+ return perf_event_paranoid_check(-1);
}
struct evsel *perf_evsel__new_cycles(bool precise)
--
2.7.4
[PATCH 5/5] perf: warn that perf_event_paranoid can restrict kernel symbols
Warn that /proc/sys/kernel/perf_event_paranoid can also restrict kernel
symbols.
Signed-off-by: Igor Lubashev
---
tools/perf/builtin-record.c | 2 +-
tools/perf/builtin-top.c| 2 +-
tools/perf/builtin-trace.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f71631f2bcb5..18505d92ff69 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -2372,7 +2372,7 @@ int cmd_record(int argc, const char **argv)
if (symbol_conf.kptr_restrict &&
!perf_evlist__exclude_kernel(rec->evlist))
pr_warning(
"WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted,\n"
-"check /proc/sys/kernel/kptr_restrict.\n\n"
+"check /proc/sys/kernel/kptr_restrict and
/proc/sys/kernel/perf_event_paranoid.\n\n"
"Samples in kernel functions may not be resolved if a suitable vmlinux\n"
"file is not found in the buildid cache or in the vmlinux path.\n\n"
"Samples in kernel modules won't be resolved at all.\n\n"
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 5970723cd55a..29e910fb2d9a 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -770,7 +770,7 @@ static void perf_event__process_sample(struct perf_tool
*tool,
if (!perf_evlist__exclude_kernel(top->session->evlist)) {
ui__warning(
"Kernel address maps (/proc/{kallsyms,modules}) are restricted.\n\n"
-"Check /proc/sys/kernel/kptr_restrict.\n\n"
+"Check /proc/sys/kernel/kptr_restrict and
/proc/sys/kernel/perf_event_paranoid.\n\n"
"Kernel%s samples will not be resolved.\n",
al.map && map__has_symbols(al.map) ?
" modules" : "");
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index bc44ed29e05a..9443b8e05810 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1381,7 +1381,7 @@ static char *trace__machine__resolve_kernel_addr(void
*vmachine, unsigned long l
if (symbol_conf.kptr_restrict) {
pr_warning("Kernel address maps (/proc/{kallsyms,modules}) are
restricted.\n\n"
- "Check /proc/sys/kernel/kptr_restrict.\n\n"
+ "Check /proc/sys/kernel/kptr_restrict and
/proc/sys/kernel/perf_event_paranoid.\n\n"
"Kernel samples will not be resolved.\n");
machine->kptr_restrict_warned = true;
return NULL;
--
2.7.4
[PATCH 4/5] perf symbols: Use CAP_SYSLOG with kptr_restrict checks
The kernel is using CAP_SYSLOG capability instead of uid==0 and euid==0 when checking kptr_restrict. Make perf do the same. Also, the kernel is a more restrictive than "no restrictions" in case of kptr_restrict==0, so add the same logic to perf. Signed-off-by: Igor Lubashev Cc: Jiri Olsa Cc: Alexander Shishkin Cc: Alexey Budankov Cc: James Morris Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Suzuki Poulouse Cc: linux-arm-ker...@lists.infradead.org Link: http://lkml.kernel.org/r/291d2cda6ee75b4cd4c9ce717c177db18bf03a31.1565188228.git.iluba...@akamai.com Cc: Arnaldo Carvalho de Melo --- tools/perf/util/symbol.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c index 4efde7879474..035f2e75728c 100644 --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -4,6 +4,7 @@ #include #include #include +#include #include #include #include @@ -15,8 +16,10 @@ #include #include "annotate.h" #include "build-id.h" +#include "cap.h" #include "util.h" #include "debug.h" +#include "event.h" #include "machine.h" #include "map.h" #include "symbol.h" @@ -2195,13 +2198,19 @@ static bool symbol__read_kptr_restrict(void) char line[8]; if (fgets(line, sizeof(line), fp) != NULL) - value = ((geteuid() != 0) || (getuid() != 0)) ? - (atoi(line) != 0) : - (atoi(line) == 2); + value = perf_cap__capable(CAP_SYSLOG) ? + (atoi(line) >= 2) : + (atoi(line) != 0); fclose(fp); } + /* Per kernel/kallsyms.c: +* we also restrict when perf_event_paranoid > 1 w/o CAP_SYSLOG +*/ + if (perf_event_paranoid() > 1 && !perf_cap__capable(CAP_SYSLOG)) + value = true; + return value; } -- 2.7.4
[PATCH 19/33] libperf: Add PERF_RECORD_COMM 'struct comm_event' to perf/event.h
From: Jiri Olsa
Moving comm_event event definition into libperf's event.h
header include.
In order to keep libperf simple, we switch 'u64/u32/u16/u8'
types used events to their generic '__u*' versions.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20190825181752.722-4-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/lib/include/perf/event.h | 6 ++
tools/perf/util/event.h | 6 --
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index c82e0c2c004b..3729a7d9253e 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -30,4 +30,10 @@ struct mmap2_event {
char filename[PATH_MAX];
};
+struct comm_event {
+ struct perf_event_header header;
+ __u32pid, tid;
+ char comm[16];
+};
+
#endif /* __LIBPERF_EVENT_H */
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index af252be8ca5b..e8973a783267 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -27,12 +27,6 @@
#define PRI_lx64 PRIx64
#endif
-struct comm_event {
- struct perf_event_header header;
- u32 pid, tid;
- char comm[16];
-};
-
struct namespaces_event {
struct perf_event_header header;
u32 pid, tid;
--
2.21.0
[PATCH 10/33] perf augmented_raw_syscalls: Postpone tmp map lookup to after pid_filter
From: Arnaldo Carvalho de Melo No sense in doing that lookup before figuring out if it will be used, i.e. if the pid is being filtered that tmp space lookup will be useless. Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-o74yggieorucfg4j74tb6...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/examples/bpf/augmented_raw_syscalls.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/perf/examples/bpf/augmented_raw_syscalls.c b/tools/perf/examples/bpf/augmented_raw_syscalls.c index b85b177c6726..0a8d217d65c7 100644 --- a/tools/perf/examples/bpf/augmented_raw_syscalls.c +++ b/tools/perf/examples/bpf/augmented_raw_syscalls.c @@ -250,13 +250,13 @@ int sys_enter(struct syscall_enter_args *args) struct syscall *syscall; int key = 0; + if (pid_filter__has(_filtered, getpid())) + return 0; + augmented_args = bpf_map_lookup_elem(_args_tmp, ); if (augmented_args == NULL) return 1; - if (pid_filter__has(_filtered, getpid())) - return 0; - probe_read(_args->args, sizeof(augmented_args->args), args); /* -- 2.21.0
[PATCH 29/33] libperf: Rename the PERF_RECORD_ structs to have a "perf" suffix
From: Arnaldo Carvalho de Melo
Even more, to have a "perf_record_" prefix, so that they match the
PERF_RECORD_ enum they map to.
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Link: https://lkml.kernel.org/n/tip-qbabmcz2a0pkzt72liyuz...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/lib/include/perf/event.h | 24 ++---
tools/perf/tests/parse-no-sample-id-all.c | 4 +--
tools/perf/util/bpf-event.c | 12 +++
tools/perf/util/event.h | 30
tools/perf/util/evsel.c | 4 +--
tools/perf/util/evsel.h | 2 +-
tools/perf/util/intel-bts.c | 2 +-
tools/perf/util/namespaces.c | 2 +-
tools/perf/util/namespaces.h | 4 +--
tools/perf/util/python.c | 44 +++
tools/perf/util/session.c | 2 +-
tools/perf/util/thread.c | 4 +--
tools/perf/util/thread.h | 4 +--
13 files changed, 69 insertions(+), 69 deletions(-)
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index e768a2dfbe53..36ad3a4a79e6 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -7,7 +7,7 @@
#include
#include
-struct mmap_event {
+struct perf_record_mmap {
struct perf_event_header header;
__u32pid, tid;
__u64start;
@@ -16,7 +16,7 @@ struct mmap_event {
char filename[PATH_MAX];
};
-struct mmap2_event {
+struct perf_record_mmap2 {
struct perf_event_header header;
__u32pid, tid;
__u64start;
@@ -31,33 +31,33 @@ struct mmap2_event {
char filename[PATH_MAX];
};
-struct comm_event {
+struct perf_record_comm {
struct perf_event_header header;
__u32pid, tid;
char comm[16];
};
-struct namespaces_event {
+struct perf_record_namespaces {
struct perf_event_header header;
__u32pid, tid;
__u64nr_namespaces;
struct perf_ns_link_info link_info[];
};
-struct fork_event {
+struct perf_record_fork {
struct perf_event_header header;
__u32pid, ppid;
__u32tid, ptid;
__u64time;
};
-struct lost_event {
+struct perf_record_lost {
struct perf_event_header header;
__u64id;
__u64lost;
};
-struct lost_samples_event {
+struct perf_record_lost_samples {
struct perf_event_header header;
__u64lost;
};
@@ -65,7 +65,7 @@ struct lost_samples_event {
/*
* PERF_FORMAT_ENABLED | PERF_FORMAT_RUNNING | PERF_FORMAT_ID
*/
-struct read_event {
+struct perf_record_read {
struct perf_event_header header;
__u32pid, tid;
__u64value;
@@ -74,7 +74,7 @@ struct read_event {
__u64id;
};
-struct throttle_event {
+struct perf_record_throttle {
struct perf_event_header header;
__u64time;
__u64id;
@@ -85,7 +85,7 @@ struct throttle_event {
#define KSYM_NAME_LEN 256
#endif
-struct ksymbol_event {
+struct perf_record_ksymbol {
struct perf_event_header header;
__u64addr;
__u32len;
@@ -94,7 +94,7 @@ struct ksymbol_event {
char name[KSYM_NAME_LEN];
};
-struct bpf_event {
+struct perf_record_bpf_event {
struct perf_event_header header;
__u16type;
__u16flags;
@@ -104,7 +104,7 @@ struct bpf_event {
__u8 tag[BPF_TAG_SIZE]; // prog tag
};
-struct sample_event {
+struct perf_record_sample {
struct perf_event_header header;
__u64array[];
};
diff --git a/tools/perf/tests/parse-no-sample-id-all.c
b/tools/perf/tests/parse-no-sample-id-all.c
index 396e40d68922..8284752a60c8 100644
--- a/tools/perf/tests/parse-no-sample-id-all.c
+++ b/tools/perf/tests/parse-no-sample-id-all.c
@@ -87,10 +87,10 @@ int test__parse_no_sample_id_all(struct test *test
__maybe_unused, int subtest _
},
.id = 2,
};
- struct mmap_event event3 = {
+ struct perf_record_mmap event3 = {
.header = {
.type = PERF_RECORD_MMAP,
- .size = sizeof(struct mmap_event),
+ .size = sizeof(struct perf_record_mmap),
},
};
union perf_event *events[] = {
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index
[PATCH 31/33] perf tools: Rename perf_event::bpf_event to perf_event::bpf
From: Arnaldo Carvalho de Melo
Just like all the other meta events, that extra _event suffix is just
redundant, ditch it.
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Song Liu
Link: https://lkml.kernel.org/n/tip-505qwpaizq1k0t6pk13v1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/bpf-event.c | 18 --
tools/perf/util/event.c | 3 +--
tools/perf/util/event.h | 2 +-
3 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index 69795c32ecf3..28fa2b1ce66e 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -35,7 +35,7 @@ static int machine__process_bpf_event_load(struct machine
*machine,
struct bpf_prog_info_linear *info_linear;
struct bpf_prog_info_node *info_node;
struct perf_env *env = machine->env;
- int id = event->bpf_event.id;
+ int id = event->bpf.id;
unsigned int i;
/* perf-record, no need to handle bpf-event */
@@ -71,7 +71,7 @@ int machine__process_bpf_event(struct machine *machine
__maybe_unused,
if (dump_trace)
perf_event__fprintf_bpf_event(event, stdout);
- switch (event->bpf_event.type) {
+ switch (event->bpf.type) {
case PERF_BPF_EVENT_PROG_LOAD:
return machine__process_bpf_event_load(machine, event, sample);
@@ -83,8 +83,7 @@ int machine__process_bpf_event(struct machine *machine
__maybe_unused,
*/
break;
default:
- pr_debug("unexpected bpf_event type of %d\n",
-event->bpf_event.type);
+ pr_debug("unexpected bpf_event type of %d\n", event->bpf.type);
break;
}
return 0;
@@ -162,7 +161,7 @@ static int perf_event__synthesize_one_bpf_prog(struct
perf_session *session,
struct record_opts *opts)
{
struct perf_record_ksymbol *ksymbol_event = >ksymbol;
- struct perf_record_bpf_event *bpf_event = >bpf_event;
+ struct perf_record_bpf_event *bpf_event = >bpf;
struct bpf_prog_info_linear *info_linear;
struct perf_tool *tool = session->tool;
struct bpf_prog_info_node *info_node;
@@ -302,7 +301,7 @@ int perf_event__synthesize_bpf_events(struct perf_session
*session,
int err;
int fd;
- event = malloc(sizeof(event->bpf_event) + KSYM_NAME_LEN +
machine->id_hdr_size);
+ event = malloc(sizeof(event->bpf) + KSYM_NAME_LEN +
machine->id_hdr_size);
if (!event)
return -1;
while (true) {
@@ -399,9 +398,9 @@ static int bpf_event__sb_cb(union perf_event *event, void
*data)
if (event->header.type != PERF_RECORD_BPF_EVENT)
return -1;
- switch (event->bpf_event.type) {
+ switch (event->bpf.type) {
case PERF_BPF_EVENT_PROG_LOAD:
- perf_env__add_bpf_info(env, event->bpf_event.id);
+ perf_env__add_bpf_info(env, event->bpf.id);
case PERF_BPF_EVENT_PROG_UNLOAD:
/*
@@ -411,8 +410,7 @@ static int bpf_event__sb_cb(union perf_event *event, void
*data)
*/
break;
default:
- pr_debug("unexpected bpf_event type of %d\n",
-event->bpf_event.type);
+ pr_debug("unexpected bpf_event type of %d\n", event->bpf.type);
break;
}
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index bdeaad434e52..17304df44fc2 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1494,8 +1494,7 @@ size_t perf_event__fprintf_ksymbol(union perf_event
*event, FILE *fp)
size_t perf_event__fprintf_bpf_event(union perf_event *event, FILE *fp)
{
return fprintf(fp, " type %u, flags %u, id %u\n",
- event->bpf_event.type, event->bpf_event.flags,
- event->bpf_event.id);
+ event->bpf.type, event->bpf.flags, event->bpf.id);
}
size_t perf_event__fprintf(union perf_event *event, FILE *fp)
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 34190e01f307..7251e2eee441 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -560,7 +560,7 @@ union perf_event {
struct perf_record_read read;
struct perf_record_throttle throttle;
struct perf_record_sample sample;
- struct perf_record_bpf_eventbpf_event;
+ struct perf_record_bpf_eventbpf;
struct perf_record_ksymbol ksymbol;
struct attr_event attr;
struct event_update_event event_update;
--
2.21.0
[PATCH 32/33] perf tool: Rename perf_tool::bpf_event to bpf
From: Arnaldo Carvalho de Melo
No need for that _event suffix, do just like all the other meta event
handlers and suppress that suffix.
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Song Liu
Link: https://lkml.kernel.org/n/tip-03spzxtqafbabbbmnm7y4...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 4 ++--
tools/perf/util/bpf-event.c | 11 +--
tools/perf/util/bpf-event.h | 10 +-
tools/perf/util/event.c | 14 +++---
tools/perf/util/event.h | 10 +-
tools/perf/util/machine.c | 2 +-
tools/perf/util/session.c | 6 +++---
tools/perf/util/tool.h | 2 +-
8 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 6f389b33fbe5..51e7e6d0eee6 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2492,8 +2492,8 @@ static int __cmd_script(struct perf_script *script)
script->tool.finished_round = process_finished_round_event;
}
if (script->show_bpf_events) {
- script->tool.ksymbol = process_bpf_events;
- script->tool.bpf_event = process_bpf_events;
+ script->tool.ksymbol = process_bpf_events;
+ script->tool.bpf = process_bpf_events;
}
if (perf_script__setup_per_event_dump(script)) {
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index 28fa2b1ce66e..2d6d500c9af7 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -64,12 +64,11 @@ static int machine__process_bpf_event_load(struct machine
*machine,
return 0;
}
-int machine__process_bpf_event(struct machine *machine __maybe_unused,
- union perf_event *event,
- struct perf_sample *sample __maybe_unused)
+int machine__process_bpf(struct machine *machine, union perf_event *event,
+struct perf_sample *sample)
{
if (dump_trace)
- perf_event__fprintf_bpf_event(event, stdout);
+ perf_event__fprintf_bpf(event, stdout);
switch (event->bpf.type) {
case PERF_BPF_EVENT_PROG_LOAD:
@@ -83,7 +82,7 @@ int machine__process_bpf_event(struct machine *machine
__maybe_unused,
*/
break;
default:
- pr_debug("unexpected bpf_event type of %d\n", event->bpf.type);
+ pr_debug("unexpected bpf event type of %d\n", event->bpf.type);
break;
}
return 0;
@@ -410,7 +409,7 @@ static int bpf_event__sb_cb(union perf_event *event, void
*data)
*/
break;
default:
- pr_debug("unexpected bpf_event type of %d\n", event->bpf.type);
+ pr_debug("unexpected bpf event type of %d\n", event->bpf.type);
break;
}
diff --git a/tools/perf/util/bpf-event.h b/tools/perf/util/bpf-event.h
index 26ab9239f986..417b78835ea0 100644
--- a/tools/perf/util/bpf-event.h
+++ b/tools/perf/util/bpf-event.h
@@ -30,8 +30,8 @@ struct btf_node {
};
#ifdef HAVE_LIBBPF_SUPPORT
-int machine__process_bpf_event(struct machine *machine, union perf_event
*event,
- struct perf_sample *sample);
+int machine__process_bpf(struct machine *machine, union perf_event *event,
+struct perf_sample *sample);
int perf_event__synthesize_bpf_events(struct perf_session *session,
perf_event__handler_t process,
@@ -43,9 +43,9 @@ void bpf_event__print_bpf_prog_info(struct bpf_prog_info
*info,
struct perf_env *env,
FILE *fp);
#else
-static inline int machine__process_bpf_event(struct machine *machine
__maybe_unused,
-union perf_event *event
__maybe_unused,
-struct perf_sample *sample
__maybe_unused)
+static inline int machine__process_bpf(struct machine *machine __maybe_unused,
+ union perf_event *event __maybe_unused,
+ struct perf_sample *sample
__maybe_unused)
{
return 0;
}
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 17304df44fc2..33616ea62a47 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1343,12 +1343,12 @@ int perf_event__process_ksymbol(struct perf_tool *tool
__maybe_unused,
return machine__process_ksymbol(machine, event, sample);
}
-int perf_event__process_bpf_event(struct perf_tool *tool __maybe_unused,
- union perf_event *event,
- struct perf_sample *sample __maybe_unused,
- struct machine *machine)
+int perf_event__process_bpf(struct perf_tool *tool
[PATCH 33/33] perf evsel: Rename perf_missing_features::bpf_event to ::bpf
From: Arnaldo Carvalho de Melo
No need for that _event suffix, do just like all the other meta events
and do away with that.
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Song Liu
Link: https://lkml.kernel.org/n/tip-bvc83f380dva83wlg52yd...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 9 -
tools/perf/util/evsel.h | 2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index b3cfe120d097..fa67639e 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1072,8 +1072,7 @@ void perf_evsel__config(struct evsel *evsel, struct
record_opts *opts,
attr->mmap2 = track && !perf_missing_features.mmap2;
attr->comm = track;
attr->ksymbol = track && !perf_missing_features.ksymbol;
- attr->bpf_event = track && !opts->no_bpf_event &&
- !perf_missing_features.bpf_event;
+ attr->bpf_event = track && !opts->no_bpf_event &&
!perf_missing_features.bpf;
if (opts->record_namespaces)
attr->namespaces = track;
@@ -1803,7 +1802,7 @@ int evsel__open(struct evsel *evsel, struct perf_cpu_map
*cpus,
evsel->core.attr.read_format &=
~(PERF_FORMAT_GROUP|PERF_FORMAT_ID);
if (perf_missing_features.ksymbol)
evsel->core.attr.ksymbol = 0;
- if (perf_missing_features.bpf_event)
+ if (perf_missing_features.bpf)
evsel->core.attr.bpf_event = 0;
retry_sample_id:
if (perf_missing_features.sample_id_all)
@@ -1920,8 +1919,8 @@ int evsel__open(struct evsel *evsel, struct perf_cpu_map
*cpus,
perf_missing_features.aux_output = true;
pr_debug2("Kernel has no attr.aux_output support, bailing
out\n");
goto out_close;
- } else if (!perf_missing_features.bpf_event &&
evsel->core.attr.bpf_event) {
- perf_missing_features.bpf_event = true;
+ } else if (!perf_missing_features.bpf && evsel->core.attr.bpf_event) {
+ perf_missing_features.bpf = true;
pr_debug2("switching off bpf_event\n");
goto fallback_missing_features;
} else if (!perf_missing_features.ksymbol && evsel->core.attr.ksymbol) {
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 77e07f2486d3..fd60caced4fc 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -194,7 +194,7 @@ struct perf_missing_features {
bool write_backward;
bool group_read;
bool ksymbol;
- bool bpf_event;
+ bool bpf;
bool aux_output;
};
--
2.21.0
[PATCH 20/33] libperf: Add PERF_RECORD_NAMESPACES 'struct namespaces_event' to perf/event.h
From: Jiri Olsa
Move the namespaces_event event definition into libperf's event.h header
include.
In order to keep libperf simple, we switch 'u64/u32/u16/u8' types used
events to their generic '__u*' versions.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20190825181752.722-5-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/lib/include/perf/event.h | 7 +++
tools/perf/util/event.h | 7 ---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index 3729a7d9253e..b90a8a21e613 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -36,4 +36,11 @@ struct comm_event {
char comm[16];
};
+struct namespaces_event {
+ struct perf_event_header header;
+ __u32pid, tid;
+ __u64nr_namespaces;
+ struct perf_ns_link_info link_info[];
+};
+
#endif /* __LIBPERF_EVENT_H */
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index e8973a783267..0d3ac4fd3ecf 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -27,13 +27,6 @@
#define PRI_lx64 PRIx64
#endif
-struct namespaces_event {
- struct perf_event_header header;
- u32 pid, tid;
- u64 nr_namespaces;
- struct perf_ns_link_info link_info[];
-};
-
struct fork_event {
struct perf_event_header header;
u32 pid, ppid;
--
2.21.0
[PATCH 16/33] perf script: Fix memory leaks in list_scripts()
From: "Gustavo A. R. Silva"
In case memory resources for *buf* and *paths* were allocated, jump to
*out* and release them before return.
Signed-off-by: Gustavo A. R. Silva
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Gustavo A. R. Silva
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Addresses-Coverity-ID: 1444328 ("Resource leak")
Fixes: 6f3da20e151f ("perf report: Support builtin perf script in scripts menu")
Link: http://lkml.kernel.org/r/20190408162748.GA21008@embeddedor
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/scripts.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/perf/ui/browsers/scripts.c b/tools/perf/ui/browsers/scripts.c
index f2fd9f0d7ab5..50e0c03171f2 100644
--- a/tools/perf/ui/browsers/scripts.c
+++ b/tools/perf/ui/browsers/scripts.c
@@ -133,8 +133,10 @@ static int list_scripts(char *script_name, bool *custom,
int key = ui_browser__input_window("perf script command",
"Enter perf script command line (without perf
script prefix)",
script_args, "", 0);
- if (key != K_ENTER)
- return -1;
+ if (key != K_ENTER) {
+ ret = -1;
+ goto out;
+ }
sprintf(script_name, "%s script %s", perf, script_args);
} else if (choice < num + max_std) {
strcpy(script_name, paths[choice]);
--
2.21.0
[PATCH 25/33] libperf: Add PERF_RECORD_THROTTLE 'struct throttle_event' to perf/event.h
From: Jiri Olsa
Move the PERF_RECORD_THROTTLE event definition into libperf's event.h
header include.
In order to keep libperf simple, we switch 'u64/u32/u16/u8' types used
events to their generic '__u*' versions.
Perf added 'u*' types mainly to ease up printing __u64 values as stated
in the linux/types.h comment:
/*
* We define u64 as uint64_t for every architecture
* so that we can print it with "%"PRIx64 without getting warnings.
*
* typedef __u64 u64;
* typedef __s64 s64;
*/
Add and use new PRI_lu64 and PRI_lx64 macros for that. Use extra '_' to
ease up the reading and differentiate them from standard PRI*64 macros.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20190825181752.722-10-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/lib/include/perf/event.h | 7 +++
tools/perf/util/event.h | 7 ---
tools/perf/util/python.c| 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index f1830702e49a..ef5ec66b566e 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -73,4 +73,11 @@ struct read_event {
__u64id;
};
+struct throttle_event {
+ struct perf_event_header header;
+ __u64time;
+ __u64id;
+ __u64stream_id;
+};
+
#endif /* __LIBPERF_EVENT_H */
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 008a2839d667..40020f5b0484 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -27,13 +27,6 @@
#define PRI_lx64 PRIx64
#endif
-struct throttle_event {
- struct perf_event_header header;
- u64 time;
- u64 id;
- u64 stream_id;
-};
-
#ifndef KSYM_NAME_LEN
#define KSYM_NAME_LEN 256
#endif
diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index 5be85f50cd1c..d21e270c7823 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -233,8 +233,8 @@ static PyObject *pyrf_throttle_event__repr(struct
pyrf_event *pevent)
{
struct throttle_event *te = (struct throttle_event
*)(>event.header + 1);
- return _PyUnicode_FromFormat("{ type: %sthrottle, time: %" PRIu64 ",
id: %" PRIu64
- ", stream_id: %" PRIu64 " }",
+ return _PyUnicode_FromFormat("{ type: %sthrottle, time: %" PRI_lu64 ",
id: %" PRI_lu64
+ ", stream_id: %" PRI_lu64 " }",
pevent->event.header.type ==
PERF_RECORD_THROTTLE ? "" : "un",
te->time, te->id, te->stream_id);
}
--
2.21.0
[PATCH 22/33] libperf: Add PERF_RECORD_LOST 'struct lost_event' to perf/event.h
From: Jiri Olsa
Move the lost_event event definition to libperf's event.h header
include.
In order to keep libperf simple, we switch 'u64/u32/u16/u8' types used
events to their generic '__u*' versions.
Perf added 'u*' types mainly to ease up printing __u64 values as stated
in the linux/types.h comment:
/*
* We define u64 as uint64_t for every architecture
* so that we can print it with "%"PRIx64 without getting warnings.
*
* typedef __u64 u64;
* typedef __s64 s64;
*/
Add and use new PRI_lu64 and PRI_lx64 macros for that. Use extra '_' to
ease up the reading and differentiate them from standard PRI*64 macros.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20190825181752.722-7-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-sched.c | 2 +-
tools/perf/lib/include/perf/event.h | 6 ++
tools/perf/util/event.c | 2 +-
tools/perf/util/event.h | 6 --
tools/perf/util/machine.c | 2 +-
tools/perf/util/python.c| 4 ++--
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 0d6b4c3b1a51..025151dcb651 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -2643,7 +2643,7 @@ static int process_lost(struct perf_tool *tool
__maybe_unused,
timestamp__scnprintf_usec(sample->time, tstr, sizeof(tstr));
printf("%15s ", tstr);
- printf("lost %" PRIu64 " events on cpu %d\n", event->lost.lost,
sample->cpu);
+ printf("lost %" PRI_lu64 " events on cpu %d\n", event->lost.lost,
sample->cpu);
return 0;
}
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index c7cae58d2535..71045ea8214c 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -50,4 +50,10 @@ struct fork_event {
__u64time;
};
+struct lost_event {
+ struct perf_event_header header;
+ __u64id;
+ __u64lost;
+};
+
#endif /* __LIBPERF_EVENT_H */
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 0954f980574f..3bd9fc2a3ae8 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1480,7 +1480,7 @@ size_t perf_event__fprintf_switch(union perf_event
*event, FILE *fp)
static size_t perf_event__fprintf_lost(union perf_event *event, FILE *fp)
{
- return fprintf(fp, " lost %" PRIu64 "\n", event->lost.lost);
+ return fprintf(fp, " lost %" PRI_lu64 "\n", event->lost.lost);
}
size_t perf_event__fprintf_ksymbol(union perf_event *event, FILE *fp)
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 38b258cbbd90..4a3f50203d04 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -27,12 +27,6 @@
#define PRI_lx64 PRIx64
#endif
-struct lost_event {
- struct perf_event_header header;
- u64 id;
- u64 lost;
-};
-
struct lost_samples_event {
struct perf_event_header header;
u64 lost;
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 47430afd3c2d..1ad6e984c2f5 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -645,7 +645,7 @@ int machine__process_namespaces_event(struct machine
*machine __maybe_unused,
int machine__process_lost_event(struct machine *machine __maybe_unused,
union perf_event *event, struct perf_sample
*sample __maybe_unused)
{
- dump_printf(": id:%" PRIu64 ": lost:%" PRIu64 "\n",
+ dump_printf(": id:%" PRI_lu64 ": lost:%" PRI_lu64 "\n",
event->lost.id, event->lost.lost);
return 0;
}
diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index 8bdadb24f6ba..5be85f50cd1c 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -263,8 +263,8 @@ static PyObject *pyrf_lost_event__repr(struct pyrf_event
*pevent)
PyObject *ret;
char *s;
- if (asprintf(, "{ type: lost, id: %#" PRIx64 ", "
-"lost: %#" PRIx64 " }",
+ if (asprintf(, "{ type: lost, id: %#" PRI_lx64 ", "
+"lost: %#" PRI_lx64 " }",
pevent->event.lost.id, pevent->event.lost.lost) < 0) {
ret = PyErr_NoMemory();
} else {
--
2.21.0
[PATCH 26/33] libperf: Add PERF_RECORD_KSYMBOL 'struct ksymbol_event' to perf/event.h
From: Jiri Olsa
Move the PERF_RECORD_KSYMBOL event definition into libperf's event.h
header include.
In order to keep libperf simple, we switch 'u64/u32/u16/u8' types used
events to their generic '__u*' versions.
Perf added 'u*' types mainly to ease up printing __u64 values
as stated in the linux/types.h comment:
/*
* We define u64 as uint64_t for every architecture
* so that we can print it with "%"PRIx64 without getting warnings.
*
* typedef __u64 u64;
* typedef __s64 s64;
*/
Add and use new PRI_lu64 and PRI_lx64 macros for that. Use extra '_' to
ease up the reading and differentiate them from standard PRI*64 macros.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20190825181752.722-11-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/lib/include/perf/event.h | 13 +
tools/perf/util/event.c | 2 +-
tools/perf/util/event.h | 13 -
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index ef5ec66b566e..8c367931cecc 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -80,4 +80,17 @@ struct throttle_event {
__u64stream_id;
};
+#ifndef KSYM_NAME_LEN
+#define KSYM_NAME_LEN 256
+#endif
+
+struct ksymbol_event {
+ struct perf_event_header header;
+ __u64addr;
+ __u32len;
+ __u16ksym_type;
+ __u16flags;
+ char name[KSYM_NAME_LEN];
+};
+
#endif /* __LIBPERF_EVENT_H */
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 3bd9fc2a3ae8..4447cd25e3f2 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1485,7 +1485,7 @@ static size_t perf_event__fprintf_lost(union perf_event
*event, FILE *fp)
size_t perf_event__fprintf_ksymbol(union perf_event *event, FILE *fp)
{
- return fprintf(fp, " addr %" PRIx64 " len %u type %u flags 0x%x name
%s\n",
+ return fprintf(fp, " addr %" PRI_lx64 " len %u type %u flags 0x%x name
%s\n",
event->ksymbol_event.addr, event->ksymbol_event.len,
event->ksymbol_event.ksym_type,
event->ksymbol_event.flags, event->ksymbol_event.name);
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 40020f5b0484..c4eec1f164ba 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -27,19 +27,6 @@
#define PRI_lx64 PRIx64
#endif
-#ifndef KSYM_NAME_LEN
-#define KSYM_NAME_LEN 256
-#endif
-
-struct ksymbol_event {
- struct perf_event_header header;
- u64 addr;
- u32 len;
- u16 ksym_type;
- u16 flags;
- char name[KSYM_NAME_LEN];
-};
-
struct bpf_event {
struct perf_event_header header;
u16 type;
--
2.21.0
[PATCH 23/33] libperf: Add PERF_RECORD_LOST_SAMPLES 'struct lost_samples_event' to perf/event.h
From: Jiri Olsa
Move the PERF_RECORD_LOST_SAMPLES event definition into libperf's
event.h header include.
In order to keep libperf simple, we switch 'u64/u32/u16/u8' types used
events to their generic '__u*' versions.
Perf added 'u*' types mainly to ease up printing __u64 values
as stated in the linux/types.h comment:
/*
* We define u64 as uint64_t for every architecture
* so that we can print it with "%"PRIx64 without getting warnings.
*
* typedef __u64 u64;
* typedef __s64 s64;
*/
Add and use new PRI_lu64 and PRI_lx64 macros for that. Use extra '_' to
ease up the reading and differentiate them from standard PRI*64 macros.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20190825181752.722-8-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/lib/include/perf/event.h | 5 +
tools/perf/util/event.h | 5 -
tools/perf/util/machine.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index 71045ea8214c..86a779593405 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -56,4 +56,9 @@ struct lost_event {
__u64lost;
};
+struct lost_samples_event {
+ struct perf_event_header header;
+ __u64lost;
+};
+
#endif /* __LIBPERF_EVENT_H */
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 4a3f50203d04..976a8f00d2a2 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -27,11 +27,6 @@
#define PRI_lx64 PRIx64
#endif
-struct lost_samples_event {
- struct perf_event_header header;
- u64 lost;
-};
-
/*
* PERF_FORMAT_ENABLED | PERF_FORMAT_RUNNING | PERF_FORMAT_ID
*/
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 1ad6e984c2f5..823aaf7b1b83 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -653,7 +653,7 @@ int machine__process_lost_event(struct machine *machine
__maybe_unused,
int machine__process_lost_samples_event(struct machine *machine __maybe_unused,
union perf_event *event, struct
perf_sample *sample)
{
- dump_printf(": id:%" PRIu64 ": lost samples :%" PRIu64 "\n",
+ dump_printf(": id:%" PRIu64 ": lost samples :%" PRI_lu64 "\n",
sample->id, event->lost_samples.lost);
return 0;
}
--
2.21.0
[PATCH 27/33] libperf: Add PERF_RECORD_BPF_EVENT 'struct bpf_event' to perf/event.h
From: Jiri Olsa
Move the PERF_RECORD_BPF_EVENT event definition to libperf's event.h.
In order to keep libperf simple, we switch 'u64/u32/u16/u8'
types used events to their generic '__u*' versions.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20190825181752.722-12-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/lib/include/perf/event.h | 11 +++
tools/perf/util/event.h | 10 --
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index 8c367931cecc..585c9d82dba3 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
struct mmap_event {
struct perf_event_header header;
@@ -93,4 +94,14 @@ struct ksymbol_event {
char name[KSYM_NAME_LEN];
};
+struct bpf_event {
+ struct perf_event_header header;
+ __u16type;
+ __u16flags;
+ __u32id;
+
+ /* for bpf_prog types */
+ __u8 tag[BPF_TAG_SIZE]; // prog tag
+};
+
#endif /* __LIBPERF_EVENT_H */
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index c4eec1f164ba..091a0690a280 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -27,16 +27,6 @@
#define PRI_lx64 PRIx64
#endif
-struct bpf_event {
- struct perf_event_header header;
- u16 type;
- u16 flags;
- u32 id;
-
- /* for bpf_prog types */
- u8 tag[BPF_TAG_SIZE]; // prog tag
-};
-
#define PERF_SAMPLE_MASK \
(PERF_SAMPLE_IP | PERF_SAMPLE_TID | \
PERF_SAMPLE_TIME | PERF_SAMPLE_ADDR | \
--
2.21.0
[PATCH 28/33] libperf: Add PERF_RECORD_SAMPLE 'struct sample_event' to perf/event.h
From: Jiri Olsa
Move the PERF_RECORD_SAMPLE event definition to libperf's event.h header
include.
In order to keep libperf simple, we switch 'u64/u32/u16/u8' types used
events to their generic '__u*' versions.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20190825181752.722-13-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/lib/include/perf/event.h | 5 +
tools/perf/util/event.h | 5 -
tools/perf/util/evlist.c| 2 +-
tools/perf/util/evsel.c | 8
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index 585c9d82dba3..e768a2dfbe53 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -104,4 +104,9 @@ struct bpf_event {
__u8 tag[BPF_TAG_SIZE]; // prog tag
};
+struct sample_event {
+ struct perf_event_header header;
+ __u64array[];
+};
+
#endif /* __LIBPERF_EVENT_H */
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 091a0690a280..dee0ee57efc2 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -37,11 +37,6 @@
/* perf sample has 16 bits size limit */
#define PERF_SAMPLE_MAX_SIZE (1 << 16)
-struct sample_event {
- struct perf_event_headerheader;
- u64 array[];
-};
-
struct regs_dump {
u64 abi;
u64 mask;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index ff415680fe0a..47bc54111f57 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -587,7 +587,7 @@ struct evsel *perf_evlist__id2evsel_strict(struct evlist
*evlist,
static int perf_evlist__event2id(struct evlist *evlist,
union perf_event *event, u64 *id)
{
- const u64 *array = event->sample.array;
+ const __u64 *array = event->sample.array;
ssize_t n;
n = (event->header.size - sizeof(event->header)) >> 3;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 9fadd5857ccc..778262f68d5c 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2009,7 +2009,7 @@ static int perf_evsel__parse_id_sample(const struct evsel
*evsel,
struct perf_sample *sample)
{
u64 type = evsel->core.attr.sample_type;
- const u64 *array = event->sample.array;
+ const __u64 *array = event->sample.array;
bool swapped = evsel->needs_swap;
union u64_swap u;
@@ -2099,7 +2099,7 @@ int perf_evsel__parse_sample(struct evsel *evsel, union
perf_event *event,
{
u64 type = evsel->core.attr.sample_type;
bool swapped = evsel->needs_swap;
- const u64 *array;
+ const __u64 *array;
u16 max_size = event->header.size;
const void *endp = (void *)event + max_size;
u64 sz;
@@ -2378,7 +2378,7 @@ int perf_evsel__parse_sample_timestamp(struct evsel
*evsel,
u64 *timestamp)
{
u64 type = evsel->core.attr.sample_type;
- const u64 *array;
+ const __u64 *array;
if (!(type & PERF_SAMPLE_TIME))
return -1;
@@ -2529,7 +2529,7 @@ int perf_event__synthesize_sample(union perf_event
*event, u64 type,
u64 read_format,
const struct perf_sample *sample)
{
- u64 *array;
+ __u64 *array;
size_t sz;
/*
* used for cross-endian analysis. See git commit 65014ab3
--
2.21.0
[PATCH 18/33] libperf: Add PERF_RECORD_MMAP2 'struct mmap2_event' to perf/event.h
From: Jiri Olsa
Moving mmap2_event event definition into libperf's event.h header
include.
In order to keep libperf simple, we switch 'u64/u32/u16/u8' types used
events to their generic '__u*' versions.
Perf added 'u*' types mainly to ease up printing __u64 values
as stated in the linux/types.h comment:
/*
* We define u64 as uint64_t for every architecture
* so that we can print it with "%"PRIx64 without getting warnings.
*
* typedef __u64 u64;
* typedef __s64 s64;
*/
Adding and using new PRI_lu64 and PRI_lx64 macros to be used for
that. Using extra '_' to ease up the reading and differentiate
them from standard PRI*64 macros.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: https://lkml.kernel.org/n/tip-ufs9ityr5w2xqwtd5w3p6...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/lib/include/perf/event.h | 15 +++
tools/perf/util/event.c | 6 +++---
tools/perf/util/event.h | 15 ---
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index 13fe15a2fe7f..c82e0c2c004b 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -15,4 +15,19 @@ struct mmap_event {
char filename[PATH_MAX];
};
+struct mmap2_event {
+ struct perf_event_header header;
+ __u32pid, tid;
+ __u64start;
+ __u64len;
+ __u64pgoff;
+ __u32maj;
+ __u32min;
+ __u64ino;
+ __u64ino_generation;
+ __u32prot;
+ __u32flags;
+ char filename[PATH_MAX];
+};
+
#endif /* __LIBPERF_EVENT_H */
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 43c86257e7fa..0954f980574f 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -387,7 +387,7 @@ int perf_event__synthesize_mmap_events(struct perf_tool
*tool,
strcpy(execname, "");
/* 0040-0040c000 r-xp fd:01 41038 /bin/cat */
- n = sscanf(bf, "%"PRIx64"-%"PRIx64" %s %"PRIx64" %x:%x %u
%[^\n]\n",
+ n = sscanf(bf, "%"PRI_lx64"-%"PRI_lx64" %s %"PRI_lx64" %x:%x %u
%[^\n]\n",
>mmap2.start, >mmap2.len, prot,
>mmap2.pgoff, >mmap2.maj,
>mmap2.min,
@@ -1362,8 +1362,8 @@ size_t perf_event__fprintf_mmap(union perf_event *event,
FILE *fp)
size_t perf_event__fprintf_mmap2(union perf_event *event, FILE *fp)
{
- return fprintf(fp, " %d/%d: [%#" PRIx64 "(%#" PRIx64 ") @ %#" PRIx64
- " %02x:%02x %"PRIu64" %"PRIu64"]: %c%c%c%c %s\n",
+ return fprintf(fp, " %d/%d: [%#" PRI_lx64 "(%#" PRI_lx64 ") @ %#"
PRI_lx64
+ " %02x:%02x %"PRI_lu64" %"PRI_lu64"]: %c%c%c%c %s\n",
event->mmap2.pid, event->mmap2.tid, event->mmap2.start,
event->mmap2.len, event->mmap2.pgoff, event->mmap2.maj,
event->mmap2.min, event->mmap2.ino,
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index f43eff2fba2d..af252be8ca5b 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -27,21 +27,6 @@
#define PRI_lx64 PRIx64
#endif
-struct mmap2_event {
- struct perf_event_header header;
- u32 pid, tid;
- u64 start;
- u64 len;
- u64 pgoff;
- u32 maj;
- u32 min;
- u64 ino;
- u64 ino_generation;
- u32 prot;
- u32 flags;
- char filename[PATH_MAX];
-};
-
struct comm_event {
struct perf_event_header header;
u32 pid, tid;
--
2.21.0
[PATCH 30/33] perf tools: Rename perf_event::ksymbol_event to perf_event::ksymbol
From: Arnaldo Carvalho de Melo
Just like all the other meta events, that extra _event suffix is just
redundant, ditch it.
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Song Liu
Link: https://lkml.kernel.org/n/tip-0q8b2xnfs17q0g523oej7...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/bpf-event.c | 2 +-
tools/perf/util/event.c | 6 +++---
tools/perf/util/event.h | 2 +-
tools/perf/util/machine.c | 16
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index 3be8c480fa1f..69795c32ecf3 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -161,7 +161,7 @@ static int perf_event__synthesize_one_bpf_prog(struct
perf_session *session,
union perf_event *event,
struct record_opts *opts)
{
- struct perf_record_ksymbol *ksymbol_event = >ksymbol_event;
+ struct perf_record_ksymbol *ksymbol_event = >ksymbol;
struct perf_record_bpf_event *bpf_event = >bpf_event;
struct bpf_prog_info_linear *info_linear;
struct perf_tool *tool = session->tool;
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 4447cd25e3f2..bdeaad434e52 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1486,9 +1486,9 @@ static size_t perf_event__fprintf_lost(union perf_event
*event, FILE *fp)
size_t perf_event__fprintf_ksymbol(union perf_event *event, FILE *fp)
{
return fprintf(fp, " addr %" PRI_lx64 " len %u type %u flags 0x%x name
%s\n",
- event->ksymbol_event.addr, event->ksymbol_event.len,
- event->ksymbol_event.ksym_type,
- event->ksymbol_event.flags, event->ksymbol_event.name);
+ event->ksymbol.addr, event->ksymbol.len,
+ event->ksymbol.ksym_type,
+ event->ksymbol.flags, event->ksymbol.name);
}
size_t perf_event__fprintf_bpf_event(union perf_event *event, FILE *fp)
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 25f5309a3442..34190e01f307 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -561,7 +561,7 @@ union perf_event {
struct perf_record_throttle throttle;
struct perf_record_sample sample;
struct perf_record_bpf_eventbpf_event;
- struct perf_record_ksymbol ksymbol_event;
+ struct perf_record_ksymbol ksymbol;
struct attr_event attr;
struct event_update_event event_update;
struct event_type_event event_type;
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 823aaf7b1b83..86b7fd24b1e1 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -713,20 +713,20 @@ static int machine__process_ksymbol_register(struct
machine *machine,
struct symbol *sym;
struct map *map;
- map = map_groups__find(>kmaps, event->ksymbol_event.addr);
+ map = map_groups__find(>kmaps, event->ksymbol.addr);
if (!map) {
- map = dso__new_map(event->ksymbol_event.name);
+ map = dso__new_map(event->ksymbol.name);
if (!map)
return -ENOMEM;
- map->start = event->ksymbol_event.addr;
- map->end = map->start + event->ksymbol_event.len;
+ map->start = event->ksymbol.addr;
+ map->end = map->start + event->ksymbol.len;
map_groups__insert(>kmaps, map);
}
sym = symbol__new(map->map_ip(map, map->start),
- event->ksymbol_event.len,
- 0, 0, event->ksymbol_event.name);
+ event->ksymbol.len,
+ 0, 0, event->ksymbol.name);
if (!sym)
return -ENOMEM;
dso__insert_symbol(map->dso, sym);
@@ -739,7 +739,7 @@ static int machine__process_ksymbol_unregister(struct
machine *machine,
{
struct map *map;
- map = map_groups__find(>kmaps, event->ksymbol_event.addr);
+ map = map_groups__find(>kmaps, event->ksymbol.addr);
if (map)
map_groups__remove(>kmaps, map);
@@ -753,7 +753,7 @@ int machine__process_ksymbol(struct machine *machine
__maybe_unused,
if (dump_trace)
perf_event__fprintf_ksymbol(event, stdout);
- if (event->ksymbol_event.flags & PERF_RECORD_KSYMBOL_FLAGS_UNREGISTER)
+ if (event->ksymbol.flags & PERF_RECORD_KSYMBOL_FLAGS_UNREGISTER)
return machine__process_ksymbol_unregister(machine, event,
sample);
return machine__process_ksymbol_register(machine, event, sample);
--
2.21.0
[PATCH 21/33] libperf: Add PERF_RECORD_FORK 'struct fork_event' to perf/event.h
From: Jiri Olsa
Move the fork_event event definition into libperf's event.h header
include.
In order to keep libperf simple, we switch 'u64/u32/u16/u8' types used
events to their generic '__u*' versions.
Perf added 'u*' types mainly to ease up printing __u64 values
as stated in the linux/types.h comment:
/*
* We define u64 as uint64_t for every architecture
* so that we can print it with "%"PRIx64 without getting warnings.
*
* typedef __u64 u64;
* typedef __s64 s64;
*/
Add and use new PRI_lu64 and PRI_lx64 macros for that. Using extra '_'
to ease up the reading and differentiate them from standard PRI*64
macros.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20190825181752.722-6-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/lib/include/perf/event.h | 7 +++
tools/perf/util/event.h | 7 ---
tools/perf/util/python.c| 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/perf/lib/include/perf/event.h
b/tools/perf/lib/include/perf/event.h
index b90a8a21e613..c7cae58d2535 100644
--- a/tools/perf/lib/include/perf/event.h
+++ b/tools/perf/lib/include/perf/event.h
@@ -43,4 +43,11 @@ struct namespaces_event {
struct perf_ns_link_info link_info[];
};
+struct fork_event {
+ struct perf_event_header header;
+ __u32pid, ppid;
+ __u32tid, ptid;
+ __u64time;
+};
+
#endif /* __LIBPERF_EVENT_H */
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 0d3ac4fd3ecf..38b258cbbd90 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -27,13 +27,6 @@
#define PRI_lx64 PRIx64
#endif
-struct fork_event {
- struct perf_event_header header;
- u32 pid, ppid;
- u32 tid, ptid;
- u64 time;
-};
-
struct lost_event {
struct perf_event_header header;
u64 id;
diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index 55ff0c3182d6..8bdadb24f6ba 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -170,7 +170,7 @@ static PyMemberDef pyrf_task_event__members[] = {
static PyObject *pyrf_task_event__repr(struct pyrf_event *pevent)
{
return _PyUnicode_FromFormat("{ type: %s, pid: %u, ppid: %u, tid: %u, "
- "ptid: %u, time: %" PRIu64 "}",
+ "ptid: %u, time: %" PRI_lu64 "}",
pevent->event.header.type ==
PERF_RECORD_FORK ? "fork" : "exit",
pevent->event.fork.pid,
pevent->event.fork.ppid,
--
2.21.0
