* [PATCH v3 3/3] ASoC: sun4i-codec: Add custom regmap configs for the A10 and A20 variants.
From: Chen-Yu Tsai @ 2016-09-15 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915143922.4890-4-dannym@scratchpost.org>
On Thu, Sep 15, 2016 at 10:39 PM, Danny Milosavljevic
<dannym@scratchpost.org> wrote:
> ASoC: sun4i-codec: Add custom regmap configs for the A10 and A20 variants.
The commit message should be a straight forward description about what
the patch does and why you did it, not a direct copy of the subject.
Something along the lines of "The A20 has a few extra registers that
the A10 doesn't have ..." will do for the why.
Regards
ChenYu
>
> Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
> ---
> sound/soc/sunxi/sun4i-codec.c | 33 ++++++++++++++++++++++++++++++---
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 3b53b78..c5d6d84c 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -682,12 +682,37 @@ static const struct regmap_config sun4i_codec_regmap_config = {
> .reg_bits = 32,
> .reg_stride = 4,
> .val_bits = 32,
> + .max_register = SUN4I_CODEC_ADC_RXCNT,
> +};
> +
> +static const struct regmap_config sun7i_codec_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> .max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
> };
>
> +struct sun4i_codec_quirks {
> + const struct regmap_config *regmap_config;
> +};
> +
> +static const struct sun4i_codec_quirks sun4i_codec_quirks = {
> + .regmap_config = &sun4i_codec_regmap_config,
> +};
> +
> +static const struct sun4i_codec_quirks sun7i_codec_quirks = {
> + .regmap_config = &sun7i_codec_regmap_config,
> +};
> +
> static const struct of_device_id sun4i_codec_of_match[] = {
> - { .compatible = "allwinner,sun4i-a10-codec" },
> - { .compatible = "allwinner,sun7i-a20-codec" },
> + {
> + .compatible = "allwinner,sun4i-a10-codec",
> + .data = &sun4i_codec_quirks,
> + },
> + {
> + .compatible = "allwinner,sun7i-a20-codec",
> + .data = &sun7i_codec_quirks,
> + },
> {}
> };
> MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
> @@ -760,6 +785,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
> {
> struct snd_soc_card *card;
> struct sun4i_codec *scodec;
> + const struct sun4i_codec_quirks *quirks;
> struct resource *res;
> void __iomem *base;
> int ret;
> @@ -777,8 +803,9 @@ static int sun4i_codec_probe(struct platform_device *pdev)
> return PTR_ERR(base);
> }
>
> + quirks = of_device_get_match_data(&pdev->dev);
> scodec->regmap = devm_regmap_init_mmio(&pdev->dev, base,
> - &sun4i_codec_regmap_config);
> + quirks->regmap_config);
> if (IS_ERR(scodec->regmap)) {
> dev_err(&pdev->dev, "Failed to create our regmap\n");
> return PTR_ERR(scodec->regmap);
^ permalink raw reply
* [PATCH v3 1/3] ASoC: sun4i-codec: rename "sun4i_codec_widgets" to "sun4i_codec_controls" for consistency with the struct field name.
From: Chen-Yu Tsai @ 2016-09-15 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915143922.4890-2-dannym@scratchpost.org>
On Thu, Sep 15, 2016 at 10:39 PM, Danny Milosavljevic
<dannym@scratchpost.org> wrote:
> ASoC: sun4i-codec: rename "sun4i_codec_widgets" to "sun4i_codec_controls" for
> consistency with the struct field name.
Subject is way too long. The commit messages should be straight
forward sentences,
not in the format of patch subjects.
Subject could read "ASoC: sun4i-codec: rename sun4i_codec_widgets for
consistency".
Then in the commit message you could elaborate on consistency with what, as you
did here in the subject.
Regards
ChenYu
>
> Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
> ---
> sound/soc/sunxi/sun4i-codec.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 0e19c50..c2c0583 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -509,7 +509,7 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
>
> static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
>
> -static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
> +static const struct snd_kcontrol_new sun4i_codec_controls[] = {
> SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
> SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
> sun4i_codec_pa_volume_scale),
> @@ -629,8 +629,8 @@ static const struct snd_soc_dapm_route sun4i_codec_codec_dapm_routes[] = {
>
> static struct snd_soc_codec_driver sun4i_codec_codec = {
> .component_driver = {
> - .controls = sun4i_codec_widgets,
> - .num_controls = ARRAY_SIZE(sun4i_codec_widgets),
> + .controls = sun4i_codec_controls,
> + .num_controls = ARRAY_SIZE(sun4i_codec_controls),
> .dapm_widgets = sun4i_codec_codec_dapm_widgets,
> .num_dapm_widgets = ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
> .dapm_routes = sun4i_codec_codec_dapm_routes,
^ permalink raw reply
* [RFC PATCH v2 11/11] irqchip: mbigen: promote mbigen init
From: Marc Zyngier @ 2016-09-15 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473862879-7769-12-git-send-email-guohanjun@huawei.com>
On 14/09/16 15:21, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> mbigen is an irqchip and it needs to be probed before
> devices, same logic is used for SMMU and etc., let's
> use arch_initcall instead of platform init for mbigen.
>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ma Jun <majun258@huawei.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> drivers/irqchip/irq-mbigen.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index ca6add1..3a33de6 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -374,7 +374,11 @@ static struct platform_driver mbigen_platform_driver = {
> .probe = mbigen_device_probe,
> };
>
> -module_platform_driver(mbigen_platform_driver);
> +static __init int mbigen_init(void)
> +{
> + return platform_driver_register(&mbigen_platform_driver);
> +}
> +arch_initcall(mbigen_init);
>
> MODULE_AUTHOR("Jun Ma <majun258@huawei.com>");
> MODULE_AUTHOR("Yun Wu <wuyun.wu@huawei.com>");
>
I've already NACKed such a patch in the past, and I will carry on
NACKing it until all the other avenues (like properly tracking device
dependencies) have been explored and have been proven not to be fit for
purpose.
Rafael had proposed something around this subject last year, and I've
been repeatedly advising you to work with him and others to make it
happen. You can choose to ignore this advise, but that doesn't make this
patch an acceptable approach.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Bryan O'Donoghue @ 2016-09-15 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915124601.GA9316@leverpostej>
On Thu, 2016-09-15 at 13:46 +0100, Mark Rutland wrote:
> On Thu, Sep 15, 2016 at 12:48:08PM +0100, Bryan O'Donoghue wrote:
> >
> > On Thu, 2016-09-15 at 12:20 +0100, Mark Rutland wrote:
> > >
> > > For example, you have absolutely no guarantee as to what backs
> > > get_cycles(). Despite this, the code assumes that get_cycles() is
> > > backed by something running at the frequency described in a
> > > "google,greybus-frame-time-counter" node.
> > >
> > > Even if this *happens* to match what some piece of arch code
> > > provides
> > > today on some platform, it is in no way *guaranteed*.
> > That's the point though, if you declare "google,greybus-frame-time-
> > counter" in your platform code - then you can use 'get_cycles()' in
> > this manner
> To be clear, *some* properties (and perhaps additional nodes) may
> need
> to be in the DT, in order to capture the hardware property or
> relationship that you are reliant upon.
Sure but on the relevant platform we know?
1. get_cycles() is derived from an architectured MMIO timer
2. What is clocking that timer
So any platform that declares that property must be aware of what its
doing.
For clarity this is the alternative to reading another register
directly bypassing get_cycles().
> >
> > >
> > > Without a higher-level view of what you're trying to achieve,
> > > it's
> > > not clear to me whether get_cycles() is the right interface.
> > I appreciate that.
> Until that's clarified, we won't make any progress here.
Let's see. We're synchronizing a set of distributed timers via a GPIO
pulse. Each processor on the system has at least one timer block
directly driven by the refclk at 19.2MHz?or a PLL driven by refclk at 19.2MHz
FrameTime is a 64 bit free-running counter running @19.2MHz that is
used as a common source of reference for events. On the MSM side this
implies reading one of the timers driven by that refclk directly.
The choices on MSM8994 to access one of those timer blocks are
1. Read the register directly as is done in earlier patches or
2. Read get_cycles() as is done in later patches.
It's no more complex than that.
---
bod
^ permalink raw reply
* next-20160915 build: 2 failures 16 warnings (next-20160915)
From: Mark Brown @ 2016-09-15 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1bkV4u-0004AY-TY@optimist>
On Thu, Sep 15, 2016 at 12:43:41PM +0100, Build bot for Mark Brown wrote:
Today's -next fails to build both arm and arm64 allmodconfigs due to:
> arm64-allmodconfig
> ERROR: "musb_root_disconnect" [drivers/usb/musb/sunxi.ko] undefined!
> arm-allmodconfig
> ERROR: "musb_root_disconnect" [drivers/usb/musb/sunxi.ko] undefined!
due to 7cba17ec9adc8cf (musb: sunxi: Add support for platform_set_mode)
which adds a call to that non-exported function to a module.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160915/0d4087c8/attachment.sig>
^ permalink raw reply
* [PATCH] MMC: meson: remove unused variable
From: Arnd Bergmann @ 2016-09-15 15:43 UTC (permalink / raw)
To: linux-arm-kernel
The newly added meson mmc driver causes a build warning from an unused
variable:
drivers/mmc/host/meson-gxbb.c: In function 'meson_mmc_request_done':
drivers/mmc/host/meson-gxbb.c:411:22: error: unused variable 'cmd' [-Werror=unused-variable]
This removes the variable.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 4b331229dda9 ("MMC: meson: initial support for GXBB platforms")
---
drivers/mmc/host/meson-gxbb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/host/meson-gxbb.c b/drivers/mmc/host/meson-gxbb.c
index c73c62178764..193d343d0afe 100644
--- a/drivers/mmc/host/meson-gxbb.c
+++ b/drivers/mmc/host/meson-gxbb.c
@@ -408,7 +408,6 @@ static void meson_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
static int meson_mmc_request_done(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct meson_host *host = mmc_priv(mmc);
- struct mmc_command *cmd = host->cmd;
WARN_ON(host->mrq != mrq);
--
2.9.0
^ permalink raw reply related
* [PATCH 1/2 v3] bus: mvebu-mbus: Provide stub function for mvebu_mbus_get_io_win_info()
From: Vinod Koul @ 2016-09-15 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915053731.25263-1-sr@denx.de>
On Thu, Sep 15, 2016 at 07:37:30AM +0200, Stefan Roese wrote:
> This patch provides a stub function for mvebu_mbus_get_io_win_info(),
> which will be used for all non-Orion (ARM32 MVEBU) platforms for
> compile test coverage.
>
> On such platforms this function will return an error so that drivers
> might detect a potential problem.
Applied both,
Thanks
--
~Vinod
^ permalink raw reply
* [PATCH] clk: zx: fix pointer case warnings
From: Arnd Bergmann @ 2016-09-15 15:45 UTC (permalink / raw)
To: linux-arm-kernel
The zx296718 clock driver has a creative way of assigning the register
values for each clock, by initializing an __iomem pointer to an
offset and then later adding the base (from ioremap) on top
with a cast to u64. This fail on all 32-bit architectures during
compile testing:
drivers/clk/zte/clk-zx296718.c: In function 'top_clocks_init':
drivers/clk/zte/clk-zx296718.c:554:35: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
zx296718_pll_clk[i].reg_base += (u64)reg_base;
drivers/clk/zte/clk-zx296718.c:579:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
drivers/clk/zte/clk-zx296718.c:592:31: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
It would be nice to avoid all the casts, but I decided to simply
shut up the warnings by changing the type from u64 to uintptr_t,
which does the right thing in practice.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: ca0233285a93 ("clk: zx: register ZX296718 clocks")
---
drivers/clk/zte/clk-zx296718.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/zte/clk-zx296718.c b/drivers/clk/zte/clk-zx296718.c
index 025e324fab5c..b34402d0cd69 100644
--- a/drivers/clk/zte/clk-zx296718.c
+++ b/drivers/clk/zte/clk-zx296718.c
@@ -551,7 +551,7 @@ static int __init top_clocks_init(struct device_node *np)
}
for (i = 0; i < ARRAY_SIZE(zx296718_pll_clk); i++) {
- zx296718_pll_clk[i].reg_base += (u64)reg_base;
+ zx296718_pll_clk[i].reg_base += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &zx296718_pll_clk[i].hw);
if (ret) {
pr_warn("top clk %s init error!\n",
@@ -576,7 +576,7 @@ static int __init top_clocks_init(struct device_node *np)
top_hw_onecell_data.hws[top_mux_clk[i].id] =
&top_mux_clk[i].mux.hw;
- top_mux_clk[i].mux.reg += (u64)reg_base;
+ top_mux_clk[i].mux.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &top_mux_clk[i].mux.hw);
if (ret) {
pr_warn("top clk %s init error!\n",
@@ -589,7 +589,7 @@ static int __init top_clocks_init(struct device_node *np)
top_hw_onecell_data.hws[top_gate_clk[i].id] =
&top_gate_clk[i].gate.hw;
- top_gate_clk[i].gate.reg += (u64)reg_base;
+ top_gate_clk[i].gate.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &top_gate_clk[i].gate.hw);
if (ret) {
pr_warn("top clk %s init error!\n",
@@ -602,7 +602,7 @@ static int __init top_clocks_init(struct device_node *np)
top_hw_onecell_data.hws[top_div_clk[i].id] =
&top_div_clk[i].div.hw;
- top_div_clk[i].div.reg += (u64)reg_base;
+ top_div_clk[i].div.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &top_div_clk[i].div.hw);
if (ret) {
pr_warn("top clk %s init error!\n",
@@ -742,7 +742,7 @@ static int __init lsp0_clocks_init(struct device_node *np)
lsp0_hw_onecell_data.hws[lsp0_mux_clk[i].id] =
&lsp0_mux_clk[i].mux.hw;
- lsp0_mux_clk[i].mux.reg += (u64)reg_base;
+ lsp0_mux_clk[i].mux.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp0_mux_clk[i].mux.hw);
if (ret) {
pr_warn("lsp0 clk %s init error!\n",
@@ -755,7 +755,7 @@ static int __init lsp0_clocks_init(struct device_node *np)
lsp0_hw_onecell_data.hws[lsp0_gate_clk[i].id] =
&lsp0_gate_clk[i].gate.hw;
- lsp0_gate_clk[i].gate.reg += (u64)reg_base;
+ lsp0_gate_clk[i].gate.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp0_gate_clk[i].gate.hw);
if (ret) {
pr_warn("lsp0 clk %s init error!\n",
@@ -768,7 +768,7 @@ static int __init lsp0_clocks_init(struct device_node *np)
lsp0_hw_onecell_data.hws[lsp0_div_clk[i].id] =
&lsp0_div_clk[i].div.hw;
- lsp0_div_clk[i].div.reg += (u64)reg_base;
+ lsp0_div_clk[i].div.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp0_div_clk[i].div.hw);
if (ret) {
pr_warn("lsp0 clk %s init error!\n",
@@ -847,7 +847,7 @@ static int __init lsp1_clocks_init(struct device_node *np)
lsp1_hw_onecell_data.hws[lsp1_mux_clk[i].id] =
&lsp0_mux_clk[i].mux.hw;
- lsp1_mux_clk[i].mux.reg += (u64)reg_base;
+ lsp1_mux_clk[i].mux.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp1_mux_clk[i].mux.hw);
if (ret) {
pr_warn("lsp1 clk %s init error!\n",
@@ -860,7 +860,7 @@ static int __init lsp1_clocks_init(struct device_node *np)
lsp1_hw_onecell_data.hws[lsp1_gate_clk[i].id] =
&lsp1_gate_clk[i].gate.hw;
- lsp1_gate_clk[i].gate.reg += (u64)reg_base;
+ lsp1_gate_clk[i].gate.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp1_gate_clk[i].gate.hw);
if (ret) {
pr_warn("lsp1 clk %s init error!\n",
@@ -873,7 +873,7 @@ static int __init lsp1_clocks_init(struct device_node *np)
lsp1_hw_onecell_data.hws[lsp1_div_clk[i].id] =
&lsp1_div_clk[i].div.hw;
- lsp1_div_clk[i].div.reg += (u64)reg_base;
+ lsp1_div_clk[i].div.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp1_div_clk[i].div.hw);
if (ret) {
pr_warn("lsp1 clk %s init error!\n",
--
2.9.0
^ permalink raw reply related
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Mark Rutland @ 2016-09-15 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473954000.4035.5.camel@nexus-software.ie>
On Thu, Sep 15, 2016 at 04:40:00PM +0100, Bryan O'Donoghue wrote:
> On Thu, 2016-09-15 at 13:46 +0100, Mark Rutland wrote:
> > On Thu, Sep 15, 2016 at 12:48:08PM +0100, Bryan O'Donoghue wrote:
> > > On Thu, 2016-09-15 at 12:20 +0100, Mark Rutland wrote:
> > > > For example, you have absolutely no guarantee as to what backs
> > > > get_cycles(). Despite this, the code assumes that get_cycles() is
> > > > backed by something running at the frequency described in a
> > > > "google,greybus-frame-time-counter" node.
> > > >
> > > > Even if this *happens* to match what some piece of arch code
> > > > provides
> > > > today on some platform, it is in no way *guaranteed*.
> > > That's the point though, if you declare "google,greybus-frame-time-
> > > counter" in your platform code - then you can use 'get_cycles()' in
> > > this manner
> > To be clear, *some* properties (and perhaps additional nodes) may
> > need
> > to be in the DT, in order to capture the hardware property or
> > relationship that you are reliant upon.
>
> Sure but on the relevant platform we know?
>
> 1. get_cycles() is derived from an architectured MMIO timer
> 2. What is clocking that timer
>
> So any platform that declares that property must be aware of what its
> doing.
I can't say this any more explicitly:
****************************************************
* The DT *cannot* know anything about get_cycles() *
****************************************************
It's no more complex than that.
Thanks,
Mark.
^ permalink raw reply
* [PATCH BUGFIX] mtd: nand: mxc: fix obiwan error in mxc_nand_v[12]_ooblayout_free() functions
From: Boris Brezillon @ 2016-09-15 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473432251-24728-1-git-send-email-LW@KARO-electronics.de>
Hi Lothar,
On Fri, 9 Sep 2016 16:44:11 +0200
Lothar Wa?mann <LW@KARO-electronics.de> wrote:
> commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
> introduced a regression accessing the OOB area from the mxc_nand
> driver due to an Obiwan error in the mxc_nand_v[12]_ooblayout_free()
> functions. They report a bogus oobregion { 64, 7 } which leads to
> errors accessing bogus data when reading the oob area.
>
> Prior to the commit the mtd-oobtest module could be run without any
> errors. With the offending commit, this test fails with results like:
> |Running mtd-oobtest
> |
> |=================================================
> |mtd_oobtest: MTD device: 5
> |mtd_oobtest: MTD device size 524288, eraseblock size 131072, page size 2048, count of eraseblocks 4, pages per eraseblock 64, OOB size 64
> |mtd_test: scanning for bad eraseblocks
> |mtd_test: scanned 4 eraseblocks, 0 are bad
> |mtd_oobtest: test 1 of 5
> |mtd_oobtest: writing OOBs of whole device
> |mtd_oobtest: written up to eraseblock 0
> |mtd_oobtest: written 4 eraseblocks
> |mtd_oobtest: verifying all eraseblocks
> |mtd_oobtest: error @addr[0x0:0x19] 0x9a -> 0x78 diff 0xe2
> |mtd_oobtest: error @addr[0x0:0x1a] 0xcc -> 0x0 diff 0xcc
> |mtd_oobtest: error @addr[0x0:0x1b] 0xe0 -> 0x85 diff 0x65
> |mtd_oobtest: error @addr[0x0:0x1c] 0x60 -> 0x62 diff 0x2
> |mtd_oobtest: error @addr[0x0:0x1d] 0x69 -> 0x45 diff 0x2c
> |mtd_oobtest: error @addr[0x0:0x1e] 0xcd -> 0xa0 diff 0x6d
> |mtd_oobtest: error @addr[0x0:0x1f] 0xf2 -> 0x60 diff 0x92
> |mtd_oobtest: error: verify failed at 0x0
> [...]
>
> Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
> ---
> drivers/mtd/nand/mxc_nand.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> index 5173fad..fdee907 100644
> --- a/drivers/mtd/nand/mxc_nand.c
> +++ b/drivers/mtd/nand/mxc_nand.c
> @@ -893,7 +893,7 @@ static int mxc_v1_ooblayout_free(struct mtd_info *mtd, int section,
> {
> struct nand_chip *nand_chip = mtd_to_nand(mtd);
>
> - if (section > nand_chip->ecc.steps)
> + if (section >= nand_chip->ecc.steps)
> return -ERANGE;
Hm, looking at the commit you're pointing to, it seems that this test
is correct (we have X + 1 free sections, where X is the number of ECC
steps).
>
> if (!section) {
> @@ -943,7 +943,7 @@ static int mxc_v2_ooblayout_free(struct mtd_info *mtd, int section,
> struct nand_chip *nand_chip = mtd_to_nand(mtd);
> int stepsize = nand_chip->ecc.bytes == 9 ? 16 : 26;
>
> - if (section > nand_chip->ecc.steps)
> + if (section >= nand_chip->ecc.steps)
> return -ERANGE;
Yep, this one is a real bug.
>
> if (!section) {
^ permalink raw reply
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Bryan O'Donoghue @ 2016-09-15 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915154736.GA19214@leverpostej>
On Thu, 2016-09-15 at 16:47 +0100, Mark Rutland wrote:
> On?
> I can't say this any more explicitly:
>
> ****************************************************
> * The DT *cannot* know anything about get_cycles() *
> ****************************************************
>
> It's no more complex than that.
Sure think Mark I understand your point.
I think to satisfy your objection the most sensible change to make is
using arch_timer_get_rate() compared to a desired rate of 19200000.
---
bod
^ permalink raw reply
* [PATCH] arm64: kprobe: Always clear pstate.D in breakpoint exception handler
From: Pratyush Anand @ 2016-09-15 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160824100644.GB4408@localhost.localdomain>
Hi Sandeepa,
On Wed, Aug 24, 2016 at 3:36 PM, Pratyush Anand <panand@redhat.com> wrote:
> Hi Sandeepa,
>
> Thanks for the review.
>
> On 23/08/2016:04:33:08 PM, Sandeepa Prabhu wrote:
>> Thanks for the fix, feel free to add my ACK as well. Has it been tested on
>> guest kernel?
>
> have not tested on guest kernel.Will do.
I tested it with guest kernel, and it worked there too :-).
@Catalin: any more comment for this patch? If not, then may be you can take it.
~Pratyush
^ permalink raw reply
* [PATCH] arm64: kprobe: Always clear pstate.D in breakpoint exception handler
From: Will Deacon @ 2016-09-15 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHB_Guods-iED+tOLeJ9XCWDvAVoButwz2XWSiP+eMYDzFhfyQ@mail.gmail.com>
On Thu, Sep 15, 2016 at 09:45:09PM +0530, Pratyush Anand wrote:
> On Wed, Aug 24, 2016 at 3:36 PM, Pratyush Anand <panand@redhat.com> wrote:
> > On 23/08/2016:04:33:08 PM, Sandeepa Prabhu wrote:
> >> Thanks for the fix, feel free to add my ACK as well. Has it been tested on
> >> guest kernel?
> >
> > have not tested on guest kernel.Will do.
>
> I tested it with guest kernel, and it worked there too :-).
>
> @Catalin: any more comment for this patch? If not, then may be you can take it.
I already queued this on the arm64 for-next/core branch.
Will
^ permalink raw reply
* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
From: Vinod Koul @ 2016-09-15 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914130739.GE13920@localhost>
On Wed, Sep 14, 2016 at 06:37:40PM +0530, Vinod Koul wrote:
> On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > > I hate to send a ping,
> >
> > Sorry about that.
> >
> > > but do you think we can merge this fdma series? It has gone
> > > through quite a few review rounds now.
> > >
> >
> > I think the remoteproc part looks good.
>
> yeah I was waiting for ack on other patches. But looks like at least
> remoteproc ones have it
>
>
> > Vinod, I don't have any changes queued in remoteproc that should cause
> > merge issues. If you want to you could take the remoteproc patch
> > through your tree.
>
> I rechecked the dma part, they look good to me, so I should be able to apply
> these. I will wait a day for ack/nacks. It is the time to speak up :)
And I have applied thru 9th patch. Others are applied by Patrice.
Btw you should send drm ones to drm folks separately and not in this
series..
Thanks
--
~Vinod
^ permalink raw reply
* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Mark Rutland @ 2016-09-15 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473788797-10879-1-git-send-email-catalin.marinas@arm.com>
Hi Catalin,
On Tue, Sep 13, 2016 at 06:46:30PM +0100, Catalin Marinas wrote:
> This is the third version of the arm64 PAN emulation using TTBR0_EL1
> switching. The series has not yet included the alternative nop patches
> from Mark Rutland, nor the empty_zero_page from Ard B. This will be done
> in a subsequent version once 4.9-rc1 is out (which will include Mark's
> alternative nop patches).
> arch/arm64/Kconfig | 8 ++
> arch/arm64/include/asm/assembler.h | 33 +++++++
> arch/arm64/include/asm/cpufeature.h | 6 ++
> arch/arm64/include/asm/efi.h | 26 ++++-
> arch/arm64/include/asm/futex.h | 14 +--
> arch/arm64/include/asm/kernel-pgtable.h | 7 ++
> arch/arm64/include/asm/mmu_context.h | 51 +++++++---
> arch/arm64/include/asm/ptrace.h | 2 +
> arch/arm64/include/asm/thread_info.h | 3 +
> arch/arm64/include/asm/uaccess.h | 163 ++++++++++++++++++++++++++++++--
> arch/arm64/kernel/armv8_deprecated.c | 10 +-
> arch/arm64/kernel/asm-offsets.c | 3 +
> arch/arm64/kernel/cpufeature.c | 1 +
> arch/arm64/kernel/entry.S | 71 +++++++++++++-
> arch/arm64/kernel/head.S | 6 +-
> arch/arm64/kernel/setup.c | 9 ++
> arch/arm64/kernel/vmlinux.lds.S | 5 +
> arch/arm64/lib/clear_user.S | 8 +-
> arch/arm64/lib/copy_from_user.S | 8 +-
> arch/arm64/lib/copy_in_user.S | 8 +-
> arch/arm64/lib/copy_to_user.S | 8 +-
> arch/arm64/mm/context.c | 7 +-
> arch/arm64/mm/fault.c | 22 +++--
> arch/arm64/mm/proc.S | 11 +--
> arch/arm64/xen/hypercall.S | 19 ++++
> 25 files changed, 428 insertions(+), 81 deletions(-)
I don't seee traps.c there. Don't we need to fix up do_sysinstr() (which
performs raw cache maintenance ops on __user addresses) with
uaccess_{enable,disable}_not_uao()?
Likewise, how do we handle __flush_cache_user_range and
flush_icache_range? Some callers (e.g. __do_compat_cache_op) pass in
__user addresses.
I hope we have some tests lying around for those. ;)
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM: s3c24xx: Add dma_slave_map for s3c2440 devices
From: Vinod Koul @ 2016-09-15 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2fa402bf-0e3f-0495-41ca-7a3c89eaa2e1@samsung.com>
On Thu, Sep 15, 2016 at 11:05:12AM +0200, Sylwester Nawrocki wrote:
> On 09/14/2016 08:29 PM, Sam Van Den Berge wrote:
> > +static const struct dma_slave_map s3c2440_dma_slave_map[] = {
> ...
> > + { "3c2440-sdi", "rx", (void *)DMACH_SDI },
> > + { "3c2440-sdi", "tx", (void *)DMACH_SDI },
>
> The device names seem misspelled here, and looking at what
> drivers/mmc/host/s3cmci.c driver does we need just a single common
> entry for rx and tx
>
> { "s3c2440-sdi", "rx-tx", (void *)DMACH_SDI },
>
> With this fixed feel free to add
And please change the title to dmaengine and NOT arm... I was about ti skip
this!
--
~Vinod
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Vinod Koul @ 2016-09-15 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160810173710.GK9681@localhost>
On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S?derlund wrote:
> > Hi,
> >
> > This series tries to solve the problem with DMA with device registers
> > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> > recent patch '9575632 (dmaengine: make slave address physical)'
> > clarifies that DMA slave address provided by clients is the physical
> > address. This puts the task of mapping the DMA slave address from a
> > phys_addr_t to a dma_addr_t on the DMA engine.
> >
> > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> > the same and no special care is needed. However if you have a IOMMU you
> > need to map the DMA slave phys_addr_t to a dma_addr_t using something
> > like this.
> >
> > This series is based on top of v4.8-rc1. And I'm hoping to be able to collect a
> > Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> > able to take the whole series through the dmaengine tree. If this is not the
> > best route I'm more then happy to do it another way.
> >
> > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> > /dev/mmcblk1, i2c and the serial console which are devices behind the
> > iommu.
>
> As I said in last one, the dmaengine parts look fine to me. But to go thru
> dmaengine tree I would need ACK on non dmaengine patches.
I havent heard back from this one and I am inclined to merge this one now.
If anyone has any objects, please speak up now...
Also ACKs welcome...
--
~Vinod
^ permalink raw reply
* [PATCH] arm64: kprobe: Always clear pstate.D in breakpoint exception handler
From: Pratyush Anand @ 2016-09-15 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915161828.GH3380@arm.com>
On Thu, Sep 15, 2016 at 9:48 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Sep 15, 2016 at 09:45:09PM +0530, Pratyush Anand wrote:
>> On Wed, Aug 24, 2016 at 3:36 PM, Pratyush Anand <panand@redhat.com> wrote:
>> > On 23/08/2016:04:33:08 PM, Sandeepa Prabhu wrote:
>> >> Thanks for the fix, feel free to add my ACK as well. Has it been tested on
>> >> guest kernel?
>> >
>> > have not tested on guest kernel.Will do.
>>
>> I tested it with guest kernel, and it worked there too :-).
>>
>> @Catalin: any more comment for this patch? If not, then may be you can take it.
>
> I already queued this on the arm64 for-next/core branch.
>
Thanks Will :-)
^ permalink raw reply
* [PATCH v4 0/3] ASoC: sun4i-codec: Distinguish sun4i from sun7i
From: Danny Milosavljevic @ 2016-09-15 16:36 UTC (permalink / raw)
To: linux-arm-kernel
ASoC: sun4i-codec: Introduce mechanism to detect sun7i and provide a
different regmap different compared to sun4i Allwinner A10.
The controls will be extended in a forthcoming patch - it is necessary
to distinguish between sun4i and sun7i controls because they have different
registers.
Renamed SUN4I_CODEC_AC_SYS_VERI to SUN7I_CODEC_AC_DAC_CAL and renamed
SUN4I_CODEC_AC_MIC_PHONE_CAL to SUN7I_CODEC_AC_MIC_PHONE_CAL because these
are actually not present on Allwinner A10.
Handle quirks by regmap config and codec and select the correct quirks
automatically.
Danny Milosavljevic (3):
ASoC: sun4i-codec: rename "sun4i_codec_widgets" to
"sun4i_codec_controls" for consistency with the struct field name.
ASoC: rename "SUN4I_CODEC_SYS_VERI" to "SUN7I_CODEC_AC_DAC_CAL";
rename "SUN4I_CODEC_AC_MIC_PHONE_CAL" to
"SUN7I_CODEC_AC_MIC_PHONE_CAL".
ASoC: sun4i-codec: Add custom regmap configs for the A10 and A20
variants.
sound/soc/sunxi/sun4i-codec.c | 45 ++++++++++++++++++++++++++++++++++---------
1 file changed, 36 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH v4 1/3] ASoC: sun4i-codec: rename sun4i_codec_widgets for consistency
From: Danny Milosavljevic @ 2016-09-15 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915163630.18026-1-dannym@scratchpost.org>
ASoC: sun4i-codec: Rename "sun4i_codec_widgets" to "sun4i_codec_controls" for
consistency with the struct field name.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
---
sound/soc/sunxi/sun4i-codec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 0e19c50..c2c0583 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -509,7 +509,7 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
-static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
+static const struct snd_kcontrol_new sun4i_codec_controls[] = {
SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
sun4i_codec_pa_volume_scale),
@@ -629,8 +629,8 @@ static const struct snd_soc_dapm_route sun4i_codec_codec_dapm_routes[] = {
static struct snd_soc_codec_driver sun4i_codec_codec = {
.component_driver = {
- .controls = sun4i_codec_widgets,
- .num_controls = ARRAY_SIZE(sun4i_codec_widgets),
+ .controls = sun4i_codec_controls,
+ .num_controls = ARRAY_SIZE(sun4i_codec_controls),
.dapm_widgets = sun4i_codec_codec_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
.dapm_routes = sun4i_codec_codec_dapm_routes,
^ permalink raw reply related
* [PATCH v4 2/3] ASoC: rename some sun7i-only registers
From: Danny Milosavljevic @ 2016-09-15 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915163630.18026-1-dannym@scratchpost.org>
ASoC: sun4i-codec: Some of the registers are sun7i-only.
Therefore rename "SUN4I_CODEC_SYS_VERI" to "SUN7I_CODEC_AC_DAC_CAL" and
rename "SUN4I_CODEC_AC_MIC_PHONE_CAL" to "SUN7I_CODEC_AC_MIC_PHONE_CAL".
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
---
sound/soc/sunxi/sun4i-codec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index c2c0583..3b53b78 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -96,8 +96,8 @@
/* Other various ADC registers */
#define SUN4I_CODEC_DAC_TXCNT (0x30)
#define SUN4I_CODEC_ADC_RXCNT (0x34)
-#define SUN4I_CODEC_AC_SYS_VERI (0x38)
-#define SUN4I_CODEC_AC_MIC_PHONE_CAL (0x3c)
+#define SUN7I_CODEC_AC_DAC_CAL (0x38)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
struct sun4i_codec {
struct device *dev;
@@ -682,7 +682,7 @@ static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
- .max_register = SUN4I_CODEC_AC_MIC_PHONE_CAL,
+ .max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
static const struct of_device_id sun4i_codec_of_match[] = {
^ permalink raw reply related
* [PATCH v4 3/3] ASoC: sun4i-codec: Add custom regmap configs
From: Danny Milosavljevic @ 2016-09-15 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915163630.18026-1-dannym@scratchpost.org>
ASoC: sun4i-codec: The A20 has a few extra registers that the A10
doesn't have.
Therefore, use different regmaps for A10 as compared to A20.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
---
sound/soc/sunxi/sun4i-codec.c | 33 ++++++++++++++++++++++++++++++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 3b53b78..c5d6d84c 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -682,12 +682,37 @@ static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
+ .max_register = SUN4I_CODEC_ADC_RXCNT,
+};
+
+static const struct regmap_config sun7i_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
.max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
+struct sun4i_codec_quirks {
+ const struct regmap_config *regmap_config;
+};
+
+static const struct sun4i_codec_quirks sun4i_codec_quirks = {
+ .regmap_config = &sun4i_codec_regmap_config,
+};
+
+static const struct sun4i_codec_quirks sun7i_codec_quirks = {
+ .regmap_config = &sun7i_codec_regmap_config,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
- { .compatible = "allwinner,sun4i-a10-codec" },
- { .compatible = "allwinner,sun7i-a20-codec" },
+ {
+ .compatible = "allwinner,sun4i-a10-codec",
+ .data = &sun4i_codec_quirks,
+ },
+ {
+ .compatible = "allwinner,sun7i-a20-codec",
+ .data = &sun7i_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
@@ -760,6 +785,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
{
struct snd_soc_card *card;
struct sun4i_codec *scodec;
+ const struct sun4i_codec_quirks *quirks;
struct resource *res;
void __iomem *base;
int ret;
@@ -777,8 +803,9 @@ static int sun4i_codec_probe(struct platform_device *pdev)
return PTR_ERR(base);
}
+ quirks = of_device_get_match_data(&pdev->dev);
scodec->regmap = devm_regmap_init_mmio(&pdev->dev, base,
- &sun4i_codec_regmap_config);
+ quirks->regmap_config);
if (IS_ERR(scodec->regmap)) {
dev_err(&pdev->dev, "Failed to create our regmap\n");
return PTR_ERR(scodec->regmap);
^ permalink raw reply related
* [PATCH V6 0/3] Adding support for address filters
From: Mathieu Poirier @ 2016-09-15 16:37 UTC (permalink / raw)
To: linux-arm-kernel
This patch set makes it possible to use the current filter
framework with address filters. That way address filters for
HW tracers such as CoreSight and IntelPT can be communicated
to the kernel drivers.
In this revision precursor work is done to make function
perf_evsel__append_filter() generic, along with changes to
current customers. From there the work on address filters is
introduced.
Thanks,
Mathieu
---
Changes for V6:
- Split work in 3 (small) patches.
- Adding tracepoint and address filter append() functions
Changes for V5:
- Modified perf_evsel__append_filter() to take a string format
rather than an operation.
Changes for V4:
- Added support for address filters over more than one
nibble.
- Removed Jiri's ack, this version is too different from
what was reviewed.
Changes for V3:
- Added Jiri's ack.
- Rebased to v4.8-rc5.
Changes for V2:
- Rebased to v4.8-rc4.
- Revisited error path.
Mathieu Poirier (3):
perf tools: making perf_evsel__append_filter() generic
perf tools: new tracepoint specific function
perf tools: adding support for address filters
tools/perf/builtin-trace.c | 8 ++++++--
tools/perf/util/evsel.c | 16 +++++++++++++---
tools/perf/util/evsel.h | 5 +++--
tools/perf/util/parse-events.c | 41 +++++++++++++++++++++++++++++++++++------
4 files changed, 57 insertions(+), 13 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH V6 1/3] perf tools: making perf_evsel__append_filter() generic
From: Mathieu Poirier @ 2016-09-15 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473957428-28311-1-git-send-email-mathieu.poirier@linaro.org>
By making function perf_evsel__append_filter() take a format rather
than an operator it is possible to reuse the code for other purposes
(ex. intelPT and CoreSight) than tracepoints.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
tools/perf/builtin-trace.c | 9 +++++++--
tools/perf/util/evsel.c | 4 ++--
tools/perf/util/evsel.h | 2 +-
tools/perf/util/parse-events.c | 4 ++--
4 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index b8c6766301db..4c2704332c14 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2140,6 +2140,7 @@ out_delete_sys_enter:
static int trace__set_ev_qualifier_filter(struct trace *trace)
{
int err = -1;
+ struct perf_evsel *sys_exit;
char *filter = asprintf_expr_inout_ints("id", !trace->not_ev_qualifier,
trace->ev_qualifier_ids.nr,
trace->ev_qualifier_ids.entries);
@@ -2147,8 +2148,12 @@ static int trace__set_ev_qualifier_filter(struct trace *trace)
if (filter == NULL)
goto out_enomem;
- if (!perf_evsel__append_filter(trace->syscalls.events.sys_enter, "&&", filter))
- err = perf_evsel__append_filter(trace->syscalls.events.sys_exit, "&&", filter);
+ if (!perf_evsel__append_filter(trace->syscalls.events.sys_enter,
+ "(%s) && (%s)", filter)) {
+ sys_exit = trace->syscalls.events.sys_exit;
+ err = perf_evsel__append_filter(sys_exit,
+ "(%s) && (%s)", filter);
+ }
free(filter);
out:
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 21fd573106ed..b93369745e08 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1046,14 +1046,14 @@ int perf_evsel__set_filter(struct perf_evsel *evsel, const char *filter)
}
int perf_evsel__append_filter(struct perf_evsel *evsel,
- const char *op, const char *filter)
+ const char *fmt, const char *filter)
{
char *new_filter;
if (evsel->filter == NULL)
return perf_evsel__set_filter(evsel, filter);
- if (asprintf(&new_filter,"(%s) %s (%s)", evsel->filter, op, filter) > 0) {
+ if (asprintf(&new_filter, fmt, evsel->filter, filter) > 0) {
free(evsel->filter);
evsel->filter = new_filter;
return 0;
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 4d44129e050b..7ab59f15892f 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -234,7 +234,7 @@ void perf_evsel__set_sample_id(struct perf_evsel *evsel,
int perf_evsel__set_filter(struct perf_evsel *evsel, const char *filter);
int perf_evsel__append_filter(struct perf_evsel *evsel,
- const char *op, const char *filter);
+ const char *fmt, const char *filter);
int perf_evsel__apply_filter(struct perf_evsel *evsel, int ncpus, int nthreads,
const char *filter);
int perf_evsel__enable(struct perf_evsel *evsel);
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 6c913c3914fb..9692300585f6 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1762,7 +1762,7 @@ static int set_filter(struct perf_evsel *evsel, const void *arg)
return -1;
}
- if (perf_evsel__append_filter(evsel, "&&", str) < 0) {
+ if (perf_evsel__append_filter(evsel, "(%s) && (%s)", str) < 0) {
fprintf(stderr,
"not enough memory to hold filter string\n");
return -1;
@@ -1793,7 +1793,7 @@ static int add_exclude_perf_filter(struct perf_evsel *evsel,
snprintf(new_filter, sizeof(new_filter), "common_pid != %d", getpid());
- if (perf_evsel__append_filter(evsel, "&&", new_filter) < 0) {
+ if (perf_evsel__append_filter(evsel, "(%s) && (%s)", new_filter) < 0) {
fprintf(stderr,
"not enough memory to hold filter string\n");
return -1;
--
2.7.4
^ permalink raw reply related
* [PATCH V6 2/3] perf tools: new tracepoint specific function
From: Mathieu Poirier @ 2016-09-15 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473957428-28311-1-git-send-email-mathieu.poirier@linaro.org>
Making function perf_evsel__append_filter() static and
introducing a new tracepoint specific function to append
filters. That way we eliminate redundant code and avoid
formatting mistake.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
tools/perf/builtin-trace.c | 7 +++----
tools/perf/util/evsel.c | 9 +++++++--
tools/perf/util/evsel.h | 3 +--
tools/perf/util/parse-events.c | 4 ++--
4 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 4c2704332c14..34effab09f39 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2148,11 +2148,10 @@ static int trace__set_ev_qualifier_filter(struct trace *trace)
if (filter == NULL)
goto out_enomem;
- if (!perf_evsel__append_filter(trace->syscalls.events.sys_enter,
- "(%s) && (%s)", filter)) {
+ if (!perf_evsel__append_tp_filter(trace->syscalls.events.sys_enter,
+ filter)) {
sys_exit = trace->syscalls.events.sys_exit;
- err = perf_evsel__append_filter(sys_exit,
- "(%s) && (%s)", filter);
+ err = perf_evsel__append_tp_filter(sys_exit, filter);
}
free(filter);
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index b93369745e08..a99e82d97df2 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1045,8 +1045,8 @@ int perf_evsel__set_filter(struct perf_evsel *evsel, const char *filter)
return -1;
}
-int perf_evsel__append_filter(struct perf_evsel *evsel,
- const char *fmt, const char *filter)
+static int perf_evsel__append_filter(struct perf_evsel *evsel,
+ const char *fmt, const char *filter)
{
char *new_filter;
@@ -1062,6 +1062,11 @@ int perf_evsel__append_filter(struct perf_evsel *evsel,
return -1;
}
+int perf_evsel__append_tp_filter(struct perf_evsel *evsel, const char *filter)
+{
+ return perf_evsel__append_filter(evsel, "(%s) && (%s)", filter);
+}
+
int perf_evsel__enable(struct perf_evsel *evsel)
{
int nthreads = thread_map__nr(evsel->threads);
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 7ab59f15892f..36ed0997e65b 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -233,8 +233,7 @@ void perf_evsel__set_sample_id(struct perf_evsel *evsel,
bool use_sample_identifier);
int perf_evsel__set_filter(struct perf_evsel *evsel, const char *filter);
-int perf_evsel__append_filter(struct perf_evsel *evsel,
- const char *fmt, const char *filter);
+int perf_evsel__append_tp_filter(struct perf_evsel *evsel, const char *filter);
int perf_evsel__apply_filter(struct perf_evsel *evsel, int ncpus, int nthreads,
const char *filter);
int perf_evsel__enable(struct perf_evsel *evsel);
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 9692300585f6..751b48fc641c 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1762,7 +1762,7 @@ static int set_filter(struct perf_evsel *evsel, const void *arg)
return -1;
}
- if (perf_evsel__append_filter(evsel, "(%s) && (%s)", str) < 0) {
+ if (perf_evsel__append_tp_filter(evsel, str) < 0) {
fprintf(stderr,
"not enough memory to hold filter string\n");
return -1;
@@ -1793,7 +1793,7 @@ static int add_exclude_perf_filter(struct perf_evsel *evsel,
snprintf(new_filter, sizeof(new_filter), "common_pid != %d", getpid());
- if (perf_evsel__append_filter(evsel, "(%s) && (%s)", new_filter) < 0) {
+ if (perf_evsel__append_tp_filter(evsel, new_filter) < 0) {
fprintf(stderr,
"not enough memory to hold filter string\n");
return -1;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox