Re: Voltage setting on chained regulators, how?
On Fri, Sep 25, 2015 at 09:47:26AM -0700, Mark Brown wrote: > On Fri, Sep 25, 2015 at 11:07:24AM +0200, Sascha Hauer wrote: > > > Any idea how such a scenario could be implemented? The regulator > > framework already has some idea of supply regulators, but it only takes > > care of en/disabling the supplies and will not change the voltage on the > > supplies. Should this be implemented in the regulator framework? Some > > first experiments brought me into a locking hell quite fast. > > It's just a case of implementation, but yes the locking is fun. I don't > think it's that big a deal to rethink it, it's partly complicated since > the existing locking is designed to be really simple and easy to review. Ok, it seems you're generally ok with putting this into the regulator core. I'll try and see what I can come up with. Maybe I leave the locking part for later to see if this otherwise solves my problem or if there are other pitfalls I don't see yet. > > > For added fun ideally we want to put the LDOs in bypass mode instead of > > configuring them for minimum dropout. The bypass mode doesn't work for > > the 1.2GHz operating point though since the ripple on the switching > > regulator gets too high. So we can't just statically configure bypass > > mode but have to enable it dynamically based on the operating points. > > I suspect you always want the LDO in there to clean the supply up, it's > just a more serious issue when more power is being drawn. I just had a look at the i.MX6 datasheets and saw that while it's possible to put the LDOs in bypass mode the expected lifetime of the SoC decreases without the LDOs. So it seems better to let them enabled and just make the voltage drop as small as possible. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf record: Limit --intr-regs to platforms supporting PERF_REGS
On 2015/09/29 08:53AM, Jiri Olsa wrote: > On Tue, Sep 29, 2015 at 11:06:17AM +0530, Naveen N. Rao wrote: > > On 2015/09/24 10:15PM, Naveen N Rao wrote: > > > On 2015/09/24 08:32AM, Stephane Eranian wrote: > > > > On Thu, Sep 24, 2015 at 5:57 AM, Jiri Olsa wrote: > > > > > > > > > > On Thu, Sep 24, 2015 at 05:41:58PM +0530, Naveen N. Rao wrote: > > > > > > perf build currently fails on powerpc: > > > > > > > > > > > > LINK perf > > > > > > libperf.a(libperf-in.o):(.toc+0x120): undefined reference to > > > > > > `sample_reg_masks' > > > > > > libperf.a(libperf-in.o):(.toc+0x130): undefined reference to > > > > > > `sample_reg_masks' > > > > > > collect2: error: ld returned 1 exit status > > > > > > make[1]: *** [perf] Error 1 > > > > > > make: *** [all] Error 2 > > > > > > > > > > > > This is due to parse-regs-options.c using sample_reg_masks, which is > > > > > > defined only with CONFIG_PERF_REGS. > > > > > > > > > > > > In addition, perf record -I is only useful if the arch supports > > > > > > PERF_REGS. Hence, let's expose -I conditionally. > > > > > > > > > > > > Signed-off-by: Naveen N. Rao > > > > > > > > > > hum, I wonder why we have sample_reg_masks defined as weak in > > > > > util/perf_regs.c > > > > > which is also built only via CONFIG_PERF_REGS > > > > > > > > > > I wonder we could get rid of the weak definition via attached patch, > > > > > Stephane? > > > > > > > > > But the whole point of having it weak is to avoid this error scenario > > > > on any arch without support > > > > and avoid ugly #ifdef HAVE_ in generic files. > > > > > > > > if perf_regs.c is compiled on PPC, then why do we get the undefined? > > > > > > As Jiri Olsa pointed out, powerpc and many other architectures don't > > > (yet) have support for perf regs. > > > > > > But, the larger reason to introduce #ifdef is so the user doesn't see > > > options (s)he can't use on a specific architecture, along the same lines > > > as builtin-probe.c > > > > Stephane, Arnaldo, > > Suka has also posted a fix for this with a different approach [1]. Can > > you please ack/pull one of these versions? Building perf is broken on > > v4.3-rc due to this. > > I did not get any answer for additional comments I made to the patch > (couldnt get marc.info working, sending the patch again) Hi Jiri, I concur with the changes you proposed to my patch here (getting rid of the weak variant): http://article.gmane.org/gmane.linux.kernel/2046108 I am aware of the other approach you posted (and the one attached below). When I said "please ack/pull one of these versions", I meant one of: your version, Suka's and mine. > > > > > [1] http://article.gmane.org/gmane.linux.kernel/2046370 > > I dont have this last version, which seems to have other changes > and patch in above link looks mangled, could you please repost it? Can you please check the raw version: http://article.gmane.org/gmane.linux.kernel/2046370/raw Thanks, Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/9] drivers/of: Introduce of_node_alloc
On Mon, 28 Sep 2015 15:50:38 -0700 Frank Rowand wrote: > On 9/28/2015 9:42 AM, Marc Zyngier wrote: > > We want to be able to generate "fake" device nodes that can be > > used as an identifier for irq domains. For that, we reuse the > > dynamic DT layer in order to generate DT nodes in a detached state > > (so that it doesn't interfere with the rest of the tree). > > > > Signed-off-by: Marc Zyngier > > --- > > drivers/of/dynamic.c | 22 ++ > > include/linux/of.h | 5 + > > 2 files changed, 27 insertions(+) > > > > diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c > > index 53826b8..709d363 100644 > > --- a/drivers/of/dynamic.c > > +++ b/drivers/of/dynamic.c > > @@ -445,6 +445,28 @@ struct device_node *__of_node_dup(const struct > > device_node *np, const char *fmt, > > return NULL; > > } > > > > +/** > > + * of_node_alloc() - Allocate an empty device node dynamically. > > + * @fmt: Format string (plus vargs) for new full name of the device node > > + * > > + * Create an device tree node, either by by allocating an empty one > > Create a device tree node by allocating an empty one Ah! Thanks! M. -- Jazz is not dead. It just smells funny. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 20/22] driver core: Allow deferring probes until late init
On 26 September 2015 at 20:15, Rob Herring wrote:
> On 09/21/2015 09:03 AM, Tomeu Vizoso wrote:
>> Add a field to struct device that instructs the device-driver core to
>> defer the probe of this device until the late_initcall level.
>
> This is true until the next patch with moves deferred probe processing
> to device_initcall_sync. So disabling this option alone won't totally
> revert to current behaviour. I guess patch 21 could be reverted if
> necessary.
Actually, the goal with that commit was to prevent potential problems
due to the increased pressure on late_initcall, as suggested by
Grygorii Strashko, but I haven't found yet any evidence of it being
needed, and in my testing the series boot all boards in kernelci with
or without this commit. So I would just not commit it for now and only
consider applying it later if someone reports a problem.
>> By letting all built-in drivers to register before starting to probe, we
>> can avoid any deferred probes by probing dependencies on demand.
>>
>> Signed-off-by: Tomeu Vizoso
>>
>> ---
>>
>> Changes in v4:
>> - Add Kconfig DELAY_DEVICE_PROBES to allow disabling delayed probing in
>> machines with initcalls that depend on devices probing at a given time.
>>
>> drivers/base/Kconfig | 18 ++
>> drivers/base/dd.c | 7 +++
>> include/linux/device.h | 2 ++
>> 3 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
>> index 98504ec99c7d..44b5d33b1f49 100644
>> --- a/drivers/base/Kconfig
>> +++ b/drivers/base/Kconfig
>> @@ -324,4 +324,22 @@ config CMA_ALIGNMENT
>>
>> endif
>>
>> +config DELAY_DEVICE_PROBES
>> + bool "Allow delaying the probe of some devices"
>
> I'd like to hide visibility of this behind EXPERT.
Done.
>> + default y
>> + help
>> + Devices can be matched to a driver and probed from the moment they
>> + are registered, but early during boot their probes are likely to be
>> + deferred because some dependency isn't available yet because most
>> + drivers haven't been registered yet.
>> +
>> + Enabling this option allows the device registration code to delay the
>> + probing of a specific device until device_initcall_sync, when all
>> + built-in drivers have been registered already.
>> +
>> + In some platforms there may be implicit assumptions about when some
>> + devices are probed, so enabling this option could cause problems
>> there.
>> +
>> + If unsure, say Y here.
>> +
>> endmenu
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index 7dc04ee81c8b..269ea76c1a4f 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -417,6 +417,13 @@ int driver_probe_device(struct device_driver *drv,
>> struct device *dev)
>> if (!device_is_registered(dev))
>> return -ENODEV;
>>
>> +#if IS_ENABLED(CONFIG_DELAY_DEVICE_PROBES)
>
> This can be moved to the if.
Done.
Thanks,
Tomeu
>> + if (!driver_deferred_probe_enable && dev->probe_late) {
>> + driver_deferred_probe_add(dev);
>> + return 0;
>> + }
>> +#endif
>> +
>> pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
>>drv->bus->name, __func__, dev_name(dev), drv->name);
>>
>> diff --git a/include/linux/device.h b/include/linux/device.h
>> index 8e7b806f0744..e64f4c7e243d 100644
>> --- a/include/linux/device.h
>> +++ b/include/linux/device.h
>> @@ -744,6 +744,7 @@ struct device_dma_parameters {
>> *
>> * @offline_disabled: If set, the device is permanently online.
>> * @offline: Set after successful invocation of bus type's .offline().
>> + * @probe_late: If set, device will be probed in the late initcall
>> level.
>> *
>> * At the lowest level, every device in a Linux system is represented by an
>> * instance of struct device. The device structure contains the information
>> @@ -828,6 +829,7 @@ struct device {
>>
>> booloffline_disabled:1;
>> booloffline:1;
>> + boolprobe_late:1;
>> };
>>
>> static inline struct device *kobj_to_dev(struct kobject *kobj)
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v3,1/2] airo: fix IW_AUTH_ALG_OPEN_SYSTEM
> IW_AUTH_ALG_OPEN_SYSTEM is ambiguous in set_auth for WEP as > wpa_supplicant uses it for both no encryption and WEP open system. > Cache the last mode set (only of these two) and use it here. > > This allows wpa_supplicant to work with unencrypted APs. > > Signed-off-by: Ondrej Zary Thanks, 2 patches applied to wireless-drivers-next.git: 4a0f2ea79797 airo: fix IW_AUTH_ALG_OPEN_SYSTEM 2b8fa9e870b7 airo: Implement netif_carrier_on/off Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/22] On-demand device probing
On 26 September 2015 at 20:17, Rob Herring wrote: > On 09/21/2015 09:02 AM, Tomeu Vizoso wrote: >> Hello, >> >> I have a problem with the panel on my Tegra Chromebook taking longer >> than expected to be ready during boot (Stéphane Marchesin reported what >> is basically the same issue in [0]), and have looked into ordered >> probing as a better way of solving this than moving nodes around in the >> DT or playing with initcall levels and linking order. >> >> While reading the thread [1] that Alexander Holler started with his >> series to make probing order deterministic, it occurred to me that it >> should be possible to achieve the same by probing devices as they are >> referenced by other devices. >> >> This basically reuses the information that is already implicit in the >> probe() implementations, saving us from refactoring existing drivers or >> adding information to DTBs. >> >> During review of v1 of this series Linus Walleij suggested that it >> should be the device driver core to make sure that dependencies are >> ready before probing a device. I gave this idea a try [2] but Mark Brown >> pointed out to the logic duplication between the resource acquisition >> and dependency discovery code paths (though I think it's fairly minor). >> >> To address that code duplication I experimented with Arnd's devm_probe >> [3] concept of having drivers declare their dependencies instead of >> acquiring them during probe, and while it worked [4], I don't think we >> end up winning anything when compared to just probing devices on-demand >> from resource getters. >> >> One remaining objection is to the "sprinkling" of calls to >> of_device_probe() in the resource getters of each subsystem, but I think >> it's the right thing to do given that the storage of resources is >> currently subsystem-specific. >> >> We could avoid the above by moving resource storage into the core, but I >> don't think there's a compelling case for that. >> >> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and >> OMAP SoCs, and these patches were enough to eliminate all the deferred >> probes (except one in PandaBoard because omap_dma_system doesn't have a >> firmware node as of yet). >> >> Have submitted a branch [5][6][7] with these patches on top of today's >> linux-next (20150921) to kernelci.org and I don't see any issues that >> could be caused by them. >> >> With this series I get the kernel to output to the panel in 0.5s, >> instead of 2.8s. > > I think we're pretty close other than some minor comments. I would like > to see ack's from Greg and some reviewed-bys from others. The subsystem > changes are minor and there has been plenty of chance to comment, so I > don't think acks from all subsystems are needed. > > Your branch is based on -next. Is there any dependence on something in > -next? I want to get this into -next soon, but need a branch not based > on -next. Please send me a pull request with the collected acks and > minor comments I have addressed. Great, I'm going to send one more revision rebased on top of v4.3-rc1, without 21 and with the minor changes you suggested, and once Greg is happy I can send the pull request. Thanks, Tomeu > Rob > >> >> Regards, >> >> Tomeu >> >> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html >> >> [1] https://lkml.org/lkml/2014/5/12/452 >> >> [2] https://lkml.org/lkml/2015/6/17/305 >> >> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689 >> >> [4] https://lkml.org/lkml/2015/7/21/441a >> >> [5] >> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v8 >> >> [6] >> http://kernelci.org/boot/all/job/collabora/kernel/v4.3-rc2-2587-gf92b0ab33d14/ >> >> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150921 >> >> Changes in v6: >> - Drop bus_type.pre_probe and read the periphid in match() instead as >> suggested by Alan Stern. >> - Merge changes to the regulator subsystem's locking so no references >> are leaked between commits. >> >> Changes in v5: >> - Set the pointer to struct device also for AMBA devices >> - Unset the pointer to struct device when the platform device is about >> to be unregistered >> - Increase the reference count of the device before returning from >> of_find_device_by_node() >> - Move the assignment to device_node->device for AMBA devices to another >> commit. >> - Hold a reference to the struct device while it's in use in >> of_device_probe(). >> - Use regulator_class' klist of devices instead of regulator_list to >> store and lookup regulator devices. >> >> Changes in v4: >> - Added bus.pre_probe callback so the probes of Primecell devices can be >> deferred if their device IDs cannot be yet read because of the clock >> driver not having probed when they are registered. Maybe this goes >> overboard and the matching information should be in the DT if there is >> one. >> - Rename of_platform_probe to of_device_probe >> - Use device_node.device instead of d
[tip:irq/core] irqchip/gicv3-its: Add range check for number of allocated pages
Commit-ID: 30f2136346cab91e1ffd9ee6370d76809f20487a
Gitweb: http://git.kernel.org/tip/30f2136346cab91e1ffd9ee6370d76809f20487a
Author: Robert Richter
AuthorDate: Mon, 21 Sep 2015 22:58:34 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 29 Sep 2015 10:10:53 +0200
irqchip/gicv3-its: Add range check for number of allocated pages
The number of pages for the its table may exceed the maximum of 256.
Adding a range check and limitting the number to its maximum.
Based on a patch from Tirumalesh Chalamarla .
Signed-off-by: Tirumalesh Chalamarla
Signed-off-by: Robert Richter
Reviewed-by: Marc Zyngier
Acked-by: Catalin Marinas
Cc: linux-arm-ker...@lists.infradead.org
Cc: Jason Cooper
Link: http://lkml.kernel.org/r/1442869119-1814-2-git-send-email-r...@kernel.org
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/irq-gic-v3-its.c | 11 ++-
include/linux/irqchip/arm-gic-v3.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index ac7ae2b..d9052fd 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -822,6 +822,7 @@ static int its_alloc_tables(const char *node_name, struct
its_node *its)
u64 entry_size = GITS_BASER_ENTRY_SIZE(val);
int order = get_order(psz);
int alloc_size;
+ int alloc_pages;
u64 tmp;
void *base;
@@ -856,6 +857,14 @@ static int its_alloc_tables(const char *node_name, struct
its_node *its)
}
alloc_size = (1 << order) * PAGE_SIZE;
+ alloc_pages = (alloc_size / psz);
+ if (alloc_pages > GITS_BASER_PAGES_MAX) {
+ alloc_pages = GITS_BASER_PAGES_MAX;
+ order = get_order(GITS_BASER_PAGES_MAX * psz);
+ pr_warn("%s: Device Table too large, reduce its page
order to %u (%u pages)\n",
+ node_name, order, alloc_pages);
+ }
+
base = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
if (!base) {
err = -ENOMEM;
@@ -884,7 +893,7 @@ retry_baser:
break;
}
- val |= (alloc_size / psz) - 1;
+ val |= alloc_pages - 1;
writeq_relaxed(val, its->base + GITS_BASER + i * 8);
tmp = readq_relaxed(its->base + GITS_BASER + i * 8);
diff --git a/include/linux/irqchip/arm-gic-v3.h
b/include/linux/irqchip/arm-gic-v3.h
index 9eeeb95..c0c8a2e 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -231,6 +231,7 @@
#define GITS_BASER_PAGE_SIZE_16K (1UL << GITS_BASER_PAGE_SIZE_SHIFT)
#define GITS_BASER_PAGE_SIZE_64K (2UL << GITS_BASER_PAGE_SIZE_SHIFT)
#define GITS_BASER_PAGE_SIZE_MASK (3UL << GITS_BASER_PAGE_SIZE_SHIFT)
+#define GITS_BASER_PAGES_MAX 256
#define GITS_BASER_TYPE_NONE 0
#define GITS_BASER_TYPE_DEVICE 1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:irq/core] irqchip/gicv3-its: Read typer register outside the loop
Commit-ID: c14e36733b8a63894db9ca0b486ce14299ef2fda
Gitweb: http://git.kernel.org/tip/c14e36733b8a63894db9ca0b486ce14299ef2fda
Author: Robert Richter
AuthorDate: Mon, 21 Sep 2015 22:58:36 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 29 Sep 2015 10:10:53 +0200
irqchip/gicv3-its: Read typer register outside the loop
No need to read the typer register in the loop. Values do not change.
This patch is basically a prerequisite for a follow-on patch that adds
errata code for Cavium ThunderX. It moves the calculation of the
number of id entries to the beginning of the function close to other
setup values that are needed to allocate the its table. Now we have a
central location to modify the setup parameters and the errata code
can be implemented in a single block.
Signed-off-by: Robert Richter
Acked-by: Marc Zyngier
Acked-by: Catalin Marinas
Cc: Tirumalesh Chalamarla
Cc: linux-arm-ker...@lists.infradead.org
Cc: Jason Cooper
Link: http://lkml.kernel.org/r/1442869119-1814-4-git-send-email-r...@kernel.org
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/irq-gic-v3-its.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index d9052fd..549e716 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -815,6 +815,8 @@ static int its_alloc_tables(const char *node_name, struct
its_node *its)
int psz = SZ_64K;
u64 shr = GITS_BASER_InnerShareable;
u64 cache = GITS_BASER_WaWb;
+ u64 typer = readq_relaxed(its->base + GITS_TYPER);
+ u32 ids = GITS_TYPER_DEVBITS(typer);
for (i = 0; i < GITS_BASER_NR_REGS; i++) {
u64 val = readq_relaxed(its->base + GITS_BASER + i * 8);
@@ -838,9 +840,6 @@ static int its_alloc_tables(const char *node_name, struct
its_node *its)
* For other tables, only allocate a single page.
*/
if (type == GITS_BASER_TYPE_DEVICE) {
- u64 typer = readq_relaxed(its->base + GITS_TYPER);
- u32 ids = GITS_TYPER_DEVBITS(typer);
-
/*
* 'order' was initialized earlier to the default page
* granule of the the ITS. We can't have an allocation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:irq/core] irqchip/gicv3-its: Add HW revision detection and configuration
Commit-ID: 67510ccafb9d69e79079b5cd6c9959025bc02061
Gitweb: http://git.kernel.org/tip/67510ccafb9d69e79079b5cd6c9959025bc02061
Author: Robert Richter
AuthorDate: Mon, 21 Sep 2015 22:58:37 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 29 Sep 2015 10:10:53 +0200
irqchip/gicv3-its: Add HW revision detection and configuration
Some GIC revisions require an individual configuration to esp. add
workarounds for HW bugs. This patch implements generic code to parse
the hw revision provided by an IIDR register value and runs specific
code if hw matches. A function is added that reads the IIDR registers
for ITS (GITS_IIDR) and then goes through a list of init functions to
be called for specific versions. Same could be done for GICV3
(GICD_IIDR), but there are no users yet for it.
The patch is needed to implement workarounds for HW errata in Cavium's
ThunderX GICV3 ITS.
Signed-off-by: Robert Richter
Reviewed-by: Marc Zygnier
Acked-by: Catalin Marinas
Cc: Tirumalesh Chalamarla
Cc: linux-arm-ker...@lists.infradead.org
Cc: Jason Cooper
Link: http://lkml.kernel.org/r/1442869119-1814-5-git-send-email-r...@kernel.org
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/irq-gic-common.c | 11 +++
drivers/irqchip/irq-gic-common.h | 9 +
drivers/irqchip/irq-gic-v3-its.c | 16
3 files changed, 36 insertions(+)
diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index 9448e39..44a077f 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic-common.c
@@ -21,6 +21,17 @@
#include "irq-gic-common.h"
+void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
+ void *data)
+{
+ for (; quirks->desc; quirks++) {
+ if (quirks->iidr != (quirks->mask & iidr))
+ continue;
+ quirks->init(data);
+ pr_info("GIC: enabling workaround for %s\n", quirks->desc);
+ }
+}
+
int gic_configure_irq(unsigned int irq, unsigned int type,
void __iomem *base, void (*sync_access)(void))
{
diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
index 35a9884..fff697d 100644
--- a/drivers/irqchip/irq-gic-common.h
+++ b/drivers/irqchip/irq-gic-common.h
@@ -20,10 +20,19 @@
#include
#include
+struct gic_quirk {
+ const char *desc;
+ void (*init)(void *data);
+ u32 iidr;
+ u32 mask;
+};
+
int gic_configure_irq(unsigned int irq, unsigned int type,
void __iomem *base, void (*sync_access)(void));
void gic_dist_config(void __iomem *base, int gic_irqs,
void (*sync_access)(void));
void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
+void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
+ void *data);
#endif /* _IRQ_GIC_COMMON_H */
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 549e716..82622af 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -37,6 +37,8 @@
#include
#include
+#include "irq-gic-common.h"
+
#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1 << 0)
#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
@@ -1375,6 +1377,18 @@ static int its_force_quiescent(void __iomem *base)
}
}
+static const struct gic_quirk its_quirks[] = {
+ {
+ }
+};
+
+static void its_enable_quirks(struct its_node *its)
+{
+ u32 iidr = readl_relaxed(its->base + GITS_IIDR);
+
+ gic_enable_quirks(iidr, its_quirks, its);
+}
+
static int its_probe(struct device_node *node, struct irq_domain *parent)
{
struct resource res;
@@ -1433,6 +1447,8 @@ static int its_probe(struct device_node *node, struct
irq_domain *parent)
}
its->cmd_write = its->cmd_base;
+ its_enable_quirks(its);
+
err = its_alloc_tables(node->full_name, its);
if (err)
goto out_free_cmd;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:irq/core] irqchip/gicv3: Workaround for Cavium ThunderX erratum 23154
Commit-ID: 6d4e11c5e2e8cd54a035ba395bf8ccfa7e22cfd8
Gitweb: http://git.kernel.org/tip/6d4e11c5e2e8cd54a035ba395bf8ccfa7e22cfd8
Author: Robert Richter
AuthorDate: Mon, 21 Sep 2015 22:58:35 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 29 Sep 2015 10:10:53 +0200
irqchip/gicv3: Workaround for Cavium ThunderX erratum 23154
This patch implements Cavium ThunderX erratum 23154.
The gicv3 of ThunderX requires a modified version for reading the IAR
status to ensure data synchronization. Since this is in the fast-path
and called with each interrupt, runtime patching is used using jump
label patching for smallest overhead (no-op). This is the same
technique as used for tracepoints.
Signed-off-by: Robert Richter
Reviewed-by: Marc Zygnier
Acked-by: Catalin Marinas
Cc: Tirumalesh Chalamarla
Cc: linux-arm-ker...@lists.infradead.org
Cc: Jason Cooper
Cc: Will Deacon
Link: http://lkml.kernel.org/r/1442869119-1814-3-git-send-email-r...@kernel.org
Signed-off-by: Thomas Gleixner
---
arch/arm64/Kconfig | 10 +
arch/arm64/include/asm/cpufeature.h | 3 ++-
arch/arm64/include/asm/cputype.h| 17 ---
arch/arm64/kernel/cpu_errata.c | 9
drivers/irqchip/irq-gic-v3.c| 42 -
5 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 07d1811..490df44 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -348,6 +348,16 @@ config ARM64_ERRATUM_843419
If unsure, say Y.
+config CAVIUM_ERRATUM_23154
+ bool "Cavium erratum 23154: Access to ICC_IAR1_EL1 is not sync'ed"
+ default y
+ help
+ The gicv3 of ThunderX requires a modified version for
+ reading the IAR status to ensure data synchronization
+ (access to icc_iar1_el1 is not sync'ed before and after).
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 1715707..dbc78d2 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -27,8 +27,9 @@
#define ARM64_HAS_SYSREG_GIC_CPUIF 3
#define ARM64_HAS_PAN 4
#define ARM64_HAS_LSE_ATOMICS 5
+#define ARM64_WORKAROUND_CAVIUM_23154 6
-#define ARM64_NCAPS6
+#define ARM64_NCAPS7
#ifndef __ASSEMBLY__
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index ee6403d..100a3d1 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -62,15 +62,18 @@
(0xf<< MIDR_ARCHITECTURE_SHIFT) | \
((partnum) << MIDR_PARTNUM_SHIFT))
-#define ARM_CPU_IMP_ARM0x41
-#define ARM_CPU_IMP_APM0x50
+#define ARM_CPU_IMP_ARM0x41
+#define ARM_CPU_IMP_APM0x50
+#define ARM_CPU_IMP_CAVIUM 0x43
-#define ARM_CPU_PART_AEM_V80xD0F
-#define ARM_CPU_PART_FOUNDATION0xD00
-#define ARM_CPU_PART_CORTEX_A570xD07
-#define ARM_CPU_PART_CORTEX_A530xD03
+#define ARM_CPU_PART_AEM_V80xD0F
+#define ARM_CPU_PART_FOUNDATION0xD00
+#define ARM_CPU_PART_CORTEX_A570xD07
+#define ARM_CPU_PART_CORTEX_A530xD03
-#define APM_CPU_PART_POTENZA 0x000
+#define APM_CPU_PART_POTENZA 0x000
+
+#define CAVIUM_CPU_PART_THUNDERX 0x0A1
#define ID_AA64MMFR0_BIGENDEL0_SHIFT 16
#define ID_AA64MMFR0_BIGENDEL0_MASK(0xf << ID_AA64MMFR0_BIGENDEL0_SHIFT)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 6ffd914..574450c 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -23,6 +23,7 @@
#define MIDR_CORTEX_A53 MIDR_CPU_PART(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_PART(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
+#define MIDR_THUNDERX MIDR_CPU_PART(ARM_CPU_IMP_CAVIUM,
CAVIUM_CPU_PART_THUNDERX)
#define CPU_MODEL_MASK (MIDR_IMPLEMENTOR_MASK | MIDR_PARTNUM_MASK | \
MIDR_ARCHITECTURE_MASK)
@@ -82,6 +83,14 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
MIDR_RANGE(MIDR_CORTEX_A53, 0x00, 0x04),
},
#endif
+#ifdef CONFIG_CAVIUM_ERRATUM_23154
+ {
+ /* Cavium ThunderX, pass 1.x */
+ .desc = "Cavium erratum 23154",
+ .capability = ARM64_WORKAROUND_CAVIUM_23154,
+ MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
+ },
+#endif
{
}
};
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 36ecfc8..eecec71 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -109,7 +109,7 @@ static void gic_redist_wait_for_rwp(void)
}
/* Low level accessors */
-static u64 __maybe_unus
[tip:irq/core] irqchip/gicv3-its: Use new jump label API
Commit-ID: 8ac2a1704a9f315d490ca1050b8fe8367644e675
Gitweb: http://git.kernel.org/tip/8ac2a1704a9f315d490ca1050b8fe8367644e675
Author: Robert Richter
AuthorDate: Mon, 21 Sep 2015 22:58:39 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 29 Sep 2015 10:10:54 +0200
irqchip/gicv3-its: Use new jump label API
Use newly introduced jump label API.
Make this a separate patch for easier backporting to older kernels of
the errata patch set.
Signed-off-by: Robert Richter
Reviewed-by: Marc Zygnier
Acked-by: Catalin Marinas
Cc: Tirumalesh Chalamarla
Cc: linux-arm-ker...@lists.infradead.org
Cc: Jason Cooper
Link: http://lkml.kernel.org/r/1442869119-1814-7-git-send-email-r...@kernel.org
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/irq-gic-v3.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index eecec71..149e3c6 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -139,11 +139,11 @@ static u64 gic_read_iar_cavium_thunderx(void)
return irqstat;
}
-static struct static_key is_cavium_thunderx = STATIC_KEY_INIT_FALSE;
+static DEFINE_STATIC_KEY_FALSE(is_cavium_thunderx);
static u64 __maybe_unused gic_read_iar(void)
{
- if (static_key_false(&is_cavium_thunderx))
+ if (static_branch_unlikely(&is_cavium_thunderx))
return gic_read_iar_cavium_thunderx();
else
return gic_read_iar_common();
@@ -871,7 +871,7 @@ static const struct irq_domain_ops gic_irq_domain_ops = {
static void gicv3_enable_quirks(void)
{
if (cpus_have_cap(ARM64_WORKAROUND_CAVIUM_23154))
- static_key_slow_inc(&is_cavium_thunderx);
+ static_branch_enable(&is_cavium_thunderx);
}
static int __init gic_of_init(struct device_node *node, struct device_node
*parent)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/25] perf callchain: Allow for max_stack greater than PERF_MAX_STACK_DEPTH
On 28/09/15 23:08, Arnaldo Carvalho de Melo wrote:
> Em Fri, Sep 25, 2015 at 04:15:48PM +0300, Adrian Hunter escreveu:
>> Adjust the validation to allow for max_stack greater than
>> PERF_MAX_STACK_DEPTH.
>>
>> Signed-off-by: Adrian Hunter
>> ---
>> tools/perf/util/machine.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
>> index fd1efeafb343..d7bd9a304535 100644
>> --- a/tools/perf/util/machine.c
>> +++ b/tools/perf/util/machine.c
>> @@ -1831,7 +1831,7 @@ static int thread__resolve_callchain_sample(struct
>> thread *thread,
>> }
>>
>> check_calls:
>> -if (chain->nr > PERF_MAX_STACK_DEPTH) {
>> +if (chain->nr > PERF_MAX_STACK_DEPTH && (int)chain->nr > max_stack) {
>
> Both?
Yes.
In the case of a hardware generated callchain, the callchain can be up to
PERF_MAX_STACK_DEPTH but max_stack can be less than PERF_MAX_STACK_DEPTH to
limit the number processed.
In the case of a synthesized callchain, the callchain can be up to max_stack
which might be more than PERF_MAX_STACK_DEPTH.
>
>> pr_warning("corrupted callchain. skipping...\n");
>> return 0;
>> }
>> --
>> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:irq/core] irqchip/gicv3-its: Workaround for Cavium ThunderX errata 22375, 24313
Commit-ID: 94100970743365a9f9e186520e77ef56c492058d
Gitweb: http://git.kernel.org/tip/94100970743365a9f9e186520e77ef56c492058d
Author: Robert Richter
AuthorDate: Mon, 21 Sep 2015 22:58:38 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 29 Sep 2015 10:10:54 +0200
irqchip/gicv3-its: Workaround for Cavium ThunderX errata 22375, 24313
This implements two gicv3-its errata workarounds for ThunderX. Both
with small impact affecting only ITS table allocation.
erratum 22375: only alloc 8MB table size
erratum 24313: ignore memory access type
The fixes are in ITS initialization and basically ignore memory access
type and table size provided by the TYPER and BASER registers.
Signed-off-by: Ganapatrao Kulkarni
Signed-off-by: Robert Richter
Reviewed-by: Marc Zygnier
Acked-by: Catalin Marinas
Cc: Tirumalesh Chalamarla
Cc: linux-arm-ker...@lists.infradead.org
Cc: Jason Cooper
Cc: Will Deacon
Link: http://lkml.kernel.org/r/1442869119-1814-6-git-send-email-r...@kernel.org
Signed-off-by: Thomas Gleixner
---
arch/arm64/Kconfig | 17 +
drivers/irqchip/irq-gic-v3-its.c | 37 +
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 490df44..440d906 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -348,6 +348,23 @@ config ARM64_ERRATUM_843419
If unsure, say Y.
+config CAVIUM_ERRATUM_22375
+ bool "Cavium erratum 22375, 24313"
+ default y
+ help
+ Enable workaround for erratum 22375, 24313.
+
+ This implements two gicv3-its errata workarounds for ThunderX. Both
+ with small impact affecting only ITS table allocation.
+
+ erratum 22375: only alloc 8MB table size
+ erratum 24313: ignore memory access type
+
+ The fixes are in ITS initialization and basically ignore memory access
+ type and table size provided by the TYPER and BASER registers.
+
+ If unsure, say Y.
+
config CAVIUM_ERRATUM_23154
bool "Cavium erratum 23154: Access to ICC_IAR1_EL1 is not sync'ed"
default y
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 82622af..eac44dd 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -39,7 +39,8 @@
#include "irq-gic-common.h"
-#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1 << 0)
+#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
+#define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
@@ -816,9 +817,22 @@ static int its_alloc_tables(const char *node_name, struct
its_node *its)
int i;
int psz = SZ_64K;
u64 shr = GITS_BASER_InnerShareable;
- u64 cache = GITS_BASER_WaWb;
- u64 typer = readq_relaxed(its->base + GITS_TYPER);
- u32 ids = GITS_TYPER_DEVBITS(typer);
+ u64 cache;
+ u64 typer;
+ u32 ids;
+
+ if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_22375) {
+ /*
+* erratum 22375: only alloc 8MB table size
+* erratum 24313: ignore memory access type
+*/
+ cache = 0;
+ ids = 0x14; /* 20 bits, 8MB */
+ } else {
+ cache = GITS_BASER_WaWb;
+ typer = readq_relaxed(its->base + GITS_TYPER);
+ ids = GITS_TYPER_DEVBITS(typer);
+ }
for (i = 0; i < GITS_BASER_NR_REGS; i++) {
u64 val = readq_relaxed(its->base + GITS_BASER + i * 8);
@@ -1377,7 +1391,22 @@ static int its_force_quiescent(void __iomem *base)
}
}
+static void __maybe_unused its_enable_quirk_cavium_22375(void *data)
+{
+ struct its_node *its = data;
+
+ its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_22375;
+}
+
static const struct gic_quirk its_quirks[] = {
+#ifdef CONFIG_CAVIUM_ERRATUM_22375
+ {
+ .desc = "ITS: Cavium errata 22375, 24313",
+ .iidr = 0xa100034c, /* ThunderX pass 1.x */
+ .mask = 0x0fff,
+ .init = its_enable_quirk_cavium_22375,
+ },
+#endif
{
}
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v4.2+ regression] fd7a4bed sched, rt: Convert switched_{from, to}_rt() / prio_changed_rt() to balance callbacks
On Mon, 2015-09-28 at 04:17 +0200, Mike Galbraith wrote: > Hi Peter, > > I bumped into an odd futextest regression, and finally bisected it to > $subject. I haven't poked at it yet, chasing down and confirming the > little bugger munched the day. homer:/home/git/futextest/functional # ./futex_requeue_pi -c -b -o -t 50 -v 2 2>&1|egrep 'exit|Blocker' INFO: Waiter 0: exiting with 0 INFO: Waiter 1: exiting with 0 INFO: Waiter 2: exiting with 0 INFO: Waiter 3: exiting with 0 INFO: Waiter 4: exiting with 0 INFO: Waiter 5: exiting with 0 INFO: Waiter 6: exiting with 0 INFO: Waiter 7: exiting with 0 INFO: Waiter 8: exiting with 0 INFO: Waiter 9: exiting with 0 INFO: Waker: exiting with 0 INFO: Blocker: Calling futex_wait() Well now, it _seems_ you're innocent Peter. Waker can call futex_wake() before blocker calls futex_wait(), leaving poor blocker stranded. Adding atomic_inc(&waiters_blocked) to blocker, and telling wakers to expect one more when a blocker exists seems to have fixed it up. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:perf/core] tools: Add err.h with ERR_PTR PTR_ERR interface
On 2015/9/29 15:57, Jiri Olsa wrote: On Tue, Sep 29, 2015 at 03:52:09PM +0800, He Kuang wrote: hi, jirka On 2015/9/29 15:20, Jiri Olsa wrote: On Tue, Sep 29, 2015 at 09:14:10AM +0200, Jiri Olsa wrote: SNIP $ gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Cheers, Vinson Hi. This build error still occurs with next-20150929. attached patch should fix it FYI there's another instance of this bug in parse-events.c in Arnaldo's perf/core due to recent fixes, I'll send out fix shortly and here it is.. He Kuang, this might collide with your recent fixes.. Do I need to send new ones based on your patch below now? that'd be great.. also please make sure you don't reintroduce it I saw Ingo just accepted ACME's pull request which contains my patches, then resend may reintroduce or conflict things, I will wait for ACME's suggestion for my lack of experience in this. Thank you. thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No more new fbdev drivers, please
On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote: > On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > As Daniel mentioned, the connector+encoder+crtc combination is one of > > > those simplifications that would make sense if more such drivers are > > > added. > > > > Another one is memory management. It's pretty complex because it can > > handle _way_ more than what simple drivers need, and the result is > > _alot_ of ttm boilerplate in the drivers. > > ttm is pretty impressive overkill for most simplistic drm drivers. If you > just need contiguous framebuffers for display then the cma helpers should > take care of pretty much all the boilerplate for you. They have ready-made > simple gem and dumb framebuffer mmap support, which is all a basic kms > driver needs. Does that work on !arm meanwhile? Last time I checked (when writing bochsdrm, around v3.14) the cma helpers didn't even build on x86 ... cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/9] watchdog: Introduce hardware maximum timeout in watchdog core
Introduce an optional hardware maximum timeout in the watchdog core.
The hardware maximum timeout can be lower than the maximum timeout.
Drivers can set the maximum hardware timeout value in the watchdog data
structure. If the configured timeout exceeds the maximum hardware timeout,
the watchdog core enables a timer function to assist sending keepalive
requests to the watchdog driver.
Cc: Timo Kokkonen
Signed-off-by: Guenter Roeck
---
v4:
- Improved and fixed documentation
- Split hw_timeout_ms variable to timeout_ms, hw_timeout_ms for clarity
- Dropped redundant comments
- Added comments explaining failure conditions in watchdog_timeout_invalid().
- Moved the call to watchdog_update_worker() into _watchdog_ping().
v3:
- Reworked and cleaned up some of the functions.
- No longer call the worker update function if all that is needed is to stop
the worker.
- max_timeout will now be ignored if max_hw_timeout_ms is provided.
v2:
- Improved and hopefully clarified documentation.
- Rearranged variables in struct watchdog_device such that internal variables
come last.
- The code now ensures that the watchdog times out seconds after
the most recent keepalive sent from user space.
- The internal keepalive now stops silently and no longer generates a
warning message. Reason is that it will now stop early, while there
may still be a substantial amount of time for keepalives from user space
to arrive. If such keepalives arrive late (for example if user space
is configured to send keepalives just a few seconds before the watchdog
times out), the message would just be noise and not provide any value.
---
Documentation/watchdog/watchdog-kernel-api.txt | 28 -
drivers/watchdog/watchdog_dev.c| 135 ++---
include/linux/watchdog.h | 44 +---
3 files changed, 175 insertions(+), 32 deletions(-)
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt
b/Documentation/watchdog/watchdog-kernel-api.txt
index d8b0d3367706..f66859117d1f 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -53,9 +53,12 @@ struct watchdog_device {
unsigned int timeout;
unsigned int min_timeout;
unsigned int max_timeout;
+ unsigned int max_hw_timeout_ms;
void *driver_data;
- struct mutex lock;
unsigned long status;
+ struct mutex lock;
+ unsigned long last_keepalive;
+ struct delayed_work work;
struct list_head deferred;
};
@@ -73,18 +76,31 @@ It contains following fields:
additional information about the watchdog timer itself. (Like it's unique
name)
* ops: a pointer to the list of watchdog operations that the watchdog supports.
* timeout: the watchdog timer's timeout value (in seconds).
+ This is the time after which the system will reboot if user space does
+ not send a heartbeat request if WDOG_ACTIVE is set.
* min_timeout: the watchdog timer's minimum timeout value (in seconds).
-* max_timeout: the watchdog timer's maximum timeout value (in seconds).
+ If set, the minimum configurable value for 'timeout'.
+* max_timeout: the watchdog timer's maximum timeout value (in seconds),
+ as seen from userspace. If set, the maximum configurable value for
+ 'timeout'. Not used if max_hw_timeout_ms is non-zero.
+* max_hw_timeout_ms: Maximum hardware timeout, in milli-seconds.
+ If set, the infrastructure will send heartbeats to the watchdog driver
+ if 'timeout' is larger than max_hw_timeout, unless WDOG_ACTIVE
+ is set and userspace failed to send a heartbeat for at least 'timeout'
+ seconds.
* bootstatus: status of the device after booting (reported with watchdog
WDIOF_* status bits).
* driver_data: a pointer to the drivers private data of a watchdog device.
This data should only be accessed via the watchdog_set_drvdata and
watchdog_get_drvdata routines.
-* lock: Mutex for WatchDog Timer Driver Core internal use only.
* status: this field contains a number of status bits that give extra
information about the status of the device (Like: is the watchdog timer
running/active, is the nowayout bit set, is the device opened via
the /dev/watchdog interface or not, ...).
+* lock: Mutex for WatchDog Timer Driver Core internal use only.
+* last_keepalive: Time of most recent keepalive triggered from user space,
+ in jiffies.
+* work: Worker data structure for WatchDog Timer Driver Core internal use only.
* deferred: entry in wtd_deferred_reg_list which is used to
register early initialized watchdogs.
@@ -160,7 +176,11 @@ they are supported. These optional routines/operations are:
and -EIO for "could not write value to the watchdog". On success this
routine should set the timeout value of the watchdog_device to the
achieved timeout value (which may be different from the requested one
- because the watchdog does not necessarily has a 1 second resolution).
+ because the watchdog do
[PATCH v4 1/9] watchdog: Always evaluate new timeout against min_timeout
Up to now, a new timeout value is only evaluated against min_timeout
if max_timeout is provided. This does not really make sense; a driver
can have a minimum timeout even if it does not have a maximum timeout.
Ensure that it is not smaller than min_timeout, even if max_timeout
is not set.
Signed-off-by: Guenter Roeck
---
v4: Now first patch of series.
Added comments.
v3: New patch.
---
include/linux/watchdog.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index d74a0e907b9e..e90e3ea5ebeb 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -119,8 +119,15 @@ static inline void watchdog_set_nowayout(struct
watchdog_device *wdd, bool noway
/* Use the following function to check if a timeout value is invalid */
static inline bool watchdog_timeout_invalid(struct watchdog_device *wdd,
unsigned int t)
{
- return ((wdd->max_timeout != 0) &&
- (t < wdd->min_timeout || t > wdd->max_timeout));
+ /*
+* The timeout is invalid if
+* - the requested value is smaller than the configured minimum timeout,
+* or
+* - a maximum timeout is configured, and the requested value is larger
+* than the maximum timeout.
+*/
+ return t < wdd->min_timeout ||
+ (wdd->max_timeout && t > wdd->max_timeout);
}
/* Use the following functions to manipulate watchdog driver specific data */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/9] watchdog: Add support for keepalives triggered by infrastructure
The watchdog infrastructure is currently purely passive, meaning it only passes information from user space to drivers and vice versa. Since watchdog hardware tends to have its own quirks, this can result in quite complex watchdog drivers. A number of scanarios are especially common. - A watchdog is always active and can not be disabled, or can not be disabled once enabled. To support such hardware, watchdog drivers have to implement their own timers and use those timers to trigger watchdog keepalives while the watchdog device is not or not yet opened. - A variant of this is the desire to enable a watchdog as soon as its driver has been instantiated, to protect the system while it is still booting up, but the watchdog daemon is not yet running. - Some watchdogs have a very short maximum timeout, in the range of just a few seconds. Such low timeouts are difficult if not impossible to support from user space. Drivers supporting such watchdog hardware need to implement a timer function to augment heartbeats from user space. This patch set solves the above problems while keeping changes to the watchdog core minimal. - A new status flag, WDOG_RUNNING, informs the watchdog subsystem that a watchdog is running, and that the watchdog subsystem needs to generate heartbeat requests while the associated watchdog device is closed. - A new parameter in the watchdog data structure, max_hw_timeout_ms, informs the watchdog subsystem about a maximum hardware timeout. The watchdog subsystem uses this information together with the configured timeout and the maximum permitted timeout to determine if it needs to generate additional heartbeat requests. As part of this patchset, the semantics of the 'timeout' variable and of the WDOG_ACTIVE flag are changed slightly. Per the current watchdog kernel API, the 'timeout' variable is supposed to reflect the actual hardware watcdog timeout. WDOG_ACTIVE is supposed to reflect if the hardware watchdog is running or not. Unfortunately, this does not always reflect reality. In drivers which solve the above mentioned problems internally, 'timeout' is the watchdog timeout as seen from user space, and WDOG_ACTIVE reflects that user space is expected to send keepalive requests to the watchdog driver. After this patch set is applied, this so far inofficial interpretation is the 'official' semantics for the timeout variable and the WDOG_ACTIVE flag. In other words, both values no longer reflect the hardware watchdog status, but its status as seen from user space. Patch #1 and #2 are preparatory patches. Patch #3 adds timer functionality to the watchdog core. It solves the problem of short maximum hardware timeouts by augmenting heartbeats triggered from user space with internally triggered heartbeats. Patch #4 adds functionality to generate heartbeats while the watchdog device is closed. It handles situation where where the watchdog is running after the driver has been instantiated, but the device is not yet opened, and post-close situations necessary if a watchdog can not be stopped. Patch #5 makes the set_timeout function optional. This is now possible since timeout changes can now be completely handled in the watchdog core, for example if the hardware watchdog timeout is fixed. Patch #6 to #8 are example conversions of some watchdog drivers. Those patches will require testing. Patch #9 adds code to unconditionally ensure that the minimum timeout meets constraints provided by the watchdog driver. The patch set is also available in branch watchdog-timer of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git. This patch set does not solve all limitations of the watchdog subsystem. Specifically, it does not add support for the following features. - It is desirable to be able to specify a maximum early timeout, from booting the system to opening the watchdog device. This and other features will be addressed with subsequent patches. It may be possible to simplify the watchdog_update_worker() function to not require the 'cancel' argument. This is left for further study. The patch set is inspired by an earlier patch set from Timo Kokonnen. v4: - Rebased to v4.3-rc3 - Rearranged patch sequence - Dropped gpio driver patch. The driver was changed since v4.2, and merging the changes turned out to be too difficult. - Various other cleanups as listed in individual patches v3: - Rebased to v4.2-rc8 - Reworked and cleaned up some of the functions. - No longer call the worker update function if all that is needed is to stop the worker. - max_timeout will now be ignored if max_hw_timeout_ms is provided. - Added patch 9/9. v2: - Rebased to v4.2-rc5 - Improved and hopefully clarified documentation. - Rearranged variables in struct watchdog_device such that internal variables come last. - The code now ensures that the watchdog times out seconds after the most recent keepalive sent from user space. - The internal keepalive now stops si
[PATCH v4 5/9] watchdog: Make set_timeout function optional
For some watchdogs, the hardware timeout is fixed, and the
watchdog driver depends on the watchdog core to handle the
actual timeout. In this situation, the watchdog driver might
only set the 'timeout' variable but do nothing else.
This can as well be handled by the infrastructure, so make
the set_timeout callback optional. If WDIOF_SETTIMEOUT is
configured but the .set_timeout callback is not available,
update the timeout variable in the infrastructure code.
Acked-by: Uwe Kleine-König
Signed-off-by: Guenter Roeck
---
v3: No changes
v2: No changes
---
Documentation/watchdog/watchdog-kernel-api.txt | 5 +
drivers/watchdog/watchdog_dev.c| 9 ++---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt
b/Documentation/watchdog/watchdog-kernel-api.txt
index 3f0963b2c33e..f480a9355b43 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -184,6 +184,11 @@ they are supported. These optional routines/operations are:
(if it is larger than hw_max_timeout_ms), or to the achieved timeout value.
(Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the
watchdog's info structure).
+ If the watchdog driver does not have to perform any action but setting the
+ watchdog_device.timeout, this callback can be omitted.
+ If set_timeout is not provided but, WDIOF_SETTIMEOUT is set, the watchdog
+ infrastructure updates the timeout value of the watchdog_device internally
+ to the requested value.
* get_timeleft: this routines returns the time that's left before a reset.
* ref: the operation that calls kref_get on the kref of a dynamically
allocated watchdog_device struct.
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 80449c8bc966..b590611b176a 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -282,9 +282,9 @@ out_status:
static int watchdog_set_timeout(struct watchdog_device *wdd,
unsigned int timeout)
{
- int err;
+ int err = 0;
- if (!wdd->ops->set_timeout || !(wdd->info->options & WDIOF_SETTIMEOUT))
+ if (!(wdd->info->options & WDIOF_SETTIMEOUT))
return -EOPNOTSUPP;
if (watchdog_timeout_invalid(wdd, timeout))
@@ -297,7 +297,10 @@ static int watchdog_set_timeout(struct watchdog_device
*wdd,
goto out_timeout;
}
- err = wdd->ops->set_timeout(wdd, timeout);
+ if (wdd->ops->set_timeout)
+ err = wdd->ops->set_timeout(wdd, timeout);
+ else
+ wdd->timeout = timeout;
watchdog_update_worker(wdd, true);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/9] watchdog: watchdog_dev: Use single variable name for struct watchdog_device
The current code uses 'wdd', wddev', and 'watchdog' as variable names
for struct watchdog_device. This is confusing and makes it difficult
to enhance the code. Replace it all with 'wdd'.
Cc: Timo Kokkonen
Acked-by: Uwe Kleine-König
Signed-off-by: Guenter Roeck
---
v2: No changes
---
drivers/watchdog/watchdog_dev.c | 151
1 file changed, 75 insertions(+), 76 deletions(-)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefbad303e..06171c73daf5 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -51,7 +51,7 @@ static struct watchdog_device *old_wdd;
/*
* watchdog_ping: ping the watchdog.
- * @wddev: the watchdog device to ping
+ * @wdd: the watchdog device to ping
*
* If the watchdog has no own ping operation then it needs to be
* restarted via the start operation. This wrapper function does
@@ -59,65 +59,65 @@ static struct watchdog_device *old_wdd;
* We only ping when the watchdog device is running.
*/
-static int watchdog_ping(struct watchdog_device *wddev)
+static int watchdog_ping(struct watchdog_device *wdd)
{
int err = 0;
- mutex_lock(&wddev->lock);
+ mutex_lock(&wdd->lock);
- if (test_bit(WDOG_UNREGISTERED, &wddev->status)) {
+ if (test_bit(WDOG_UNREGISTERED, &wdd->status)) {
err = -ENODEV;
goto out_ping;
}
- if (!watchdog_active(wddev))
+ if (!watchdog_active(wdd))
goto out_ping;
- if (wddev->ops->ping)
- err = wddev->ops->ping(wddev); /* ping the watchdog */
+ if (wdd->ops->ping)
+ err = wdd->ops->ping(wdd); /* ping the watchdog */
else
- err = wddev->ops->start(wddev); /* restart watchdog */
+ err = wdd->ops->start(wdd); /* restart watchdog */
out_ping:
- mutex_unlock(&wddev->lock);
+ mutex_unlock(&wdd->lock);
return err;
}
/*
* watchdog_start: wrapper to start the watchdog.
- * @wddev: the watchdog device to start
+ * @wdd: the watchdog device to start
*
* Start the watchdog if it is not active and mark it active.
* This function returns zero on success or a negative errno code for
* failure.
*/
-static int watchdog_start(struct watchdog_device *wddev)
+static int watchdog_start(struct watchdog_device *wdd)
{
int err = 0;
- mutex_lock(&wddev->lock);
+ mutex_lock(&wdd->lock);
- if (test_bit(WDOG_UNREGISTERED, &wddev->status)) {
+ if (test_bit(WDOG_UNREGISTERED, &wdd->status)) {
err = -ENODEV;
goto out_start;
}
- if (watchdog_active(wddev))
+ if (watchdog_active(wdd))
goto out_start;
- err = wddev->ops->start(wddev);
+ err = wdd->ops->start(wdd);
if (err == 0)
- set_bit(WDOG_ACTIVE, &wddev->status);
+ set_bit(WDOG_ACTIVE, &wdd->status);
out_start:
- mutex_unlock(&wddev->lock);
+ mutex_unlock(&wdd->lock);
return err;
}
/*
* watchdog_stop: wrapper to stop the watchdog.
- * @wddev: the watchdog device to stop
+ * @wdd: the watchdog device to stop
*
* Stop the watchdog if it is still active and unmark it active.
* This function returns zero on success or a negative errno code for
@@ -125,155 +125,154 @@ out_start:
* If the 'nowayout' feature was set, the watchdog cannot be stopped.
*/
-static int watchdog_stop(struct watchdog_device *wddev)
+static int watchdog_stop(struct watchdog_device *wdd)
{
int err = 0;
- mutex_lock(&wddev->lock);
+ mutex_lock(&wdd->lock);
- if (test_bit(WDOG_UNREGISTERED, &wddev->status)) {
+ if (test_bit(WDOG_UNREGISTERED, &wdd->status)) {
err = -ENODEV;
goto out_stop;
}
- if (!watchdog_active(wddev))
+ if (!watchdog_active(wdd))
goto out_stop;
- if (test_bit(WDOG_NO_WAY_OUT, &wddev->status)) {
- dev_info(wddev->dev, "nowayout prevents watchdog being
stopped!\n");
+ if (test_bit(WDOG_NO_WAY_OUT, &wdd->status)) {
+ dev_info(wdd->dev, "nowayout prevents watchdog being
stopped!\n");
err = -EBUSY;
goto out_stop;
}
- err = wddev->ops->stop(wddev);
+ err = wdd->ops->stop(wdd);
if (err == 0)
- clear_bit(WDOG_ACTIVE, &wddev->status);
+ clear_bit(WDOG_ACTIVE, &wdd->status);
out_stop:
- mutex_unlock(&wddev->lock);
+ mutex_unlock(&wdd->lock);
return err;
}
/*
* watchdog_get_status: wrapper to get the watchdog status
- * @wddev: the watchdog device to get the status from
+ * @wdd: the watchdog device to get the status from
* @status: the status of the watchdog device
*
*
[PATCH v4 4/9] watchdog: Introduce WDOG_RUNNING flag
The WDOG_RUNNING flag is expected to be set by watchdog drivers if the hardware watchdog is running. If the flag is set, the watchdog subsystem will ping the watchdog even if the watchdog device is closed. The watchdog driver stop function is now optional and may be omitted if the watchdog can not be stopped. If stopping the watchdog is not possible but the driver implements a stop function, it is responsible to set the WDOG_RUNNING flag in its stop function. Cc: Timo Kokkonen Signed-off-by: Guenter Roeck --- v3: Clarified meaning of WDOG_ACTIVE. Do not call cancel_delayed_work_sync() from watchdog_update_worker(). Call it directly where needed instead, to keep the common code simple. Do not (re-)start an already running watchdog when opening the watchdog device. Send a heartbeat request instead. v2: Improved documentation. --- Documentation/watchdog/watchdog-kernel-api.txt | 28 +-- drivers/watchdog/watchdog_core.c | 2 +- drivers/watchdog/watchdog_dev.c| 49 +++--- include/linux/watchdog.h | 7 4 files changed, 63 insertions(+), 23 deletions(-) diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt index f66859117d1f..3f0963b2c33e 100644 --- a/Documentation/watchdog/watchdog-kernel-api.txt +++ b/Documentation/watchdog/watchdog-kernel-api.txt @@ -146,17 +146,18 @@ are: device. The routine needs a pointer to the watchdog timer device structure as a parameter. It returns zero on success or a negative errno code for failure. -* stop: with this routine the watchdog timer device is being stopped. - The routine needs a pointer to the watchdog timer device structure as a - parameter. It returns zero on success or a negative errno code for failure. - Some watchdog timer hardware can only be started and not be stopped. The - driver supporting this hardware needs to make sure that a start and stop - routine is being provided. This can be done by using a timer in the driver - that regularly sends a keepalive ping to the watchdog timer hardware. Not all watchdog timer hardware supports the same functionality. That's why all other routines/operations are optional. They only need to be provided if they are supported. These optional routines/operations are: +* stop: with this routine the watchdog timer device is being stopped. + The routine needs a pointer to the watchdog timer device structure as a + parameter. It returns zero on success or a negative errno code for failure. + Some watchdog timer hardware can only be started and not be stopped. A + driver supporting such hardware does not have to implement the stop routine. + If a driver has no stop function, the watchdog core will set WDOG_RUNNING and + start calling the driver's keepalive pings function after the watchdog device + is closed. * ping: this is the routine that sends a keepalive ping to the watchdog timer hardware. The routine needs a pointer to the watchdog timer device structure as a @@ -196,9 +197,8 @@ they are supported. These optional routines/operations are: The status bits should (preferably) be set with the set_bit and clear_bit alike bit-operations. The status bits that are defined are: * WDOG_ACTIVE: this status bit indicates whether or not a watchdog timer device - is active or not. When the watchdog is active after booting, then you should - set this status bit (Note: when you register the watchdog timer device with - this bit set, then opening /dev/watchdog will skip the start operation) + is active or not from user perspective. User space is expected to send + heartbeat requests to the driver while this flag is set. * WDOG_DEV_OPEN: this status bit shows whether or not the watchdog device was opened via /dev/watchdog. (This bit should only be used by the WatchDog Timer Driver Core). @@ -212,6 +212,14 @@ bit-operations. The status bits that are defined are: any watchdog_ops, so that you can be sure that no operations (other then unref) will get called after unregister, even if userspace still holds a reference to /dev/watchdog +* WDOG_RUNNING: Set by the watchdog driver if the hardware watchdog is running. + The bit must be set if the watchdog timer hardware can not be stopped. + The bit may also be set if the watchdog timer is running aftyer booting, + before the watchdog device is opened. If set, the watchdog infrastructure + will send keepalives to the watchdog hardware while WDOG_ACTIVE is not set. + Note: when you register the watchdog timer device with this bit set, + then opening /dev/watchdog will skip the start operation but send a keepalive + request instead. To set the WDOG_NO_WAY_OUT status bit (before registering your watchdog timer device) you can either: diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c index 1a8059455413..b38d1b7ae10e 100644 --- a/drivers/wat
[PATCH v4 6/9] watchdog: imx2: Convert to use infrastructure triggered keepalives
The watchdog infrastructure now supports handling watchdog keepalive
if the watchdog is running while the watchdog device is closed.
Convert the driver to use this infrastructure.
Signed-off-by: Guenter Roeck
---
v3: No changes
v2: No changes
---
drivers/watchdog/imx2_wdt.c | 72 -
1 file changed, 12 insertions(+), 60 deletions(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 0bb1a1d1b170..66feef254661 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -34,7 +33,6 @@
#include
#include
#include
-#include
#include
#define DRIVER_NAME "imx2-wdt"
@@ -62,7 +60,6 @@
struct imx2_wdt_device {
struct clk *clk;
struct regmap *regmap;
- struct timer_list timer;/* Pings the watchdog when closed */
struct watchdog_device wdog;
struct notifier_block restart_handler;
};
@@ -151,16 +148,6 @@ static int imx2_wdt_ping(struct watchdog_device *wdog)
return 0;
}
-static void imx2_wdt_timer_ping(unsigned long arg)
-{
- struct watchdog_device *wdog = (struct watchdog_device *)arg;
- struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
-
- /* ping it every wdog->timeout / 2 seconds to prevent reboot */
- imx2_wdt_ping(wdog);
- mod_timer(&wdev->timer, jiffies + wdog->timeout * HZ / 2);
-}
-
static int imx2_wdt_set_timeout(struct watchdog_device *wdog,
unsigned int new_timeout)
{
@@ -177,40 +164,19 @@ static int imx2_wdt_start(struct watchdog_device *wdog)
{
struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
- if (imx2_wdt_is_running(wdev)) {
- /* delete the timer that pings the watchdog after close */
- del_timer_sync(&wdev->timer);
+ if (imx2_wdt_is_running(wdev))
imx2_wdt_set_timeout(wdog, wdog->timeout);
- } else
+ else
imx2_wdt_setup(wdog);
- return imx2_wdt_ping(wdog);
-}
-
-static int imx2_wdt_stop(struct watchdog_device *wdog)
-{
- /*
-* We don't need a clk_disable, it cannot be disabled once started.
-* We use a timer to ping the watchdog while /dev/watchdog is closed
-*/
- imx2_wdt_timer_ping((unsigned long)wdog);
- return 0;
-}
-
-static inline void imx2_wdt_ping_if_active(struct watchdog_device *wdog)
-{
- struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ set_bit(WDOG_RUNNING, &wdog->status);
- if (imx2_wdt_is_running(wdev)) {
- imx2_wdt_set_timeout(wdog, wdog->timeout);
- imx2_wdt_timer_ping((unsigned long)wdog);
- }
+ return imx2_wdt_ping(wdog);
}
static const struct watchdog_ops imx2_wdt_ops = {
.owner = THIS_MODULE,
.start = imx2_wdt_start,
- .stop = imx2_wdt_stop,
.ping = imx2_wdt_ping,
.set_timeout = imx2_wdt_set_timeout,
};
@@ -277,9 +243,10 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
watchdog_set_nowayout(wdog, nowayout);
watchdog_init_timeout(wdog, timeout, &pdev->dev);
- setup_timer(&wdev->timer, imx2_wdt_timer_ping, (unsigned long)wdog);
-
- imx2_wdt_ping_if_active(wdog);
+ if (imx2_wdt_is_running(wdev)) {
+ imx2_wdt_set_timeout(wdog, wdog->timeout);
+ set_bit(WDOG_RUNNING, &wdog->status);
+ }
/*
* Disable the watchdog power down counter at boot. Otherwise the power
@@ -320,7 +287,6 @@ static int __exit imx2_wdt_remove(struct platform_device
*pdev)
watchdog_unregister_device(wdog);
if (imx2_wdt_is_running(wdev)) {
- del_timer_sync(&wdev->timer);
imx2_wdt_ping(wdog);
dev_crit(&pdev->dev, "Device removed: Expect reboot!\n");
}
@@ -334,10 +300,9 @@ static void imx2_wdt_shutdown(struct platform_device *pdev)
if (imx2_wdt_is_running(wdev)) {
/*
-* We are running, we need to delete the timer but will
-* give max timeout before reboot will take place
+* We are running, configure max timeout before reboot
+* will take place.
*/
- del_timer_sync(&wdev->timer);
imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
imx2_wdt_ping(wdog);
dev_crit(&pdev->dev, "Device shutdown: Expect reboot!\n");
@@ -355,10 +320,6 @@ static int imx2_wdt_suspend(struct device *dev)
if (imx2_wdt_is_running(wdev)) {
imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
imx2_wdt_ping(wdog);
-
- /* The watchdog is not active */
- if (!watchdog_active(wdog))
- del_timer_sync(&wdev->timer);
}
clk_disable_unpre
[PATCH v4 9/9] watchdog: Add support for minimum time between heartbeats
Some watchdogs require a minimum time between heartbeats.
Examples are the watchdogs in DA9062 and AT91SAM9x.
Signed-off-by: Guenter Roeck
---
Documentation/watchdog/watchdog-kernel-api.txt | 4
drivers/watchdog/watchdog_dev.c| 12
include/linux/watchdog.h | 6 ++
3 files changed, 22 insertions(+)
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt
b/Documentation/watchdog/watchdog-kernel-api.txt
index f480a9355b43..449b8f12873a 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -53,11 +53,13 @@ struct watchdog_device {
unsigned int timeout;
unsigned int min_timeout;
unsigned int max_timeout;
+ unsigned int min_hw_heartbeat_ms;
unsigned int max_hw_timeout_ms;
void *driver_data;
unsigned long status;
struct mutex lock;
unsigned long last_keepalive;
+ unsigned long last_hw_keepalive;
struct delayed_work work;
struct list_head deferred;
};
@@ -83,6 +85,8 @@ It contains following fields:
* max_timeout: the watchdog timer's maximum timeout value (in seconds),
as seen from userspace. If set, the maximum configurable value for
'timeout'. Not used if max_hw_timeout_ms is non-zero.
+* min_hw_heartbeat_ms: Minimum time between heartbeats send to the chip,
+ in milli-seconds.
* max_hw_timeout_ms: Maximum hardware timeout, in milli-seconds.
If set, the infrastructure will send heartbeats to the watchdog driver
if 'timeout' is larger than max_hw_timeout, unless WDOG_ACTIVE
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index b590611b176a..568a14462e17 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -111,6 +111,8 @@ static inline void watchdog_update_worker(struct
watchdog_device *wdd,
static int _watchdog_ping(struct watchdog_device *wdd)
{
+ unsigned long earliest_keepalive = wdd->last_hw_keepalive +
+ msecs_to_jiffies(wdd->min_hw_heartbeat_ms);
int err;
if (test_bit(WDOG_UNREGISTERED, &wdd->status))
@@ -119,6 +121,13 @@ static int _watchdog_ping(struct watchdog_device *wdd)
if (!watchdog_active(wdd) && !watchdog_running(wdd))
return 0;
+ if (time_is_after_jiffies(earliest_keepalive)) {
+ mod_delayed_work(watchdog_wq, &wdd->work,
+earliest_keepalive - jiffies);
+ return 0;
+ }
+
+ wdd->last_hw_keepalive = jiffies;
if (wdd->ops->ping)
err = wdd->ops->ping(wdd); /* ping the watchdog */
else
@@ -661,6 +670,9 @@ int watchdog_dev_register(struct watchdog_device *wdd)
return err;
}
+ /* Record time of most recent heartbeat as 'just before now'. */
+ wdd->last_hw_keepalive = jiffies - 1;
+
/*
* If the watchdog is running, prevent its driver from being unloaded,
* and schedule an immediate ping.
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index 15d04e0fa926..5f83f63ab2cc 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -66,6 +66,8 @@ struct watchdog_ops {
* @max_timeout:The watchdog devices maximum timeout value, in seconds,
* as configurable from user space. Only relevant if
* max_hw_timeout_ms is not provided.
+ * @min_hw_heartbeat_ms:
+ * Minimum time between heartbeats, in milli-seconds.
* @max_hw_timeout_ms:
* Hardware limit for maximum timeout, in milli-seconds.
* Replaces max_timeout if specified.
@@ -75,6 +77,8 @@ struct watchdog_ops {
* @last_keepalive:
* Time of most recent keepalive triggered from user space,
* in jiffies (watchdog core internal).
+ * @last_hw_keepalive:
+ * Time of most recent keepalive sent to the driver, in jiffies.
* @work: Data structure for worker function (watchdog core internal).
* @deferred: entry in wtd_deferred_reg_list which is used to
* register early initialized watchdogs.
@@ -99,6 +103,7 @@ struct watchdog_device {
unsigned int timeout;
unsigned int min_timeout;
unsigned int max_timeout;
+ unsigned int min_hw_heartbeat_ms;
unsigned int max_hw_timeout_ms;
void *driver_data;
unsigned long status;
@@ -112,6 +117,7 @@ struct watchdog_device {
/* the following variables are for internal use only */
struct mutex lock;
unsigned long last_keepalive;
+ unsigned long last_hw_keepalive;
struct delayed_work work;
struct list_head deferred;
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pleas
[PATCH v4 7/9] watchdog: retu: Convert to use infrastructure triggered keepalives
The watchdog infrastructure now supports handling watchdog keepalive
if the watchdog is running while the watchdog device is closed.
Convert the driver to use this infrastructure.
Signed-off-by: Guenter Roeck
---
v3: No changes
v2: No changes
---
drivers/watchdog/retu_wdt.c | 78 -
1 file changed, 7 insertions(+), 71 deletions(-)
diff --git a/drivers/watchdog/retu_wdt.c b/drivers/watchdog/retu_wdt.c
index 39cd51df2ffc..9a85c687824c 100644
--- a/drivers/watchdog/retu_wdt.c
+++ b/drivers/watchdog/retu_wdt.c
@@ -28,69 +28,22 @@
/* Watchdog timer values in seconds */
#define RETU_WDT_MAX_TIMER 63
-struct retu_wdt_dev {
- struct retu_dev *rdev;
- struct device *dev;
- struct delayed_work ping_work;
-};
-
-/*
- * Since Retu watchdog cannot be disabled in hardware, we must kick it
- * with a timer until userspace watchdog software takes over. If
- * CONFIG_WATCHDOG_NOWAYOUT is set, we never start the feeding.
- */
-static void retu_wdt_ping_enable(struct retu_wdt_dev *wdev)
-{
- retu_write(wdev->rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
- schedule_delayed_work(&wdev->ping_work,
- round_jiffies_relative(RETU_WDT_MAX_TIMER * HZ / 2));
-}
-
-static void retu_wdt_ping_disable(struct retu_wdt_dev *wdev)
-{
- retu_write(wdev->rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
- cancel_delayed_work_sync(&wdev->ping_work);
-}
-
-static void retu_wdt_ping_work(struct work_struct *work)
-{
- struct retu_wdt_dev *wdev = container_of(to_delayed_work(work),
- struct retu_wdt_dev, ping_work);
- retu_wdt_ping_enable(wdev);
-}
-
static int retu_wdt_start(struct watchdog_device *wdog)
{
- struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+ struct retu_dev *rdev = watchdog_get_drvdata(wdog);
- retu_wdt_ping_disable(wdev);
+ set_bit(WDOG_RUNNING, &wdog->status);
- return retu_write(wdev->rdev, RETU_REG_WATCHDOG, wdog->timeout);
-}
-
-static int retu_wdt_stop(struct watchdog_device *wdog)
-{
- struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
-
- retu_wdt_ping_enable(wdev);
-
- return 0;
-}
-
-static int retu_wdt_ping(struct watchdog_device *wdog)
-{
- struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
-
- return retu_write(wdev->rdev, RETU_REG_WATCHDOG, wdog->timeout);
+ return retu_write(rdev, RETU_REG_WATCHDOG, wdog->timeout);
}
static int retu_wdt_set_timeout(struct watchdog_device *wdog,
unsigned int timeout)
{
- struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+ struct retu_dev *rdev = watchdog_get_drvdata(wdog);
wdog->timeout = timeout;
- return retu_write(wdev->rdev, RETU_REG_WATCHDOG, wdog->timeout);
+ return retu_write(rdev, RETU_REG_WATCHDOG, wdog->timeout);
}
static const struct watchdog_info retu_wdt_info = {
@@ -101,8 +54,6 @@ static const struct watchdog_info retu_wdt_info = {
static const struct watchdog_ops retu_wdt_ops = {
.owner = THIS_MODULE,
.start = retu_wdt_start,
- .stop = retu_wdt_stop,
- .ping = retu_wdt_ping,
.set_timeout= retu_wdt_set_timeout,
};
@@ -111,17 +62,12 @@ static int retu_wdt_probe(struct platform_device *pdev)
struct retu_dev *rdev = dev_get_drvdata(pdev->dev.parent);
bool nowayout = WATCHDOG_NOWAYOUT;
struct watchdog_device *retu_wdt;
- struct retu_wdt_dev *wdev;
int ret;
retu_wdt = devm_kzalloc(&pdev->dev, sizeof(*retu_wdt), GFP_KERNEL);
if (!retu_wdt)
return -ENOMEM;
- wdev = devm_kzalloc(&pdev->dev, sizeof(*wdev), GFP_KERNEL);
- if (!wdev)
- return -ENOMEM;
-
retu_wdt->info = &retu_wdt_info;
retu_wdt->ops = &retu_wdt_ops;
retu_wdt->timeout = RETU_WDT_MAX_TIMER;
@@ -129,22 +75,14 @@ static int retu_wdt_probe(struct platform_device *pdev)
retu_wdt->max_timeout = RETU_WDT_MAX_TIMER;
retu_wdt->parent= &pdev->dev;
- watchdog_set_drvdata(retu_wdt, wdev);
+ watchdog_set_drvdata(retu_wdt, rdev);
watchdog_set_nowayout(retu_wdt, nowayout);
- wdev->rdev = rdev;
- wdev->dev = &pdev->dev;
-
- INIT_DELAYED_WORK(&wdev->ping_work, retu_wdt_ping_work);
-
ret = watchdog_register_device(retu_wdt);
if (ret < 0)
return ret;
- if (nowayout)
- retu_wdt_ping(retu_wdt);
- else
- retu_wdt_ping_enable(wdev);
+ retu_wdt_start(retu_wdt);
platform_set_drvdata(pdev, retu_wdt);
@@ -154,10 +92,8 @@ static int retu_wdt_probe(struct platform_device *pdev)
static int retu_wdt_remove(struct platform_device *pdev)
{
struct watchdog_device *wdog
[PATCH v4 8/9] watchdog: at91sam9: Convert to use infrastructure triggered keepalives
The watchdog infrastructure now supports handling watchdog keepalive
if the watchdog is running while the watchdog device is closed.
The infrastructure now also supports generating additional heartbeats
if the maximum hardware timeout is smaller than or close to the
configured timeout. Convert the driver to use this
infrastructure.
Signed-off-by: Guenter Roeck
---
v3: No changes
v2: No changes
---
drivers/watchdog/at91sam9_wdt.c | 103 +---
1 file changed, 12 insertions(+), 91 deletions(-)
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index 7e6acaf3ece4..a1c1c79b700e 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -30,7 +30,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -49,8 +48,8 @@
* use this to convert a watchdog
* value from/to milliseconds.
*/
-#define ticks_to_hz_rounddown(t) t) + 1) * HZ) >> 8)
-#define ticks_to_hz_roundup(t) (t) + 1) * HZ) + 255) >> 8)
+#define ticks_to_ms_rounddown(t) t) + 1) * 1000) >> 8)
+#define ticks_to_ms_roundup(t) (t) + 1) * 1000) + 255) >> 8)
#define ticks_to_secs(t) (((t) + 1) >> 8)
#define secs_to_ticks(s) ((s) ? (((s) << 8) - 1) : 0)
@@ -65,9 +64,6 @@
/* Hardware timeout in seconds */
#define WDT_HW_TIMEOUT 2
-/* Timer heartbeat (500ms) */
-#define WDT_TIMEOUT(HZ/2)
-
/* User land timeout */
#define WDT_HEARTBEAT 15
static int heartbeat;
@@ -84,11 +80,8 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
started "
struct at91wdt {
struct watchdog_device wdd;
void __iomem *base;
- unsigned long next_heartbeat; /* the next_heartbeat for the timer */
- struct timer_list timer;/* The timer that pings the watchdog */
u32 mr;
u32 mr_mask;
- unsigned long heartbeat;/* WDT heartbeat in jiffies */
bool nowayout;
unsigned int irq;
struct clk *sclk;
@@ -109,47 +102,13 @@ static irqreturn_t wdt_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
-/*
- * Reload the watchdog timer. (ie, pat the watchdog)
- */
-static inline void at91_wdt_reset(struct at91wdt *wdt)
-{
- wdt_write(wdt, AT91_WDT_CR, AT91_WDT_KEY | AT91_WDT_WDRSTT);
-}
-
-/*
- * Timer tick
- */
-static void at91_ping(unsigned long data)
-{
- struct at91wdt *wdt = (struct at91wdt *)data;
- if (time_before(jiffies, wdt->next_heartbeat) ||
- !watchdog_active(&wdt->wdd)) {
- at91_wdt_reset(wdt);
- mod_timer(&wdt->timer, jiffies + wdt->heartbeat);
- } else {
- pr_crit("I will reset your machine !\n");
- }
-}
-
static int at91_wdt_start(struct watchdog_device *wdd)
{
struct at91wdt *wdt = to_wdt(wdd);
- /* calculate when the next userspace timeout will be */
- wdt->next_heartbeat = jiffies + wdd->timeout * HZ;
- return 0;
-}
-static int at91_wdt_stop(struct watchdog_device *wdd)
-{
- /* The watchdog timer hardware can not be stopped... */
- return 0;
-}
+ wdt_write(wdt, AT91_WDT_CR, AT91_WDT_KEY | AT91_WDT_WDRSTT);
-static int at91_wdt_set_timeout(struct watchdog_device *wdd, unsigned int
new_timeout)
-{
- wdd->timeout = new_timeout;
- return at91_wdt_start(wdd);
+ return 0;
}
static int at91_wdt_init(struct platform_device *pdev, struct at91wdt *wdt)
@@ -159,8 +118,8 @@ static int at91_wdt_init(struct platform_device *pdev,
struct at91wdt *wdt)
u32 value;
int err;
u32 mask = wdt->mr_mask;
- unsigned long min_heartbeat = 1;
- unsigned long max_heartbeat;
+ unsigned int min_timeout = jiffies_to_msecs(1);
+ unsigned int hw_timeout;
struct device *dev = &pdev->dev;
tmp = wdt_read(wdt, AT91_WDT_MR);
@@ -182,31 +141,15 @@ static int at91_wdt_init(struct platform_device *pdev,
struct at91wdt *wdt)
delta = (tmp & AT91_WDT_WDD) >> 16;
if (delta < value)
- min_heartbeat = ticks_to_hz_roundup(value - delta);
+ min_timeout = ticks_to_ms_roundup(value - delta);
- max_heartbeat = ticks_to_hz_rounddown(value);
- if (!max_heartbeat) {
+ hw_timeout = ticks_to_ms_rounddown(value);
+ if (hw_timeout < min_timeout * 2) {
dev_err(dev,
"heartbeat is too small for the system to handle it
correctly\n");
return -EINVAL;
}
-
- /*
-* Try to reset the watchdog counter 4 or 2 times more often than
-* actually requested, to avoid spurious watchdog reset.
-* If this is not possible because of the min_heartbeat value, reset
-* it at the min_heartbeat period.
-*/
- if ((max_heartbeat / 4) >= min_heartbeat)
- wdt->heartbeat = max_heartbeat / 4;
- else if ((max_heartbeat / 2) >= mi
Re: [PATCH v2 3/3] mfd: add CSR SiRFSoC on-chip power management module driver
2015-09-29 15:16 GMT+08:00 Lee Jones :
> On Tue, 29 Sep 2015, Barry Song wrote:
>> >> >> +static int sirfsoc_pwrc_probe(struct platform_device *pdev)
>> >> >> +{
>> >> >> + struct device_node *np = pdev->dev.of_node;
>> >> >> + const struct of_device_id *match;
>> >> >> + struct sirfsoc_pwrc_info *pwrcinfo;
>> >> >> + struct regmap_irq_chip *regmap_irq_chip;
>> >> >> + struct sirfsoc_pwrc_register *pwrc_reg;
>> >> >> + struct regmap *map;
>> >> >> + int ret;
>> >> >> + u32 base;
>> >> >> +
>> >> >> + if (of_property_read_u32(np, "reg", &base))
>> >> >> + panic("unable to find base address of pwrc node in
>> >> >> dtb\n");
>> >> >
>> >> > It looks like this driver should depend on OF.
>> >> >
>> >> > Why are you obtaining the base address manually? Use:
>> >> >
>> >> > res = platform_get_resource();
>> >> > devm_ioremap_resource(res);
>> >> >
>> >> > ... instead.
>> >>
>> >> this was explained as they are not in memory space, they are behind a
>> >> bus bridge.
>> >
>> > Use 'ranges' in the DT, then you can pull out the proper address
>> > without hand rolling your own method.
>>
>> it seems it is not a "ranges" thing, things behind rtciobrg is much
>> like things behind USB or sdio. we need to use a rtciobrg protocol to
>> do read/write.
>> they can not be randomly accessed by load/store, and can't be XIP.
>> they don't have any ranges in CPU memory space.
>
> So what's the point of 'base' then? I assumed this was the base of
> the IP registers which where memory mapped?
just think we have a i2c device, and this i2c device has multi-functions.
each function has a base of its register offset.
actually, the base is the offset of 1st register.
-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: No more new fbdev drivers, please
Hi Gerd, On Tuesday 29 September 2015 10:23:23 Gerd Hoffmann wrote: > On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote: > > On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote: > > > Hi, > > > > > > > As Daniel mentioned, the connector+encoder+crtc combination is one of > > > > those simplifications that would make sense if more such drivers are > > > > added. > > > > > > Another one is memory management. It's pretty complex because it can > > > handle _way_ more than what simple drivers need, and the result is > > > _alot_ of ttm boilerplate in the drivers. > > > > ttm is pretty impressive overkill for most simplistic drm drivers. If you > > just need contiguous framebuffers for display then the cma helpers should > > take care of pretty much all the boilerplate for you. They have ready-made > > simple gem and dumb framebuffer mmap support, which is all a basic kms > > driver needs. > > Does that work on !arm meanwhile? Last time I checked (when writing > bochsdrm, around v3.14) the cma helpers didn't even build on x86 ... config DRM_GEM_CMA_HELPER bool depends on DRM && HAVE_DMA_ATTRS help Choose this if you need the GEM CMA helper functions x86 defines HAVE_DMA_ATTRS. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [net] orinoco_usb:Fix error handling in ezusb_probe()
RUC_Soft_Sec writes:
> Current code assigns 0 to variable 'retval', which makes ezusb_probe() to
> return success even if alloc_orinocodev() fails.
>
> The related code snippets in mantis_dma_init() is as following.
>
> 1573 static int ezusb_probe(struct usb_interface *interface,
> 1574const struct usb_device_id *id)
> 1575 {
>
>
>
> 1583 int retval = 0;
> 1584 int i;
> 1585
> 1586 priv = alloc_orinocodev(sizeof(*upriv), &udev->dev,
> 1587 ezusb_hard_reset, NULL);
> 1588 if (!priv) {
> 1589 err("Couldn't allocate orinocodev");
> 1590 goto exit;
> 1591 }
> ...
>
> 1729 exit:
> 1730 if (fw_entry) {
> 1731 firmware.code = NULL;
> 1732 firmware.size = 0;
> 1733 release_firmware(fw_entry);
> 1734 }
> 1735 usb_set_intfdata(interface, upriv);
> 1736 return retval;
> 1737 }
>
> Fix it by checking the return value from alloc_orinocodev() and assigns
> '-ENOMEM' to variable 'retval' in the case of error.
>
> Signed-off-by: Zhang Yan ---
> orinoco_usb.c |1 +
> 1 file changed, 1 insertion(+)
> diff --git a/orinoco_usb.c b/orinoco_usb.c
The patch looks corrupted. And the from header doesn't contain a proper
name.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ASoC: ad193x: add support to ad1934
The AD1934 codec has no DAC feature. Hence it register mapping is slightly
different from the register mapping of other members of the AD193x family.
Some ASoC controls and widgets are related to the DAC feature so are not
relevant in the case of an AD1934 codec.
Signed-off-by: Cyrille Pitchen
---
Hi all,
This patch adds support to the AD1934 codec, which is DAC only.
Best Regards,
Cyrille
---
sound/soc/codecs/ad193x-i2c.c | 8 +--
sound/soc/codecs/ad193x-spi.c | 16 +-
sound/soc/codecs/ad193x.c | 121 --
sound/soc/codecs/ad193x.h | 9 +++-
4 files changed, 120 insertions(+), 34 deletions(-)
diff --git a/sound/soc/codecs/ad193x-i2c.c b/sound/soc/codecs/ad193x-i2c.c
index df3a1a415825..8aa50d35662f 100644
--- a/sound/soc/codecs/ad193x-i2c.c
+++ b/sound/soc/codecs/ad193x-i2c.c
@@ -15,8 +15,8 @@
#include "ad193x.h"
static const struct i2c_device_id ad193x_id[] = {
- { "ad1936", 0 },
- { "ad1937", 0 },
+ { "ad1936", AD193x },
+ { "ad1937", AD193x },
{ }
};
MODULE_DEVICE_TABLE(i2c, ad193x_id);
@@ -30,7 +30,9 @@ static int ad193x_i2c_probe(struct i2c_client *client,
config.val_bits = 8;
config.reg_bits = 8;
- return ad193x_probe(&client->dev, devm_regmap_init_i2c(client,
&config));
+ return ad193x_probe(&client->dev,
+ devm_regmap_init_i2c(client, &config),
+ (enum ad193x_type)id->driver_data);
}
static int ad193x_i2c_remove(struct i2c_client *client)
diff --git a/sound/soc/codecs/ad193x-spi.c b/sound/soc/codecs/ad193x-spi.c
index 390cef9b9dc2..364e82112e8c 100644
--- a/sound/soc/codecs/ad193x-spi.c
+++ b/sound/soc/codecs/ad193x-spi.c
@@ -16,6 +16,7 @@
static int ad193x_spi_probe(struct spi_device *spi)
{
+ const struct spi_device_id *id = spi_get_device_id(spi);
struct regmap_config config;
config = ad193x_regmap_config;
@@ -24,7 +25,8 @@ static int ad193x_spi_probe(struct spi_device *spi)
config.read_flag_mask = 0x09;
config.write_flag_mask = 0x08;
- return ad193x_probe(&spi->dev, devm_regmap_init_spi(spi, &config));
+ return ad193x_probe(&spi->dev, devm_regmap_init_spi(spi, &config),
+ (enum ad193x_type)id->driver_data);
}
static int ad193x_spi_remove(struct spi_device *spi)
@@ -33,6 +35,17 @@ static int ad193x_spi_remove(struct spi_device *spi)
return 0;
}
+static const struct spi_device_id ad193x_spi_id[] = {
+ { "ad193x", AD193X },
+ { "ad1933", AD1933 },
+ { "ad1934", AD1934 },
+ { "ad1936", AD193X },
+ { "ad1937", AD193X },
+ { "ad1938", AD193X },
+ { }
+};
+MODULE_DEVICE_TABLE(spi, ad193x_spi_id);
+
static struct spi_driver ad193x_spi_driver = {
.driver = {
.name = "ad193x",
@@ -40,6 +53,7 @@ static struct spi_driver ad193x_spi_driver = {
},
.probe = ad193x_spi_probe,
.remove = ad193x_spi_remove,
+ .id_table = ad193x_spi_id,
};
module_spi_driver(ad193x_spi_driver);
diff --git a/sound/soc/codecs/ad193x.c b/sound/soc/codecs/ad193x.c
index 17c953595660..80ffecf98673 100644
--- a/sound/soc/codecs/ad193x.c
+++ b/sound/soc/codecs/ad193x.c
@@ -23,6 +23,7 @@
/* codec private data */
struct ad193x_priv {
struct regmap *regmap;
+ enum ad193x_type type;
int sysclk;
};
@@ -47,12 +48,6 @@ static const struct snd_kcontrol_new ad193x_snd_controls[] =
{
SOC_DOUBLE_R_TLV("DAC4 Volume", AD193X_DAC_L4_VOL,
AD193X_DAC_R4_VOL, 0, 0xFF, 1, adau193x_tlv),
- /* ADC switch control */
- SOC_DOUBLE("ADC1 Switch", AD193X_ADC_CTRL0, AD193X_ADCL1_MUTE,
- AD193X_ADCR1_MUTE, 1, 1),
- SOC_DOUBLE("ADC2 Switch", AD193X_ADC_CTRL0, AD193X_ADCL2_MUTE,
- AD193X_ADCR2_MUTE, 1, 1),
-
/* DAC switch control */
SOC_DOUBLE("DAC1 Switch", AD193X_DAC_CHNL_MUTE, AD193X_DACL1_MUTE,
AD193X_DACR1_MUTE, 1, 1),
@@ -63,26 +58,37 @@ static const struct snd_kcontrol_new ad193x_snd_controls[]
= {
SOC_DOUBLE("DAC4 Switch", AD193X_DAC_CHNL_MUTE, AD193X_DACL4_MUTE,
AD193X_DACR4_MUTE, 1, 1),
+ /* DAC de-emphasis */
+ SOC_ENUM("Playback Deemphasis", ad193x_deemp_enum),
+};
+
+static const struct snd_kcontrol_new ad193x_adc_snd_controls[] = {
+ /* ADC switch control */
+ SOC_DOUBLE("ADC1 Switch", AD193X_ADC_CTRL0, AD193X_ADCL1_MUTE,
+ AD193X_ADCR1_MUTE, 1, 1),
+ SOC_DOUBLE("ADC2 Switch", AD193X_ADC_CTRL0, AD193X_ADCL2_MUTE,
+ AD193X_ADCR2_MUTE, 1, 1),
+
/* ADC high-pass filter */
SOC_SINGLE("ADC High Pass Filter Switch", AD193X_ADC_CTRL0,
AD193X_ADC_HIGHPASS_FILTER, 1, 0),
-
- /* DAC de-emphasis */
- SOC_ENUM("Playback Deemphasis", ad193x_deemp_enum),
};
static const struct snd_so
[tip:perf/core] perf top: Filter symbols based on __map__is_kernel(map)
Commit-ID: cfc5acd4c80b875d2f739d6a93562034aee5563f
Gitweb: http://git.kernel.org/tip/cfc5acd4c80b875d2f739d6a93562034aee5563f
Author: Arnaldo Carvalho de Melo
AuthorDate: Wed, 23 Sep 2015 15:15:54 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 15:50:53 -0300
perf top: Filter symbols based on __map__is_kernel(map)
Instead of using dso->kernel, this is equivalent at the moment,
and helps in reducing the accesses to dso->kernel.
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-1pc2v63iphtifovw3bv0b...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-top.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index bdaf44f..38d4d6c 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -655,7 +655,7 @@ static int symbol_filter(struct map *map, struct symbol
*sym)
{
const char *name = sym->name;
- if (!map->dso->kernel)
+ if (!__map__is_kernel(map))
return 0;
/*
* ppc64 uses function descriptors and appends a '.' to the
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf hists browser: Use the map to determine if a DSO is being used as a kernel
Commit-ID: 045b80dd03403b8e61a29460987c231317ebfbd4
Gitweb: http://git.kernel.org/tip/045b80dd03403b8e61a29460987c231317ebfbd4
Author: Arnaldo Carvalho de Melo
AuthorDate: Wed, 23 Sep 2015 15:38:55 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 15:50:54 -0300
perf hists browser: Use the map to determine if a DSO is being used as a kernel
The map is what should say if an ELF (or some other format) image is
being used for some particular purpose, as a kernel, host or guest.
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-zufousvfar0710p4qj71c...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index e1f28f4..a4e9b37 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1527,7 +1527,7 @@ add_thread_opt(struct hist_browser *browser, struct
popup_action *act,
static int
do_zoom_dso(struct hist_browser *browser, struct popup_action *act)
{
- struct dso *dso = act->dso;
+ struct map *map = act->ms.map;
if (browser->hists->dso_filter) {
pstack__remove(browser->pstack, &browser->hists->dso_filter);
@@ -1535,11 +1535,11 @@ do_zoom_dso(struct hist_browser *browser, struct
popup_action *act)
browser->hists->dso_filter = NULL;
ui_helpline__pop();
} else {
- if (dso == NULL)
+ if (map == NULL)
return 0;
ui_helpline__fpush("To zoom out press <- or -> + \"Zoom out of
%s DSO\"",
- dso->kernel ? "the Kernel" :
dso->short_name);
- browser->hists->dso_filter = dso;
+ __map__is_kernel(map) ? "the Kernel" :
map->dso->short_name);
+ browser->hists->dso_filter = map->dso;
perf_hpp__set_elide(HISTC_DSO, true);
pstack__push(browser->pstack, &browser->hists->dso_filter);
}
@@ -1551,17 +1551,18 @@ do_zoom_dso(struct hist_browser *browser, struct
popup_action *act)
static int
add_dso_opt(struct hist_browser *browser, struct popup_action *act,
- char **optstr, struct dso *dso)
+ char **optstr, struct map *map)
{
- if (dso == NULL)
+ if (map == NULL)
return 0;
if (asprintf(optstr, "Zoom %s %s DSO",
browser->hists->dso_filter ? "out of" : "into",
-dso->kernel ? "the Kernel" : dso->short_name) < 0)
+__map__is_kernel(map) ? "the Kernel" :
map->dso->short_name) < 0)
return 0;
- act->dso = dso;
+ act->ms.map = map;
+ act->dso = map->dso;
act->fn = do_zoom_dso;
return 1;
}
@@ -1814,6 +1815,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
while (1) {
struct thread *thread = NULL;
struct dso *dso = NULL;
+ struct map *map = NULL;
int choice = 0;
int socked_id = -1;
@@ -1823,7 +1825,9 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
if (browser->he_selection != NULL) {
thread = hist_browser__selected_thread(browser);
- dso = browser->selection->map ?
browser->selection->map->dso : NULL;
+ map = browser->selection->map;
+ if (map)
+ dso = map->dso;
socked_id = browser->he_selection->socket;
}
switch (key) {
@@ -2014,7 +2018,7 @@ skip_annotation:
nr_options += add_thread_opt(browser, &actions[nr_options],
&options[nr_options], thread);
nr_options += add_dso_opt(browser, &actions[nr_options],
- &options[nr_options], dso);
+ &options[nr_options], map);
nr_options += add_map_opt(browser, &actions[nr_options],
&options[nr_options],
browser->selection ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/2] ASoC: Add support for the Allwinner A10 codec
On Mon, Sep 28, 2015 at 3:42 PM, Maxime Ripard wrote: > Hi Priit, > > On Tue, Sep 22, 2015 at 04:26:57PM +0300, Priit Laes wrote: >> On Sat, 2015-09-12 at 15:26 +0200, Maxime Ripard wrote: >> > Hi everyone, >> > >> > This patch set adds the support for what Allwinner calls the codec on >> > their SoCs. >> > >> > This codec is actually a combination of a codec and DAI, tied >> > together >> > in a single memory-mapped IP. It is completely standalone, and >> > outputs >> > directly the analog signal. >> > >> > While it supports both playback and capture, the capture is not >> > implemented in this patch, and will be posted eventually as a >> > separate >> > one. >> > >> > This set, in order to be functional, has a dependency on the audio >> > clocks patch set posted separately. However, it doesn't needs this to >> > compile properly, so I guess it can be merged without really caring >> > for the merging status of the clock patches. >> >> It works on Gemei G9 tablet which has also extra chip that >> automatically switches output over from internal speakers to headphones >> when connector is inserted. >> >> Now I noticed some weird things: >> >> When I have all the switches as ON in alsamixer, and I start disabling >> them, I get following weird results. >> >> Left Mixer Left - LML >> Right Mixer Left - LMR >> Right Mixer Right - RMR >> >> Very faint output: >> LML - ON >> RML - Mute >> RMR - ON >> >> Output works fully: >> LML - Mute >> RML - Mute >> RMR - Mute >> >> When I Mute Pre-Amplifier and fiddle any of LML, RML or RMR, the output >> stays mute even after setting Pre-Amplifier Mute back on: >> >> 1. All switches on >> 2. Mute pre-amplifier >> 3. Mute RMR >> 4. Pre-Amilifier Mute Off >> .. Music stays off >> 5. Toggle Pre-Amplifier twice - output turns on > > Unfortunately, I don't have access to that SoC or that setup. > > Do you have another A10 board with a simpler audio setup, like a > cubieboard? > >> And also following in dmesg: >> sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok >> sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack >> sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Left -> direct -> >> Headphone Jack >> sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack >> sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Right -> direct -> >> Headphone Jack > > That one is weird, I'll look into this. This also appears on my Cubietruck, when using the dts patch from Hans' sunxi-wip branch, which is the same patch, albeit for a different dts file, as Priit. The immediate culprit seems to be the routing property, though I'm not sure what it should be set to, or what extra drivers might be needed. Regards ChenYu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools lib api fs: Store tracing mountpoint for better error message
Commit-ID: dc240c5dc2a02e335c5bcb50ad3a1274818c8609
Gitweb: http://git.kernel.org/tip/dc240c5dc2a02e335c5bcb50ad3a1274818c8609
Author: Jiri Olsa
AuthorDate: Sat, 19 Sep 2015 16:47:07 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 15:50:54 -0300
tools lib api fs: Store tracing mountpoint for better error message
Storing the actual tracing path mountpoint to display correct
error message hint ('Hint:' line). The error hint rediscovers
mountpoints, but it could be different from what we actually
used in tracing path.
Before we'd display debugfs mount even though tracefs was used:
$ perf record -e sched:sched_krava ls
event syntax error: 'sched:sched_krava'
\___ can't access trace events
Error: No permissions to read
/sys/kernel/debug/tracing/events/sched/sched_krava
Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/debug'
...
After this change, correct mountpoint is displayed:
$ perf record -e sched:sched_krava ls
event syntax error: 'sched:sched_krava'
\___ can't access trace events
Error: No permissions to read
/sys/kernel/debug/tracing/events/sched/sched_krava
Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing'
...
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Matt Fleming
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Raphael Beamonte
Link:
http://lkml.kernel.org/r/1442674027-19427-1-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/api/fs/tracing_path.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/tools/lib/api/fs/tracing_path.c b/tools/lib/api/fs/tracing_path.c
index 38aca2d..0406a7d 100644
--- a/tools/lib/api/fs/tracing_path.c
+++ b/tools/lib/api/fs/tracing_path.c
@@ -12,12 +12,14 @@
#include "tracing_path.h"
+char tracing_mnt[PATH_MAX + 1] = "/sys/kernel/debug";
char tracing_path[PATH_MAX + 1]= "/sys/kernel/debug/tracing";
char tracing_events_path[PATH_MAX + 1] = "/sys/kernel/debug/tracing/events";
static void __tracing_path_set(const char *tracing, const char *mountpoint)
{
+ snprintf(tracing_mnt, sizeof(tracing_mnt), "%s", mountpoint);
snprintf(tracing_path, sizeof(tracing_path), "%s/%s",
mountpoint, tracing);
snprintf(tracing_events_path, sizeof(tracing_events_path), "%s/%s%s",
@@ -109,19 +111,10 @@ static int strerror_open(int err, char *buf, size_t size,
const char *filename)
"Hint:\tTry 'sudo mount -t debugfs nodev
/sys/kernel/debug'");
break;
case EACCES: {
- const char *mountpoint = debugfs__mountpoint();
-
- if (!access(mountpoint, R_OK) && strncmp(filename, "tracing/",
8) == 0) {
- const char *tracefs_mntpoint = tracefs__mountpoint();
-
- if (tracefs_mntpoint)
- mountpoint = tracefs__mountpoint();
- }
-
snprintf(buf, size,
"Error:\tNo permissions to read %s/%s\n"
"Hint:\tTry 'sudo mount -o remount,mode=755 %s'\n",
-tracing_events_path, filename, mountpoint);
+tracing_events_path, filename, tracing_mnt);
}
break;
default:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Use __map__is_kernel() when synthesizing kernel module mmap records
Commit-ID: ab9c2bdc8947482057b81258c0128952763661cb
Gitweb: http://git.kernel.org/tip/ab9c2bdc8947482057b81258c0128952763661cb
Author: Arnaldo Carvalho de Melo
AuthorDate: Wed, 23 Sep 2015 15:45:20 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 15:50:54 -0300
perf tools: Use __map__is_kernel() when synthesizing kernel module mmap records
Equivalent and removes one more case of using dso->kernel.
# perf record -a usleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.768 MB perf.data (30 samples) ]
Before:
[root@zoo ~]# perf script --show-task --show-mmap | head -3
swapper 0 [0] 0.0: PERF_RECORD_MMAP -1/0: [0x8100(0x1f00) @
0x8100]: x [kernel.kallsyms]_text
swapper 0 [0] 0.0: PERF_RECORD_MMAP -1/0: [0xa000(0xa000) @ 0]:
x /lib/modules/4.3.0-rc1+/kernel/drivers/acpi/video.ko
swapper 0 [0] 0.0: PERF_RECORD_MMAP -1/0: [0xa000a000(0x5000) @ 0]:
x /lib/modules/4.3.0-rc1+/kernel/drivers/i2c/algos/i2c-algo-bit.ko
#
# perf script --show-task --show-mmap | head -3
swapper 0 [0] 0.0: PERF_RECORD_MMAP -1/0: [0x8100(0x1f00) @
0x8100]: x [kernel.kallsyms]_text
swapper 0 [0] 0.0: PERF_RECORD_MMAP -1/0: [0xa000(0xa000) @ 0]:
x /lib/modules/4.3.0-rc1+/kernel/drivers/acpi/video.ko
swapper 0 [0] 0.0: PERF_RECORD_MMAP -1/0: [0xa000a000(0x5000) @ 0]:
x /lib/modules/4.3.0-rc1+/kernel/drivers/i2c/algos/i2c-algo-bit.ko
#
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-b65xe578dwq22mzmmj5y9...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 6214ad4..b1bb348 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -378,7 +378,7 @@ int perf_event__synthesize_modules(struct perf_tool *tool,
for (pos = maps__first(maps); pos; pos = map__next(pos)) {
size_t size;
- if (pos->dso->kernel)
+ if (__map__is_kernel(pos))
continue;
size = PERF_ALIGN(pos->dso->long_name_len + 1, sizeof(u64));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 3/6] x86, efi, kasan: #undef memset/memcpy/memmove per arch.
* Andrey Ryabinin wrote: > In not-instrumented code KASAN replaces instrumented > memset/memcpy/memmove with not-instrumented analogues > __memset/__memcpy/__memove. > However, on x86 the EFI stub is not linked with the kernel. > It uses not-instrumented mem*() functions from > arch/x86/boot/compressed/string.c > So we don't replace them with __mem*() variants in EFI stub. > > On ARM64 the EFI stub is linked with the kernel, so we should > replace mem*() functions with __mem*(), because the EFI stub > runs before KASAN sets up early shadow. > > So let's move these #undef mem* into arch's asm/efi.h which is > also included by the EFI stub. > > Also, this will fix the warning in 32-bit build reported by > kbuild test robot : > efi-stub-helper.c:599:2: warning: implicit declaration of function > 'memcpy' > > Signed-off-by: Andrey Ryabinin > --- > arch/x86/include/asm/efi.h | 12 > drivers/firmware/efi/libstub/efistub.h | 4 > 2 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h > index 155162e..6db2742 100644 > --- a/arch/x86/include/asm/efi.h > +++ b/arch/x86/include/asm/efi.h > @@ -86,6 +86,18 @@ extern u64 asmlinkage efi_call(void *fp, ...); > extern void __iomem *__init efi_ioremap(unsigned long addr, unsigned long > size, > u32 type, u64 attribute); > > +/* > + * CONFIG_KASAN may redefine memset to __memset. > + * __memset function is present only in kernel binary. > + * Since the EFI stub linked into a separate binary it > + * doesn't have __memset(). So we should use standard > + * memset from arch/x86/boot/compressed/string.c > + * The same applies to memcpy and memmove. > + */ > +#undef memcpy > +#undef memset > +#undef memmove Hm, so this hack got upstream via -mm, and it breaks the 64-bit x86 build with some configs: arch/x86/platform/efi/efi.c:673:3: error: implicit declaration of function ‘memcpy’ [-Werror=implicit-function-declaration] arch/x86/platform/efi/efi_64.c:139:2: error: implicit declaration of function ‘memcpy’ [-Werror=implicit-function-declaration] ./arch/x86/include/asm/desc.h:121:2: error: implicit declaration of function ‘memcpy’ [-Werror=implicit-function-declaration] I guess it's about EFI=y but KASAN=n. Config attached. beyond fixing the build bug ... could we also engineer this in a better fashion than spreading random #undefs across various KASAN unrelated headers? Thanks, Ingo # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.3.0-rc3 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set 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 is not set CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y
[tip:x86/debug] x86/kgdb: Replace bool_int_array[NR_CPUS] with bitmap
Commit-ID: 0d44975d1e2791f6df2b84b182f49d815ba3c9e0
Gitweb: http://git.kernel.org/tip/0d44975d1e2791f6df2b84b182f49d815ba3c9e0
Author: Denys Vlasenko
AuthorDate: Sat, 26 Sep 2015 14:47:17 +0200
Committer: Ingo Molnar
CommitDate: Mon, 28 Sep 2015 10:13:31 +0200
x86/kgdb: Replace bool_int_array[NR_CPUS] with bitmap
Straigntforward conversion from:
int was_in_debug_nmi[NR_CPUS]
to:
DECLARE_BITMAP(was_in_debug_nmi, NR_CPUS)
Saves about 2 kbytes in BSS for NR_CPUS=512.
Signed-off-by: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Jason Wessel
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
Link:
http://lkml.kernel.org/r/1443271638-2568-1-git-send-email-dvlas...@redhat.com
[ Tidied up the code a bit. ]
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/kgdb.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index d6178d9..44256a6 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -511,26 +511,31 @@ single_step_cont(struct pt_regs *regs, struct die_args
*args)
return NOTIFY_STOP;
}
-static int was_in_debug_nmi[NR_CPUS];
+static DECLARE_BITMAP(was_in_debug_nmi, NR_CPUS);
static int kgdb_nmi_handler(unsigned int cmd, struct pt_regs *regs)
{
+ int cpu;
+
switch (cmd) {
case NMI_LOCAL:
if (atomic_read(&kgdb_active) != -1) {
/* KGDB CPU roundup */
- kgdb_nmicallback(raw_smp_processor_id(), regs);
- was_in_debug_nmi[raw_smp_processor_id()] = 1;
+ cpu = raw_smp_processor_id();
+ kgdb_nmicallback(cpu, regs);
+ set_bit(cpu, was_in_debug_nmi);
touch_nmi_watchdog();
+
return NMI_HANDLED;
}
break;
case NMI_UNKNOWN:
- if (was_in_debug_nmi[raw_smp_processor_id()]) {
- was_in_debug_nmi[raw_smp_processor_id()] = 0;
+ cpu = raw_smp_processor_id();
+
+ if (__test_and_clear_bit(cpu, was_in_debug_nmi))
return NMI_HANDLED;
- }
+
break;
default:
/* do nothing */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools build: Add Makefile.include
Commit-ID: ab6201d09b1840c7ffcd6606c1d3dae68b8b3048 Gitweb: http://git.kernel.org/tip/ab6201d09b1840c7ffcd6606c1d3dae68b8b3048 Author: Jiri Olsa AuthorDate: Wed, 23 Sep 2015 12:33:56 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 28 Sep 2015 15:50:54 -0300 tools build: Add Makefile.include To ease up build framework code setup for users. More shared code will be added in the following patches. Signed-off-by: Jiri Olsa Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1443004442-32660-2-git-send-email-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/build/Documentation/Build.txt | 45 ++--- tools/build/Makefile.include| 1 + tools/build/tests/ex/Makefile | 3 ++- tools/lib/api/Makefile | 2 +- tools/lib/bpf/Makefile | 2 +- tools/lib/lockdep/Makefile | 2 +- tools/perf/Makefile.perf| 2 +- 7 files changed, 39 insertions(+), 18 deletions(-) diff --git a/tools/build/Documentation/Build.txt b/tools/build/Documentation/Build.txt index aa5e092..8882435 100644 --- a/tools/build/Documentation/Build.txt +++ b/tools/build/Documentation/Build.txt @@ -11,8 +11,9 @@ Unlike the kernel we don't have a single build object 'obj-y' list that where we setup source objects, but we support more. This allows one 'Build' file to carry a sources list for multiple build objects. -a) Build framework makefiles - + +Build framework makefiles +- The build framework consists of 2 Makefiles: @@ -23,7 +24,7 @@ While the 'Build.include' file contains just some generic definitions, the 'Makefile.build' file is the makefile used from the outside. It's interface/usage is following: - $ make -f tools/build/Makefile srctree=$(KSRC) dir=$(DIR) obj=$(OBJECT) + $ make -f tools/build/Makefile.build srctree=$(KSRC) dir=$(DIR) obj=$(OBJECT) where: @@ -38,8 +39,9 @@ called $(OBJECT)-in.o: which includes all compiled sources described in 'Build' makefiles. -a) Build makefiles --- + +Build makefiles +--- The user supplies 'Build' makefiles that contains a objects list, and connects the build to nested directories. @@ -95,8 +97,24 @@ It's only a matter of 2 single commands to create the final binaries: You can check the 'ex' example in 'tools/build/tests/ex' for more details. -b) Rules - + +Makefile.include + + +The tools/build/Makefile.include makefile could be included +via user makefiles to get usefull definitions. + +It defines following interface: + + - build macro definition: + build := -f $(srctree)/tools/build/Makefile.build dir=. obj + +to make it easier to invoke build like: + make $(build)=ex + + +Rules +- The build framework provides standard compilation rules to handle .S and .c compilation. @@ -104,8 +122,9 @@ compilation. It's possible to include special rule if needed (like we do for flex or bison code generation). -c) CFLAGS -- + +CFLAGS +-- It's possible to alter the standard object C flags in the following way: @@ -115,8 +134,8 @@ It's possible to alter the standard object C flags in the following way: This C flags changes has the scope of the Build makefile they are defined in. -d) Dependencies +Dependencies + For each built object file 'a.o' the '.a.cmd' is created and holds: @@ -130,8 +149,8 @@ All existing '.cmd' files are included in the Build process to follow properly the dependencies and trigger a rebuild when necessary. -e) Single rules +Single rules + It's possible to build single object file by choice, like: diff --git a/tools/build/Makefile.include b/tools/build/Makefile.include new file mode 100644 index 000..91bc606 --- /dev/null +++ b/tools/build/Makefile.include @@ -0,0 +1 @@ +build := -f $(srctree)/tools/build/Makefile.build dir=. obj diff --git a/tools/build/tests/ex/Makefile b/tools/build/tests/ex/Makefile index 52d2476..a8f596e 100644 --- a/tools/build/tests/ex/Makefile +++ b/tools/build/tests/ex/Makefile @@ -3,7 +3,8 @@ export CC := gcc export LD := ld export AR := ar -build := -f $(srctree)/tools/build/Makefile.build dir=. obj +include $(srctree)/tools/build/Makefile.include + ex: ex-in.o libex-in.o gcc -o $@ $^ diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile index fe1b02c..8806ea7 100644 --- a/tools/lib/api/Makefile +++ b/tools/lib/api/Makefile @@ -21,10 +21,10 @@ CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 RM = rm -f -build := -f $(srctree)/tools/build/Makefile.build dir=. obj API_IN := $(OUTPUT)libapi-in.o export srctree OUTPUT CC LD CFLAGS V +include $(srctree)/tools/build/Makefile.include all: $(LIBFILE) diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile index e630f9f..c66ade6 100644
[tip:perf/core] tools build: Add test for missing include
Commit-ID: 0c00c3fb4e4a6ff714b7ad864f58e0fb33b3534c
Gitweb: http://git.kernel.org/tip/0c00c3fb4e4a6ff714b7ad864f58e0fb33b3534c
Author: Jiri Olsa
AuthorDate: Wed, 23 Sep 2015 12:33:57 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 15:50:54 -0300
tools build: Add test for missing include
The current build framework fails to cope with header file removal. The
reason is that the removed header file stays in the .cmd file target
rule and forces the build to fail.
This issue is fixed and explained in the following patches.
Adding a new build test that simulates header removal.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1443004442-32660-3-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/build/tests/ex/Build| 1 +
tools/build/tests/ex/Makefile | 2 +-
tools/build/tests/ex/ex.c | 2 ++
tools/build/tests/ex/inc.c| 8
tools/build/tests/run.sh | 27 +++
5 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/tools/build/tests/ex/Build b/tools/build/tests/ex/Build
index 429c7d4..4d502f9 100644
--- a/tools/build/tests/ex/Build
+++ b/tools/build/tests/ex/Build
@@ -4,6 +4,7 @@ ex-y += b.o
ex-y += b.o
ex-y += empty/
ex-y += empty2/
+ex-y += inc.o
libex-y += c.o
libex-y += d.o
diff --git a/tools/build/tests/ex/Makefile b/tools/build/tests/ex/Makefile
index a8f596e..f279b84 100644
--- a/tools/build/tests/ex/Makefile
+++ b/tools/build/tests/ex/Makefile
@@ -1,4 +1,4 @@
-export srctree := ../../../..
+export srctree := $(abspath ../../../..)
export CC := gcc
export LD := ld
export AR := ar
diff --git a/tools/build/tests/ex/ex.c b/tools/build/tests/ex/ex.c
index dc42eb2..57de607 100644
--- a/tools/build/tests/ex/ex.c
+++ b/tools/build/tests/ex/ex.c
@@ -5,6 +5,7 @@ int c(void);
int d(void);
int e(void);
int f(void);
+int inc(void);
int main(void)
{
@@ -14,6 +15,7 @@ int main(void)
d();
e();
f();
+ inc();
return 0;
}
diff --git a/tools/build/tests/ex/inc.c b/tools/build/tests/ex/inc.c
new file mode 100644
index 000..c20f1e9
--- /dev/null
+++ b/tools/build/tests/ex/inc.c
@@ -0,0 +1,8 @@
+#ifdef INCLUDE
+#include "krava.h"
+#endif
+
+int inc(void)
+{
+ return 0;
+}
diff --git a/tools/build/tests/run.sh b/tools/build/tests/run.sh
index 5494f8e..44d2a0f 100755
--- a/tools/build/tests/run.sh
+++ b/tools/build/tests/run.sh
@@ -34,9 +34,36 @@ function test_ex_suffix {
make -C ex V=1 clean > /dev/null 2>&1
rm -f ex.out
}
+
+function test_ex_include {
+ make -C ex V=1 clean > ex.out 2>&1
+
+ # build with krava.h include
+ touch ex/krava.h
+ make -C ex V=1 CFLAGS=-DINCLUDE >> ex.out 2>&1
+
+ if [ ! -x ./ex/ex ]; then
+ echo FAILED
+ exit -1
+ fi
+
+ # build without the include
+ rm -f ex/krava.h ex/ex
+ make -C ex V=1 >> ex.out 2>&1
+
+ if [ ! -x ./ex/ex ]; then
+ echo FAILED
+ exit -1
+ fi
+
+ make -C ex V=1 clean > /dev/null 2>&1
+ rm -f ex.out
+}
+
echo -n Testing..
test_ex
test_ex_suffix
+test_ex_include
echo OK
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools build: Add fixdep dependency helper
Commit-ID: 9f7ef9854e800bc3bab3d9a527e8f8f960eec1a6
Gitweb: http://git.kernel.org/tip/9f7ef9854e800bc3bab3d9a527e8f8f960eec1a6
Author: Jiri Olsa
AuthorDate: Wed, 23 Sep 2015 12:33:58 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 15:50:55 -0300
tools build: Add fixdep dependency helper
For dependency tracking we currently use targets that fall out of the
gcc -MD command. We store this info in the .cmd file and include as
makefile during the build.
This format put object as target and all the c and header files as
dependencies, like:
util/abspath.o: util/abspath.c /usr/include/stdc-predef.h util/cache.h \
/usr/include/bits/wordsize.h /usr/include/gnu/stubs.h \
...
If any of those dependency header files (krava.h below) is removed the
build fails on:
make[1]: *** No rule to make target 'krava.h', needed by 'inc.o'. Stop.
This patch adds fixdep helper, that is used by kbuild to alter the shape
of the object dependencies like:
source_util/abspath.o := util/abspath.c
deps_util/abspath.o := \
/usr/include/stdc-predef.h \
util/cache.h \
...
util/abspath.o: $(deps_util/abspath.o)
$(deps_util/abspath.o):
With this format the header removal won't make the build fail, because
it'll be picked up by the last empty target defined for each header.
As previously mentioned the fixdep tool is taken from kbuild. It's not
complete backport, only the part that alters the standard dependency
info was taken, the part that adds the CONFIG_* dependency logic will be
probably taken later on.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Kai Germaschewski
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1443004442-32660-4-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/build/Build| 1 +
tools/build/Makefile | 43 +
tools/build/fixdep.c | 168 +++
3 files changed, 212 insertions(+)
diff --git a/tools/build/Build b/tools/build/Build
new file mode 100644
index 000..63a6c34
--- /dev/null
+++ b/tools/build/Build
@@ -0,0 +1 @@
+fixdep-y := fixdep.o
diff --git a/tools/build/Makefile b/tools/build/Makefile
new file mode 100644
index 000..a930362
--- /dev/null
+++ b/tools/build/Makefile
@@ -0,0 +1,43 @@
+ifeq ($(srctree),)
+srctree := $(patsubst %/,%,$(dir $(shell pwd)))
+srctree := $(patsubst %/,%,$(dir $(srctree)))
+endif
+
+include $(srctree)/tools//scripts/Makefile.include
+
+define allow-override
+ $(if $(or $(findstring environment,$(origin $(1))),\
+$(findstring command line,$(origin $(1,,\
+$(eval $(1) = $(2)))
+endef
+
+$(call allow-override,CC,$(CROSS_COMPILE)gcc)
+$(call allow-override,LD,$(CROSS_COMPILE)ld)
+
+ifeq ($(V),1)
+ Q =
+else
+ Q = @
+endif
+
+export Q srctree CC LD
+
+MAKEFLAGS := --no-print-directory
+build := -f $(srctree)/tools/build/Makefile.build dir=. obj
+
+all: fixdep
+
+clean:
+ $(call QUIET_CLEAN, fixdep)
+ $(Q)find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name
'\.*.d' -delete
+ $(Q)rm -f fixdep
+
+$(OUTPUT)fixdep-in.o: FORCE
+ $(Q)$(MAKE) $(build)=fixdep
+
+$(OUTPUT)fixdep: $(OUTPUT)fixdep-in.o
+ $(QUIET_LINK)$(CC) $(LDFLAGS) -o $@ $<
+
+FORCE:
+
+.PHONY: FORCE
diff --git a/tools/build/fixdep.c b/tools/build/fixdep.c
new file mode 100644
index 000..1521d36
--- /dev/null
+++ b/tools/build/fixdep.c
@@ -0,0 +1,168 @@
+/*
+ * "Optimize" a list of dependencies as spit out by gcc -MD
+ * for the build framework.
+ *
+ * Original author:
+ * Copyright2002 by Kai Germaschewski
+ *
+ * This code has been borrowed from kbuild's fixdep (scripts/basic/fixdep.c),
+ * Please check it for detailed explanation. This fixdep borow only the
+ * base transformation of dependecies without the CONFIG mangle.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+char *target;
+char *depfile;
+char *cmdline;
+
+static void usage(void)
+{
+ fprintf(stderr, "Usage: fixdep \n");
+ exit(1);
+}
+
+/*
+ * Print out the commandline prefixed with cmd_ :=
+ */
+static void print_cmdline(void)
+{
+ printf("cmd_%s := %s\n\n", target, cmdline);
+}
+
+/*
+ * Important: The below generated source_foo.o and deps_foo.o variable
+ * assignments are parsed not only by make, but also by the rather simple
+ * parser in scripts/mod/sumversion.c.
+ */
+static void parse_dep_file(void *map, size_t len)
+{
+ char *m = map;
+ char *end = m + len;
+ char *p;
+ char s[PATH_MAX];
+ int is_target;
+ int saw_any_target = 0;
+ int is_first_dep = 0;
+
+ while (m < end) {
+ /* Skip any "white space" */
+ while (m < end && (*m == ' ' || *m == '\\' || *m == '\n'))
+ m++;
+ /* Find next "white space" */
+ p = m;
+ while (p < end && *p != ' ' && *p != '\\' && *p !=
[tip:perf/core] tools build: Make the fixdep helper part of the build process
Commit-ID: 9fb81323eb3085b6a47fe81d78541958ae7eaea3 Gitweb: http://git.kernel.org/tip/9fb81323eb3085b6a47fe81d78541958ae7eaea3 Author: Jiri Olsa AuthorDate: Wed, 23 Sep 2015 12:34:00 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 28 Sep 2015 15:50:55 -0300 tools build: Make the fixdep helper part of the build process Making the fixdep helper to be invoked within dep-cmd. Each user of the build framework needs to make sure fixdep exists before executing the build itself. If the build doesn't find fixdep, it falls back to the old style dependency tracking. Signed-off-by: Jiri Olsa Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1443004442-32660-6-git-send-email-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/build/Build.include | 10 -- tools/build/Makefile.build | 7 +++ 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/tools/build/Build.include b/tools/build/Build.include index 851c420..4d000bc 100644 --- a/tools/build/Build.include +++ b/tools/build/Build.include @@ -58,8 +58,14 @@ any-prereq = $(filter-out $(PHONY),$?) $(filter-out $(PHONY) $(wildcard $^),$^) # Copy dependency data into .cmd file # - gcc -M dependency info # - command line to create object 'cmd_object :=' -dep-cmd = cat $(depfile) > $(dot-target).cmd; \ - printf '%s\n' 'cmd_$@ := $(make-cmd)' >> $(dot-target).cmd +dep-cmd = $(if $(wildcard $(fixdep)), \ + $(fixdep) $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp; \ + rm -f $(depfile); \ + mv -f $(dot-target).tmp $(dot-target).cmd, \ + printf '\# cannot find fixdep (%s)\n' $(fixdep) > $(dot-target).cmd; \ + printf '\# using basic dep data\n\n' >> $(dot-target).cmd; \ + cat $(depfile) >> $(dot-target).cmd; \ + printf '%s\n' 'cmd_$@ := $(make-cmd)' >> $(dot-target).cmd) ### # if_changed_dep - execute command if any prerequisite is newer than diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build index 0c5f485..4a96473 100644 --- a/tools/build/Makefile.build +++ b/tools/build/Makefile.build @@ -21,6 +21,13 @@ endif build-dir := $(srctree)/tools/build +# Define $(fixdep) for dep-cmd function +ifeq ($(OUTPUT),) + fixdep := $(build-dir)/fixdep +else + fixdep := $(OUTPUT)/fixdep +endif + # Generic definitions include $(build-dir)/Build.include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Rename the 'single_dep' target to ' prepare'
Commit-ID: 324c824ade1cad094a21e6177b9aa7977146feeb Gitweb: http://git.kernel.org/tip/324c824ade1cad094a21e6177b9aa7977146feeb Author: Jiri Olsa AuthorDate: Wed, 23 Sep 2015 12:34:01 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 28 Sep 2015 15:50:55 -0300 perf tools: Rename the 'single_dep' target to 'prepare' And use the new 'prepare' target for the $(PERF_IN) target. Signed-off-by: Jiri Olsa Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1443004442-32660-7-git-send-email-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile.perf | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 6dec866..25c1753 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -299,7 +299,7 @@ PERF_IN := $(OUTPUT)perf-in.o export srctree OUTPUT RM CC LD AR CFLAGS V BISON FLEX AWK include $(srctree)/tools/build/Makefile.include -$(PERF_IN): $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h FORCE +$(PERF_IN): prepare FORCE $(Q)$(MAKE) $(build)=perf $(OUTPUT)perf: $(PERFLIBS) $(PERF_IN) $(LIBTRACEEVENT_DYNAMIC_LIST) @@ -349,27 +349,27 @@ endif __build-dir = $(subst $(OUTPUT),,$(dir $@)) build-dir = $(if $(__build-dir),$(__build-dir),.) -single_dep: $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h +prepare: $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h -$(OUTPUT)%.o: %.c single_dep FORCE +$(OUTPUT)%.o: %.c prepare FORCE $(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@ -$(OUTPUT)%.i: %.c single_dep FORCE +$(OUTPUT)%.i: %.c prepare FORCE $(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@ -$(OUTPUT)%.s: %.c single_dep FORCE +$(OUTPUT)%.s: %.c prepare FORCE $(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@ -$(OUTPUT)%-bison.o: %.c single_dep FORCE +$(OUTPUT)%-bison.o: %.c prepare FORCE $(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@ -$(OUTPUT)%-flex.o: %.c single_dep FORCE +$(OUTPUT)%-flex.o: %.c prepare FORCE $(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@ -$(OUTPUT)%.o: %.S single_dep FORCE +$(OUTPUT)%.o: %.S prepare FORCE $(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@ -$(OUTPUT)%.i: %.S single_dep FORCE +$(OUTPUT)%.i: %.S prepare FORCE $(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@ $(OUTPUT)perf-%: %.o $(PERFLIBS) @@ -591,6 +591,6 @@ FORCE: .PHONY: all install clean config-clean strip install-gtk .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell -.PHONY: $(GIT-HEAD-PHONY) TAGS tags cscope FORCE single_dep +.PHONY: $(GIT-HEAD-PHONY) TAGS tags cscope FORCE prepare .PHONY: libtraceevent_plugins -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:ras/core] x86/mce: Don' t clear shared banks on Intel when offlining CPUs
Commit-ID: 6e06780a98f149f131d46c1108d4ae27f05a9357
Gitweb: http://git.kernel.org/tip/6e06780a98f149f131d46c1108d4ae27f05a9357
Author: Ashok Raj
AuthorDate: Mon, 28 Sep 2015 09:21:43 +0200
Committer: Ingo Molnar
CommitDate: Mon, 28 Sep 2015 10:15:26 +0200
x86/mce: Don't clear shared banks on Intel when offlining CPUs
It is not safe to clear global MCi_CTL banks during CPU offline
or suspend/resume operations. These MSRs are either
thread-scoped (meaning private to a thread), or core-scoped
(private to threads in that core only), or with a socket scope:
visible and controllable from all threads in the socket.
When we offline a single CPU, clearing those MCi_CTL bits will
stop signaling for all the shared, i.e., socket-wide resources,
such as LLC, iMC, etc.
In addition, it might be possible to compromise the integrity of
an Intel Secure Guard eXtentions (SGX) system if the attacker
has control of the host system and is able to inject errors
which would be otherwise ignored when MCi_CTL bits are cleared.
Hence on SGX enabled systems, if MCi_CTL is cleared, SGX gets
disabled.
Tested-by: Serge Ayoun
Signed-off-by: Ashok Raj
[ Cleanup text. ]
Signed-off-by: Borislav Petkov
Reviewed-by: Tony Luck
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-edac
Link:
http://lkml.kernel.org/r/1441391390-16985-1-git-send-email-ashok@intel.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/cpu/mcheck/mce.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 9d014b82..17b5ec6 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -2042,7 +2042,7 @@ int __init mcheck_init(void)
* Disable machine checks on suspend and shutdown. We can't really handle
* them later.
*/
-static int mce_disable_error_reporting(void)
+static void mce_disable_error_reporting(void)
{
int i;
@@ -2052,17 +2052,32 @@ static int mce_disable_error_reporting(void)
if (b->init)
wrmsrl(MSR_IA32_MCx_CTL(i), 0);
}
- return 0;
+ return;
+}
+
+static void vendor_disable_error_reporting(void)
+{
+ /*
+* Don't clear on Intel CPUs. Some of these MSRs are socket-wide.
+* Disabling them for just a single offlined CPU is bad, since it will
+* inhibit reporting for all shared resources on the socket like the
+* last level cache (LLC), the integrated memory controller (iMC), etc.
+*/
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
+ return;
+
+ mce_disable_error_reporting();
}
static int mce_syscore_suspend(void)
{
- return mce_disable_error_reporting();
+ vendor_disable_error_reporting();
+ return 0;
}
static void mce_syscore_shutdown(void)
{
- mce_disable_error_reporting();
+ vendor_disable_error_reporting();
}
/*
@@ -2342,19 +2357,14 @@ static void mce_device_remove(unsigned int cpu)
static void mce_disable_cpu(void *h)
{
unsigned long action = *(unsigned long *)h;
- int i;
if (!mce_available(raw_cpu_ptr(&cpu_info)))
return;
if (!(action & CPU_TASKS_FROZEN))
cmci_clear();
- for (i = 0; i < mca_cfg.banks; i++) {
- struct mce_bank *b = &mce_banks[i];
- if (b->init)
- wrmsrl(MSR_IA32_MCx_CTL(i), 0);
- }
+ vendor_disable_error_reporting();
}
static void mce_reenable_cpu(void *h)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf intel-pt: Fix potential loop forever
Commit-ID: 9992c2d50a73f442653968a98a9e5f3bf4e769e9
Gitweb: http://git.kernel.org/tip/9992c2d50a73f442653968a98a9e5f3bf4e769e9
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:34 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:44:31 -0300
perf intel-pt: Fix potential loop forever
TSC packets contain only 7 bytes of TSC. The 8th byte is assumed to
change so infrequently that its value can be inferred. However the
logic must cater for a 7 byte wraparound, which it does by adding 1 to
the top byte.
The existing code was doing that with a while loop even though the
addition should only need to be done once. That logic won't work (will
loop forever) if TSC wraps around at the 8th byte. Theoretically that
would take at least 10 years, unless something else went wrong.
And what else could go wrong. Well, if the chunks of trace data are
processed out of order, it will make it look like the 7-byte TSC has
gone backwards (i.e. wrapped). If that happens 256 times then stuck in
the while loop it will be.
Fix that by getting rid of the unnecessary while loop.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-4-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
index 22ba502..9409d01 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -650,7 +650,7 @@ static int intel_pt_calc_cyc_cb(struct intel_pt_pkt_info
*pkt_info)
if (data->from_mtc && timestamp < data->timestamp &&
data->timestamp - timestamp < decoder->tsc_slip)
return 1;
- while (timestamp < data->timestamp)
+ if (timestamp < data->timestamp)
timestamp += (1ULL << 56);
if (pkt_info->last_packet_type != INTEL_PT_CYC) {
if (data->from_mtc)
@@ -1191,7 +1191,7 @@ static void intel_pt_calc_tsc_timestamp(struct
intel_pt_decoder *decoder)
timestamp);
timestamp = decoder->timestamp;
}
- while (timestamp < decoder->timestamp) {
+ if (timestamp < decoder->timestamp) {
intel_pt_log_to("Wraparound timestamp", timestamp);
timestamp += (1ULL << 56);
decoder->tsc_timestamp = timestamp;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools build: Build fixdep helper from perf and basic libs
Commit-ID: 7c422f5572667fef0db38d2046ecce69dcf0afc8 Gitweb: http://git.kernel.org/tip/7c422f5572667fef0db38d2046ecce69dcf0afc8 Author: Jiri Olsa AuthorDate: Wed, 23 Sep 2015 12:34:02 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 28 Sep 2015 15:50:55 -0300 tools build: Build fixdep helper from perf and basic libs Adding the fixdep target into the Makefile.include to ease up building of fixdep helper, that needs to be built before we dive in to the build itself. The user can invoke the fixdep target to build the helper. Signed-off-by: Jiri Olsa Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1443004442-32660-8-git-send-email-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/build/Documentation/Build.txt | 7 +++ tools/build/Makefile.include| 5 + tools/build/tests/ex/Makefile | 8 +--- tools/lib/api/Makefile | 4 +++- tools/lib/bpf/Makefile | 4 +++- tools/lib/lockdep/Makefile | 4 +++- tools/perf/Makefile.perf| 12 ++-- 7 files changed, 32 insertions(+), 12 deletions(-) diff --git a/tools/build/Documentation/Build.txt b/tools/build/Documentation/Build.txt index 8882435..a47bffb 100644 --- a/tools/build/Documentation/Build.txt +++ b/tools/build/Documentation/Build.txt @@ -113,6 +113,13 @@ It defines following interface: make $(build)=ex +Fixdep +-- +It is necessary to build the fixdep helper before invoking the build. +The Makefile.include file adds the fixdep target, that could be +invoked by the user. + + Rules - diff --git a/tools/build/Makefile.include b/tools/build/Makefile.include index 91bc606..6572bb0 100644 --- a/tools/build/Makefile.include +++ b/tools/build/Makefile.include @@ -1 +1,6 @@ build := -f $(srctree)/tools/build/Makefile.build dir=. obj + +fixdep: + $(Q)$(MAKE) -C $(srctree)/tools/build fixdep + +.PHONY: fixdep diff --git a/tools/build/tests/ex/Makefile b/tools/build/tests/ex/Makefile index f279b84..c50d578 100644 --- a/tools/build/tests/ex/Makefile +++ b/tools/build/tests/ex/Makefile @@ -3,18 +3,20 @@ export CC := gcc export LD := ld export AR := ar +ex: + include $(srctree)/tools/build/Makefile.include ex: ex-in.o libex-in.o gcc -o $@ $^ -ex.%: FORCE +ex.%: fixdep FORCE make -f $(srctree)/tools/build/Makefile.build dir=. $@ -ex-in.o: FORCE +ex-in.o: fixdep FORCE make $(build)=ex -libex-in.o: FORCE +libex-in.o: fixdep FORCE make $(build)=libex clean: diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile index 8806ea7..d85904d 100644 --- a/tools/lib/api/Makefile +++ b/tools/lib/api/Makefile @@ -23,10 +23,12 @@ RM = rm -f API_IN := $(OUTPUT)libapi-in.o +all: + export srctree OUTPUT CC LD CFLAGS V include $(srctree)/tools/build/Makefile.include -all: $(LIBFILE) +all: fixdep $(LIBFILE) $(API_IN): FORCE @$(MAKE) $(build)=libapi diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile index c66ade6..fc9af57 100644 --- a/tools/lib/bpf/Makefile +++ b/tools/lib/bpf/Makefile @@ -123,6 +123,8 @@ endif # the same command line setup. MAKEOVERRIDES= +all: + export srctree OUTPUT CC LD CFLAGS V include $(srctree)/tools/build/Makefile.include @@ -133,7 +135,7 @@ CMD_TARGETS = $(LIB_FILE) TARGETS = $(CMD_TARGETS) -all: $(VERSION_FILES) all_cmd +all: fixdep $(VERSION_FILES) all_cmd all_cmd: $(CMD_TARGETS) diff --git a/tools/lib/lockdep/Makefile b/tools/lib/lockdep/Makefile index d12081d..7e319af 100644 --- a/tools/lib/lockdep/Makefile +++ b/tools/lib/lockdep/Makefile @@ -93,6 +93,8 @@ else print_install = echo ' INSTALL '$1' to $(DESTDIR_SQ)$2'; endif +all: + export srctree OUTPUT CC LD CFLAGS V include $(srctree)/tools/build/Makefile.include @@ -109,7 +111,7 @@ CMD_TARGETS = $(LIB_FILE) TARGETS = $(CMD_TARGETS) -all: all_cmd +all: fixdep all_cmd all_cmd: $(CMD_TARGETS) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 25c1753..56517d3 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -306,7 +306,7 @@ $(OUTPUT)perf: $(PERFLIBS) $(PERF_IN) $(LIBTRACEEVENT_DYNAMIC_LIST) $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $(LIBTRACEEVENT_DYNAMIC_LIST_LDFLAGS) \ $(PERF_IN) $(LIBS) -o $@ -$(GTK_IN): FORCE +$(GTK_IN): fixdep FORCE $(Q)$(MAKE) $(build)=gtk $(OUTPUT)libperf-gtk.so: $(GTK_IN) $(PERFLIBS) @@ -349,7 +349,7 @@ endif __build-dir = $(subst $(OUTPUT),,$(dir $@)) build-dir = $(if $(__build-dir),$(__build-dir),.) -prepare: $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h +prepare: $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h fixdep $(OUTPUT)%.o: %.c prepare FORCE $(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@ @@ -389,7 +389,7 @@ $(patsubst perf-%,%.o,$(PROGRAMS)): $(wildcard */*.h) LIBPERF_IN := $(OUTPUT)libperf-in.o -$(LIBPERF
[tip:perf/core] perf intel-pt: Make logging slightly more efficient
Commit-ID: 116f349c5bf8c7aec4047dd6e06c310354b46e4f
Gitweb: http://git.kernel.org/tip/116f349c5bf8c7aec4047dd6e06c310354b46e4f
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:35 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:45:26 -0300
perf intel-pt: Make logging slightly more efficient
Logging is only used for debugging. Use macros to save calling into the
functions only to return immediately when logging is not enabled.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-5-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/intel-pt-decoder/intel-pt-log.c | 21 +++---
tools/perf/util/intel-pt-decoder/intel-pt-log.h | 38 +
2 files changed, 43 insertions(+), 16 deletions(-)
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-log.c
b/tools/perf/util/intel-pt-decoder/intel-pt-log.c
index d09c7d9..319bef3 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-log.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-log.c
@@ -29,18 +29,18 @@
static FILE *f;
static char log_name[MAX_LOG_NAME];
-static bool enable_logging;
+bool intel_pt_enable_logging;
void intel_pt_log_enable(void)
{
- enable_logging = true;
+ intel_pt_enable_logging = true;
}
void intel_pt_log_disable(void)
{
if (f)
fflush(f);
- enable_logging = false;
+ intel_pt_enable_logging = false;
}
void intel_pt_log_set_name(const char *name)
@@ -80,7 +80,7 @@ static void intel_pt_print_no_data(uint64_t pos, int indent)
static int intel_pt_log_open(void)
{
- if (!enable_logging)
+ if (!intel_pt_enable_logging)
return -1;
if (f)
@@ -91,15 +91,15 @@ static int intel_pt_log_open(void)
f = fopen(log_name, "w+");
if (!f) {
- enable_logging = false;
+ intel_pt_enable_logging = false;
return -1;
}
return 0;
}
-void intel_pt_log_packet(const struct intel_pt_pkt *packet, int pkt_len,
-uint64_t pos, const unsigned char *buf)
+void __intel_pt_log_packet(const struct intel_pt_pkt *packet, int pkt_len,
+ uint64_t pos, const unsigned char *buf)
{
char desc[INTEL_PT_PKT_DESC_MAX];
@@ -111,7 +111,7 @@ void intel_pt_log_packet(const struct intel_pt_pkt *packet,
int pkt_len,
fprintf(f, "%s\n", desc);
}
-void intel_pt_log_insn(struct intel_pt_insn *intel_pt_insn, uint64_t ip)
+void __intel_pt_log_insn(struct intel_pt_insn *intel_pt_insn, uint64_t ip)
{
char desc[INTEL_PT_INSN_DESC_MAX];
size_t len = intel_pt_insn->length;
@@ -128,7 +128,8 @@ void intel_pt_log_insn(struct intel_pt_insn *intel_pt_insn,
uint64_t ip)
fprintf(f, "Bad instruction!\n");
}
-void intel_pt_log_insn_no_data(struct intel_pt_insn *intel_pt_insn, uint64_t
ip)
+void __intel_pt_log_insn_no_data(struct intel_pt_insn *intel_pt_insn,
+uint64_t ip)
{
char desc[INTEL_PT_INSN_DESC_MAX];
@@ -142,7 +143,7 @@ void intel_pt_log_insn_no_data(struct intel_pt_insn
*intel_pt_insn, uint64_t ip)
fprintf(f, "Bad instruction!\n");
}
-void intel_pt_log(const char *fmt, ...)
+void __intel_pt_log(const char *fmt, ...)
{
va_list args;
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-log.h
b/tools/perf/util/intel-pt-decoder/intel-pt-log.h
index db3942f..debe751 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-log.h
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-log.h
@@ -25,20 +25,46 @@ void intel_pt_log_enable(void);
void intel_pt_log_disable(void);
void intel_pt_log_set_name(const char *name);
-void intel_pt_log_packet(const struct intel_pt_pkt *packet, int pkt_len,
-uint64_t pos, const unsigned char *buf);
+void __intel_pt_log_packet(const struct intel_pt_pkt *packet, int pkt_len,
+ uint64_t pos, const unsigned char *buf);
struct intel_pt_insn;
-void intel_pt_log_insn(struct intel_pt_insn *intel_pt_insn, uint64_t ip);
-void intel_pt_log_insn_no_data(struct intel_pt_insn *intel_pt_insn,
- uint64_t ip);
+void __intel_pt_log_insn(struct intel_pt_insn *intel_pt_insn, uint64_t ip);
+void __intel_pt_log_insn_no_data(struct intel_pt_insn *intel_pt_insn,
+uint64_t ip);
__attribute__((format(printf, 1, 2)))
-void intel_pt_log(const char *fmt, ...);
+void __intel_pt_log(const char *fmt, ...);
+
+#define intel_pt_log(fmt, ...) \
+ do { \
+ if (intel_pt_enable_logging) \
+ __intel_pt_log(fmt, ##__VA_ARGS__); \
+ } while (0)
+
+#define intel_pt_log_packet(arg, ...) \
+ do { \
+ if (intel_pt_enable_logging) \
+ __intel_pt_log_packet(arg, ##__VA_ARGS__); \
+ } while (0
Re: [PATCH 02/11] x86/mm/hotplug: Remove pgd_list use from the memory hotplug code
* Oleg Nesterov wrote:
> On 09/22, Linus Torvalds wrote:
> >
> > However, this now becomes a pattern for the series, and that just makes me
> > think
> >
> > "Why is this not a 'for_each_mm()' pattern helper?"
>
> And we already have other users. And note that oom_kill_process() does _not_
> follow this pattern and that is why it is buggy.
>
> So this is funny, but I was thinking about almost the same, something like
>
> struct task_struct *next_task_with_mm(struct task_struct *p)
> {
> struct task_struct *t;
>
> p = p->group_leader;
> while ((p = next_task(p)) != &init_task) {
> if (p->flags & PF_KTHREAD)
> continue;
>
> t = find_lock_task_mm(p);
> if (t)
> return t;
> }
>
> return NULL;
> }
>
> #define for_each_task_lock_mm(p)
> for (p = &init_task; (p = next_task_with_mm(p)); task_unlock(p))
>
>
> So that you can do
>
> for_each_task_lock_mm(p) {
> do_something_with(p->mm);
>
> if (some_condition()) {
> // UNFORTUNATELY you can't just do "break"
> task_unlock(p);
> break;
> }
> }
>
> do you think it makes sense?
Sure, I'm inclined to use the above code from you.
> In fact it can't be simpler, we can move task_unlock() into
> next_task_with_mm(),
> it can check ->mm != NULL or p != init_task.
s/can't/can ?
But even with that I'm not sure I can parse your suggestion. Got some (pseudo)
code
perhaps?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf session: Warn when AUX data has been lost
Commit-ID: a38f48e300f9dac30a9b2d2ce958c8dbd7def351
Gitweb: http://git.kernel.org/tip/a38f48e300f9dac30a9b2d2ce958c8dbd7def351
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:37 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:51:33 -0300
perf session: Warn when AUX data has been lost
By default 'perf record' will postprocess the perf.data file to
determine build-ids. When that happens, the number of lost perf events
is displayed.
Make that also happen for AUX events.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-7-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/event.h | 1 +
tools/perf/util/session.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index be5cbc7..a0dbcbd 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -257,6 +257,7 @@ struct events_stats {
u64 total_non_filtered_period;
u64 total_lost;
u64 total_lost_samples;
+ u64 total_aux_lost;
u64 total_invalid_chains;
u32 nr_events[PERF_RECORD_HEADER_MAX];
u32 nr_non_filtered_samples;
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index f5e..15c84ca 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1101,6 +1101,9 @@ static int machines__deliver_event(struct machines
*machines,
case PERF_RECORD_UNTHROTTLE:
return tool->unthrottle(tool, event, sample, machine);
case PERF_RECORD_AUX:
+ if (tool->aux == perf_event__process_aux &&
+ (event->aux.flags & PERF_AUX_FLAG_TRUNCATED))
+ evlist->stats.total_aux_lost += 1;
return tool->aux(tool, event, sample, machine);
case PERF_RECORD_ITRACE_START:
return tool->itrace_start(tool, event, sample, machine);
@@ -1346,6 +1349,13 @@ static void perf_session__warn_about_errors(const struct
perf_session *session)
}
}
+ if (session->tool->aux == perf_event__process_aux &&
+ stats->total_aux_lost != 0) {
+ ui__warning("AUX data lost %" PRIu64 " times out of %u!\n\n",
+ stats->total_aux_lost,
+ stats->nr_events[PERF_RECORD_AUX]);
+ }
+
if (stats->nr_unknown_events != 0) {
ui__warning("Found %u unknown events!\n\n"
"Is this an older tool processing a perf.data "
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Add more documentation to export-to-postgresql.py script
Commit-ID: 35ca01c117da9b8e5b60204f730cdde414735596 Gitweb: http://git.kernel.org/tip/35ca01c117da9b8e5b60204f730cdde414735596 Author: Adrian Hunter AuthorDate: Fri, 25 Sep 2015 16:15:38 +0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 28 Sep 2015 16:53:07 -0300 perf tools: Add more documentation to export-to-postgresql.py script Add some comments to the script and some 'views' to the created database that better illustrate the database structure and how it can be used. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1443186956-18718-8-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/scripts/python/export-to-postgresql.py | 221 ++ 1 file changed, 221 insertions(+) diff --git a/tools/perf/scripts/python/export-to-postgresql.py b/tools/perf/scripts/python/export-to-postgresql.py index 84a3203..1b02cdc 100644 --- a/tools/perf/scripts/python/export-to-postgresql.py +++ b/tools/perf/scripts/python/export-to-postgresql.py @@ -61,6 +61,142 @@ import datetime # # An example of using the database is provided by the script # call-graph-from-postgresql.py. Refer to that script for details. +# +# Tables: +# +# The tables largely correspond to perf tools' data structures. They are largely self-explanatory. +# +# samples +# +# 'samples' is the main table. It represents what instruction was executing at a point in time +# when something (a selected event) happened. The memory address is the instruction pointer or 'ip'. +# +# calls +# +# 'calls' represents function calls and is related to 'samples' by 'call_id' and 'return_id'. +# 'calls' is only created when the 'calls' option to this script is specified. +# +# call_paths +# +# 'call_paths' represents all the call stacks. Each 'call' has an associated record in 'call_paths'. +# 'calls_paths' is only created when the 'calls' option to this script is specified. +# +# branch_types +# +# 'branch_types' provides descriptions for each type of branch. +# +# comm_threads +# +# 'comm_threads' shows how 'comms' relates to 'threads'. +# +# comms +# +# 'comms' contains a record for each 'comm' - the name given to the executable that is running. +# +# dsos +# +# 'dsos' contains a record for each executable file or library. +# +# machines +# +# 'machines' can be used to distinguish virtual machines if virtualization is supported. +# +# selected_events +# +# 'selected_events' contains a record for each kind of event that has been sampled. +# +# symbols +# +# 'symbols' contains a record for each symbol. Only symbols that have samples are present. +# +# threads +# +# 'threads' contains a record for each thread. +# +# Views: +# +# Most of the tables have views for more friendly display. The views are: +# +# calls_view +# call_paths_view +# comm_threads_view +# dsos_view +# machines_view +# samples_view +# symbols_view +# threads_view +# +# More examples of browsing the database with psql: +# Note that some of the examples are not the most optimal SQL query. +# Note that call information is only available if the script's 'calls' option has been used. +# +# Top 10 function calls (not aggregated by symbol): +# +# SELECT * FROM calls_view ORDER BY elapsed_time DESC LIMIT 10; +# +# Top 10 function calls (aggregated by symbol): +# +# SELECT symbol_id,(SELECT name FROM symbols WHERE id = symbol_id) AS symbol, +# SUM(elapsed_time) AS tot_elapsed_time,SUM(branch_count) AS tot_branch_count +# FROM calls_view GROUP BY symbol_id ORDER BY tot_elapsed_time DESC LIMIT 10; +# +# Note that the branch count gives a rough estimation of cpu usage, so functions +# that took a long time but have a relatively low branch count must have spent time +# waiting. +# +# Find symbols by pattern matching on part of the name (e.g. names containing 'alloc'): +# +# SELECT * FROM symbols_view WHERE name LIKE '%alloc%'; +# +# Top 10 function calls for a specific symbol (e.g. whose symbol_id is 187): +# +# SELECT * FROM calls_view WHERE symbol_id = 187 ORDER BY elapsed_time DESC LIMIT 10; +# +# Show function calls made by function in the same context (i.e. same call path) (e.g. one with call_path_id 254): +# +# SELECT * FROM calls_view WHERE parent_call_path_id = 254; +# +# Show branches made during a function call (e.g. where call_id is 29357 and return_id is 29370 and tid is 29670) +# +# SELECT * FROM samples_view WHERE id >= 29357 AND i
Re: [PATCH 1/1] ASoC: ad193x: add support to ad1934
On 09/29/2015 10:36 AM, Cyrille Pitchen wrote:
> The AD1934 codec has no DAC feature. Hence it register mapping is slightly
> different from the register mapping of other members of the AD193x family.
>
> Some ASoC controls and widgets are related to the DAC feature so are not
> relevant in the case of an AD1934 codec.
Looks mostly good, thanks.
> diff --git a/sound/soc/codecs/ad193x-i2c.c b/sound/soc/codecs/ad193x-i2c.c
> index df3a1a415825..8aa50d35662f 100644
> --- a/sound/soc/codecs/ad193x-i2c.c
> +++ b/sound/soc/codecs/ad193x-i2c.c
> @@ -15,8 +15,8 @@
> #include "ad193x.h"
>
> static const struct i2c_device_id ad193x_id[] = {
> - { "ad1936", 0 },
> - { "ad1937", 0 },
> + { "ad1936", AD193x },
> + { "ad1937", AD193x },
Should be a upper case X.
> { }
> };
[...]
[...]
> @@ -91,18 +97,33 @@ static const struct snd_soc_dapm_route audio_paths[] = {
> { "DAC", NULL, "SYSCLK" },
> { "DAC Output", NULL, "DAC" },
> { "DAC Output", NULL, "VMID" },
> - { "ADC", NULL, "SYSCLK" },
> - { "DAC", NULL, "ADC_PWR" },
> - { "ADC", NULL, "ADC_PWR" },
> { "DAC1OUT", NULL, "DAC Output" },
> { "DAC2OUT", NULL, "DAC Output" },
> { "DAC3OUT", NULL, "DAC Output" },
> { "DAC4OUT", NULL, "DAC Output" },
> + { "SYSCLK", NULL, "PLL_PWR" },
> +};
> +
> +static const struct snd_soc_dapm_route adc_audio_paths[] = {
this should have the ad193x_ prefix as well.
> + { "ADC", NULL, "SYSCLK" },
> + { "ADC", NULL, "ADC_PWR" },
> { "ADC", NULL, "ADC1IN" },
> { "ADC", NULL, "ADC2IN" },
> - { "SYSCLK", NULL, "PLL_PWR" },
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf script: Allow time to be displayed in nanoseconds
Commit-ID: 83e1986032dfcd3f9e9fc0d06e11d9153edae19b
Gitweb: http://git.kernel.org/tip/83e1986032dfcd3f9e9fc0d06e11d9153edae19b
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:36 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:46:05 -0300
perf script: Allow time to be displayed in nanoseconds
Add option --ns to display time to 9 decimal places. That is useful in
some cases, for example when using Intel PT cycle accurate mode.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-6-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-script.txt | 3 +++
tools/perf/builtin-script.c | 8 +++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-script.txt
b/tools/perf/Documentation/perf-script.txt
index dc3ec78..b3b42f9 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -249,6 +249,9 @@ include::itrace.txt[]
--full-source-path::
Show the full path for source files for srcline output.
+--ns::
+ Use 9 decimal places when displaying time (i.e. show the nanoseconds)
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-script-perl[1],
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 284a76e..0928439 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -29,6 +29,7 @@ static bool no_callchain;
static boollatency_format;
static boolsystem_wide;
static boolprint_flags;
+static boolnanosecs;
static const char *cpu_list;
static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -415,7 +416,10 @@ static void print_sample_start(struct perf_sample *sample,
secs = nsecs / NSECS_PER_SEC;
nsecs -= secs * NSECS_PER_SEC;
usecs = nsecs / NSECS_PER_USEC;
- printf("%5lu.%06lu: ", secs, usecs);
+ if (nanosecs)
+ printf("%5lu.%09llu: ", secs, nsecs);
+ else
+ printf("%5lu.%06lu: ", secs, usecs);
}
}
@@ -1695,6 +1699,8 @@ int cmd_script(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_BOOLEAN('\0', "show-switch-events", &script.show_switch_events,
"Show context switch events (if recorded)"),
OPT_BOOLEAN('f', "force", &file.force, "don't complain, do it"),
+ OPT_BOOLEAN(0, "ns", &nanosecs,
+ "Use 9 decimal places when displaying time"),
OPT_CALLBACK_OPTARG(0, "itrace", &itrace_synth_opts, NULL, "opts",
"Instruction Tracing options",
itrace_parse_synth_opts),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf report: Adjust sample type validation for synthesized branch stacks
Commit-ID: c7eced63f2f67bd06ceb2269062416db9d81d29d
Gitweb: http://git.kernel.org/tip/c7eced63f2f67bd06ceb2269062416db9d81d29d
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:40 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:54:21 -0300
perf report: Adjust sample type validation for synthesized branch stacks
perf report looks at event sample types to determine if branch stacks
have been sampled. Adjust the validation to know about instruction
tracing options.
This change allows the use of the -b option which otherwise would
complain with an error like:
Error:
Selected -b but no branch data. Did you call perf record without -b?
# To display the perf.data header info,
# please use --header/--header-only options.
#
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-10-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 0d53b48..7af35af 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -220,6 +220,9 @@ static int report__setup_sample_type(struct report *rep)
!session->itrace_synth_opts->set))
sample_type |= PERF_SAMPLE_CALLCHAIN;
+ if (session->itrace_synth_opts->last_branch)
+ sample_type |= PERF_SAMPLE_BRANCH_STACK;
+
if (!is_pipe && !(sample_type & PERF_SAMPLE_CALLCHAIN)) {
if (sort__has_parent) {
ui__error("Selected --sort parent, but no "
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf report: Also do default setup for synthesized branch stacks
Commit-ID: fb9fab66e6e3ee737e521c899684c6d684b24a22 Gitweb: http://git.kernel.org/tip/fb9fab66e6e3ee737e521c899684c6d684b24a22 Author: Adrian Hunter AuthorDate: Fri, 25 Sep 2015 16:15:41 +0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 28 Sep 2015 16:54:45 -0300 perf report: Also do default setup for synthesized branch stacks The 'perf report' tool will default to displaying branch stacks (-b option) if they are present. Make that also happen for synthesized branch stacks. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1443186956-18718-11-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-report.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c index 7af35af..92f7c5a 100644 --- a/tools/perf/builtin-report.c +++ b/tools/perf/builtin-report.c @@ -829,6 +829,9 @@ repeat: has_br_stack = perf_header__has_feat(&session->header, HEADER_BRANCH_STACK); + if (itrace_synth_opts.last_branch) + has_br_stack = true; + /* * Branch mode is a tristate: * -1 means default, so decide based on the file having branch data. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/11] x86/virt/guest/xen: Remove use of pgd_list from the Xen guest code
* Linus Torvalds wrote:
> On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar wrote:
> > xen_mm_pin_all()/unpin_all() are used to implement full guest instance
> > suspend/restore. It's a stop-all method that needs to iterate through
> > all allocated pgds in the system to fix them up for Xen's use.
>
> And _this_ is why I'd reall ylike that "for_each_mm()" helper.
>
> Yeah, yeah, maybe it would require syntax like
>
> for_each_mm (tsk, mm) {
> ...
> } end_for_each_mm(mm);
>
> to do variable allocation things or cleanups (ie "end_for_each_mm()" might
> drop
> the task lock etc), but wouldn't that still be better than this complex
> boilerplate thing?
Yeah, agreed absolutely.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf auxtrace: Add option to synthesize branch stacks on samples
Commit-ID: 601897b54c7ed492a89b262dccd7c6f7faf12b30
Gitweb: http://git.kernel.org/tip/601897b54c7ed492a89b262dccd7c6f7faf12b30
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:39 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:53:44 -0300
perf auxtrace: Add option to synthesize branch stacks on samples
Add AUX area tracing option 'l' to synthesize branch stacks on samples
just like sample type PERF_SAMPLE_BRANCH_STACK. This is taken into use
by Intel PT in a subsequent patch.
Based-on-patch-by: Andi Kleen
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-9-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/itrace.txt | 4
tools/perf/util/auxtrace.c | 20
tools/perf/util/auxtrace.h | 4
3 files changed, 28 insertions(+)
diff --git a/tools/perf/Documentation/itrace.txt
b/tools/perf/Documentation/itrace.txt
index 2ff9466..65453f4 100644
--- a/tools/perf/Documentation/itrace.txt
+++ b/tools/perf/Documentation/itrace.txt
@@ -6,6 +6,7 @@
e synthesize error events
d create a debug log
g synthesize a call chain (use with i or x)
+ l synthesize last branch entries (use with i or x)
The default is all events i.e. the same as --itrace=ibxe
@@ -20,3 +21,6 @@
Also the call chain size (default 16, max. 1024) for instructions or
transactions events can be specified.
+
+ Also the number of last branch entries (default 64, max. 1024) for
+ instructions or transactions events can be specified.
diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index c4993b2..7f10430 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -926,6 +926,8 @@ s64 perf_event__process_auxtrace(struct perf_tool *tool,
#define PERF_ITRACE_DEFAULT_PERIOD 10
#define PERF_ITRACE_DEFAULT_CALLCHAIN_SZ 16
#define PERF_ITRACE_MAX_CALLCHAIN_SZ 1024
+#define PERF_ITRACE_DEFAULT_LAST_BRANCH_SZ 64
+#define PERF_ITRACE_MAX_LAST_BRANCH_SZ 1024
void itrace_synth_opts__set_default(struct itrace_synth_opts *synth_opts)
{
@@ -936,6 +938,7 @@ void itrace_synth_opts__set_default(struct
itrace_synth_opts *synth_opts)
synth_opts->period_type = PERF_ITRACE_DEFAULT_PERIOD_TYPE;
synth_opts->period = PERF_ITRACE_DEFAULT_PERIOD;
synth_opts->callchain_sz = PERF_ITRACE_DEFAULT_CALLCHAIN_SZ;
+ synth_opts->last_branch_sz = PERF_ITRACE_DEFAULT_LAST_BRANCH_SZ;
}
/*
@@ -1043,6 +1046,23 @@ int itrace_parse_synth_opts(const struct option *opt,
const char *str,
synth_opts->callchain_sz = val;
}
break;
+ case 'l':
+ synth_opts->last_branch = true;
+ synth_opts->last_branch_sz =
+ PERF_ITRACE_DEFAULT_LAST_BRANCH_SZ;
+ while (*p == ' ' || *p == ',')
+ p += 1;
+ if (isdigit(*p)) {
+ unsigned int val;
+
+ val = strtoul(p, &endptr, 10);
+ p = endptr;
+ if (!val ||
+ val > PERF_ITRACE_MAX_LAST_BRANCH_SZ)
+ goto out_err;
+ synth_opts->last_branch_sz = val;
+ }
+ break;
case ' ':
case ',':
break;
diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h
index bf72b77..b86f90db 100644
--- a/tools/perf/util/auxtrace.h
+++ b/tools/perf/util/auxtrace.h
@@ -63,7 +63,9 @@ enum itrace_period_type {
* @calls: limit branch samples to calls (can be combined with @returns)
* @returns: limit branch samples to returns (can be combined with @calls)
* @callchain: add callchain to 'instructions' events
+ * @last_branch: add branch context to 'instruction' events
* @callchain_sz: maximum callchain size
+ * @last_branch_sz: branch context size
* @period: 'instructions' events period
* @period_type: 'instructions' events period type
*/
@@ -79,7 +81,9 @@ struct itrace_synth_opts {
boolcalls;
boolreturns;
boolcallchain;
+ boollast_branch;
unsigned intcallchain_sz;
+ unsigned intlast_branch_sz;
unsigned long long period;
enum itrace_period_type period_type;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at h
[tip:perf/core] perf inject: Set branch stack feature flag when synthesizing branch stacks
Commit-ID: 051a01b9a2c1c1ef3049973a43d9ed4ddcc946f3
Gitweb: http://git.kernel.org/tip/051a01b9a2c1c1ef3049973a43d9ed4ddcc946f3
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:43 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:57:59 -0300
perf inject: Set branch stack feature flag when synthesizing branch stacks
The branch stack feature flag is set by 'perf record' when recording
data that contains branch stacks. Consequently, when 'perf inject'
synthesizes branch stacks, the feature flag should be set also.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-13-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-inject.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index f62c49b..8638fad 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -537,9 +537,13 @@ static int __cmd_inject(struct perf_inject *inject)
* The AUX areas have been removed and replaced with
* synthesized hardware events, so clear the feature flag.
*/
- if (inject->itrace_synth_opts.set)
+ if (inject->itrace_synth_opts.set) {
perf_header__clear_feat(&session->header,
HEADER_AUXTRACE);
+ if (inject->itrace_synth_opts.last_branch)
+ perf_header__set_feat(&session->header,
+ HEADER_BRANCH_STACK);
+ }
session->header.data_offset = output_data_offset;
session->header.data_size = inject->bytes_written;
perf_session__write_header(session, session->evlist, fd, true);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: shmobile: dt: Rename incorrect interrupt related binding
interrupts-names => interrupt-names Other line changes are re-aligning. Signed-off-by: Lee Jones --- .../bindings/memory-controllers/renesas-memory-controllers.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt b/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt index c64b792..9f78e6c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt +++ b/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt @@ -24,9 +24,9 @@ Required properties: Optional properties: - interrupts: Must contain a list of interrupt specifiers for memory controller interrupts, if available. - - interrupts-names: Must contain a list of interrupt names corresponding to - the interrupts in the interrupts property, if available. - Valid interrupt names are: + - interrupt-names: Must contain a list of interrupt names corresponding to +the interrupts in the interrupts property, if available. +Valid interrupt names are: - "sec" (secure interrupt) - "temp" (normal (temperature) interrupt) - power-domains: Must contain a reference to the PM domain that the memory -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf report: Skip events with null branch stacks
Commit-ID: f86225db3aa0e394915af45eea1c3cca6f3e2dba
Gitweb: http://git.kernel.org/tip/f86225db3aa0e394915af45eea1c3cca6f3e2dba
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:42 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:57:01 -0300
perf report: Skip events with null branch stacks
A non-synthesized event might not have a branch stack if branch stacks
have been synthesized (using itrace options).
An example of that is when Intel PT records sched_switch events for
decoding purposes. Those sched_switch events do not have branch stacks
even though the Intel PT decoder may be synthesizing other events that
do due to the itrace options.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-12-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 92f7c5a..e94e5c7 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -163,14 +163,21 @@ static int process_sample_event(struct perf_tool *tool,
if (rep->cpu_list && !test_bit(sample->cpu, rep->cpu_bitmap))
goto out_put;
- if (sort__mode == SORT_MODE__BRANCH)
+ if (sort__mode == SORT_MODE__BRANCH) {
+ /*
+* A non-synthesized event might not have a branch stack if
+* branch stacks have been synthesized (using itrace options).
+*/
+ if (!sample->branch_stack)
+ goto out_put;
iter.ops = &hist_iter_branch;
- else if (rep->mem_mode)
+ } else if (rep->mem_mode) {
iter.ops = &hist_iter_mem;
- else if (symbol_conf.cumulate_callchain)
+ } else if (symbol_conf.cumulate_callchain) {
iter.ops = &hist_iter_cumulative;
- else
+ } else {
iter.ops = &hist_iter_normal;
+ }
if (al.map != NULL)
al.map->dso->hit = 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf intel-pt: Support generating branch stack
Commit-ID: f14445ee72c59f32aa5cbf4d0f0330a5f62a752d
Gitweb: http://git.kernel.org/tip/f14445ee72c59f32aa5cbf4d0f0330a5f62a752d
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:45 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:59:14 -0300
perf intel-pt: Support generating branch stack
Add support for generating branch stack context for PT samples. The
decoder reports a configurable number of branches as branch context for
each sample. Internally it keeps track of them by using a simple sliding
window. We also flush the last branch buffer on each sample to avoid
overlapping intervals.
This is useful for:
- Reporting accurate basic block edge frequencies through the perf
report branch view
- Using with --branch-history to get the wider context of samples
- Other users of LBRs
Also the Documentation is updated.
Examples:
Record with Intel PT:
perf record -e intel_pt//u ls
Branch stacks are used by default if synthesized so:
perf report --itrace=ile
is the same as:
perf report --itrace=ile -b
Branch history can be requested also:
perf report --itrace=igle --branch-history
Based-on-patch-by: Andi Kleen
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-15-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/intel-pt.txt | 10 +++
tools/perf/util/intel-pt.c| 115 ++
2 files changed, 125 insertions(+)
diff --git a/tools/perf/Documentation/intel-pt.txt
b/tools/perf/Documentation/intel-pt.txt
index 886612b..a0fbb5d 100644
--- a/tools/perf/Documentation/intel-pt.txt
+++ b/tools/perf/Documentation/intel-pt.txt
@@ -671,6 +671,7 @@ The letters are:
e synthesize tracing error events
d create a debug log
g synthesize a call chain (use with i or x)
+ l synthesize last branch entries (use with i or x)
"Instructions" events look like they were recorded by "perf record -e
instructions".
@@ -718,6 +719,15 @@ transactions events can be specified. e.g.
--itrace=ig32
--itrace=xg32
+Also the number of last branch entries (default 64, max. 1024) for
instructions or
+transactions events can be specified. e.g.
+
+ --itrace=il10
+ --itrace=xl10
+
+Note that last branch entries are cleared for each sample, so there is no
overlap
+from one sample to the next.
+
To disable trace decoding entirely, use the option --no-itrace.
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 2c01e72..05e8fcc51 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -22,6 +22,7 @@
#include "../perf.h"
#include "session.h"
#include "machine.h"
+#include "sort.h"
#include "tool.h"
#include "event.h"
#include "evlist.h"
@@ -115,6 +116,9 @@ struct intel_pt_queue {
void *decoder;
const struct intel_pt_state *state;
struct ip_callchain *chain;
+ struct branch_stack *last_branch;
+ struct branch_stack *last_branch_rb;
+ size_t last_branch_pos;
union perf_event *event_buf;
bool on_heap;
bool stop;
@@ -675,6 +679,19 @@ static struct intel_pt_queue *intel_pt_alloc_queue(struct
intel_pt *pt,
goto out_free;
}
+ if (pt->synth_opts.last_branch) {
+ size_t sz = sizeof(struct branch_stack);
+
+ sz += pt->synth_opts.last_branch_sz *
+ sizeof(struct branch_entry);
+ ptq->last_branch = zalloc(sz);
+ if (!ptq->last_branch)
+ goto out_free;
+ ptq->last_branch_rb = zalloc(sz);
+ if (!ptq->last_branch_rb)
+ goto out_free;
+ }
+
ptq->event_buf = malloc(PERF_SAMPLE_MAX_SIZE);
if (!ptq->event_buf)
goto out_free;
@@ -732,6 +749,8 @@ static struct intel_pt_queue *intel_pt_alloc_queue(struct
intel_pt *pt,
out_free:
zfree(&ptq->event_buf);
+ zfree(&ptq->last_branch);
+ zfree(&ptq->last_branch_rb);
zfree(&ptq->chain);
free(ptq);
return NULL;
@@ -746,6 +765,8 @@ static void intel_pt_free_queue(void *priv)
thread__zput(ptq->thread);
intel_pt_decoder_free(ptq->decoder);
zfree(&ptq->event_buf);
+ zfree(&ptq->last_branch);
+ zfree(&ptq->last_branch_rb);
zfree(&ptq->chain);
free(ptq);
}
@@ -876,6 +897,57 @@ static int intel_pt_setup_queues(struct intel_pt *pt)
return 0;
}
+static inline void intel_pt_copy_last_branch_rb(struct intel_pt_queue *ptq)
+{
+ struct branch_stack *bs_src = ptq->last_branch_rb;
+ struct branch_stack *bs_dst = ptq->last_branch;
+ size_t nr = 0;
+
+ bs_dst->nr = bs_src->nr;
+
+ if (!bs_src->nr)
+
[tip:perf/core] perf report: Make max_stack value allow for synthesized callchains
Commit-ID: 188bb5e2ce112463428994f91291e5df6fc05521
Gitweb: http://git.kernel.org/tip/188bb5e2ce112463428994f91291e5df6fc05521
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:46 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:03:20 -0300
perf report: Make max_stack value allow for synthesized callchains
perf report has an option (--max-stack) to set the maximum stack depth
when processing callchains. The option defaults to the hard-coded
maximum definition PERF_MAX_STACK_DEPTH which is 127. The intention of
the option is to allow the user to reduce the processing time by
reducing the amount of the callchain that is processed.
It is also possible, when processing instruction traces, to synthesize
callchains. Synthesized callchains do not have the kernel size
limitation and are whatever size the user requests, although validation
presently prevents the user requested a value greater that 1024. The
default value is 16.
To allow for synthesized callchains, make the max_stack value at least
the same size as the synthesized callchain size.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-16-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index e94e5c7..37c9f51 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -809,6 +809,10 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
if (report.inverted_callchain)
callchain_param.order = ORDER_CALLER;
+ if (itrace_synth_opts.callchain &&
+ (int)itrace_synth_opts.callchain_sz > report.max_stack)
+ report.max_stack = itrace_synth_opts.callchain_sz;
+
if (!input_name || !strlen(input_name)) {
if (!fstat(STDIN_FILENO, &st) && S_ISFIFO(st.st_mode))
input_name = "-";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf script: Add a setting for maximum stack depth
Commit-ID: 03cd1fed2b8730271d3a8dbabd87989abddc33c4
Gitweb: http://git.kernel.org/tip/03cd1fed2b8730271d3a8dbabd87989abddc33c4
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:49 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:08:48 -0300
perf script: Add a setting for maximum stack depth
Add a setting for maximum stack depth in preparation for allowing for
synthesized callchains.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-19-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 6 --
tools/perf/util/session.c | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 0928439..a65b498 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -33,6 +33,8 @@ static bool nanosecs;
static const char *cpu_list;
static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
+static unsigned int scripting_max_stack = PERF_MAX_STACK_DEPTH;
+
enum perf_output_field {
PERF_OUTPUT_COMM= 1U << 0,
PERF_OUTPUT_TID = 1U << 1,
@@ -475,7 +477,7 @@ static void print_sample_bts(union perf_event *event,
}
}
perf_evsel__print_ip(evsel, sample, al, print_opts,
-PERF_MAX_STACK_DEPTH);
+scripting_max_stack);
}
/* print branch_to information */
@@ -552,7 +554,7 @@ static void process_event(union perf_event *event, struct
perf_sample *sample,
perf_evsel__print_ip(evsel, sample, al,
output[attr->type].print_ip_opts,
-PERF_MAX_STACK_DEPTH);
+scripting_max_stack);
}
if (PRINT_FIELD(IREGS))
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 15c84ca..84a02eae 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1800,7 +1800,7 @@ void perf_evsel__print_ip(struct perf_evsel *evsel,
struct perf_sample *sample,
if (thread__resolve_callchain(al->thread, evsel,
sample, NULL, NULL,
- PERF_MAX_STACK_DEPTH) != 0) {
+ stack_depth) != 0) {
if (verbose)
error("Failed to resolve callchain.
Skipping\n");
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf hists: Allow for max_stack greater than PERF_MAX_STACK_DEPTH
Commit-ID: 96b40f3c05f36e061fd4dde920b9e9c795a88b69
Gitweb: http://git.kernel.org/tip/96b40f3c05f36e061fd4dde920b9e9c795a88b69
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:47 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:06:16 -0300
perf hists: Allow for max_stack greater than PERF_MAX_STACK_DEPTH
Use the max_stack value instead of PERF_MAX_STACK_DEPTH so that
arbitrary-sized callchains can be supported.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-17-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/hist.c | 6 --
tools/perf/util/hist.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index b3567a2..0cad9e0 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -695,7 +695,7 @@ iter_finish_normal_entry(struct hist_entry_iter *iter,
}
static int
-iter_prepare_cumulative_entry(struct hist_entry_iter *iter __maybe_unused,
+iter_prepare_cumulative_entry(struct hist_entry_iter *iter,
struct addr_location *al __maybe_unused)
{
struct hist_entry **he_cache;
@@ -707,7 +707,7 @@ iter_prepare_cumulative_entry(struct hist_entry_iter *iter
__maybe_unused,
* cumulated only one time to prevent entries more than 100%
* overhead.
*/
- he_cache = malloc(sizeof(*he_cache) * (PERF_MAX_STACK_DEPTH + 1));
+ he_cache = malloc(sizeof(*he_cache) * (iter->max_stack + 1));
if (he_cache == NULL)
return -ENOMEM;
@@ -868,6 +868,8 @@ int hist_entry_iter__add(struct hist_entry_iter *iter,
struct addr_location *al,
if (err)
return err;
+ iter->max_stack = max_stack_depth;
+
err = iter->ops->prepare_entry(iter, al);
if (err)
goto out;
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 4d6aa1d..8c20a8f 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -90,6 +90,7 @@ struct hist_entry_iter {
int curr;
bool hide_unresolved;
+ int max_stack;
struct perf_evsel *evsel;
struct perf_sample *sample;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf scripting python: Allow for max_stack greater than PERF_MAX_STACK_DEPTH
Commit-ID: 44cbe7295c3808977159f500a5bcdebf12a7db5f
Gitweb: http://git.kernel.org/tip/44cbe7295c3808977159f500a5bcdebf12a7db5f
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:50 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:09:12 -0300
perf scripting python: Allow for max_stack greater than PERF_MAX_STACK_DEPTH
Use the scripting_max_stack value to allow for values greater than
PERF_MAX_STACK_DEPTH.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-20-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c| 2 +-
tools/perf/util/scripting-engines/trace-event-python.c | 2 +-
tools/perf/util/trace-event.h | 2 ++
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index a65b498..5c3c02d 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -33,7 +33,7 @@ static bool nanosecs;
static const char *cpu_list;
static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
-static unsigned int scripting_max_stack = PERF_MAX_STACK_DEPTH;
+unsigned int scripting_max_stack = PERF_MAX_STACK_DEPTH;
enum perf_output_field {
PERF_OUTPUT_COMM= 1U << 0,
diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
b/tools/perf/util/scripting-engines/trace-event-python.c
index aa9e125..a8e825f 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -319,7 +319,7 @@ static PyObject *python_process_callchain(struct
perf_sample *sample,
if (thread__resolve_callchain(al->thread, evsel,
sample, NULL, NULL,
- PERF_MAX_STACK_DEPTH) != 0) {
+ scripting_max_stack) != 0) {
pr_err("Failed to resolve callchain. Skipping\n");
goto exit;
}
diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h
index da6cc4c..b85ee55 100644
--- a/tools/perf/util/trace-event.h
+++ b/tools/perf/util/trace-event.h
@@ -78,6 +78,8 @@ struct scripting_ops {
int (*generate_script) (struct pevent *pevent, const char *outfile);
};
+extern unsigned int scripting_max_stack;
+
int script_spec_register(const char *spec, struct scripting_ops *ops);
void setup_perl_scripting(void);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Shared scaffolding to unit-test kernel code in userspace (was Re: [Intel-gfx] [PATCH] drm/i915: Add link training test)
On Wed, 2015-09-23 at 11:38 +0200, Daniel Vetter wrote: > On Wed, Sep 23, 2015 at 11:18 AM, Ander Conselvan De Oliveira > wrote: > > On Wed, 2015-09-23 at 10:24 +0200, Daniel Vetter wrote: > > > On Tue, Sep 15, 2015 at 04:08:53PM +0300, Ander Conselvan De Oliveira > > > wrote: > > > > On Mon, 2015-09-14 at 16:38 +0300, Ander Conselvan De Oliveira wrote: > > > > > On Mon, 2015-09-14 at 15:11 +0200, Daniel Vetter wrote: > > > > > > On Mon, Sep 14, 2015 at 02:51:51PM +0300, Ander Conselvan de > > > > > > Oliveira wrote: > > > > > > > --- > > > > > > > > > > > > > > On Fri, 2015-09-11 at 17:11 +0300, Ander Conselvan de Oliveira > > > > > > > wrote: > > > > > > > > On Wed, 2015-09-09 at 11:33 +0100, Thomas Wood wrote: > > > > > > > > > On 8 September 2015 at 13:28, Ander Conselvan de Oliveira > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/link-training-test/Makefile > > > > > > > > > > b/link-training-test/Makefile > > > > > > > > > > > > > > > > > > If this is meant to be part of the test suite, then it needs > > > > > > > > > to be in > > > > > > > > > the tests directory and use the igt test infrastructure. > > > > > > > > > Otherwise it > > > > > > > > > should be placed in tools or tools/link-training-test. > > > > > > > > > > > > > > > > I made the test use the igt infrastructure, but I'm not sure if > > > > > > > > this is > > > > > > > > a good fit for it. The dependency on the kernel is on build > > > > > > > > time, but > > > > > > > > once compiled this can be run on any machine. This can also > > > > > > > > introduce > > > > > > > > build failures if the test is not kept in sync with the driver > > > > > > > > source. > > > > > > > > Ideally that a failure to build this would be reported as the > > > > > > > > test > > > > > > > > failing, but I have no idea of how to achieve that. > > > > > > > > > > > > > > Alternatively, this could be in the kernel source tree directly. > > > > > > > This > > > > > > > patch adds a test subdir to the i915 source dir, containing the > > > > > > > link > > > > > > > training test. The test is compiled as part of the normal build > > > > > > > using > > > > > > > the extra-y variable so that it doesn't get linked to the final > > > > > > > kernel. > > > > > > > > > > > > > > When make is run from the tests directory, a thin wrapper around > > > > > > > the > > > > > > > tests is built and linked to the object file compiled as part of > > > > > > > the > > > > > > > kernel build. Running make run_tests from the test dir runs the > > > > > > > test > > > > > > > and reports success or failure. > > > > > > > > > > > > > > Any thoughts? > > > > > > > > > > > > I think there's some precedence in other subsystems to integrate > > > > > > unit > > > > > > tests directly in the kernel, e.g. locking selftest or similar > > > > > > things. > > > > > > Usual approach is to either have a special module (but that often > > > > > > means > > > > > > piles of EXPORT_SYMBOL only for that selftest module). Or just a y/n > > > > > > Kconfig option which enables that code and runs all the self/unit > > > > > > tests > > > > > > when the module loads. > > > > > > > > > > > > I'd go with that approach since it's simpler. And we'd only need to > > > > > > tell > > > > > > QA to enable that Kconfig option for more testing. > > > > > > > > > > I'll have a look into that Kconfig approach, but there's a couple of > > > > > things > > > > > I like about having the unit test as user space binaries: > > > > > > > > > > - there's no need to boot the newly compiled kernel, so doing a > > > > > test run > > > > > is super fast; > > > > > - the binaries can be debugged with gdb just like other user space > > > > > stuff. > > > > > > > > I implemented the test using the Kconfig approach, and it seems to work > > > > well > > > > without impacting the points above. I added the call to run the test as > > > > the > > > > first thing in i915_init(), and with the driver compiled built-in, > > > > running > > > > the kernel under qemu will run the tests. And qemu can also provide a > > > > gdb > > > > remote target. > > > > > > > > One thing might be a problem though. With the previous approach, the > > > > functions overriden by the test where simply reimplemented in the new > > > > binary. > > > > But now the test is linked to the entire driver, so that's not > > > > possible. To > > > > work around that, I had to add function pointers to all the functions > > > > called > > > > by the link training state machine to intel_dp. I don't think that > > > > method > > > > scales well. > > > > > > > > I'll send update patches for reference as replies to this mail. > > > > > > I had a few discussions about this at XDC and I know think doing this is > > > userspace is better: > > > - Faster to run tests (since no module reloading required). > > > - Nouveau is developed in userspace and would like to reu
[tip:perf/core] perf evlist: Add perf_evlist__id2evsel_strict()
Commit-ID: dddcf6abbf5946f9ec1183dd2099cede6dbe12fc
Gitweb: http://git.kernel.org/tip/dddcf6abbf5946f9ec1183dd2099cede6dbe12fc
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:52 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:11:00 -0300
perf evlist: Add perf_evlist__id2evsel_strict()
perf_evlist__id2evsel_strict() is the same as perf_evlist__id2evsel()
except that it ensures that the id must match.
This will be used by perf inject to find a specific evsel that is to be
deleted, hence the need to match exactly.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-22-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evlist.c | 15 +++
tools/perf/util/evlist.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index a864373..e676038 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -617,6 +617,21 @@ struct perf_evsel *perf_evlist__id2evsel(struct
perf_evlist *evlist, u64 id)
return NULL;
}
+struct perf_evsel *perf_evlist__id2evsel_strict(struct perf_evlist *evlist,
+ u64 id)
+{
+ struct perf_sample_id *sid;
+
+ if (!id)
+ return NULL;
+
+ sid = perf_evlist__id2sid(evlist, id);
+ if (sid)
+ return sid->evsel;
+
+ return NULL;
+}
+
static int perf_evlist__event2id(struct perf_evlist *evlist,
union perf_event *event, u64 *id)
{
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 115d8b5..0edf0d4 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -104,6 +104,8 @@ int perf_evlist__filter_pollfd(struct perf_evlist *evlist,
short revents_and_mas
int perf_evlist__poll(struct perf_evlist *evlist, int timeout);
struct perf_evsel *perf_evlist__id2evsel(struct perf_evlist *evlist, u64 id);
+struct perf_evsel *perf_evlist__id2evsel_strict(struct perf_evlist *evlist,
+ u64 id);
struct perf_sample_id *perf_evlist__id2sid(struct perf_evlist *evlist, u64 id);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf evlist: Add perf_evlist__remove()
Commit-ID: 4768230ad57d4e4fc6d36c44e98e0062c89b0dc0
Gitweb: http://git.kernel.org/tip/4768230ad57d4e4fc6d36c44e98e0062c89b0dc0
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:53 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:15:31 -0300
perf evlist: Add perf_evlist__remove()
Add a counterpart to perf_evlist__add() that does the opposite and
deletes the evsel.
This will be used by perf inject to remove unwanted evsels.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-23-git-send-email-adrian.hun...@intel.com
[ Renamed it from perf_evlist__del() to perf_evlist__remove() and removed the
perf_evsel__delete() call ]
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evlist.c | 7 +++
tools/perf/util/evlist.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index e676038..8954622 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -165,6 +165,13 @@ void perf_evlist__add(struct perf_evlist *evlist, struct
perf_evsel *entry)
__perf_evlist__propagate_maps(evlist, entry);
}
+void perf_evlist__remove(struct perf_evlist *evlist, struct perf_evsel *evsel)
+{
+ evsel->evlist = NULL;
+ list_del_init(&evsel->node);
+ evlist->nr_entries -= 1;
+}
+
void perf_evlist__splice_list_tail(struct perf_evlist *evlist,
struct list_head *list)
{
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 0edf0d4..66bc9d4 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -73,6 +73,7 @@ void perf_evlist__exit(struct perf_evlist *evlist);
void perf_evlist__delete(struct perf_evlist *evlist);
void perf_evlist__add(struct perf_evlist *evlist, struct perf_evsel *entry);
+void perf_evlist__remove(struct perf_evlist *evlist, struct perf_evsel *evsel);
int perf_evlist__add_default(struct perf_evlist *evlist);
int __perf_evlist__add_default_attrs(struct perf_evlist *evlist,
struct perf_event_attr *attrs, size_t
nr_attrs);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf inject: Add --strip option to strip out non-synthesized events
Commit-ID: f56fb9864c501dc85ebe40af5bf925dd07d990c0
Gitweb: http://git.kernel.org/tip/f56fb9864c501dc85ebe40af5bf925dd07d990c0
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:55 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:19:51 -0300
perf inject: Add --strip option to strip out non-synthesized events
Add a new option --strip which is used with --itrace to strip out
non-synthesized events. This results in a perf.data file that is
simpler for external tools to parse. In particular, this can be used to
prepare a perf.data file for consumption by autofdo.
A subsequent patch makes a change to Intel PT also to enable use with
autofdo and gives an example of that use.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-25-git-send-email-adrian.hun...@intel.com
[ Made it use perf_evlist__remove() + perf_evsel__delete() ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-inject.txt | 3 ++
tools/perf/builtin-inject.c | 92
2 files changed, 95 insertions(+)
diff --git a/tools/perf/Documentation/perf-inject.txt
b/tools/perf/Documentation/perf-inject.txt
index 0c721c3..0b1cede 100644
--- a/tools/perf/Documentation/perf-inject.txt
+++ b/tools/perf/Documentation/perf-inject.txt
@@ -50,6 +50,9 @@ OPTIONS
include::itrace.txt[]
+--strip::
+ Use with --itrace to strip out non-synthesized events.
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-report[1], linkperf:perf-archive[1]
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 9b6119f..0a945d2 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -28,6 +28,7 @@ struct perf_inject {
boolbuild_ids;
boolsched_stat;
boolhave_auxtrace;
+ boolstrip;
const char *input_name;
struct perf_data_file output;
u64 bytes_written;
@@ -177,6 +178,14 @@ static int perf_event__repipe(struct perf_tool *tool,
return perf_event__repipe_synth(tool, event);
}
+static int perf_event__drop(struct perf_tool *tool __maybe_unused,
+ union perf_event *event __maybe_unused,
+ struct perf_sample *sample __maybe_unused,
+ struct machine *machine __maybe_unused)
+{
+ return 0;
+}
+
static int perf_event__drop_aux(struct perf_tool *tool,
union perf_event *event __maybe_unused,
struct perf_sample *sample,
@@ -480,6 +489,78 @@ static int perf_evsel__check_stype(struct perf_evsel
*evsel,
return 0;
}
+static int drop_sample(struct perf_tool *tool __maybe_unused,
+ union perf_event *event __maybe_unused,
+ struct perf_sample *sample __maybe_unused,
+ struct perf_evsel *evsel __maybe_unused,
+ struct machine *machine __maybe_unused)
+{
+ return 0;
+}
+
+static void strip_init(struct perf_inject *inject)
+{
+ struct perf_evlist *evlist = inject->session->evlist;
+ struct perf_evsel *evsel;
+
+ inject->tool.context_switch = perf_event__drop;
+
+ evlist__for_each(evlist, evsel)
+ evsel->handler = drop_sample;
+}
+
+static bool has_tracking(struct perf_evsel *evsel)
+{
+ return evsel->attr.mmap || evsel->attr.mmap2 || evsel->attr.comm ||
+ evsel->attr.task;
+}
+
+#define COMPAT_MASK (PERF_SAMPLE_ID | PERF_SAMPLE_TID | PERF_SAMPLE_TIME | \
+PERF_SAMPLE_ID | PERF_SAMPLE_CPU | PERF_SAMPLE_IDENTIFIER)
+
+/*
+ * In order that the perf.data file is parsable, tracking events like MMAP need
+ * their selected event to exist, except if there is only 1 selected event left
+ * and it has a compatible sample type.
+ */
+static bool ok_to_remove(struct perf_evlist *evlist,
+struct perf_evsel *evsel_to_remove)
+{
+ struct perf_evsel *evsel;
+ int cnt = 0;
+ bool ok = false;
+
+ if (!has_tracking(evsel_to_remove))
+ return true;
+
+ evlist__for_each(evlist, evsel) {
+ if (evsel->handler != drop_sample) {
+ cnt += 1;
+ if ((evsel->attr.sample_type & COMPAT_MASK) ==
+ (evsel_to_remove->attr.sample_type & COMPAT_MASK))
+ ok = true;
+ }
+ }
+
+ return ok && cnt == 1;
+}
+
+static void strip_fini(struct perf_inject *inject)
+{
+ struct perf_evlist *evlist = inject->session->evlist;
+ struct perf_evsel *evsel, *tmp;
+
+ /* Remove non-synthesized evsels if possible */
+ evlist__for_each_safe(evlist, tmp, evsel) {
+ if (evsel->handler == drop_sample &&
+
[tip:perf/core] perf inject: Remove more aux-related stuff when processing instruction traces
Commit-ID: 73117308f953afb60a1383725b7d5372feeb2433
Gitweb: http://git.kernel.org/tip/73117308f953afb60a1383725b7d5372feeb2433
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:54 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:17:15 -0300
perf inject: Remove more aux-related stuff when processing instruction traces
perf inject can process instruction traces (using the --itrace option)
which removes aux-related events and replaces them with the requested
synthesized events.
However there are still some leftovers, namely PERF_RECORD_ITRACE_START
events and the original evsel (selected event) e.g. intel_pt//
For the sake of completeness, remove them too.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-24-git-send-email-adrian.hun...@intel.com
[ Made it use perf_evlist__remove() + perf_evsel__delete() ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-inject.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 8638fad..9b6119f 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -31,6 +31,7 @@ struct perf_inject {
const char *input_name;
struct perf_data_file output;
u64 bytes_written;
+ u64 aux_id;
struct list_headsamples;
struct itrace_synth_opts itrace_synth_opts;
};
@@ -176,6 +177,19 @@ static int perf_event__repipe(struct perf_tool *tool,
return perf_event__repipe_synth(tool, event);
}
+static int perf_event__drop_aux(struct perf_tool *tool,
+ union perf_event *event __maybe_unused,
+ struct perf_sample *sample,
+ struct machine *machine __maybe_unused)
+{
+ struct perf_inject *inject = container_of(tool, struct perf_inject,
tool);
+
+ if (!inject->aux_id)
+ inject->aux_id = sample->id;
+
+ return 0;
+}
+
typedef int (*inject_handler)(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample,
@@ -512,6 +526,8 @@ static int __cmd_inject(struct perf_inject *inject)
inject->tool.id_index = perf_event__repipe_id_index;
inject->tool.auxtrace_info = perf_event__process_auxtrace_info;
inject->tool.auxtrace = perf_event__process_auxtrace;
+ inject->tool.aux= perf_event__drop_aux;
+ inject->tool.itrace_start = perf_event__drop_aux,
inject->tool.ordered_events = true;
inject->tool.ordering_requires_timestamps = true;
/* Allow space in the header for new attributes */
@@ -535,14 +551,25 @@ static int __cmd_inject(struct perf_inject *inject)
}
/*
* The AUX areas have been removed and replaced with
-* synthesized hardware events, so clear the feature flag.
+* synthesized hardware events, so clear the feature flag and
+* remove the evsel.
*/
if (inject->itrace_synth_opts.set) {
+ struct perf_evsel *evsel;
+
perf_header__clear_feat(&session->header,
HEADER_AUXTRACE);
if (inject->itrace_synth_opts.last_branch)
perf_header__set_feat(&session->header,
HEADER_BRANCH_STACK);
+ evsel = perf_evlist__id2evsel_strict(session->evlist,
+inject->aux_id);
+ if (evsel) {
+ pr_debug("Deleting %s\n",
+perf_evsel__name(evsel));
+ perf_evlist__remove(session->evlist, evsel);
+ perf_evsel__delete(evsel);
+ }
}
session->header.data_offset = output_data_offset;
session->header.data_size = inject->bytes_written;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf script: Make scripting_max_stack value allow for synthesized callchains
Commit-ID: 3c5b645faee7afbd417f6127694adbd26778a9eb Gitweb: http://git.kernel.org/tip/3c5b645faee7afbd417f6127694adbd26778a9eb Author: Adrian Hunter AuthorDate: Fri, 25 Sep 2015 16:15:51 +0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 28 Sep 2015 17:09:41 -0300 perf script: Make scripting_max_stack value allow for synthesized callchains perf script has a setting to set the maximum stack depth when processing callchains. The setting defaults to the hard-coded maximum definition PERF_MAX_STACK_DEPTH which is 127. It is possible, when processing instruction traces, to synthesize callchains. Synthesized callchains do not have the kernel size limitation and are whatever size the user requests, although validation presently prevents the user requested a value greater that 1024. The default value is 16. To allow for synthesized callchains, make the scripting_max_stack value at least the same size as the synthesized callchain size. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1443186956-18718-21-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-script.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c index 5c3c02d..8ce1c6b 100644 --- a/tools/perf/builtin-script.c +++ b/tools/perf/builtin-script.c @@ -1748,6 +1748,10 @@ int cmd_script(int argc, const char **argv, const char *prefix __maybe_unused) } } + if (itrace_synth_opts.callchain && + itrace_synth_opts.callchain_sz > scripting_max_stack) + scripting_max_stack = itrace_synth_opts.callchain_sz; + /* make sure PERF_EXEC_PATH is set for scripts */ perf_set_argv_exec_path(perf_exec_path()); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf intel-pt: Move branch filter logic
Commit-ID: 385e33063fb963f5cccb0a37fe539319b6481fa5
Gitweb: http://git.kernel.org/tip/385e33063fb963f5cccb0a37fe539319b6481fa5
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:44 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:58:27 -0300
perf intel-pt: Move branch filter logic
intel_pt_synth_branch_sample() skips synthesizing if the branch does not
match the branch filter. That logic was sitting in the middle of the
function but is more efficiently placed at the start of the function, so
move it.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-14-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/intel-pt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index c8bb5ca..2c01e72 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -891,6 +891,9 @@ static int intel_pt_synth_branch_sample(struct
intel_pt_queue *ptq)
union perf_event *event = ptq->event_buf;
struct perf_sample sample = { .ip = 0, };
+ if (pt->branches_filter && !(pt->branches_filter & ptq->flags))
+ return 0;
+
event->sample.header.type = PERF_RECORD_SAMPLE;
event->sample.header.misc = PERF_RECORD_MISC_USER;
event->sample.header.size = sizeof(struct perf_event_header);
@@ -909,9 +912,6 @@ static int intel_pt_synth_branch_sample(struct
intel_pt_queue *ptq)
sample.flags = ptq->flags;
sample.insn_len = ptq->insn_len;
- if (pt->branches_filter && !(pt->branches_filter & ptq->flags))
- return 0;
-
if (pt->synth_opts.inject) {
ret = intel_pt_inject_event(event, &sample,
pt->branches_sample_type,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf intel-pt: Add mispred-all config option to aid use with autofdo
Commit-ID: ba11ba65e02836c475427ae199adfc2d8cc4a900
Gitweb: http://git.kernel.org/tip/ba11ba65e02836c475427ae199adfc2d8cc4a900
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:56 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:21:00 -0300
perf intel-pt: Add mispred-all config option to aid use with autofdo
autofdo incorrectly expects branch flags to include either mispred or
predicted. In fact mispred = predicted = 0 is valid and means the flags
are not supported, which they aren't by Intel PT.
To make autofdo work, add a config option which will cause Intel PT
decoder to set the mispred flag on all branches.
Below is an example of using Intel PT with autofdo. The example is
also added to the Intel PT documentation. It requires autofdo
(https://github.com/google/autofdo) and gcc version 5. The bubble
sort example is from the AutoFDO tutorial
(https://gcc.gnu.org/wiki/AutoFDO/Tutorial)
amended to take the number of elements as a parameter.
$ gcc-5 -O3 sort.c -o sort_optimized
$ ./sort_optimized 3
Bubble sorting array of 3 elements
2254 ms
$ cat ~/.perfconfig
[intel-pt]
mispred-all
$ perf record -e intel_pt//u ./sort 3000
Bubble sorting array of 3000 elements
58 ms
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 3.939 MB perf.data ]
$ perf inject -i perf.data -o inj --itrace=i100usle --strip
$ ./create_gcov --binary=./sort --profile=inj --gcov=sort.gcov
-gcov_version=1
$ gcc-5 -O3 -fauto-profile=sort.gcov sort.c -o sort_autofdo
$ ./sort_autofdo 3
Bubble sorting array of 3 elements
2155 ms
Note there is currently no advantage to using Intel PT instead of LBR,
but that may change in the future if greater use is made of the data.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-26-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/intel-pt.txt | 29 +
tools/perf/util/intel-pt.c| 14 ++
2 files changed, 43 insertions(+)
diff --git a/tools/perf/Documentation/intel-pt.txt
b/tools/perf/Documentation/intel-pt.txt
index a0fbb5d..be764f9 100644
--- a/tools/perf/Documentation/intel-pt.txt
+++ b/tools/perf/Documentation/intel-pt.txt
@@ -764,3 +764,32 @@ perf inject also accepts the --itrace option in which case
tracing data is
removed and replaced with the synthesized events. e.g.
perf inject --itrace -i perf.data -o perf.data.new
+
+Below is an example of using Intel PT with autofdo. It requires autofdo
+(https://github.com/google/autofdo) and gcc version 5. The bubble
+sort example is from the AutoFDO tutorial
(https://gcc.gnu.org/wiki/AutoFDO/Tutorial)
+amended to take the number of elements as a parameter.
+
+ $ gcc-5 -O3 sort.c -o sort_optimized
+ $ ./sort_optimized 3
+ Bubble sorting array of 3 elements
+ 2254 ms
+
+ $ cat ~/.perfconfig
+ [intel-pt]
+ mispred-all
+
+ $ perf record -e intel_pt//u ./sort 3000
+ Bubble sorting array of 3000 elements
+ 58 ms
+ [ perf record: Woken up 2 times to write data ]
+ [ perf record: Captured and wrote 3.939 MB perf.data ]
+ $ perf inject -i perf.data -o inj --itrace=i100usle --strip
+ $ ./create_gcov --binary=./sort --profile=inj --gcov=sort.gcov
-gcov_version=1
+ $ gcc-5 -O3 -fauto-profile=sort.gcov sort.c -o sort_autofdo
+ $ ./sort_autofdo 3
+ Bubble sorting array of 3 elements
+ 2155 ms
+
+Note there is currently no advantage to using Intel PT instead of LBR, but
+that may change in the future if greater use is made of the data.
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 05e8fcc51..03ff072 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -64,6 +64,7 @@ struct intel_pt {
bool data_queued;
bool est_tsc;
bool sync_switch;
+ bool mispred_all;
int have_sched_switch;
u32 pmu_type;
u64 kernel_start;
@@ -943,6 +944,7 @@ static void intel_pt_update_last_branch_rb(struct
intel_pt_queue *ptq)
be->flags.abort = !!(state->flags & INTEL_PT_ABORT_TX);
be->flags.in_tx = !!(state->flags & INTEL_PT_IN_TX);
/* No support for mispredict */
+ be->flags.mispred = ptq->pt->mispred_all;
if (bs->nr < ptq->pt->synth_opts.last_branch_sz)
bs->nr += 1;
@@ -1967,6 +1969,16 @@ static bool intel_pt_find_switch(struct perf_evlist
*evlist)
return false;
}
+static int intel_pt_perf_config(const char *var, const char *value, void *data)
+{
+ struct intel_pt *pt = data;
+
+ if (!strcmp(var, "intel-pt.mispred-all"))
+ pt->mispred_all = perf_config_b
[tip:perf/core] perf tools: Adds the config_term callback for different type events
Commit-ID: 0b8891a8e62cb537b65ebc55cfbbb4ec22333c44
Gitweb: http://git.kernel.org/tip/0b8891a8e62cb537b65ebc55cfbbb4ec22333c44
Author: He Kuang
AuthorDate: Mon, 28 Sep 2015 03:52:13 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:25:53 -0300
perf tools: Adds the config_term callback for different type events
Currently, function config_term() is used for checking config terms of
all types of events, while unknown terms is not reported as an error
because pmu events have valid terms in sysfs.
But this is wrong when unknown terms are specificed to hw/sw events.
This patch Adds the config_term callback so we can use separate check
routines for each type of events.
Signed-off-by: He Kuang
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Kan Liang
Cc: Peter Zijlstra
Cc: Wang Nan
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1443412336-120050-1-git-send-email-heku...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 61c2bc2..9dc3fb6 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -599,9 +599,13 @@ static int check_type_val(struct parse_events_term *term,
return -EINVAL;
}
-static int config_term(struct perf_event_attr *attr,
- struct parse_events_term *term,
- struct parse_events_error *err)
+typedef int config_term_func_t(struct perf_event_attr *attr,
+ struct parse_events_term *term,
+ struct parse_events_error *err);
+
+static int config_term_common(struct perf_event_attr *attr,
+ struct parse_events_term *term,
+ struct parse_events_error *err)
{
#define CHECK_TYPE_VAL(type) \
do { \
@@ -610,12 +614,6 @@ do {
\
} while (0)
switch (term->type_term) {
- case PARSE_EVENTS__TERM_TYPE_USER:
- /*
-* Always succeed for sysfs terms, as we dont know
-* at this point what type they need to have.
-*/
- return 0;
case PARSE_EVENTS__TERM_TYPE_CONFIG:
CHECK_TYPE_VAL(NUM);
attr->config = term->val.num;
@@ -665,9 +663,24 @@ do {
\
#undef CHECK_TYPE_VAL
}
+static int config_term_pmu(struct perf_event_attr *attr,
+ struct parse_events_term *term,
+ struct parse_events_error *err)
+{
+ if (term->type_term == PARSE_EVENTS__TERM_TYPE_USER)
+ /*
+* Always succeed for sysfs terms, as we dont know
+* at this point what type they need to have.
+*/
+ return 0;
+ else
+ return config_term_common(attr, term, err);
+}
+
static int config_attr(struct perf_event_attr *attr,
struct list_head *head,
- struct parse_events_error *err)
+ struct parse_events_error *err,
+ config_term_func_t config_term)
{
struct parse_events_term *term;
@@ -735,7 +748,8 @@ int parse_events_add_numeric(struct parse_events_evlist
*data,
attr.config = config;
if (head_config) {
- if (config_attr(&attr, head_config, data->error))
+ if (config_attr(&attr, head_config, data->error,
+ config_term_common))
return -EINVAL;
if (get_config_terms(head_config, &config_terms))
@@ -795,7 +809,7 @@ int parse_events_add_pmu(struct parse_events_evlist *data,
* Configure hardcoded terms first, no need to check
* return value when called with fail == 0 ;)
*/
- if (config_attr(&attr, head_config, data->error))
+ if (config_attr(&attr, head_config, data->error, config_term_pmu))
return -EINVAL;
if (get_config_terms(head_config, &config_terms))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps
David Ahern writes: > On 9/23/15 6:37 PM, Huang Ying wrote: >>> >>> I take it you have CONFIG_NET_VRF enabled. correct? >>> >>> With it disabled I see no relevant change in performance between >>> 8f58336d3f78 and 192132b9a034. Can you confirm? >> >> The kconfig file is attached with the mail. It appears that >> CONFIG_NET_VRF is disabled. >> > > Something is not adding up. I anticipate access to a multi-socket numa > system in the next few days. Until then a couple of questions: > > 1. do you take patches to run your tests? No. We checkout your commits and test them. Without applying any other patches. > 2. do you have a wiki/web page with all of the tests run? Sorry, we still have no this information now. > I'd like to > know what other networking tests have been run. Only this one was > flagged, so I presume it means other tests did not hit the > threshold. I would like to know what other tests are run. For the commit and its parent, we have only tested the benchmark in the report email. Best Regards, Huang, Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Show proper error message for wrong terms of hw/sw events
Commit-ID: ffeb883e5662e94b14948078e85812261277ad67
Gitweb: http://git.kernel.org/tip/ffeb883e5662e94b14948078e85812261277ad67
Author: He Kuang
AuthorDate: Mon, 28 Sep 2015 03:52:14 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:26:54 -0300
perf tools: Show proper error message for wrong terms of hw/sw events
Show proper error message and show valid terms when wrong config terms
is specified for hw/sw type perf events.
This patch makes the original error format function formats_error_string()
more generic, which only outputs the static config terms for hw/sw perf
events, and prepends pmu formats for pmu events.
Before this patch:
$ perf record -e 'cpu-clock/freqx=200/' -a sleep 1
invalid or unsupported event: 'cpu-clock/freqx=200/'
Run 'perf list' for a list of valid events
usage: perf record [] []
or: perf record [] -- []
-e, --eventevent selector. use 'perf list' to list available
events
After this patch:
$ perf record -e 'cpu-clock/freqx=200/' -a sleep 1
event syntax error: 'cpu-clock/freqx=200/'
\___ unknown term
valid terms:
config,config1,config2,name,period,freq,branch_type,time,call-graph,stack-size
Run 'perf list' for a list of valid events
usage: perf record [] []
or: perf record [] -- []
-e, --eventevent selector. use 'perf list' to list available
events
Signed-off-by: He Kuang
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Kan Liang
Cc: Peter Zijlstra
Cc: Wang Nan
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1443412336-120050-2-git-send-email-heku...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 29 +
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.l | 2 +-
tools/perf/util/pmu.c | 37 ++---
4 files changed, 45 insertions(+), 24 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 9dc3fb6..ea64ec07 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -656,6 +656,9 @@ do {
\
CHECK_TYPE_VAL(STR);
break;
default:
+ err->str = strdup("unknown term");
+ err->idx = term->err_term;
+ err->help = parse_events_formats_error_string(NULL);
return -EINVAL;
}
@@ -1875,3 +1878,29 @@ void parse_events_evlist_error(struct
parse_events_evlist *data,
err->str = strdup(str);
WARN_ONCE(!err->str, "WARNING: failed to allocate error string");
}
+
+/*
+ * Return string contains valid config terms of an event.
+ * @additional_terms: For terms such as PMU sysfs terms.
+ */
+char *parse_events_formats_error_string(char *additional_terms)
+{
+ char *str;
+ static const char *static_terms = "config,config1,config2,name,"
+ "period,freq,branch_type,time,"
+ "call-graph,stack-size\n";
+
+ /* valid terms */
+ if (additional_terms) {
+ if (!asprintf(&str, "valid terms: %s,%s",
+ additional_terms, static_terms))
+ goto fail;
+ } else {
+ if (!asprintf(&str, "valid terms: %s", static_terms))
+ goto fail;
+ }
+ return str;
+
+fail:
+ return NULL;
+}
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index ffee7ec..c7b904a 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -156,5 +156,6 @@ int print_hwcache_events(const char *event_glob, bool
name_only);
extern int is_valid_tracepoint(const char *event_string);
int valid_event_mount(const char *eventfs);
+char *parse_events_formats_error_string(char *additional_terms);
#endif /* __PERF_PARSE_EVENTS_H */
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 936d566..c29832b 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -174,7 +174,7 @@ modifier_bp [rwx]{1,3}
{
/*
-* Please update formats_error_string any time
+* Please update parse_events_formats_error_string any time
* new static term is added.
*/
config { return term(yyscanner,
PARSE_EVENTS__TERM_TYPE_CONFIG); }
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 89c91a1..ac42c97 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -626,38 +626,26 @@ static int pmu_resolve_param_term(struct
parse_events_term *term,
return -1;
}
-static char *formats_error_string(struct list_head *formats)
+static char *pmu_formats_string(struct list_head *formats)
{
struct perf_pmu_format *format;
- char *err, *str;
- s
[tip:perf/core] perf tools: Adds the tracepoint name parsing support
Commit-ID: 865582c3f48e12b7ab9e260161868313e4a37f44
Gitweb: http://git.kernel.org/tip/865582c3f48e12b7ab9e260161868313e4a37f44
Author: He Kuang
AuthorDate: Mon, 28 Sep 2015 03:52:15 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:29:38 -0300
perf tools: Adds the tracepoint name parsing support
Adds rules for parsing tracepoint names. Change rules of tracepoint which
derives from PE_NAMEs into tracepoint names directly, so adding more rules
based on tracepoint names will be easier.
Changes v2-v3:
- Change __event_legacy_tracepoint label in bison file to tracepoint_name
- Fix formats error.
Signed-off-by: He Kuang
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Kan Liang
Cc: Peter Zijlstra
Cc: Wang Nan
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1443412336-120050-3-git-send-email-heku...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.y | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 8bcc458..1c598c2 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -67,6 +67,7 @@ static inc_group_count(struct list_head *list,
%type event_legacy_cache
%type event_legacy_mem
%type event_legacy_tracepoint
+%type tracepoint_name
%type event_legacy_numeric
%type event_legacy_raw
%type event_def
@@ -84,6 +85,10 @@ static inc_group_count(struct list_head *list,
u64 num;
struct list_head *head;
struct parse_events_term *term;
+ struct tracepoint_name {
+ char *sys;
+ char *event;
+ } tracepoint_name;
}
%%
@@ -368,36 +373,40 @@ PE_PREFIX_MEM PE_VALUE sep_dc
}
event_legacy_tracepoint:
-PE_NAME '-' PE_NAME ':' PE_NAME
+tracepoint_name
{
struct parse_events_evlist *data = _data;
struct parse_events_error *error = data->error;
struct list_head *list;
- char sys_name[128];
- snprintf(&sys_name, 128, "%s-%s", $1, $3);
ALLOC_LIST(list);
- if (parse_events_add_tracepoint(list, &data->idx, &sys_name, $5,
error)) {
+ if (parse_events_add_tracepoint(list, &data->idx, $1.sys, $1.event,
+ error)) {
if (error)
error->idx = @1.first_column;
return -1;
}
$$ = list;
}
+
+tracepoint_name:
+PE_NAME '-' PE_NAME ':' PE_NAME
+{
+ char sys_name[128];
+ struct tracepoint_name tracepoint;
+
+ snprintf(&sys_name, 128, "%s-%s", $1, $3);
+ tracepoint.sys = &sys_name;
+ tracepoint.event = $5;
+
+ $$ = tracepoint;
+}
|
PE_NAME ':' PE_NAME
{
- struct parse_events_evlist *data = _data;
- struct parse_events_error *error = data->error;
- struct list_head *list;
+ struct tracepoint_name tracepoint = {$1, $3};
- ALLOC_LIST(list);
- if (parse_events_add_tracepoint(list, &data->idx, $1, $3, error)) {
- if (error)
- error->idx = @1.first_column;
- return -1;
- }
- $$ = list;
+ $$ = tracepoint;
}
event_legacy_numeric:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/9] watchdog: Always evaluate new timeout against min_timeout
On Tue, Sep 29, 2015 at 01:27:24AM -0700, Guenter Roeck wrote: > Up to now, a new timeout value is only evaluated against min_timeout > if max_timeout is provided. This does not really make sense; a driver > can have a minimum timeout even if it does not have a maximum timeout. > Ensure that it is not smaller than min_timeout, even if max_timeout > is not set. > > Signed-off-by: Guenter Roeck Acked-by: Uwe Kleine-König -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90() - evildoer found and neutralized
On 2015/9/27 0:46, Borislav Petkov wrote:
> On Wed, Sep 23, 2015 at 06:18:39PM +0200, Borislav Petkov wrote:
>> On Wed, Sep 23, 2015 at 06:06:21PM +0200, Borislav Petkov wrote:
>>> On Wed, Sep 23, 2015 at 04:44:50PM +0200, Daniel Vetter wrote:
sorry I sprinkled the locking stuff in the wrong places. Still confused
why the resume side doesn't blow up anywhere
>>>
>>> But it does:
>
> Ok, I bisected it.
>
> First of all, Daniel, you didn't see the resume side blow up because
> of the NULL ptr deref f*cking up the box much earlier. Once I reverted
> the bad commit by hand (it wouldn't revert cleanly) the resume splats
> showed.
>
> And in talking about the bad commit, it is this one:
>
> 991de2e59090e55c65a7f59a049142e3c480f7bd is the first bad commit
> commit 991de2e59090e55c65a7f59a049142e3c480f7bd
> Author: Jiang Liu
> Date: Wed Jun 10 16:54:59 2015 +0800
>
> PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()
>
> To support IOAPIC hotplug, we need to allocate PCI IRQ resources on demand
> and free them when not used anymore.
>
> Implement pcibios_alloc_irq() and pcibios_free_irq() to dynamically
> allocate and free PCI IRQs.
>
> Remove mp_should_keep_irq(), which is no longer used.
>
> [bhelgaas: changelog]
> Signed-off-by: Jiang Liu
> Signed-off-by: Bjorn Helgaas
> Acked-by: Thomas Gleixner
>
> :04 04 765e2d5232d53247ec260b34b51589c3bccb36ae
> f680234a27685e94b1a35ae2a7218f8eafa9071a M arch
> :04 04 d55a682bcde72682e883365e88ad1df6186fd54d
> f82c470a04a6845fcf5e0aa934512c75628f798d M drivers
>
> Jiang, you have to stop breaking my box with your changes. This is
> maybe the third time I'm bisecting fallout from your patches. If you're
> touching all x86, you need to test on an AMD box too. Like everyone else
> testing on the hardware their changes affect. It is that simple.
Hi Boris and Daniel,
Sorry for the regression!
I have tried to reproduce the regression by doing
suspend/resume with a laptop, but failed. The PCI MSI suspend/resume
code work as expected. And I have checked msi.c and radeon driver,
but haven't gotten any hint about the cause.
So could you please help to apply the attached debug patch
to gather more information about the regression?
Thanks!
Gerry
>
> Anyway, reverting that commit by hand fixes my resume splat.
>
> Here's the partial revert I did by hand:
>
> ---
> diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
> index fa1195dae425..164e3f8d3c3d 100644
> --- a/arch/x86/include/asm/pci_x86.h
> +++ b/arch/x86/include/asm/pci_x86.h
> @@ -93,6 +93,8 @@ extern raw_spinlock_t pci_config_lock;
> extern int (*pcibios_enable_irq)(struct pci_dev *dev);
> extern void (*pcibios_disable_irq)(struct pci_dev *dev);
>
> +extern bool mp_should_keep_irq(struct device *dev);
> +
> struct pci_raw_ops {
> int (*read)(unsigned int domain, unsigned int bus, unsigned int devfn,
> int reg, int len, u32 *val);
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> index 09d3afc0a181..3bff24438b00 100644
> --- a/arch/x86/pci/common.c
> +++ b/arch/x86/pci/common.c
> @@ -672,20 +672,22 @@ int pcibios_add_device(struct pci_dev *dev)
> return 0;
> }
>
> -int pcibios_alloc_irq(struct pci_dev *dev)
> +int pcibios_enable_device(struct pci_dev *dev, int mask)
> {
> - return pcibios_enable_irq(dev);
> -}
> + int err;
>
> -void pcibios_free_irq(struct pci_dev *dev)
> -{
> - if (pcibios_disable_irq)
> - pcibios_disable_irq(dev);
> + if ((err = pci_enable_resources(dev, mask)) < 0)
> + return err;
> +
> + if (!pci_dev_msi_enabled(dev))
> + return pcibios_enable_irq(dev);
> + return 0;
> }
>
> -int pcibios_enable_device(struct pci_dev *dev, int mask)
> +void pcibios_disable_device (struct pci_dev *dev)
> {
> - return pci_enable_resources(dev, mask);
> + if (!pci_dev_msi_enabled(dev) && pcibios_disable_irq)
> + pcibios_disable_irq(dev);
> }
>
> int pci_ext_cfg_avail(void)
> diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
> index 32e70343e6fd..f229834b36d4 100644
> --- a/arch/x86/pci/irq.c
> +++ b/arch/x86/pci/irq.c
> @@ -1186,6 +1186,18 @@ void pcibios_penalize_isa_irq(int irq, int active)
> pirq_penalize_isa_irq(irq, active);
> }
>
> +bool mp_should_keep_irq(struct device *dev)
> +{
> + if (dev->power.is_prepared)
> + return true;
> +#ifdef CONFIG_PM
> + if (dev->power.runtime_status == RPM_SUSPENDING)
> + return true;
> +#endif
> +
> + return false;
> +}
> +
> static int pirq_enable_irq(struct pci_dev *dev)
> {
> u8 pin = 0;
> @@ -1258,7 +1270,8 @@ static int pirq_enable_irq(struct pci_dev *dev)
>
> static void pirq_disable_irq(struct pci_dev *dev)
> {
> - if (io_apic_assign_pci_irqs && pci_has_managed_irq(dev))
[tip:perf/core] perf tools: Enable event_config terms to tracepoint events
Commit-ID: e637d17757a10732fa5d573c18f20b3cd4d31245
Gitweb: http://git.kernel.org/tip/e637d17757a10732fa5d573c18f20b3cd4d31245
Author: He Kuang
AuthorDate: Mon, 28 Sep 2015 03:52:16 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 17:30:07 -0300
perf tools: Enable event_config terms to tracepoint events
This patch enables config terms for tracepoint perf events. Valid terms
for tracepoint events are 'call-graph' and 'stack-size', so we can use
different callgraph settings for each event and eliminate unnecessary
overhead.
Here is an example for using different call-graph config for each
tracepoint.
$ perf record -e syscalls:sys_enter_write/call-graph=fp/
-e syscalls:sys_exit_write/call-graph=no/
dd if=/dev/zero of=test bs=4k count=10
$ perf report --stdio
#
# Total Lost Samples: 0
#
# Samples: 13 of event 'syscalls:sys_enter_write'
# Event count (approx.): 13
#
# Children Self Command Shared Object Symbol
# ... .. ..
#
76.92%76.92% dd libpthread-2.20.so [.] __write_nocancel
|
---__write_nocancel
23.08%23.08% dd libc-2.20.so[.] write
|
---write
|
|--33.33%-- 0x2031342820736574
|
|--33.33%-- 0xa6e69207364726f
|
--33.33%-- 0x34202c7320393039
...
# Samples: 13 of event 'syscalls:sys_exit_write'
# Event count (approx.): 13
#
# Children Self Command Shared Object Symbol
# ... .. ..
#
76.92%76.92% dd libpthread-2.20.so [.] __write_nocancel
23.08%23.08% dd libc-2.20.so[.] write
7.69% 0.00% dd [unknown] [.] 0x0a6e69207364726f
7.69% 0.00% dd [unknown] [.] 0x2031342820736574
7.69% 0.00% dd [unknown] [.] 0x34202c7320393039
Signed-off-by: He Kuang
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Kan Liang
Cc: Peter Zijlstra
Cc: Wang Nan
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1443412336-120050-4-git-send-email-heku...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 84 +-
tools/perf/util/parse-events.h | 3 +-
tools/perf/util/parse-events.y | 26 +++--
3 files changed, 90 insertions(+), 23 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index ea64ec07..5ffb356 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -27,6 +27,8 @@
extern int parse_events_debug;
#endif
int parse_events_parse(void *data, void *scanner);
+static int get_config_terms(struct list_head *head_config,
+ struct list_head *head_terms __maybe_unused);
static struct perf_pmu_event_symbol *perf_pmu_events_list;
/*
@@ -416,7 +418,8 @@ static void tracepoint_error(struct parse_events_error
*error, int err,
static int add_tracepoint(struct list_head *list, int *idx,
char *sys_name, char *evt_name,
- struct parse_events_error *error __maybe_unused)
+ struct parse_events_error *error __maybe_unused,
+ struct list_head *head_config)
{
struct perf_evsel *evsel;
@@ -426,13 +429,22 @@ static int add_tracepoint(struct list_head *list, int
*idx,
return PTR_ERR(evsel);
}
+ if (head_config) {
+ LIST_HEAD(config_terms);
+
+ if (get_config_terms(head_config, &config_terms))
+ return -ENOMEM;
+ list_splice(&config_terms, &evsel->config_terms);
+ }
+
list_add_tail(&evsel->node, list);
return 0;
}
static int add_tracepoint_multi_event(struct list_head *list, int *idx,
char *sys_name, char *evt_name,
- struct parse_events_error *error)
+ struct parse_events_error *error,
+ struct list_head *head_config)
{
char evt_path[MAXPATHLEN];
struct dirent *evt_ent;
@@ -456,7 +468,8 @@ static int add_tracepoint_multi_event(struct list_head
*list, int *idx,
if (!strglobmatch(evt_ent->d_name, evt_name))
continue;
- ret = add_tracepoint(list, idx, sys_name, evt_ent->d_name,
error);
+ ret = add_tracepoint(list, idx, sys_name, evt_ent->d_name,
+error, head_config);
}
closedir(evt_dir);
@@ -465,16 +478,20 @@ static int add_tracepoint_mul
[tip:perf/core] tools build: Move dependency copy into function
Commit-ID: 275e2d95591e2714d6b541d4e26959381d6b2705 Gitweb: http://git.kernel.org/tip/275e2d95591e2714d6b541d4e26959381d6b2705 Author: Jiri Olsa AuthorDate: Wed, 23 Sep 2015 12:33:59 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 28 Sep 2015 15:50:55 -0300 tools build: Move dependency copy into function So it's easier to add more functionality in the following commit. Signed-off-by: Jiri Olsa Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1443004442-32660-5-git-send-email-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/build/Build.include | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/tools/build/Build.include b/tools/build/Build.include index 4c8daac..851c420 100644 --- a/tools/build/Build.include +++ b/tools/build/Build.include @@ -55,14 +55,19 @@ make-cmd = $(call escsq,$(subst \#,\\\#,$(subst $$,,$(cmd_$(1) any-prereq = $(filter-out $(PHONY),$?) $(filter-out $(PHONY) $(wildcard $^),$^) ### +# Copy dependency data into .cmd file +# - gcc -M dependency info +# - command line to create object 'cmd_object :=' +dep-cmd = cat $(depfile) > $(dot-target).cmd; \ + printf '%s\n' 'cmd_$@ := $(make-cmd)' >> $(dot-target).cmd + +### # if_changed_dep - execute command if any prerequisite is newer than # target, or command line has changed and update # dependencies in the cmd file if_changed_dep = $(if $(strip $(any-prereq) $(arg-check)), \ @set -e; \ - $(echo-cmd) $(cmd_$(1)); \ - cat $(depfile) > $(dot-target).cmd;\ - printf '%s\n' 'cmd_$@ := $(make-cmd)' >> $(dot-target).cmd) + $(echo-cmd) $(cmd_$(1)) && $(dep-cmd)) # if_changed - execute command if any prerequisite is newer than # target, or command line has changed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf auxtrace: Fix 'instructions' period of zero
Commit-ID: e1791347b5d57d13326cf0114df1a3f3b1c4ca24
Gitweb: http://git.kernel.org/tip/e1791347b5d57d13326cf0114df1a3f3b1c4ca24
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:32 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 15:50:56 -0300
perf auxtrace: Fix 'instructions' period of zero
Instruction tracing options (i.e. --itrace) include an option for
sampling instructions at an arbitrary period. e.g.
--itrace=i10us
means make an 'instructions' sample for every 10us of trace.
Currently the logic does not distinguish between a period of
zero and no period being specified at all, so it gets treated
as the default period which is 10. That doesn't really
make sense.
Fix it so that zero period is accepted and treated as meaning
"as often as possible".
In the case of Intel PT that is the same as a period of 1 and
a unit of 'instructions' (i.e. --itrace=i1i).
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-2-git-send-email-adrian.hun...@intel.com
[ Add a few lines describing this in the Documentation/intel-pt.txt file ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/intel-pt.txt | 5 +
tools/perf/util/auxtrace.c| 4 +++-
tools/perf/util/intel-pt.c| 2 +-
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/intel-pt.txt
b/tools/perf/Documentation/intel-pt.txt
index c94c9de..886612b 100644
--- a/tools/perf/Documentation/intel-pt.txt
+++ b/tools/perf/Documentation/intel-pt.txt
@@ -707,6 +707,11 @@ on the sample is *not* adjusted and reflects the last
known value of TSC.
For Intel PT, the default period is 100us.
+Setting it to a zero period means "as often as possible".
+
+In the case of Intel PT that is the same as a period of 1 and a unit of
+'instructions' (i.e. --itrace=i1i).
+
Also the call chain size (default 16, max. 1024) for instructions or
transactions events can be specified. e.g.
diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index a980e7c..c4993b2 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -950,6 +950,7 @@ int itrace_parse_synth_opts(const struct option *opt, const
char *str,
const char *p;
char *endptr;
bool period_type_set = false;
+ bool period_set = false;
synth_opts->set = true;
@@ -971,6 +972,7 @@ int itrace_parse_synth_opts(const struct option *opt, const
char *str,
p += 1;
if (isdigit(*p)) {
synth_opts->period = strtoull(p, &endptr, 10);
+ period_set = true;
p = endptr;
while (*p == ' ' || *p == ',')
p += 1;
@@ -1053,7 +1055,7 @@ out:
if (!period_type_set)
synth_opts->period_type =
PERF_ITRACE_DEFAULT_PERIOD_TYPE;
- if (!synth_opts->period)
+ if (!period_set)
synth_opts->period = PERF_ITRACE_DEFAULT_PERIOD;
}
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 38942e1..c8bb5ca 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -720,7 +720,7 @@ static struct intel_pt_queue *intel_pt_alloc_queue(struct
intel_pt *pt,
if (!params.period) {
params.period_type = INTEL_PT_PERIOD_INSTRUCTIONS;
- params.period = 1000;
+ params.period = 1;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load()
Hi Minfei,
On Tue, Sep 29, 2015 at 11:50:44AM +0800, Minfei Huang wrote:
> On 09/28/15 at 02:41pm, Lee, Chun-Yi wrote:
> > On big machines have CPU number that's very nearly to consume whole ELF
> > headers buffer that's page aligned, 4096, 8192... Then the page fault error
> > randomly happened.
> >
> > This patch modified the code in fill_up_crash_elf_data() by using
> > walk_system_ram_res() instead of walk_system_ram_range() to count the max
> > number of crash memory ranges. That's because the walk_system_ram_range()
> > filters out small memory regions that reside the same page, but
> > walk_system_ram_res() does not.
> >
> > The oringial page fault issue sometimes happened on big machines when
> > preparing ELF headers:
> >
> > [ 305.291522] BUG: unable to handle kernel paging request at
> > c90613fc9000
> > [ 305.299621] IP: []
> > prepare_elf64_ram_headers_callback+0x165/0x260
> > [ 305.308300] PGD e32067 PUD 6dcbec54067 PMD 9dc9bdeb067 PTE 0
> > [ 305.315393] Oops: 0002 [#1] SMP
> > [...snip]
> > [ 305.420953] task: 8e1c01ced600 ti: 8e1c03ec2000 task.ti:
> > 8e1c03ec2000
> > [ 305.429292] RIP: 0010:[] []
> > prepare_elf64_ra
> > m_headers_callback+0x165/0x260
> > [...snip]
> >
> > After tracing prepare_elf64_headers() and
> > prepare_elf64_ram_headers_callback(),
> > the code uses walk_system_ram_res() to fill-in crash memory regions
> > information
> > to program header, so it counts those small memory regions that reside in a
> > page area. But, when kernel was using walk_system_ram_range() in
> > fill_up_crash_elf_data() to count the number of crash memory regions, it
> > filters out small regions.
> >
> > I printed those small memory regions, for example:
> >
> > kexec: Get nr_ram ranges. vaddr=0x880077592258 paddr=0x77592258,
> > sz=0xdc0
> >
> > Base on the logic of walk_system_ram_range(), this memory region will be
> > filter out:
> >
> > pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
> > end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
> > end_pfn - pfn = 0x77593 - 0x77593 = 0 <=== if (end_pfn > pfn) [FAIL]
> >
> > So, the max_nr_ranges that counted by kernel doesn't include small memory
> > regions. That causes the page fault issue happened in later code path for
> > preparing EFL headers,
> >
> > This issue was hided on small machine that doesn't have too many CPU because
> > the free space of ELF headers buffer can cover the number of small memory
> > regions. But, when the machine has more CPUs or the number of memory regions
> > very nearly to consume whole page aligned buffer, e.g. 4096, 8192... Then
> > issue will happen randomly.
> >
> > Signed-off-by: Lee, Chun-Yi
> > ---
> > arch/x86/kernel/crash.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> > index e068d66..ad273b3d 100644
> > --- a/arch/x86/kernel/crash.c
> > +++ b/arch/x86/kernel/crash.c
> > @@ -185,8 +185,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
> > }
> >
> > #ifdef CONFIG_KEXEC_FILE
> > -static int get_nr_ram_ranges_callback(unsigned long start_pfn,
> > - unsigned long nr_pfn, void *arg)
> > +static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
> > {
> > int *nr_ranges = arg;
>
> Ccing kexec maillist.
>
> Good cacthing.
>
> It is appreciate if you can change the above type to unsigned int
> accordingly.
>
> Thanks
> Minfei
>
Looks unsigned int* is better, I will change in next version.
Thanks for your review.
Joey Lee
> >
> > @@ -214,7 +213,7 @@ static void fill_up_crash_elf_data(struct
> > crash_elf_data *ced,
> >
> > ced->image = image;
> >
> > - walk_system_ram_range(0, -1, &nr_ranges,
> > + walk_system_ram_res(0, -1, &nr_ranges,
> > get_nr_ram_ranges_callback);
> >
> > ced->max_nr_ranges = nr_ranges;
> > --
> > 2.1.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf report: Fix sample type validation for synthesized callchains
Commit-ID: d062ac16f53d1a24047bcc9eded5514a71c363b8
Gitweb: http://git.kernel.org/tip/d062ac16f53d1a24047bcc9eded5514a71c363b8
Author: Adrian Hunter
AuthorDate: Fri, 25 Sep 2015 16:15:33 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Sep 2015 16:42:38 -0300
perf report: Fix sample type validation for synthesized callchains
Processing instruction tracing data (e.g. Intel PT) can synthesize
callchains e.g.
$ perf record -e intel_pt//u uname
$ perf report --stdio --itrace=ige
However perf report's callgraph option gets extra validation, so:
$ perf report --stdio --itrace=ige -gflat
Error:
Selected -g or --branch-history but no callchain data. Did
you call 'perf record' without -g?
# To display the perf.data header info,
# please use --header/--header-only options.
#
Fix the validation to know about instruction tracing options so
above command works.
A side-effect of the change is that the default option to
accumulate the callchain of child functions comes into force.
To get the previous behaviour the --no-children option can be
used e.g.
$ perf report --stdio --itrace=ige -gflat --no-children
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1443186956-18718-3-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index e4e3f14..0d53b48 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -214,6 +214,12 @@ static int report__setup_sample_type(struct report *rep)
u64 sample_type = perf_evlist__combined_sample_type(session->evlist);
bool is_pipe = perf_data_file__is_pipe(session->file);
+ if (session->itrace_synth_opts->callchain ||
+ (!is_pipe &&
+perf_header__has_feat(&session->header, HEADER_AUXTRACE) &&
+!session->itrace_synth_opts->set))
+ sample_type |= PERF_SAMPLE_CALLCHAIN;
+
if (!is_pipe && !(sample_type & PERF_SAMPLE_CALLCHAIN)) {
if (sort__has_parent) {
ui__error("Selected --sort parent, but no "
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lkp] [sched/fair] 482eaa50ff: INFO: suspicious RCU usage. ]
On 29.09.2015 10:44, kernel test robot wrote:
> FYI, we noticed the below changes on
>
> git://internal_merge_and_test_tree
> revert-482eaa50ff81046e1e9f95af94176953d0743ec9-482eaa50ff81046e1e9f95af94176953d0743ec9
> commit 482eaa50ff81046e1e9f95af94176953d0743ec9 ("sched/fair: Skip
> wake_affine() for core siblings")
Yeah, thanks.
> +---+--++
> | | v4.3-rc3 |
> 482eaa50ff |
> +---+--++
> | boot_successes| 54 | 0
> |
> | boot_failures | 10 | 13
> |
> | IP-Config:Auto-configuration_of_network_failed| 10 |
> |
> | INFO:suspicious_RCU_usage | 0| 13
> |
> | BUG:scheduling_while_atomic | 0| 13
> |
> | INFO:lockdep_is_turned_off| 0| 13
> |
> | kernel_BUG_at_kernel/sched/core.c | 0| 13
> |
> | invalid_opcode:#[##]SMP_DEBUG_PAGEALLOC | 0| 13
> |
> | EIP_is_at__sched_setscheduler | 0| 13
> |
> | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0| 13
> |
> | backtrace:spawn_ksoftirqd | 0| 13
> |
> | backtrace:kernel_init_freeable| 0| 13
> |
> | backtrace:schedule| 0| 13
> |
> +---+--++
>
>
> [0.074005] Failed to access perfctr msr (MSR c2 is 0)
> [0.075108]
> [0.075427] ===
> [0.076000] [ INFO: suspicious RCU usage. ]
> [0.076000] 4.3.0-rc3-1-g482eaa5 #282 Not tainted
> [0.076000] ---
> [0.076000] kernel/sched/fair.c:4796 suspicious rcu_dereference_check()
> usage!
> [0.076000]
> [0.076000] other info that might help us debug this:
> [0.076000]
> [0.076000]
> [0.076000] rcu_scheduler_active = 1, debug_locks = 0
> [0.076000] 3 locks held by swapper/0/1:
> [0.076000] #0: (cpu_hotplug.lock){.+.+.+}, at: []
> get_online_cpus+0x27/0x62
> [0.076000] #1: (smpboot_threads_lock){+.+.+.}, at: []
> smpboot_register_percpu_thread_cpumask+0x24/0xa1
> [0.076000] #2: (&p->pi_lock){..}, at: []
> try_to_wake_up+0x1d/0x19c
> [0.076000]
> [0.076000] stack backtrace:
> [0.076000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.3.0-rc3-1-g482eaa5 #282
> [0.076000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.7.5-20140531_083030-gandalf 04/01/2014
> [0.076000] d3081da8 c1219245 0001 d3081dc4
> c1070a55 c1aeb4d8
> [0.076000] d3078000 d3081e1c c106444c
> 0001 0010
> [0.076000] 480d0069 d307f198 0046 0046 d3081e18
> c107064c 0002
> [0.076000] Call Trace:
> [0.076000] [] dump_stack+0x48/0x60
> [0.076000] [] lockdep_rcu_suspicious+0xd4/0xdd
> [0.076000] [] select_task_rq_fair+0x2d8/0x64d
> [0.076000] [] ? lock_acquire+0x72/0x7d
> [0.076000] [] ? __lock_is_held+0x2e/0x44
> [0.076000] [] select_task_rq+0x3c/0x8f
> [0.076000] [] try_to_wake_up+0xd4/0x19c
> [0.076000] [] wake_up_process+0x29/0x2c
> [0.076000] [] kthread_create_on_node+0x95/0x104
> [0.076000] [] kthread_create_on_cpu+0x14/0x44
> [0.076000] [] ? cpumask_next+0x26/0x26
> [0.076000] [] __smpboot_create_thread+0x4e/0xb0
> [0.076000] [] smpboot_register_percpu_thread_cpumask+0x44/0xa1
> [0.076000] [] ? cpu_hotplug_pm_sync_init+0x11/0x11
> [0.076000] [] spawn_ksoftirqd+0x1d/0x27
> [0.076000] [] do_one_initcall+0xd0/0x14e
> [0.076000] [] ? vprintk_default+0x12/0x14
> [0.076000] [] ? printk+0x12/0x14
> [0.076000] [] ? print_cpu_info+0x8e/0xab
> [0.076000] [] ? print_cpu_info+0xa4/0xab
> [0.076000] [] ? native_smp_prepare_cpus+0x223/0x25e
> [0.076000] [] kernel_init_freeable+0x5d/0x172
> [0.076000] [] kernel_init+0x8/0xb5
> [0.076000] [] ret_from_kernel_thread+0x21/0x30
> [0.076000] [] ? rest_init+0x116/0x116
> [0.076008] BUG: scheduling while atomic: swapper/0/1/0x
> [0.077003] INFO: lockdep is turned off.
> [0.078006] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.3.0-rc3-1-g482eaa5 #282
> [0.079004] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.7.5-20140531_083030-gandalf 04/01/2014
> [0.080004] d3081db0 c1219245 d3078000 d3081dbc
> c105c084
> [0.082003] d3081de0 c17aedc2 d307f188 d3081e84
[PATCH] ARM: STi: DT: STiH407: Rename incorrect interrupt related binding
interrupts-names => interrupt-names
Signed-off-by: Lee Jones
---
arch/arm/boot/dts/stih407-pinctrl.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi
b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 1683deb..7992063 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -53,7 +53,7 @@
reg = <0x0961f080 0x4>;
reg-names = "irqmux";
interrupts = ;
- interrupts-names = "irqmux";
+ interrupt-names = "irqmux";
ranges = <0 0x0961 0x6000>;
pio0: gpio@0961 {
@@ -264,7 +264,7 @@
reg = <0x0920f080 0x4>;
reg-names = "irqmux";
interrupts = ;
- interrupts-names = "irqmux";
+ interrupt-names = "irqmux";
ranges = <0 0x0920 0x1>;
pio10: pio@0920 {
@@ -637,7 +637,7 @@
reg = <0x0921f080 0x4>;
reg-names = "irqmux";
interrupts = ;
- interrupts-names = "irqmux";
+ interrupt-names = "irqmux";
ranges = <0 0x0921 0x1>;
tsin4 {
@@ -670,7 +670,7 @@
reg = <0x0922f080 0x4>;
reg-names = "irqmux";
interrupts = ;
- interrupts-names = "irqmux";
+ interrupt-names = "irqmux";
ranges = <0 0x0922 0x6000>;
pio30: gpio@0922 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] mfd: add CSR SiRFSoC on-chip power management module driver
On Tue, 29 Sep 2015, Barry Song wrote:
> 2015-09-29 15:16 GMT+08:00 Lee Jones :
> > On Tue, 29 Sep 2015, Barry Song wrote:
> >> >> >> +static int sirfsoc_pwrc_probe(struct platform_device *pdev)
> >> >> >> +{
> >> >> >> + struct device_node *np = pdev->dev.of_node;
> >> >> >> + const struct of_device_id *match;
> >> >> >> + struct sirfsoc_pwrc_info *pwrcinfo;
> >> >> >> + struct regmap_irq_chip *regmap_irq_chip;
> >> >> >> + struct sirfsoc_pwrc_register *pwrc_reg;
> >> >> >> + struct regmap *map;
> >> >> >> + int ret;
> >> >> >> + u32 base;
> >> >> >> +
> >> >> >> + if (of_property_read_u32(np, "reg", &base))
> >> >> >> + panic("unable to find base address of pwrc node in
> >> >> >> dtb\n");
> >> >> >
> >> >> > It looks like this driver should depend on OF.
> >> >> >
> >> >> > Why are you obtaining the base address manually? Use:
> >> >> >
> >> >> > res = platform_get_resource();
> >> >> > devm_ioremap_resource(res);
> >> >> >
> >> >> > ... instead.
> >> >>
> >> >> this was explained as they are not in memory space, they are behind a
> >> >> bus bridge.
> >> >
> >> > Use 'ranges' in the DT, then you can pull out the proper address
> >> > without hand rolling your own method.
> >>
> >> it seems it is not a "ranges" thing, things behind rtciobrg is much
> >> like things behind USB or sdio. we need to use a rtciobrg protocol to
> >> do read/write.
> >> they can not be randomly accessed by load/store, and can't be XIP.
> >> they don't have any ranges in CPU memory space.
> >
> > So what's the point of 'base' then? I assumed this was the base of
> > the IP registers which where memory mapped?
>
> just think we have a i2c device, and this i2c device has multi-functions.
> each function has a base of its register offset.
> actually, the base is the offset of 1st register.
Does it every change, from device to device?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/25] perf report: Make max_stack value allow for synthesized callchains
On 28/09/15 23:03, Arnaldo Carvalho de Melo wrote:
> Em Fri, Sep 25, 2015 at 04:15:46PM +0300, Adrian Hunter escreveu:
>> perf report has an option (--max-stack) to set the maximum stack depth
>> when processing callchains. The option defaults to the hard-coded
>> maximum definition PERF_MAX_STACK_DEPTH which is 127. The intention of
>> the option is to allow the user to reduce the processing time by
>> reducing the amount of the callchain that is processed.
>>
>> It is also possible, when processing instruction traces, to synthesize
>> callchains. Synthesized callchains do not have the kernel size
>> limitation and are whatever size the user requests, although validation
>> presently prevents the user requested a value greater that 1024. The
>> default value is 16.
>
> So, haven't checked the options, but one can possibly use both the way
> itrace has to ask for a max stack size and also via --max-stack, right?
Possibly, but it would not be a common paradigm.
>
> In that case we better emit a warning or plain state that one either
> uses one way of setting the max stack or the other?
max_stack was added as an optimization to reduce processing time, so
people specifying --max-stack might get a increased processing time
if combined with synthesized callchains, but otherwise no real harm.
A warning seems like overkill. Could amend the documenation e.g.
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index b941d5e07e28..ce499035e6d8 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -205,6 +205,8 @@ OPTIONS
beyond the specified depth will be ignored. This is a trade-off
between information loss and faster processing especially for
workloads that can have a very long callchain stack.
+ Note that when using the --itrace option the synthesized callchain size
+ will override this value if the synthesized callchain size is bigger.
Default: 127
>
> I'm applying the patch, because it is unlikely that this gets specified,
> but would be good to close this gap.
>
> - Arnaldo
>
>> To allow for synthesized callchains, make the max_stack value at least
>> the same size as the synthesized callchain size.
>>
>> Signed-off-by: Adrian Hunter
>> ---
>> tools/perf/builtin-report.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
>> index e94e5c7155af..37c9f5125887 100644
>> --- a/tools/perf/builtin-report.c
>> +++ b/tools/perf/builtin-report.c
>> @@ -809,6 +809,10 @@ int cmd_report(int argc, const char **argv, const char
>> *prefix __maybe_unused)
>> if (report.inverted_callchain)
>> callchain_param.order = ORDER_CALLER;
>>
>> +if (itrace_synth_opts.callchain &&
>> +(int)itrace_synth_opts.callchain_sz > report.max_stack)
>> +report.max_stack = itrace_synth_opts.callchain_sz;
>> +
>> if (!input_name || !strlen(input_name)) {
>> if (!fstat(STDIN_FILENO, &st) && S_ISFIFO(st.st_mode))
>> input_name = "-";
>> --
>> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: nVMX: expose VPID capability to L1
On 29/09/2015 03:15, Wanpeng Li wrote: >>> >> Hi Wanpeng, the comment above is about invept, but the same applies >> applies to invvpid. We can set only VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT. > > Agreed. I see the patch has already in kvm/queue, if I need to send out > another patch or you can adjust it for me? :-) Please resend the patch. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4.2+ regression] fd7a4bed sched, rt: Convert switched_{from, to}_rt() / prio_changed_rt() to balance callbacks
On Tue, Sep 29, 2015 at 10:19:51AM +0200, Mike Galbraith wrote: > On Mon, 2015-09-28 at 04:17 +0200, Mike Galbraith wrote: > > Hi Peter, > > > > I bumped into an odd futextest regression, and finally bisected it to > > $subject. I haven't poked at it yet, chasing down and confirming the > > little bugger munched the day. > Well now, it _seems_ you're innocent Peter. Whee! thanks for looking. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled
* Denys Vlasenko wrote: > On 09/28/2015 09:58 AM, Ingo Molnar wrote: > > > > * Denys Vlasenko wrote: > > > >> On 09/26/2015 09:50 PM, H. Peter Anvin wrote: > >>> NAK. We really should map the GDT read-only on all 64 bit systems, > >>> since we can't hide the address from SLDT. Same with the IDT. > >> > >> Sorry, I don't understand your point. > > > > So the problem is that right now the SGDT instruction (which is > > unprivileged) > > leaks the real address of the kernel image: > > > > fomalhaut:~> ./sgdt > > SGDT: 88303fd89000 / 007f > > > > that '88303fd89000' is a kernel address. > > Thank you. > I do know that SGDT and friends are unprivileged on x86 > and thus they allow userspace (and guest kernels in paravirt) > learn things they don't need to know. > > I don't see how making GDT page-aligned and page-sized > changes anything in this regard. SGDT will still work, > and still leak GDT address. Well, as I try to explain it in the other part of my mail, doing so enables us to remap the GDT to a less security sensitive virtual address that does not leak the kernel's randomized address: > > Your observation in the changelog and your patch: > > > It is page-sized because of paravirt. [...] > > > > ... conflicts with the intention to mark (remap) the primary GDT address > > read-only > > on native kernels as well. > > > > So what we should do instead is to use the page alignment properly and > > remap the > > GDT to a read-only location, and load that one. > > If we'd have a small GDT (i.e. what my patch does), we still can remap the > entire page which contains small GDT, and simply don't care that some other > data > is also visible through that RO page. That's generally considered fragile: suppose an attacker has a limited information leak that can read absolute addresses with system privilege but he doesn't know the kernel's randomized base offset. With a 'partial page' mapping there could be function pointers near the GDT, part of the page the GDT happens to be on, that leak this information. (Same goes for crypto keys or other critical information (like canary information, salts, etc.) accidentally ending up nearby.) Arguably it's a bit tenuous, but when playing remapping games it's generally considered good to be page aligned and page sized, with zero padding. > > This would have a couple of advantages: > > > > - This would give kernel address randomization more teeth on x86. > > > > - An additional advantage would be that rootkits overwriting the GDT would > > have > >a bit more work to do. > > > > - A third advantage would be that for NUMA systems we could 'mirror' the > > GDT into > >node-local memory and load those. This makes GDT load cache-misses a bit > > less > >expensive. > > GDT is per-cpu. Isn't per-cpu memory already NUMA-local? Indeed it is: fomalhaut:~> for ((cpu=1; cpu<9; cpu++)); do taskset $cpu ./sgdt ; done SGDT: 88103fa09000 / 007f SGDT: 88103fa29000 / 007f SGDT: 88103fa29000 / 007f SGDT: 88103fa49000 / 007f SGDT: 88103fa49000 / 007f SGDT: 88103fa49000 / 007f SGDT: 88103fa29000 / 007f SGDT: 88103fa69000 / 007f I confused it with the IDT, which is still global. This also means that the GDT in itself does not leak kernel addresses at the moment, except it leaks the layout of the percpu area. So my suggestion would be to: - make the GDT unconditionally page aligned and sized, then remap it to a read-only address unconditionally as well, like we do it for the IDT. - make the IDT per CPU as well, for performance reasons. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: multitouch: Fetch feature reports on demand for Win8 devices
On Sep 28 2015 or thereabouts, Mika Westerberg wrote:
> Some newer Intel Skylake based Dell laptops with Win8 precision touchpad
> fail when initial feature reports are fetched from it. Below is an example
> output with some additional debug included:
>
> i2c_hid i2c-DLL0704:01: Fetching the HID descriptor
> i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00
> i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ...
> ...
> i2c_hid i2c-DLL0704:01: i2c_hid_get_report
> i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00
> i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05
> i2c_hid i2c-DLL0704:01: report id 13
> i2c_hid i2c-DLL0704:01: i2c_hid_get_report
> i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00
> i2c_hid i2c-DLL0704:01: failed to retrieve report from device.
> i2c_hid i2c-DLL0704:01: report id 7
> i2c_hid i2c-DLL0704:01: i2c_hid_get_report
> i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00
> i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ...
> i2c_hid i2c-DLL0704:01: report id 4
> i2c_hid i2c-DLL0704:01: i2c_hid_get_report
> i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00
>
> We manage to fetch few reports but then the touchpad dies:
>
> i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration
> i2c_hid i2c-DLL0704:01: failed to retrieve report from device.
>
> it eventually pulls the whole I2C bus low:
>
> i2c_designware i2c_designware.1: controller timed out
> i2c_hid i2c-DLL0704:01: failed to set a report to device.
>
> Fix this by preventing initial feature report retrieval for Win8 devices.
> Instead we fetch reports as needed in mt_feature_mapping(). This prevents
> fetching reports which might cause problems with the device in question.
>
> Suggested-by: Benjamin Tissoires
> Signed-off-by: Mika Westerberg
> ---
> This is a second version. The first one which just prevented initial report
> reading can be found here:
>
> https://lkml.org/lkml/2015/9/24/191
>
> This version tries to do what Benjamin suggested by reading feature values
> as needed in mt_feature_mapping(). This fixes the issue in the Dell laptop
> I have here.
Thanks for the re-spin Mika.
I just have one comment that needs discussion:
>
> drivers/hid/hid-multitouch.c | 42 +-
> 1 file changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 661b4fce1a5d..d9ca2b96ab68 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -309,6 +309,38 @@ static struct attribute_group mt_attribute_group = {
> .attrs = sysfs_attrs
> };
>
> +static void mt_get_feature(struct hid_device *hdev, struct hid_report
> *report)
> +{
> + int ret, size = hid_report_len(report);
> + u8 *buf;
> +
> + /*
> + * Only fetch the feature report if initial reports are not already
> + * been retrieved. Currently this is only done for Windows 8 touch
> + * devices.
> + */
> + if (!(hdev->quirks & HID_QUIRK_NO_INIT_REPORTS))
> + return;
Some Win 7 panels have this quirk set too because they do not support
either querying random feature or input reports.
I think this test is safe given that this is, I think, what the Windows
driver does (I remember that it queries for the features it needs).
However I am not 100% sure if this will not break one low quality
touchscreen.
I would be in favor of applying the patch in its current shape, but if
Jiri thinks we need a little bit more caution here, we would need to add
a test regarding the Win8 capability here.
Jiri?
If we apply it, this patch is:
Reviewed-by: Benjamin Tissoires
Cheers,
Benjamin
> +
> + buf = hid_alloc_report_buf(report, GFP_KERNEL);
> + if (!buf)
> + return;
> +
> + ret = hid_hw_raw_request(hdev, report->id, buf, size,
> + HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
> + if (ret < 0) {
> + dev_warn(&hdev->dev, "failed to fetch feature %d\n",
> + report->id);
> + } else {
> + ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, buf,
> +size, 0);
> + if (ret)
> + dev_warn(&hdev->dev, "failed to report feature\n");
> + }
> +
> + kfree(buf);
> +}
> +
> static void mt_feature_mapping(struct hid_device *hdev,
> struct hid_field *field, struct hid_usage *usage)
> {
> @@ -327,6 +359,8 @@ static void mt_feature_mapping(struct hid_device *hdev,
>
> break;
> case HID_DG_CONTACTMAX:
> + mt_get_feature(hdev, field->report);
> +
> td->maxcontact_report_id = field->report->id;
> td->maxcontacts = field->value[0];
> if (!td->maxcontacts &&
> @@ -343,6 +377,7 @@ static void mt_feature_mapping(struct hi
[PATCH v7 0/20] On-demand device probing
Hello, I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels and linking order. While reading the thread [1] that Alexander Holler started with his series to make probing order deterministic, it occurred to me that it should be possible to achieve the same by probing devices as they are referenced by other devices. This basically reuses the information that is already implicit in the probe() implementations, saving us from refactoring existing drivers or adding information to DTBs. During review of v1 of this series Linus Walleij suggested that it should be the device driver core to make sure that dependencies are ready before probing a device. I gave this idea a try [2] but Mark Brown pointed out to the logic duplication between the resource acquisition and dependency discovery code paths (though I think it's fairly minor). To address that code duplication I experimented with Arnd's devm_probe [3] concept of having drivers declare their dependencies instead of acquiring them during probe, and while it worked [4], I don't think we end up winning anything when compared to just probing devices on-demand from resource getters. One remaining objection is to the "sprinkling" of calls to of_device_probe() in the resource getters of each subsystem, but I think it's the right thing to do given that the storage of resources is currently subsystem-specific. We could avoid the above by moving resource storage into the core, but I don't think there's a compelling case for that. I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and OMAP SoCs, and these patches were enough to eliminate all the deferred probes (except one in PandaBoard because omap_dma_system doesn't have a firmware node as of yet). Have submitted a branch [5][6][7] with these patches on top of friday's linux-next (20150925) to kernelci.org and I don't see any issues that could be caused by them. With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. Regards, Tomeu [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html [1] https://lkml.org/lkml/2014/5/12/452 [2] https://lkml.org/lkml/2015/6/17/305 [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689 [4] https://lkml.org/lkml/2015/7/21/441a [5] https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v9 [6] http://kernelci.org/boot/all/job/collabora/kernel/v4.3-rc2-3497-g96d8df1bbcc1/ [7] http://kernelci.org/boot/all/job/next/kernel/next-20150925 Changes in v7: - Move IS_ENABLED(CONFIG_DELAY_DEVICE_PROBES) into if condition - Hide CONFIG_DELAY_DEVICE_PROBES behind EXPERT - Removed patch that moved deferred probe processing to device_initcall_sync, as it's not currently needed and can be applied later if we find any boards that fail to boot without this change. Changes in v6: - Drop bus_type.pre_probe and read the periphid in match() instead as suggested by Alan Stern. Changes in v5: - Set the pointer to struct device also for AMBA devices - Unset the pointer to struct device when the platform device is about to be unregistered - Increase the reference count of the device before returning from of_find_device_by_node() - Move the assignment to device_node->device for AMBA devices to another commit. - Hold a reference to the struct device while it's in use in of_device_probe(). Changes in v4: - Added bus.pre_probe callback so the probes of Primecell devices can be deferred if their device IDs cannot be yet read because of the clock driver not having probed when they are registered. Maybe this goes overboard and the matching information should be in the DT if there is one. - Rename of_platform_probe to of_device_probe - Use device_node.device instead of device_node.platform_dev - Add Kconfig DELAY_DEVICE_PROBES to allow disabling delayed probing in machines with initcalls that depend on devices probing at a given time. - Also defer probes of AMBA devices registered from the DT as they can also request resources. Changes in v3: - Set and use device_node.platform_dev instead of reversing the logic to find the platform device that encloses a device node. - Drop the fwnode API to probe firmware nodes and add OF-only API for now. I think this same scheme could be used for machines with ACPI, but I haven't been able to find one that had to defer its probes because of the device probe order. Tomeu Vizoso (20): driver core: handle -EPROBE_DEFER from bus_type.match() ARM: amba: Move reading of periphid to amba_match() of/platform: Point to struct device from device node of: add function to allow probing a device from a OF node gpio: Probe GPIO drivers on demand pinctrl: Probe pinctrl devices on de
[PATCH v7 02/20] ARM: amba: Move reading of periphid to amba_match()
Reading the periphid when the Primecell device is registered means that
the apb pclk must be available by then or the device won't be registered
at all.
By reading the periphid in amba_match() we can return -EPROBE_DEFER if
the apb pclk isn't there yet and the device will be retried later.
Signed-off-by: Tomeu Vizoso
---
Changes in v6:
- Drop bus_type.pre_probe and read the periphid in match() instead as
suggested by Alan Stern.
Changes in v4:
- Added bus.pre_probe callback so the probes of Primecell devices can be
deferred if their device IDs cannot be yet read because of the clock
driver not having probed when they are registered. Maybe this goes
overboard and the matching information should be in the DT if there is
one.
drivers/amba/bus.c | 88 --
1 file changed, 46 insertions(+), 42 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index f0099360039e..72ebf9b1c715 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -24,6 +24,8 @@
#define to_amba_driver(d) container_of(d, struct amba_driver, drv)
+static int read_periphid(struct amba_device *d, unsigned int *periphid);
+
static const struct amba_id *
amba_lookup(const struct amba_id *table, struct amba_device *dev)
{
@@ -43,11 +45,22 @@ static int amba_match(struct device *dev, struct
device_driver *drv)
{
struct amba_device *pcdev = to_amba_device(dev);
struct amba_driver *pcdrv = to_amba_driver(drv);
+ int ret;
/* When driver_override is set, only bind to the matching driver */
if (pcdev->driver_override)
return !strcmp(pcdev->driver_override, drv->name);
+ if (!pcdev->periphid) {
+ ret = read_periphid(pcdev, &pcdev->periphid);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to read periphid: %d",
+ ret);
+ return ret;
+ }
+ }
+
return amba_lookup(pcdrv->id_table, pcdev) != NULL;
}
@@ -336,44 +349,22 @@ static void amba_device_release(struct device *dev)
kfree(d);
}
-/**
- * amba_device_add - add a previously allocated AMBA device structure
- * @dev: AMBA device allocated by amba_device_alloc
- * @parent: resource parent for this devices resources
- *
- * Claim the resource, and read the device cell ID if not already
- * initialized. Register the AMBA device with the Linux device
- * manager.
- */
-int amba_device_add(struct amba_device *dev, struct resource *parent)
+static int read_periphid(struct amba_device *d, unsigned int *periphid)
{
u32 size;
void __iomem *tmp;
- int i, ret;
-
- WARN_ON(dev->irq[0] == (unsigned int)-1);
- WARN_ON(dev->irq[1] == (unsigned int)-1);
-
- ret = request_resource(parent, &dev->res);
- if (ret)
- goto err_out;
-
- /* Hard-coded primecell ID instead of plug-n-play */
- if (dev->periphid != 0)
- goto skip_probe;
+ int i, ret = 0;
/*
* Dynamically calculate the size of the resource
* and use this for iomap
*/
- size = resource_size(&dev->res);
- tmp = ioremap(dev->res.start, size);
- if (!tmp) {
- ret = -ENOMEM;
- goto err_release;
- }
+ size = resource_size(&d->res);
+ tmp = ioremap(d->res.start, size);
+ if (!tmp)
+ return -ENOMEM;
- ret = amba_get_enable_pclk(dev);
+ ret = amba_get_enable_pclk(d);
if (ret == 0) {
u32 pid, cid;
@@ -388,37 +379,50 @@ int amba_device_add(struct amba_device *dev, struct
resource *parent)
cid |= (readl(tmp + size - 0x10 + 4 * i) & 255) <<
(i * 8);
- amba_put_disable_pclk(dev);
+ amba_put_disable_pclk(d);
if (cid == AMBA_CID || cid == CORESIGHT_CID)
- dev->periphid = pid;
+ *periphid = pid;
- if (!dev->periphid)
+ if (!*periphid)
ret = -ENODEV;
}
iounmap(tmp);
+ return ret;
+}
+
+/**
+ * amba_device_add - add a previously allocated AMBA device structure
+ * @dev: AMBA device allocated by amba_device_alloc
+ * @parent: resource parent for this devices resources
+ *
+ * Claim the resource, and register the AMBA device with the Linux device
+ * manager.
+ */
+int amba_device_add(struct amba_device *dev, struct resource *parent)
+{
+ int ret;
+
+ WARN_ON(dev->irq[0] == (unsigned int)-1);
+ WARN_ON(dev->irq[1] == (unsigned int)-1);
+
+ ret = request_resource(parent, &dev->res);
if (ret)
- goto err_release;
+ return ret;
- skip_probe:
ret = devic
[PATCH v7 07/20] regulator: core: Probe regulators on demand
When looking up a regulator through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
Acked-by: Mark Brown
---
drivers/regulator/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 7a85ac9e32c5..ee75199c2cfa 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1340,6 +1341,7 @@ static struct regulator_dev *regulator_dev_lookup(struct
device *dev,
if (dev && dev->of_node) {
node = of_get_regulator(dev, supply);
if (node) {
+ of_device_probe(node);
list_for_each_entry(r, ®ulator_list, list)
if (r->dev.parent &&
node == r->dev.of_node)
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 03/20] of/platform: Point to struct device from device node
When adding platform and AMBA devices, set the device node's device
member to point to it.
This speeds lookups considerably and is safe because we only create one
of these devices for any given device node.
Signed-off-by: Tomeu Vizoso
---
Changes in v5:
- Set the pointer to struct device also for AMBA devices
- Unset the pointer to struct device when the platform device is about
to be unregistered
- Increase the reference count of the device before returning from
of_find_device_by_node()
drivers/of/platform.c | 19 ++-
include/linux/of.h| 1 +
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 1001efaedcb8..408d89f1d124 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -32,11 +32,6 @@ const struct of_device_id of_default_bus_match_table[] = {
{} /* Empty terminated list */
};
-static int of_dev_node_match(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
/**
* of_find_device_by_node - Find the platform_device associated with a node
* @np: Pointer to device tree node
@@ -45,10 +40,10 @@ static int of_dev_node_match(struct device *dev, void *data)
*/
struct platform_device *of_find_device_by_node(struct device_node *np)
{
- struct device *dev;
-
- dev = bus_find_device(&platform_bus_type, NULL, np, of_dev_node_match);
- return dev ? to_platform_device(dev) : NULL;
+ if (np->device && np->device->bus == &platform_bus_type &&
+ get_device(np->device))
+ return to_platform_device(np->device);
+ return NULL;
}
EXPORT_SYMBOL(of_find_device_by_node);
@@ -192,6 +187,8 @@ static struct platform_device
*of_platform_device_create_pdata(
goto err_clear_flag;
}
+ np->device = &dev->dev;
+
return dev;
err_clear_flag:
@@ -272,6 +269,8 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
goto err_free;
}
+ node->device = &dev->dev;
+
return dev;
err_free:
@@ -476,6 +475,8 @@ static int of_platform_device_destroy(struct device *dev,
void *data)
if (of_node_check_flag(dev->of_node, OF_POPULATED_BUS))
device_for_each_child(dev, NULL, of_platform_device_destroy);
+ dev->of_node->device = NULL;
+
if (dev->bus == &platform_bus_type)
platform_device_unregister(to_platform_device(dev));
#ifdef CONFIG_ARM_AMBA
diff --git a/include/linux/of.h b/include/linux/of.h
index 2194b8ca41f9..eb091be0f8ee 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -52,6 +52,7 @@ struct device_node {
phandle phandle;
const char *full_name;
struct fwnode_handle fwnode;
+ struct device *device;
struct property *properties;
struct property *deadprops;/* removed properties */
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 01/20] driver core: handle -EPROBE_DEFER from bus_type.match()
Lets implementations of the match() callback in struct bus_type to
return errors and if it's -EPROBE_DEFER then queue the device for
deferred probing.
This is useful to buses such as AMBA in which devices are registered
before their matching information can be retrieved from the HW
(typically because a clock driver hasn't probed yet).
Signed-off-by: Tomeu Vizoso
---
drivers/base/dd.c | 24 ++--
include/linux/device.h | 2 +-
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb4639128..7dc04ee81c8b 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -488,6 +488,7 @@ static int __device_attach_driver(struct device_driver
*drv, void *_data)
struct device_attach_data *data = _data;
struct device *dev = data->dev;
bool async_allowed;
+ int ret;
/*
* Check if device has already been claimed. This may
@@ -498,8 +499,17 @@ static int __device_attach_driver(struct device_driver
*drv, void *_data)
if (dev->driver)
return -EBUSY;
- if (!driver_match_device(drv, dev))
+ ret = driver_match_device(drv, dev);
+ if (!ret)
return 0;
+ else if (ret < 0) {
+ if (ret == -EPROBE_DEFER) {
+ dev_dbg(dev, "Device match requests probe deferral\n");
+ driver_deferred_probe_add(dev);
+ } else
+ dev_warn(dev, "Bus failed to match device: %d", ret);
+ return ret;
+ }
async_allowed = driver_allows_async_probing(drv);
@@ -619,6 +629,7 @@ void device_initial_probe(struct device *dev)
static int __driver_attach(struct device *dev, void *data)
{
struct device_driver *drv = data;
+ int ret;
/*
* Lock device and try to bind to it. We drop the error
@@ -630,8 +641,17 @@ static int __driver_attach(struct device *dev, void *data)
* is an error.
*/
- if (!driver_match_device(drv, dev))
+ ret = driver_match_device(drv, dev);
+ if (!ret)
+ return 0;
+ else if (ret < 0) {
+ if (ret == -EPROBE_DEFER) {
+ dev_dbg(dev, "Device match requests probe deferral\n");
+ driver_deferred_probe_add(dev);
+ } else
+ dev_warn(dev, "Bus failed to match device: %d", ret);
return 0;
+ }
if (dev->parent)/* Needed for USB */
device_lock(dev->parent);
diff --git a/include/linux/device.h b/include/linux/device.h
index 5d7bc6349930..8e7b806f0744 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -70,7 +70,7 @@ extern void bus_remove_file(struct bus_type *, struct
bus_attribute *);
* @dev_groups:Default attributes of the devices on the bus.
* @drv_groups: Default attributes of the device drivers on the bus.
* @match: Called, perhaps multiple times, whenever a new device or driver
- * is added for this bus. It should return a nonzero value if the
+ * is added for this bus. It should return a positive value if the
* given device can be handled by the given driver.
* @uevent:Called when a device is added, removed, or a few other things
* that generate uevents to add the environment variables.
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 06/20] pinctrl: Probe pinctrl devices on demand
When looking up a pin controller through its OF node, probe it if it hasn't already. The goal is to reduce deferred probes to a minimum, as it makes it very cumbersome to find out why a device failed to probe, and can introduce very big delays in when a critical device is probed. Signed-off-by: Tomeu Vizoso Acked-by: Linus Walleij --- drivers/gpio/gpiolib-of.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c index 9a439dab7a87..05da9a56608d 100644 --- a/drivers/gpio/gpiolib-of.c +++ b/drivers/gpio/gpiolib-of.c @@ -359,6 +359,8 @@ static int of_gpiochip_add_pin_range(struct gpio_chip *chip) if (ret) break; + of_device_probe(pinspec.np); + pctldev = of_pinctrl_get(pinspec.np); if (!pctldev) return -EPROBE_DEFER; -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 19/20] driver core: Allow deferring probes until late init
Add a field to struct device that instructs the device-driver core to
defer the probe of this device until the late_initcall level.
By letting all built-in drivers to register before starting to probe, we
can avoid any deferred probes by probing dependencies on demand.
Signed-off-by: Tomeu Vizoso
---
Changes in v7:
- Move IS_ENABLED(CONFIG_DELAY_DEVICE_PROBES) into if condition
- Hide CONFIG_DELAY_DEVICE_PROBES behind EXPERT
Changes in v4:
- Add Kconfig DELAY_DEVICE_PROBES to allow disabling delayed probing in
machines with initcalls that depend on devices probing at a given time.
drivers/base/Kconfig | 18 ++
drivers/base/dd.c | 6 ++
include/linux/device.h | 2 ++
3 files changed, 26 insertions(+)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 98504ec99c7d..8bb7b556da1b 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -324,4 +324,22 @@ config CMA_ALIGNMENT
endif
+config DELAY_DEVICE_PROBES
+ bool "Allow delaying the probe of some devices" if EXPERT
+ default y
+ help
+ Devices can be matched to a driver and probed from the moment they
+ are registered, but early during boot their probes are likely to be
+ deferred because some dependency isn't available yet because most
+ drivers haven't been registered yet.
+
+ Enabling this option allows the device registration code to delay the
+ probing of a specific device until device_initcall_sync, when all
+ built-in drivers have been registered already.
+
+ In some platforms there may be implicit assumptions about when some
+ devices are probed, so enabling this option could cause problems
there.
+
+ If unsure, say Y here.
+
endmenu
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 7dc04ee81c8b..c4a3f298e726 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -417,6 +417,12 @@ int driver_probe_device(struct device_driver *drv, struct
device *dev)
if (!device_is_registered(dev))
return -ENODEV;
+ if (IS_ENABLED(CONFIG_DELAY_DEVICE_PROBES) &&
+ !driver_deferred_probe_enable && dev->probe_late) {
+ driver_deferred_probe_add(dev);
+ return 0;
+ }
+
pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
drv->bus->name, __func__, dev_name(dev), drv->name);
diff --git a/include/linux/device.h b/include/linux/device.h
index 8e7b806f0744..e64f4c7e243d 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -744,6 +744,7 @@ struct device_dma_parameters {
*
* @offline_disabled: If set, the device is permanently online.
* @offline: Set after successful invocation of bus type's .offline().
+ * @probe_late:If set, device will be probed in the late initcall
level.
*
* At the lowest level, every device in a Linux system is represented by an
* instance of struct device. The device structure contains the information
@@ -828,6 +829,7 @@ struct device {
booloffline_disabled:1;
booloffline:1;
+ boolprobe_late:1;
};
static inline struct device *kobj_to_dev(struct kobject *kobj)
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 08/20] drm: Probe panels on demand
When looking up a panel through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_panel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e037b7..ad79a7b9c74d 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
@@ -80,6 +81,8 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
{
struct drm_panel *panel;
+ of_device_probe(np);
+
mutex_lock(&panel_lock);
list_for_each_entry(panel, &panel_list, list) {
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 10/20] i2c: core: Probe i2c adapters and devices on demand
When looking up an i2c adapter or device through its OF node, probe it if it hasn't already. The goal is to reduce deferred probes to a minimum, as it makes it very cumbersome to find out why a device failed to probe, and can introduce very big delays in when a critical device is probed. Signed-off-by: Tomeu Vizoso --- drivers/i2c/i2c-core.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 5f89f1e3c2f2..02da3acbbd35 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -1413,6 +1413,8 @@ struct i2c_client *of_find_i2c_device_by_node(struct device_node *node) struct device *dev; struct i2c_client *client; + of_device_probe(node); + dev = bus_find_device(&i2c_bus_type, NULL, node, of_dev_node_match); if (!dev) return NULL; @@ -1431,6 +1433,8 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node) struct device *dev; struct i2c_adapter *adapter; + of_device_probe(node); + dev = bus_find_device(&i2c_bus_type, NULL, node, of_dev_node_match); if (!dev) return NULL; -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime
* Ard Biesheuvel wrote:
> > except that I don't think
> > the condition on 64-bit makes any sense:
> >
> > + if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
> >
> > I can see us being nervous wrt. backported patches, but is there any strong
> > reason
> > to not follow this up with a third (non-backported) patch that changes this
> > to:
> >
> > + if (!efi_enabled(EFI_OLD_MEMMAP)) {
> >
> > for v4.4?
> >
>
> The 32-bit side essentially implements the old memmap only, which is the the
> bottom-up version. So old memmap will be implied by 32-bit but not set in the
> EFI flags, resulting in the reverse enumeration being used with the bottom-up
> mapping logic. The net result of that is that we create the same problem for
> 32-bit that we are trying to solve for 64-bit, i.e., the regions will end up
> in
> reverse order in the VA mapping.
>
> To deobfuscate this particular conditional, we could set EFI_OLD_MEMMAP
> unconditionally on 32-bit x86. Or we could reshuffle variables and
> conditionals
> in various other way.
Setting EFI_OLD_MEMMAP would be fine, if doing that has no bad side effects.
> [...] I am not convinced that the overall end result will be any better
> though.
That's not true, we change an obscure, implicit dependency on 32-bit detail to
an
explicit EFI_OLD_MEMMAP flag that shows exactly what's happening. That's a
clear
improvement.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
