[PATCH] mips: Fix console output for Fulong2e system
Commit 3adeb2566b9b ("MIPS: Loongson: Improve LEFI firmware interface")
made the number of UARTs dynamic if LEFI_FIRMWARE_INTERFACE is configured.
Unfortunately, it did not initialize the number of UARTs if
LEFI_FIRMWARE_INTERFACE is not configured. As a result, the Fulong2e
system has no console.
Fixes: 3adeb2566b9b ("MIPS: Loongson: Improve LEFI firmware interface")
Cc: Huacai Chen
Signed-off-by: Guenter Roeck
---
Never mind my earlier e-mail, I figured it out.
Should be a candidate for stable (v3.19+, ie v4.1 in practice).
arch/mips/loongson64/common/env.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/mips/loongson64/common/env.c
b/arch/mips/loongson64/common/env.c
index f6c44dd332e2..d6d07ad56180 100644
--- a/arch/mips/loongson64/common/env.c
+++ b/arch/mips/loongson64/common/env.c
@@ -64,6 +64,9 @@ void __init prom_init_env(void)
}
if (memsize == 0)
memsize = 256;
+
+ loongson_sysconf.nr_uarts = 1;
+
pr_info("memsize=%u, highmemsize=%u\n", memsize, highmemsize);
#else
struct boot_params *boot_p;
--
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/
Re: [PATCH] usb: chipidea: imx: properly check for usbmisc
On Fri, Aug 07, 2015 at 10:11:47AM +0800, Peter Chen wrote: > On Thu, Aug 06, 2015 at 03:09:54PM +0200, Tomeu Vizoso wrote: > > If usbmisc hasn't probed yet, defer the probe. > > > > It's not enough to check if the platform device for the OF node of the > > usbmisc has been registered, but it also needs to have been probed > > already before we can call imx_usbmisc_init(). > > > > This can happen if the order in which devices are probed change due to > > async probing or on-demand probing of dependencies. > > > > Signed-off-by: Tomeu Vizoso > > --- > > drivers/usb/chipidea/ci_hdrc_imx.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c > > b/drivers/usb/chipidea/ci_hdrc_imx.c > > index 504554e41922..e3c61d5e9270 100644 > > --- a/drivers/usb/chipidea/ci_hdrc_imx.c > > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c > > @@ -104,7 +104,7 @@ static struct imx_usbmisc_data > > *usbmisc_get_init_data(struct device *dev) > > misc_pdev = of_find_device_by_node(args.np); > > of_node_put(args.np); > > > > - if (!misc_pdev) > > + if (!misc_pdev || !platform_get_drvdata(misc_pdev)) > > return ERR_PTR(-EPROBE_DEFER); > > "||"? or "&&"? You want usbmisc has already been probed. Oh, oops. The patch is right, I will queue it. -- Best Regards, Peter Chen -- 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: [RFC PATCH v4 4/9] arc: axs10x_defconfig: remove CONFIG_MMC_DW_IDMAC
On Thursday 06 August 2015 12:19 PM, Shawn Lin wrote: > DesignWare MMC Controller's transfer mode should be decided > at runtime instead of compile-time. So we remove this config > option and read dw_mmc's register to select DMA master. > > Signed-off-by: Shawn Lin Acked-by: Vineet Gupta Thx, -Vineet -- 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] gadget: Introduce the usb charger framework
On 7 August 2015 at 00:39, Greg KH wrote:
> On Thu, Aug 06, 2015 at 03:03:48PM +0800, Baolin Wang wrote:
>> This patch introduces the usb charger driver based on usb gadget that
>> makes an enhancement to a power driver. It works well in practice but
>> that requires a system with suitable hardware.
>>
>> The basic conception of the usb charger is that, when one usb charger
>> is added or removed by reporting from the usb gadget state change or
>> the extcon device state change, the usb charger will report to power
>> user to set the current limitation.
>>
>> The usb charger will register notifiees on the usb gadget or the extcon
>> device to get notified the usb charger state.
>>
>> Power user will register a notifiee on the usb charger to get notified
>> by status changes from the usb charger. It will report to power user
>> to set the current limitation when detecting the usb charger is added
>> or removed from extcon device state or usb gadget state.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> drivers/usb/gadget/charger.c| 547
>> +++
>> include/linux/usb/usb_charger.h | 101
>> 2 files changed, 648 insertions(+)
>> create mode 100644 drivers/usb/gadget/charger.c
>> create mode 100644 include/linux/usb/usb_charger.h
>>
>> diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
>> new file mode 100644
>> index 000..3ca0180
>> --- /dev/null
>> +++ b/drivers/usb/gadget/charger.c
>> @@ -0,0 +1,547 @@
>> +/*
>> + * usb charger.c -- USB charger driver
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>
> I have to ask, do you really mean "any later version"?
>
I'll think about this and modify it.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DEFAULT_CUR_PROTECT (50)
>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_DCP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_CDP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_ACA_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +
>> +static LIST_HEAD(usb_charger_list);
>> +static DEFINE_MUTEX(usb_charger_list_lock);
>> +
>> +/*
>> + * usb_charger_find_by_name - Get the usb charger device by name.
>> + * @name - usb charger device name.
>> + *
>> + * notes: when this function walks the list and returns a charger
>> + * it's dropped the lock which means that something else could come
>> + * along and delete the charger before we dereference the pointer.
>> + * It's very unlikely but it's a possibility so you should take care
>> + * of it.
>> + * Thus when you get the usb charger by name, you should call
>> + * put_usb_charger() to derease the reference count of the usb charger.
>> + *
>> + * return the instance of usb charger device.
>> + */
>> +struct usb_charger *usb_charger_find_by_name(char *name)
>> +{
>> + struct usb_charger *uchger;
>> +
>> + if (!name)
>> + return ERR_PTR(-EINVAL);
>> +
>> + mutex_lock(_charger_list_lock);
>> + list_for_each_entry(uchger, _charger_list, entry) {
>> + if (!strcmp(uchger->name, name)) {
>> + get_usb_charger(uchger);
>> + mutex_unlock(_charger_list_lock);
>> + return uchger;
>> + }
>> + }
>> + mutex_unlock(_charger_list_lock);
>> +
>> + return NULL;
>> +}
>> +
>> +/*
>> + * usb_charger_register_notify() - Register a notifiee to get notified by
>> + * any attach status changes from the usb charger type detection.
>> + * @uchger - the usb charger device which is monitored.
>> + * @nb - a notifier block to be registered.
>> + */
>> +void usb_charger_register_notify(struct usb_charger *uchger,
>> + struct notifier_block *nb)
>> +{
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(>lock, flags);
>> + raw_notifier_chain_register(>uchger_nh, nb);
>> + spin_unlock_irqrestore(>lock, flags);
>> +}
>> +
>> +/*
>> + * usb_charger_unregister_notify() - Unregister a notifiee from the usb
>> charger.
>> + * @uchger - the usb charger device which is monitored.
>> + * @nb - a notifier block to be unregistered.
>> + */
>> +void usb_charger_unregister_notify(struct usb_charger *uchger,
>> +struct notifier_block *nb)
>> +{
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(>lock, flags);
>> + raw_notifier_chain_unregister(>uchger_nh, nb);
>> + spin_unlock_irqrestore(>lock, flags);
>> +}
>> +
>> +/*
>> + * usb_charger_register_extcon_notifier() - Register a
RE: [PATCH 8/9] KVM: x86: Add EOI exit bitmap inference
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Paolo Bonzini
> Sent: Wednesday, August 05, 2015 11:24 PM
> To: linux-kernel@vger.kernel.org; k...@vger.kernel.org
> Cc: Steve Rutherford; rkrc...@redhat.com
> Subject: [PATCH 8/9] KVM: x86: Add EOI exit bitmap inference
>
> From: Steve Rutherford
>
> In order to support a userspace IOAPIC interacting with an in kernel
> APIC, the EOI exit bitmaps need to be configurable.
>
> If the IOAPIC is in userspace (i.e. the irqchip has been split), the
> EOI exit bitmaps will be set whenever the GSI Routes are configured.
> In particular, for the low MSI routes are reservable for userspace
> IOAPICs. For these MSI routes, the EOI Exit bit corresponding to the
> destination vector of the route will be set for the destination VCPU.
>
> The intention is for the userspace IOAPICs to use the reservable MSI
> routes to inject interrupts into the guest.
>
> This is a slight abuse of the notion of an MSI Route, given that MSIs
> classically bypass the IOAPIC. It might be worthwhile to add an
> additional route type to improve clarity.
>
> Compile tested for Intel x86.
>
> Signed-off-by: Steve Rutherford
> Signed-off-by: Paolo Bonzini
> ---
> Documentation/virtual/kvm/api.txt | 9 ++---
> arch/x86/include/asm/kvm_host.h | 1 +
> arch/x86/kvm/ioapic.h | 2 ++
> arch/x86/kvm/irq_comm.c | 42
> +++
> arch/x86/kvm/lapic.c | 3 +--
> arch/x86/kvm/x86.c| 9 -
> include/linux/kvm_host.h | 17
> virt/kvm/irqchip.c| 12 ++-
> 8 files changed, 79 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index bda6cb747b23..dcd748e2d46d 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -3635,7 +3635,7 @@ KVM handlers should exit to userspace with rc =
> -EREMOTE.
> 7.5 KVM_CAP_SPLIT_IRQCHIP
>
> Architectures: x86
> -Parameters: None
> +Parameters: args[0] - number of routes reserved for userspace IOAPICs
> Returns: 0 on success, -1 on error
>
> Create a local apic for each processor in the kernel. This can be used
> @@ -3643,8 +3643,11 @@ instead of KVM_CREATE_IRQCHIP if the userspace
> VMM wishes to emulate the
> IOAPIC and PIC (and also the PIT, even though this has to be enabled
> separately).
>
> -This supersedes KVM_CREATE_IRQCHIP, creating only local APICs, but no in
> kernel
> -IOAPIC or PIC. This also enables in kernel routing of interrupt requests.
> +This capability also enables in kernel routing of interrupt requests;
> +when KVM_CAP_SPLIT_IRQCHIP only routes of KVM_IRQ_ROUTING_MSI type
> are
> +used in the IRQ routing table. The first args[0] MSI routes are reserved
> +for the IOAPIC pins. Whenever the LAPIC receives an EOI for these routes,
> +a KVM_EXIT_IOAPIC_EOI vmexit will be reported to userspace.
>
> Fails if VCPU has already been created, or if the irqchip is already in the
> kernel (i.e. KVM_CREATE_IRQCHIP has already been called).
> diff --git a/arch/x86/include/asm/kvm_host.h
> b/arch/x86/include/asm/kvm_host.h
> index 4294722dfd1d..4bc714f7b164 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -687,6 +687,7 @@ struct kvm_arch {
> u64 disabled_quirks;
>
> bool irqchip_split;
> + u8 nr_reserved_ioapic_pins;
> };
>
> struct kvm_vm_stat {
> diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
> index a8842c0dee73..084617d37c74 100644
> --- a/arch/x86/kvm/ioapic.h
> +++ b/arch/x86/kvm/ioapic.h
> @@ -9,6 +9,7 @@ struct kvm;
> struct kvm_vcpu;
>
> #define IOAPIC_NUM_PINS KVM_IOAPIC_NUM_PINS
> +#define MAX_NR_RESERVED_IOAPIC_PINS KVM_MAX_IRQ_ROUTES
> #define IOAPIC_VERSION_ID 0x11 /* IOAPIC version */
> #define IOAPIC_EDGE_TRIG 0
> #define IOAPIC_LEVEL_TRIG 1
> @@ -121,5 +122,6 @@ int kvm_irq_delivery_to_apic(struct kvm *kvm, struct
> kvm_lapic *src,
> int kvm_get_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
> int kvm_set_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
> void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
> +void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
>
> #endif
> diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
> index 67f6b62a6814..177460998bb0 100644
> --- a/arch/x86/kvm/irq_comm.c
> +++ b/arch/x86/kvm/irq_comm.c
> @@ -335,3 +335,45 @@ int kvm_setup_empty_irq_routing(struct kvm *kvm)
> {
> return kvm_set_irq_routing(kvm, empty_routing, 0, 0);
> }
> +
> +void kvm_arch_irq_routing_update(struct kvm *kvm)
> +{
> + if (ioapic_in_kernel(kvm) || !irqchip_in_kernel(kvm))
> + return;
> + kvm_make_scan_ioapic_request(kvm);
> +}
> +
> +void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
> +{
Re: [PATCH] modpost: abort if a module symbol is too long
On Thu, 06 Aug 2015 23:09:12 +0200, Rusty Russell wrote: > > Takashi Iwai writes: > > Module symbols have a limited length, but currently the build system > > allows the build finishing even if the driver code contains a too long > > symbol name, which eventually overflows the modversion_info[] item. > > The compiler may catch at compiling *.mod.c like > > CC xxx.mod.o > > xxx.mod.c:18:16: warning: initializer-string for array of chars is too > > long > > but it's merely a warning. > > > > This patch adds the check of the symbol length in modpost and stops > > the build properly. > > > > As of now, MODULE_NAME_LEN is copied in modpost.c. At best, this > > should be read directly from kernel headers. But including > > linux/module.h is too troublesome for now, so just paper over it. > > > > Signed-off-by: Takashi Iwai > > --- > > scripts/mod/modpost.c | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c > > index 12d3db3bd46b..25bda9d2868c 100644 > > --- a/scripts/mod/modpost.c > > +++ b/scripts/mod/modpost.c > > @@ -2133,6 +2133,9 @@ static void add_staging_flag(struct buffer *b, const > > char *name) > > buf_printf(b, "\nMODULE_INFO(staging, \"Y\");\n"); > > } > > > > +/* FIXME: better to be included from kernel header */ > > +#define MODULE_NAME_LEN (64 - sizeof(unsigned long)) > > This isn't quite right, since modpost handles cross-compilation. > > #define MODULE_NAME_LEN (64 - sizeof(Elf_Addr)) > > Should work... Alright, I'll resubmit with this fix. Thanks! Takashi -- 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] irqchip: gic-v3: Explicitly include linux/io.h
linux/io.h is needed because the driver uses:
readl_relaxed
writel_relaxed
writeq_relaxed
readq_relaxed
iounmap
The header was implicitly included by an unrelated
commit 332fd7c4fef5
("genirq: Generic chip: Change irq_reg_{readl,writel} arguments")
from the path below:
include/linux/io.h
include/linux/irq.h
include/linux/of_irq.h
drivers/irqchip/irq-gic-v3.c
Signed-off-by: Ben Zhang
---
drivers/irqchip/irq-gic-v3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index e406bc5..3350b8d 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
2.5.0.rc2.392.g76e840b
--
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-next: manual merge of the driver-core tree with Linus' tree
On 07-08-15, 15:26, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in:
>
> drivers/cpufreq/cpufreq.c
>
> between commit:
>
> 559ed40752dc ("cpufreq: Avoid attempts to create duplicate symbolic links")
>
> from Linus' tree and commit:
>
> 71db87ba5700 ("bus: subsys: update return type of ->remove_dev() to void")
>
> from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks fine. Thanks.
--
viresh
--
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 07/13] twl4030_charger: distinguish between USB current and 'AC' current
On Fri, 7 Aug 2015 07:13:09 +0200 Sebastian Reichel wrote: > Hi, > > This actually slipped through my review. IMHO madc should be > accessed through IIO, as already done for twl4030-madc-battery > and rx51-battery. That way the custom API can be removed at > some point. > > Anyway, I queued the below patch with Tony's ACK to fix the build > issue in next. > OK, thanks. I'll try to figure out are more proper approach ... might be a week or so though. Thanks, NeilBrown pgpDmsQwOgnXj.pgp Description: OpenPGP digital signature
[PULL] vhost: fix for 4.2
The following changes since commit 74d33293e467df61de1b1d8b2fbe29e550dec33b: Linux 4.2-rc5 (2015-08-02 18:34:55 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to df4198b1e0c4a7d1adde1e5c2ceb67ac10b391bb: virtio-input: reset device and detach unused during remove (2015-08-06 10:40:35 +0300) virtio: fix for 4.2 A last minute fix for the new virtio input driver. It seems pretty obvious, and the problem it's fixing would be quite hard to debug. Signed-off-by: Michael S. Tsirkin Jason Wang (1): virtio-input: reset device and detach unused during remove drivers/virtio/virtio_input.c | 4 1 file changed, 4 insertions(+) -- 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/
linux-next: manual merge of the driver-core tree with Linus' tree
Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in:
drivers/cpufreq/cpufreq.c
between commit:
559ed40752dc ("cpufreq: Avoid attempts to create duplicate symbolic links")
from Linus' tree and commit:
71db87ba5700 ("bus: subsys: update return type of ->remove_dev() to void")
from the driver-core tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/cpufreq/cpufreq.c
index 76a26609d96b,6da25c10bdfd..
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@@ -1464,44 -1518,43 +1464,42 @@@ static void cpufreq_offline_finish(unsi
*
* Removes the cpufreq interface for a CPU device.
*/
- static int cpufreq_remove_dev(struct device *dev, struct subsys_interface
*sif)
+ static void cpufreq_remove_dev(struct device *dev, struct subsys_interface
*sif)
{
unsigned int cpu = dev->id;
- int ret;
-
- /*
- * Only possible if 'cpu' is getting physically removed now. A hotplug
- * notifier should have already been called and we just need to remove
- * link or free policy here.
- */
- if (cpu_is_offline(cpu)) {
- struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
- struct cpumask mask;
+ struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
- if (!policy)
- return;
+ if (!policy)
- return 0;
++ return;
- cpumask_copy(, policy->related_cpus);
- cpumask_clear_cpu(cpu, );
+ if (cpu_online(cpu)) {
+ cpufreq_offline_prepare(cpu);
+ cpufreq_offline_finish(cpu);
+ }
- /*
- * Free policy only if all policy->related_cpus are removed
- * physically.
- */
- if (cpumask_intersects(, cpu_present_mask)) {
- remove_cpu_dev_symlink(policy, cpu);
- return;
- }
+ cpumask_clear_cpu(cpu, policy->real_cpus);
+ if (cpumask_empty(policy->real_cpus)) {
cpufreq_policy_free(policy, true);
- return 0;
+ return;
}
- ret = __cpufreq_remove_dev_prepare(dev, sif);
+ if (cpu != policy->kobj_cpu) {
+ remove_cpu_dev_symlink(policy, cpu);
+ } else {
+ /*
+ * The CPU owning the policy object is going away. Move it to
+ * another suitable CPU.
+ */
+ unsigned int new_cpu = cpumask_first(policy->real_cpus);
+ struct device *new_dev = get_cpu_device(new_cpu);
- if (!ret)
- __cpufreq_remove_dev_finish(dev, sif);
+ dev_dbg(dev, "%s: Moving policy object to CPU%u\n", __func__,
new_cpu);
+
+ sysfs_remove_link(_dev->kobj, "cpufreq");
+ policy->kobj_cpu = new_cpu;
+ WARN_ON(kobject_move(>kobj, _dev->kobj));
+ }
-
- return 0;
}
static void handle_update(struct work_struct *work)
--
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] video: fbdev: atmel: fix warning for const return value
On Mon, Jul 27, 2015 at 10:41:41AM -0500, Rob Herring wrote: > A const on a return value is meaningless and generates a warning on some > versions of gcc: > > drivers/video/fbdev/atmel_lcdfb.c:1003: warning: type qualifiers ignored on > function return type maybe this one should have been static instead of const. regards sudip -- 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 v3] base/platform: assert that dev_pm_domain callbacks are called unconditionally
When a platform driver doesn't provide a .remove callback the function
platform_drv_remove isn't called and so the call to dev_pm_domain_attach
called at probe time isn't paired by dev_pm_domain_detach at remove
time.
To fix this (and similar issues if different callbacks are missing) hook
up the driver callbacks unconditionally and make them aware that the
platform callbacks might be missing.
Signed-off-by: Uwe Kleine-König
---
Hello,
Changes since (implicit) v1, sent with
Message-Id: 1437491315-2370-1-git-send-email-...@kleine-koenig.org:
- initialize ret in platform_drv_remove
- change my email to the right one (only in the S-o-B) :-(
- adding some more people to Cc
Changes since v2, sent with
Message-Id: 1438849860-18504-1-git-send-email-u.kleine-koe...@pengutronix.de
- change my email to the right one also in the author spec
Best regards
Uwe
drivers/base/platform.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 063f0ab15259..58cea3ea00f8 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -517,7 +517,7 @@ static int platform_drv_probe(struct device *_dev)
return ret;
ret = dev_pm_domain_attach(_dev, true);
- if (ret != -EPROBE_DEFER) {
+ if (ret != -EPROBE_DEFER && drv->probe) {
ret = drv->probe(dev);
if (ret)
dev_pm_domain_detach(_dev, true);
@@ -540,9 +540,10 @@ static int platform_drv_remove(struct device *_dev)
{
struct platform_driver *drv = to_platform_driver(_dev->driver);
struct platform_device *dev = to_platform_device(_dev);
- int ret;
+ int ret = 0;
- ret = drv->remove(dev);
+ if (drv->remove)
+ ret = drv->remove(dev);
dev_pm_domain_detach(_dev, true);
return ret;
@@ -553,7 +554,8 @@ static void platform_drv_shutdown(struct device *_dev)
struct platform_driver *drv = to_platform_driver(_dev->driver);
struct platform_device *dev = to_platform_device(_dev);
- drv->shutdown(dev);
+ if (drv->shutdown)
+ drv->shutdown(dev);
dev_pm_domain_detach(_dev, true);
}
@@ -567,12 +569,9 @@ int __platform_driver_register(struct platform_driver *drv,
{
drv->driver.owner = owner;
drv->driver.bus = _bus_type;
- if (drv->probe)
- drv->driver.probe = platform_drv_probe;
- if (drv->remove)
- drv->driver.remove = platform_drv_remove;
- if (drv->shutdown)
- drv->driver.shutdown = platform_drv_shutdown;
+ drv->driver.probe = platform_drv_probe;
+ drv->driver.remove = platform_drv_remove;
+ drv->driver.shutdown = platform_drv_shutdown;
return driver_register(>driver);
}
--
2.4.6
--
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 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
On 07-08-15, 13:52, Krzysztof Kozlowski wrote: > Thanks for explanation. As fair as I understand, Bartlomiej wanted to > merge this in a way which would avoid loosing the boost mode. Kukjin > prepared topic branches for previous cpu-freq/clk stuff so maybe > everything could go through PM? We aren't loosing anything at all. There can be two cases here: 1. Patch 1/6 and 6/6 make it to 4.3 (with suggested changes) via PM tree: - All will work fine in this case, no issues at all.. 2. They don't make it: - Even in this case, nothing will break. Users can just enable a config option and that's all.. So, no need to divert things into another tree this late. Over that, Rafael will not be around for 2 weeks now (Plumbers and other stuff) .. So, just target the cpufreq core changes via PM tree.. rest is just fine. I hope that makes sense :) -- viresh -- 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 07/13] twl4030_charger: distinguish between USB current and 'AC' current
Hi,
This actually slipped through my review. IMHO madc should be
accessed through IIO, as already done for twl4030-madc-battery
and rx51-battery. That way the custom API can be removed at
some point.
Anyway, I queued the below patch with Tony's ACK to fix the build
issue in next.
On Fri, Aug 07, 2015 at 01:45:25PM +1000, NeilBrown wrote:
> From: NeilBrown
> Date: Fri, 7 Aug 2015 13:44:37 +1000
> Subject: [PATCH] twl4030_charger: fix compile error when TWL4030_MADC not
> available.
>
> We can only use the madc to check for 'ac' availability
> if the madc has been compiled in.
> If not: assume always using USB.
>
> Reported-by: Tony Lindgren
> Signed-off-by: NeilBrown
>
> diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
> index c7432f532a83..265fd236f4c0 100644
> --- a/drivers/power/twl4030_charger.c
> +++ b/drivers/power/twl4030_charger.c
> @@ -91,6 +91,21 @@
> #define TWL4030_MSTATEC_COMPLETE10x0b
> #define TWL4030_MSTATEC_COMPLETE40x0e
>
> +#if IS_ENABLED(CONFIG_TWL4030_MADC)
> +/*
> + * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
> + * then AC is available.
> + */
> +static inline int ac_available(void)
> +{
> + return twl4030_get_madc_conversion(11) > 4500;
> +}
> +#else
> +static inline int ac_available(void)
> +{
> + return 0;
> +}
> +#endif
> static bool allow_usb;
> module_param(allow_usb, bool, 0644);
> MODULE_PARM_DESC(allow_usb, "Allow USB charge drawing default current");
> @@ -263,7 +278,7 @@ static int twl4030_charger_update_current(struct
> twl4030_bci *bci)
>* If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
>* and AC is enabled, set current for 'ac'
>*/
> - if (twl4030_get_madc_conversion(11) > 4500) {
> + if (ac_available()) {
> cur = bci->ac_cur;
> bci->ac_is_active = true;
> } else {
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH 0/4] loop: enable different physical blocksizes
On Mon, Aug 3, 2015 at 7:00 PM, Alexander Graf wrote: > > > On 27.07.15 11:40, Ming Lei wrote: >> On Fri, Jul 17, 2015 at 3:27 AM, Hannes Reinecke wrote: >>> Currently the loop driver just simulates 512-byte blocks. When >>> creating images for virtual machines it might be required to use >>> a different physical blocksize (eg 4k for S/390 DASD). >> >> Looks 'qemu-img create' doesn't have parameter of block size, >> so could you share your use case? And I am just curious why >> 512-byte can't work for this case. > > If you only want to access the virtual disk inside of QEMU you're all > good. However, if you want to directly run mkfs or fdasd on a loopback > device, then you need to expose 4k blocksize to the tools or they end up > creating a different on-disk format (if they work at all). > > So the easiest case where things go wrong is > > $ qemu-img create test.img 1G > $ losetup /dev/loop0 test.img > $ mkfs.ext4 /dev/loop0 The default block size of mkfs.ext4 is 4K, so suppose it is 1024 by passing '-b 1024'; otherwise inside VM, the block device(with 4k logical block size) can be mounted correctly. > $ qemu Then you should pass 'logical_block_size=1024 or 512' in '-device ' parameter of qemu. The story is that block size of filesystem should be equal or greater than logical block size of block device, see sb_min_blocksize(). > > because the guest thinks the disk is formatted with 4k sector size, > while mkfs thought it's formatted with 512 byte sector size. I am wondering if mkfs is remembering the sector size of actual block device, and at least it can't be found by 'dumpe2fs'. And it shouldn't have do that, otherwise it isn't flexible. And one fs image often can be looped successully by loop because loop's block size is 512. That is why I am wondering if we need support other logical block size for loop. > > With this patch you can do > > $ qemu-img create test.img 1G > $ losetup -B 4096 /dev/loop0 test.img > $ mkfs.ext4 /dev/loop0 > $ qemu > > and it will work because both views of the world are identical. The same > applies for images you pull from a disk. So if you have a real 4k > logical sector size disk and you dd an image from it, you won't be able > to loop mount it today. With this patch set, you can. No, the filesystem block size is just equal or bigger than logical block size of the backing device, then it can be loop mounted successfully without any problem. Thanks, Ming Lei -- 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 net-next 0/6] test_bpf improvements
From: Nicolas Schichan Date: Tue, 4 Aug 2015 15:19:06 +0200 > Please find below the patch series with my latest changes to test_bpf. Series applied, thank you. -- 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 2/2] x86, mwaitt: introduce mwaitx delay with a configurable timer
On Thu, Aug 06, 2015 at 05:14:40PM +0200, Borislav Petkov wrote:
> On Wed, Aug 05, 2015 at 11:18:52AM +0800, Huang Rui wrote:
> > +static void delay_mwaitx(unsigned long __loops)
> > +{
> > + u32 delay, loops = __loops;
> > + u64 end, start;
>
> Hmm, this truncates __loops in case someone wants to delay for more
> than (u32)-1 TSC clocks. I guess the right thing to do is to do the
> calculation with u64s and MWAITX_MAX_LOOPS will keep us within bounds.
>
Yes, you're right. Thanks to update. :)
Thanks,
Rui
--
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] staging: ion: Add a default struct device for cma heap
On Fri, Aug 07, 2015 at 11:50:13AM +0800, Feng Tang wrote:
> When trying to use several cma heaps on our platforms,
> we met a memory issue due to that the several cma_heaps
> are sharing the same "struct device *".
>
> As in current code base, the normal cma heap creating
> process is, one platform device is created during boot,
> and it will sequentially create cma heaps (usually passing
> its own struct device * as a parameter)
>
> For the multiple cma heaps case, there will be one "struct
> cma" created for each cma heap, and this "struct cma *" is
> saved in dev->cma_area. So the single platform device can't
> meet the requirement here.
>
> This patch adds one default device for each cma heap to avoid
> sharing the same "struct device", thus fix the issue. And it
> doesn't break existing code by only using that default device
> when no "struct device *" is passed in.
>
> Also, since the cma framework has been cleaned up recently,
> this patch also adds a platform data member to pass the
> "struct cma*" to ion_cma_heap_create().
>
> Signed-off-by: Feng Tang
> [From CMA’s point of view: ]
> Acked-by: Michal Nazarewicz
> ---
> drivers/staging/android/ion/ion.h |4
> drivers/staging/android/ion/ion_cma_heap.c | 20 +---
> 2 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.h
> b/drivers/staging/android/ion/ion.h
> index 443db84..11336df 100644
> --- a/drivers/staging/android/ion/ion.h
> +++ b/drivers/staging/android/ion/ion.h
> @@ -44,6 +44,9 @@ struct ion_buffer;
> * @base:base address of heap in physical memory if applicable
> * @size:size of the heap in bytes if applicable
> * @align: required alignment in physical memory if applicable
> + * @cma: when creating CMA heap, platform device should better also
> + * pass the "struct cma *" info, so that the cma buffer request
> + * know where to go for the buffer
> * @priv:private info passed from the board file
> *
> * Provided by the board file.
> @@ -55,6 +58,7 @@ struct ion_platform_heap {
> ion_phys_addr_t base;
> size_t size;
> ion_phys_addr_t align;
> + struct cma *cma;
> void *priv;
> };
>
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c
> b/drivers/staging/android/ion/ion_cma_heap.c
> index f4211f1..27f218a 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -29,6 +29,7 @@
> struct ion_cma_heap {
> struct ion_heap heap;
> struct device *dev;
> + struct device default_dma_dev;
Why do we have 2 struct devices here?
> };
>
> #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
> @@ -180,9 +181,22 @@ struct ion_heap *ion_cma_heap_create(struct
> ion_platform_heap *data)
> return ERR_PTR(-ENOMEM);
>
> cma_heap->heap.ops = _cma_ops;
> - /* get device from private heaps data, later it will be
> - * used to make the link with reserved CMA memory */
> - cma_heap->dev = data->priv;
> +
> + /*
> + * data->priv for cma heap is currently supposed to point
> + * to a "struct device *"
> + */
> + if (data->priv) {
> + cma_heap->dev = data->priv;
> + } else {
> + cma_heap->dev = _heap->default_dma_dev;
That's not good, it's not initialized, or if it is, what's the lifetime
rules for it now?
Why are you needing an extra struct device now?
this seems odd.
greg k-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/
Re: [PATCH v4 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
On 07.08.2015 13:30, Viresh Kumar wrote: > On 07-08-15, 13:13, Krzysztof Kozlowski wrote: >> Still patches 1/6 and 6/6 need your acks. Is the patch 1/6 a >> prerequisite for others? It does not look like a prerequisite... but it >> was put at the beginning of the patchset. > > Patch 1/6 is required to get boost working, that's all.. Not sure how > important is that. Anyway, that will work without 1/6 as well, all you > need to do is enable CONFIG_CPU_FREQ_BOOST_SW in you .config. > > Anyway, it should go via pm tree and can be sent separately. Thanks for explanation. As fair as I understand, Bartlomiej wanted to merge this in a way which would avoid loosing the boost mode. Kukjin prepared topic branches for previous cpu-freq/clk stuff so maybe everything could go through PM? Kukjin, are you fine with that? Best regards, Krzysztof -- 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/1] Staging: media: davinci_vpfe: fix over 80 characters coding style issue.
On Thu, Aug 06, 2015 at 09:55:54PM -0500, Junsu Shin wrote: > This is a patch to the dm365_ipipe.c that fixes over 80 characters warning > detected by checkpatch.pl. > Signed-off-by: Junsu Shin please do not use whitespace before Signed-off-by: line. > > --- > drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c > b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c > index 1bbb90c..57cd274 100644 > --- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c > +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c > @@ -1536,8 +1536,9 @@ ipipe_get_format(struct v4l2_subdev *sd, struct > v4l2_subdev_pad_config *cfg, > * @fse: pointer to v4l2_subdev_frame_size_enum structure. > */ > static int > -ipipe_enum_frame_size(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config > *cfg, > - struct v4l2_subdev_frame_size_enum *fse) > +ipipe_enum_frame_size(struct v4l2_subdev *sd, > + struct v4l2_subdev_pad_config *cfg, > + struct v4l2_subdev_frame_size_enum *fse) since you are modifying this line, please fix up the indention also. regards sudip -- 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] ARM: brcmstb: select ARCH_DMA_ADDR_T_64BIT for LPAE
Le 08/06/15 19:22, Gregory Fong a écrit : > Broadcom STB (BRCMSTB) has some 64-bit capable DMA and therefore needs > dma_addr_t to be a 64-bit size. One user is the Broadcom SATA3 AHCI > controller driver. > > Signed-off-by: Gregory Fong Applied to soc/next, thanks Gregory! -- Florian -- 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 6/6] cpufreq: remove no longer needed CPU_FREQ_BOOST_SW config option
On 06-08-15, 15:41, Bartlomiej Zolnierkiewicz wrote: > Remove no longer needed CPU_FREQ_BOOST_SW config option. > > Cc: Viresh Kumar > Cc: Thomas Abraham > Cc: Javier Martinez Canillas > Cc: Krzysztof Kozlowski > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > drivers/cpufreq/Kconfig | 4 > drivers/cpufreq/freq_table.c | 3 --- > 2 files changed, 7 deletions(-) This must be applied only after fixing 1/6. -- viresh -- 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 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
On 07-08-15, 13:13, Krzysztof Kozlowski wrote: > Still patches 1/6 and 6/6 need your acks. Is the patch 1/6 a > prerequisite for others? It does not look like a prerequisite... but it > was put at the beginning of the patchset. Patch 1/6 is required to get boost working, that's all.. Not sure how important is that. Anyway, that will work without 1/6 as well, all you need to do is enable CONFIG_CPU_FREQ_BOOST_SW in you .config. Anyway, it should go via pm tree and can be sent separately. -- viresh -- 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: [v2 2/5] arm64: kdump: implement machine_crash_shutdown()
Marc,
On 08/07/2015 12:51 AM, Marc Zyngier wrote:
Hi,
On 06/08/15 08:09, AKASHI Takahiro wrote:
Marc, Mark
Sorry for not revisiting your comment below for a while.
Wow. It took me a few minutes to page the context back in.
Please don't purge the page from your cache for a while :)
On 04/24/2015 07:43 PM, Marc Zyngier wrote:
On 24/04/15 11:39, Mark Rutland wrote:
On Fri, Apr 24, 2015 at 08:53:05AM +0100, AKASHI Takahiro wrote:
kdump calls machine_crash_shutdown() to shut down non-boot cpus and
save per-cpu general-purpose registers before restarting the crash dump
kernel. See kernel_kexec().
ipi_cpu_stop() is used and a bit modified to support this behavior.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/include/asm/kexec.h| 34 ++-
arch/arm64/kernel/machine_kexec.c | 55
-
arch/arm64/kernel/smp.c | 12 ++--
3 files changed, 97 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 3530ff5..eaf3fcb 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -30,6 +30,8 @@
#if !defined(__ASSEMBLY__)
+extern bool in_crash_kexec;
+
/**
* crash_setup_regs() - save registers for the panic kernel
*
@@ -40,7 +42,37 @@
static inline void crash_setup_regs(struct pt_regs *newregs,
struct pt_regs *oldregs)
{
- /* Empty routine needed to avoid build errors. */
+ if (oldregs) {
+ memcpy(newregs, oldregs, sizeof(*newregs));
+ } else {
+ __asm__ __volatile__ (
+ "stpx0, x1, [%3]\n\t"
Why the tabs?
Please use #16 * N as the offset for consistency with entry.S, with 0
for the first N.
[...]
+static void machine_kexec_mask_interrupts(void)
+{
+ unsigned int i;
+ struct irq_desc *desc;
+
+ for_each_irq_desc(i, desc) {
+ struct irq_chip *chip;
+
+ chip = irq_desc_get_chip(desc);
+ if (!chip)
+ continue;
+
+ if (chip->irq_eoi && irqd_irq_inprogress(>irq_data))
+ chip->irq_eoi(>irq_data);
+
+ if (chip->irq_mask)
+ chip->irq_mask(>irq_data);
+
+ if (chip->irq_disable && !irqd_irq_disabled(>irq_data))
+ chip->irq_disable(>irq_data);
+ }
+}
I'm surprised that this isn't left to the irqchip driver init code in
the crash kernel. For all we know this state could be corrupt anyway.
Indeed, parsing the irqdesc list is a recipe for disaster. Who knows
which locks have been taken or simply corrupted, pointers nuked...
Is there any reason we can't get the GIC driver to nuke all of this at
probe time?
Is it just enough to remove kexec_mask_interrupts() and add gic_eoi_irq()
at the beginning of gic_cpu_init() in irq-gic.c and irq-gic-v3.c?
No, doing an EOI is definitely the wrong thing to do. If you do it in
the wrong order, you just screw up the GIC state machine. Plus, you have
no idea what to write there...
The only real solution is to zero the "active" registers.
This feels like the better option. I can cook a patch or two for that.
If you do, that will be much better :)
OK, I'll prepare something that we can merge at the same time kexec
comes back from the dead (if it ever does - I'm not holding my breath).
Thank you.
Please note that the same function, machine_kexec_mask_interrupts(),
is already there on arm(/kernel/machine_kexec.c).
Well, kexec/kdump stuff is not dead.
Hopefully I and Geoff will submit a full series of patchset in a few weeks
although the main logic will be the same.
BTW, in arm-gic-v3.h, GICD_CTRL_ARE_NS is defined as
(1U << 4)
but should it be 5?
(I'm referring to the page 8-415 in IHI0069A.)
No, look at the definition ARE_NS has when the access is non-secure or
on a system supporting a single security state. The definition you're
referring to is for a secure access (firmware).
Aha, I should remember that arm has "multiple personalities."
-Takahiro AKASHI
Thanks,
M.
--
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 07/13] twl4030_charger: distinguish between USB current and 'AC' current
* NeilBrown [150806 20:48]: > > Thanks, I did get notified about that by Fengguang's test robot, but > it's still on my list > > I guess making CHARGER_TWL4030 auto-select TWL4030_MADC would not be > acceptable? That would pull in IIO (it didn't use to...). > > If this OK? Looks OK to me thanks: Acked-by: Tony Lindgren -- 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/
linux-next: manual merge of the audit tree with Linus' tree
Hi Paul,
Today's linux-next merge of the audit tree got a conflict in:
kernel/audit.c
between commit:
5985de6754a6 ("audit: code clean up")
from Linus' tree and commit:
84cb777e6781 ("audit: use macros for unset inode and device values")
from the audit tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/audit.c
index f9e6065346db,060153dc47d4..
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@@ -1761,7 -1759,7 +1761,7 @@@ void audit_log_name(struct audit_contex
} else
audit_log_format(ab, " name=(null)");
- if (n->ino != (unsigned long)-1)
- if (n->ino != AUDIT_INO_UNSET) {
++ if (n->ino != AUDIT_INO_UNSET)
audit_log_format(ab, " inode=%lu"
" dev=%02x:%02x mode=%#ho"
" ouid=%u ogid=%u rdev=%02x:%02x",
--
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 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
On 07.08.2015 12:51, Viresh Kumar wrote: > Fixed Olof's email id.. > > On 07-08-15, 09:20, Viresh Kumar wrote: >> Cc'ing Rafael again. Guys please don't miss him for any PM related >> stuff or use get_maintainers .. >> >> Cc'ing Arnd/Olof as well to discuss the merge stuff.. >> >> On 07-08-15, 08:53, Kukjin Kim wrote: >>>> Depends on: >>>> - next-20150806 branch of linux-next kernel tree >>>> - "[PATCH V3 00/16] OPP: Add code to support operating-points-v2 bindings" >>>> (http://www.spinics.net/lists/arm-kernel/msg435408.html) >>>> >>> BTW, hmm...how can we see this series in v4.3?...to be honest, I don't >>> think it >>> can be done in v4.3 because of dependencies with PM / OPP series >> >> That is merged by Rafael Yesterday. That is manageable Indeed, happy to hear it! So the patchset has no external dependencies. >> >>> and previous >>> exynos CPU OPP series in each cross trees...maybe that's why you created >>> based >>> on linux-next...any idea? >> >> So there is no build dependency with OPP patches I hope, as its all >> about using the bindings defined by them. And so you don't need to >> depend on that. >> >> You might have to rebase on the ARM tree to manage your conflicts. In >> this case you can rebase directly on ARM SoC branch which has your >> patches (rebase directly over the last patch instead of the whole >> branch) and make sure Olof knows about this and he doesn't update >> (i.e. rebase) his branch, which he might not anyway. >> >> The whole idea is to keep a single sha-id for a commit. So you can >> rebase over the published material present in ARM-SoC .. Still patches 1/6 and 6/6 need your acks. Is the patch 1/6 a prerequisite for others? It does not look like a prerequisite... but it was put at the beginning of the patchset. Best regards, Krzysztof -- 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] Input: do not emit unneeded EV_SYN when suspending
On Thu, Aug 6, 2015 at 7:26 PM, Dmitry Torokhov wrote: > Do not emit EV_SYN/SYN_REPORT on suspend if there were no keys that are > still pressed as we are suspending the device. It looks like input_dev_release_keys is used in several other places other than input_dev_suspend (reset, disconnect, freeze), so maybe change the commit message to reflect that? Otherwise, LGTM. -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org -- 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 v3] iio: adc: xilinx-xadc: Push interrupts into threaded context
On Tue, Aug 4, 2015 at 1:35 PM, Lars-Peter Clausen wrote: > > Well there is no need to use a threaded IRQ. The interrupt handler is quite > small and doesn't take too much time and doesn't have any delays or sleeps > in it either. > > Ok thanks for the explanation. -- 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] Input: elants_i2c - wire up regulator support
Hi Dmitry,
Thanks for your explanation, I understand.
Reviewed-by: Scott Liu
Best Regards,
--
Scott
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: Friday, August 07, 2015 8:25 AM
> To: ELAN 劉嘉駿
> Cc: Dmitry Torokhov; linux-in...@vger.kernel.org; Rob Herring; Mark Rutland;
> Benson Leung; Duson Lin; James Chen; devicet...@vger.kernel.org; lkml
> Subject: Re: [PATCH] Input: elants_i2c - wire up regulator support
>
> Hi Scott,
>
> On Thu, Aug 6, 2015 at 12:03 AM, ELAN 劉嘉駿
> wrote:
> > Hi Dmitry
> >
> > I am curious about how reset gpio works and I think the reset
> > gpio at low level after elants_i2c_power_on(),
> > So that the controller won't response anyway, please see below
> > my question and correct me if I am wrong.
> >
> >> -Original Message-
> >> From: Dmitry Torokhov [mailto:d...@chromium.org]
> >> Sent: Thursday, August 06, 2015 2:54 AM
> >> To: linux-in...@vger.kernel.org
> >> Cc: Rob Herring; Mark Rutland; Benson Leung; Duson Lin; Scott Liu;
> >> James Chen; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> linux-in...@vger.kernel.org
> >> Subject: [PATCH] Input: elants_i2c - wire up regulator support
> >>
> >> Elan touchscreen controllers use two power supplies, vcc33 and vccio,
> >> and we need to enable them before trying to access the device. On X86
> >> firmware usually does this, but on ARM it is usually left to the kernel.
> >>
> >> Signed-off-by: Dmitry Torokhov
> >> Reviewed-by: Benson Leung
> >> Signed-off-by: Dmitry Torokhov
> >> ---
> >> .../devicetree/bindings/input/elants_i2c.txt | 3 +
> >> drivers/input/touchscreen/elants_i2c.c | 184
> >> ++---
> >> 2 files changed, 165 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/input/elants_i2c.txt
> >> b/Documentation/devicetree/bindings/input/elants_i2c.txt
> >> index a765232..8a71038 100644
> >> --- a/Documentation/devicetree/bindings/input/elants_i2c.txt
> >> +++ b/Documentation/devicetree/bindings/input/elants_i2c.txt
> >> @@ -13,6 +13,9 @@ Optional properties:
> >> - pinctrl-names: should be "default" (see pinctrl binding [1]).
> >> - pinctrl-0: a phandle pointing to the pin settings for the device (see
> >>pinctrl binding [1]).
> >> +- reset-gpios: reset gpio the chip is connected to.
> >> +- vcc33-supply: a phandle for the regulator supplying 3.3V power.
> >> +- vccio-supply: a phandle for the regulator supplying IO power.
> >>
> >> [0]:
> > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> >> [1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> >> diff --git a/drivers/input/touchscreen/elants_i2c.c
> >> b/drivers/input/touchscreen/elants_i2c.c
> >> index 42e43f1..1912265 100644
> >> --- a/drivers/input/touchscreen/elants_i2c.c
> >> +++ b/drivers/input/touchscreen/elants_i2c.c
> >> @@ -38,6 +38,8 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> +#include
> >> #include
> >>
> >> /* Device, Driver information */
> >> @@ -102,6 +104,9 @@
> >> /* calibration timeout definition */
> >> #define ELAN_CALI_TIMEOUT_MSEC 1
> >>
> >> +#define ELAN_POWERON_DELAY_USEC 500
> >> +#define ELAN_RESET_DELAY_MSEC20
> >> +
> >> enum elants_state {
> >> ELAN_STATE_NORMAL,
> >> ELAN_WAIT_QUEUE_HEADER,
> >> @@ -118,6 +123,10 @@ struct elants_data {
> >> struct i2c_client *client;
> >> struct input_dev *input;
> >>
> >> + struct regulator *vcc33;
> >> + struct regulator *vccio;
> >> + struct gpio_desc *reset_gpio;
> >> +
> >> u16 fw_version;
> >> u8 test_version;
> >> u8 solution_version;
> >> @@ -141,6 +150,7 @@ struct elants_data {
> >> u8 buf[MAX_PACKET_SIZE];
> >>
> >> bool wake_irq_enabled;
> >> + bool keep_power_in_suspend;
> >> };
> >>
> >> static int elants_i2c_send(struct i2c_client *client, @@ -1058,6
> >> +1068,67 @@ static void elants_i2c_remove_sysfs_group(void *_data)
> >> sysfs_remove_group(>client->dev.kobj,
> >> _attribute_group); }
> >>
> >> +static int elants_i2c_power_on(struct elants_data *ts) {
> >> + int error;
> >> +
> >> + /*
> >> + * If we do not have reset gpio assume platform firmware
> >> + * controls regulators and does power them on for us.
> >> + */
> >> + if (IS_ERR_OR_NULL(ts->reset_gpio))
> >> + return 0;
> >> +
> >> + gpiod_set_value_cansleep(ts->reset_gpio, 1);
> >> +
> >> + error = regulator_enable(ts->vcc33);
> >> + if (error) {
> >> + dev_err(>client->dev,
> >> + "failed to enable vcc33 regulator: %d\n",
> >> + error);
> >> + goto release_reset_gpio;
> >> + }
> >> +
> >> + error = regulator_enable(ts->vccio);
> >> + if (error) {
> >> + dev_err(>client->dev,
> >> + "failed to enable vccio
Re: [PATCH v4 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
Fixed Olof's email id.. On 07-08-15, 09:20, Viresh Kumar wrote: > Cc'ing Rafael again. Guys please don't miss him for any PM related > stuff or use get_maintainers .. > > Cc'ing Arnd/Olof as well to discuss the merge stuff.. > > On 07-08-15, 08:53, Kukjin Kim wrote: > > > Depends on: > > > - next-20150806 branch of linux-next kernel tree > > > - "[PATCH V3 00/16] OPP: Add code to support operating-points-v2 bindings" > > > (http://www.spinics.net/lists/arm-kernel/msg435408.html) > > > > > BTW, hmm...how can we see this series in v4.3?...to be honest, I don't > > think it > > can be done in v4.3 because of dependencies with PM / OPP series > > That is merged by Rafael Yesterday. That is manageable > > > and previous > > exynos CPU OPP series in each cross trees...maybe that's why you created > > based > > on linux-next...any idea? > > So there is no build dependency with OPP patches I hope, as its all > about using the bindings defined by them. And so you don't need to > depend on that. > > You might have to rebase on the ARM tree to manage your conflicts. In > this case you can rebase directly on ARM SoC branch which has your > patches (rebase directly over the last patch instead of the whole > branch) and make sure Olof knows about this and he doesn't update > (i.e. rebase) his branch, which he might not anyway. > > The whole idea is to keep a single sha-id for a commit. So you can > rebase over the published material present in ARM-SoC .. > > -- > viresh -- viresh -- 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 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
Cc'ing Rafael again. Guys please don't miss him for any PM related stuff or use get_maintainers .. Cc'ing Arnd/Olof as well to discuss the merge stuff.. On 07-08-15, 08:53, Kukjin Kim wrote: > > Depends on: > > - next-20150806 branch of linux-next kernel tree > > - "[PATCH V3 00/16] OPP: Add code to support operating-points-v2 bindings" > > (http://www.spinics.net/lists/arm-kernel/msg435408.html) > > > BTW, hmm...how can we see this series in v4.3?...to be honest, I don't think > it > can be done in v4.3 because of dependencies with PM / OPP series That is merged by Rafael Yesterday. That is manageable > and previous > exynos CPU OPP series in each cross trees...maybe that's why you created based > on linux-next...any idea? So there is no build dependency with OPP patches I hope, as its all about using the bindings defined by them. And so you don't need to depend on that. You might have to rebase on the ARM tree to manage your conflicts. In this case you can rebase directly on ARM SoC branch which has your patches (rebase directly over the last patch instead of the whole branch) and make sure Olof knows about this and he doesn't update (i.e. rebase) his branch, which he might not anyway. The whole idea is to keep a single sha-id for a commit. So you can rebase over the published material present in ARM-SoC .. -- viresh -- 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 07/13] twl4030_charger: distinguish between USB current and 'AC' current
On Thu, 6 Aug 2015 20:11:16 -0700 Tony Lindgren
wrote:
> * NeilBrown [150729 17:28]:
> > --- a/drivers/power/twl4030_charger.c
> > +++ b/drivers/power/twl4030_charger.c
> > static int twl4030_charger_update_current(struct twl4030_bci *bci)
> > {
> > int status;
> > + int cur;
> > unsigned reg, cur_reg;
> > u8 bcictl1, oldreg, fullreg;
> > bool cgain = false;
> > u8 boot_bci;
> >
> > + /*
> > +* If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
> > +* and AC is enabled, set current for 'ac'
> > +*/
> > + if (twl4030_get_madc_conversion(11) > 4500) {
> > + cur = bci->ac_cur;
> > + bci->ac_is_active = true;
> > + } else {
> > + cur = bci->usb_cur;
> > + bci->ac_is_active = false;
> > + }
> > +
> > /* First, check thresholds and see if cgain is needed */
> > if (bci->ichg_eoc >= 20)
> > cgain = true;
>
> Neil, you need a stub or something for twl4030_get_madc_conversion
> if madc is not selected. Now at least omap2plus_defconfig and
> ARM allmodconfig fails in Linux next.
>
> Regards,
>
> Tony
Thanks, I did get notified about that by Fengguang's test robot, but
it's still on my list
I guess making CHARGER_TWL4030 auto-select TWL4030_MADC would not be
acceptable? That would pull in IIO (it didn't use to...).
If this OK?
Thanks,
NeilBrown
From: NeilBrown
Date: Fri, 7 Aug 2015 13:44:37 +1000
Subject: [PATCH] twl4030_charger: fix compile error when TWL4030_MADC not
available.
We can only use the madc to check for 'ac' availability
if the madc has been compiled in.
If not: assume always using USB.
Reported-by: Tony Lindgren
Signed-off-by: NeilBrown
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index c7432f532a83..265fd236f4c0 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -91,6 +91,21 @@
#define TWL4030_MSTATEC_COMPLETE1 0x0b
#define TWL4030_MSTATEC_COMPLETE4 0x0e
+#if IS_ENABLED(CONFIG_TWL4030_MADC)
+/*
+ * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
+ * then AC is available.
+ */
+static inline int ac_available(void)
+{
+ return twl4030_get_madc_conversion(11) > 4500;
+}
+#else
+static inline int ac_available(void)
+{
+ return 0;
+}
+#endif
static bool allow_usb;
module_param(allow_usb, bool, 0644);
MODULE_PARM_DESC(allow_usb, "Allow USB charge drawing default current");
@@ -263,7 +278,7 @@ static int twl4030_charger_update_current(struct
twl4030_bci *bci)
* If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
* and AC is enabled, set current for 'ac'
*/
- if (twl4030_get_madc_conversion(11) > 4500) {
+ if (ac_available()) {
cur = bci->ac_cur;
bci->ac_is_active = true;
} else {
--
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/6] cpufreq: make scaling_boost_freqs sysfs attr available when boost is enabled
Hi,
I would suggest you sending such patches as reply to the earlier
threads only, instead of a new chain. This will save your time.
For example, you will need to resend other patches unnecessarily if I
NAK this patch :)
On 06-08-15, 15:41, Bartlomiej Zolnierkiewicz wrote:
> Add cpufreq_boost_enabled_generic_attr table and use it in
> cpufreq-dt driver instead of cpufreq_generic_attr one when
> boost support is enabled. As a result scaling_boost_freqs
> sysfs attribute is available when cpufreq-dt driver is
> used and boost support is enabled.
>
> Cc: Viresh Kumar
> Cc: Thomas Abraham
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/cpufreq/cpufreq-dt.c | 3 +++
> drivers/cpufreq/freq_table.c | 7 +++
> include/linux/cpufreq.h | 1 +
> 3 files changed, 11 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index b9259ab..7b091c0 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -182,6 +182,8 @@ try_again:
> return ret;
> }
>
> +static struct cpufreq_driver dt_cpufreq_driver;
> +
> static int cpufreq_init(struct cpufreq_policy *policy)
> {
> struct cpufreq_frequency_table *freq_table;
> @@ -336,6 +338,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
> ret = cpufreq_enable_boost_support();
> if (ret)
> goto out_free_cpufreq_table;
> + dt_cpufreq_driver.attr = cpufreq_boost_enabled_generic_attr;
> }
>
> policy->cpuinfo.transition_latency = transition_latency;
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> index a8f1daf..5a00a09 100644
> --- a/drivers/cpufreq/freq_table.c
> +++ b/drivers/cpufreq/freq_table.c
> @@ -300,6 +300,13 @@ struct freq_attr *cpufreq_generic_attr[] = {
> };
> EXPORT_SYMBOL_GPL(cpufreq_generic_attr);
>
> +struct freq_attr *cpufreq_boost_enabled_generic_attr[] = {
> + _freq_attr_scaling_available_freqs,
> + _freq_attr_scaling_boost_freqs,
> + NULL,
> +};
> +EXPORT_SYMBOL_GPL(cpufreq_boost_enabled_generic_attr);
This isn't scalable. We can't create a new generic structure every time
a entry comes in. Rather we should leave the generic attr for
cpufreq-dt and do something like this in the cpufreq-dt driver (And
that patch should rather go via cpufreq tree and not ARM SoC)..
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index a5b6a854661f..e229258ad791 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -36,6 +36,12 @@ struct private_data {
unsigned int voltage_tolerance; /* in percentage */
};
+static struct freq_attr *cpufreq_dt_attr[] = {
+ _freq_attr_scaling_available_freqs,
+ NULL, /* Extra space for boost-attr if required */
+ NULL,
+};
+
static int set_target(struct cpufreq_policy *policy, unsigned int index)
{
struct dev_pm_opp *opp;
@@ -337,6 +343,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
ret = cpufreq_enable_boost_support();
if (ret)
goto out_free_cpufreq_table;
+ cpufreq_dt_attr[1] = _freq_attr_scaling_boost_freqs;
}
policy->cpuinfo.transition_latency = transition_latency;
@@ -412,7 +419,7 @@ static struct cpufreq_driver dt_cpufreq_driver = {
.exit = cpufreq_exit,
.ready = cpufreq_ready,
.name = "cpufreq-dt",
- .attr = cpufreq_generic_attr,
+ .attr = cpufreq_dt_attr,
};
static int dt_cpufreq_probe(struct platform_device *pdev)
--
viresh
--
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 v2] staging: ion: Add a default struct device for cma heap
When trying to use several cma heaps on our platforms,
we met a memory issue due to that the several cma_heaps
are sharing the same "struct device *".
As in current code base, the normal cma heap creating
process is, one platform device is created during boot,
and it will sequentially create cma heaps (usually passing
its own struct device * as a parameter)
For the multiple cma heaps case, there will be one "struct
cma" created for each cma heap, and this "struct cma *" is
saved in dev->cma_area. So the single platform device can't
meet the requirement here.
This patch adds one default device for each cma heap to avoid
sharing the same "struct device", thus fix the issue. And it
doesn't break existing code by only using that default device
when no "struct device *" is passed in.
Also, since the cma framework has been cleaned up recently,
this patch also adds a platform data member to pass the
"struct cma*" to ion_cma_heap_create().
Signed-off-by: Feng Tang
[From CMA’s point of view: ]
Acked-by: Michal Nazarewicz
---
drivers/staging/android/ion/ion.h |4
drivers/staging/android/ion/ion_cma_heap.c | 20 +---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 443db84..11336df 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -44,6 +44,9 @@ struct ion_buffer;
* @base: base address of heap in physical memory if applicable
* @size: size of the heap in bytes if applicable
* @align: required alignment in physical memory if applicable
+ * @cma: when creating CMA heap, platform device should better also
+ * pass the "struct cma *" info, so that the cma buffer request
+ * know where to go for the buffer
* @priv: private info passed from the board file
*
* Provided by the board file.
@@ -55,6 +58,7 @@ struct ion_platform_heap {
ion_phys_addr_t base;
size_t size;
ion_phys_addr_t align;
+ struct cma *cma;
void *priv;
};
diff --git a/drivers/staging/android/ion/ion_cma_heap.c
b/drivers/staging/android/ion/ion_cma_heap.c
index f4211f1..27f218a 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -29,6 +29,7 @@
struct ion_cma_heap {
struct ion_heap heap;
struct device *dev;
+ struct device default_dma_dev;
};
#define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
@@ -180,9 +181,22 @@ struct ion_heap *ion_cma_heap_create(struct
ion_platform_heap *data)
return ERR_PTR(-ENOMEM);
cma_heap->heap.ops = _cma_ops;
- /* get device from private heaps data, later it will be
-* used to make the link with reserved CMA memory */
- cma_heap->dev = data->priv;
+
+ /*
+* data->priv for cma heap is currently supposed to point
+* to a "struct device *"
+*/
+ if (data->priv) {
+ cma_heap->dev = data->priv;
+ } else {
+ cma_heap->dev = _heap->default_dma_dev;
+ cma_heap->dev->coherent_dma_mask = DMA_BIT_MASK(32);
+ cma_heap->dev->dma_mask = _heap->dev->coherent_dma_mask;
+ }
+
+ if (data->cma)
+ dev_set_cma_area(cma_heap->dev, data->cma);
+
cma_heap->heap.type = ION_HEAP_TYPE_DMA;
return _heap->heap;
}
--
1.7.9.5
--
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/
Fuulong2e support broken since commit 3adeb2566b9 ("MIPS: Loongson: Improve LEFI firmware interface")
Hi,
I have been playing with qemu and its fuloong2e support. Unfortunately,
it turned out that mainline support for it is broken. Maybe just the qemu
simulation, maybe for real. The breakage was introduced with commit
3adeb2566b9 ("MIPS: Loongson: Improve LEFI firmware interface").
Bisect log and the test script used to track down the commit are below.
Unfortunately the changes are too substantial for me to understand.
I'll be happy to test potential patches, but I don't think I can identify
the actual problem.
Key question though is if this is going to be fixed or not. The basic reason
for spending time on it was that I wanted to get a qemu test run to work
with the Fuulong2e target, so it would be useful for me to know. If not, it
might make sense to drop the Fuulong2e default configuration.
Please let me know if you need additional information.
Thanks,
Guenter
---
bisect log:
# bad: [bfa76d49576599a4b9f9b7a71f23d73d6dcff735] Linux 3.19
# good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18
git bisect start 'v3.19' 'v3.18'
# bad: [54850e73e86e3bc092680d1bdb84eb322f982ab1] zram: change parameter from
vaild_io_request()
git bisect bad 54850e73e86e3bc092680d1bdb84eb322f982ab1
# good: [6b9e2cea428cf7af93a84bcb865e478d8bf1c165] Merge tag 'for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
git bisect good 6b9e2cea428cf7af93a84bcb865e478d8bf1c165
# good: [b5f185f33d0432cef6ff78765e033dfa8f4de068] Merge tag
'master-2014-12-08' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next
git bisect good b5f185f33d0432cef6ff78765e033dfa8f4de068
# good: [bae41e45b7400496b9bf0c70c6004419d9987819] Merge tag 'sound-3.19-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect good bae41e45b7400496b9bf0c70c6004419d9987819
# bad: [c0222ac086669a631814bbf857f8c8023452a4d7] Merge branch 'upstream' of
git://git.linux-mips.org/pub/scm/ralf/upstream-linus
git bisect bad c0222ac086669a631814bbf857f8c8023452a4d7
# good: [140cd7fb04a4a2bc09a30980bc8104cc89e09330] Merge tag 'powerpc-3.19-1'
of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux
git bisect good 140cd7fb04a4a2bc09a30980bc8104cc89e09330
# bad: [b0854514537e4e2f0a599ca05d18fe95dcd3ee42] clocksource: mips-gic: Move
gic_frequency to clocksource driver
git bisect bad b0854514537e4e2f0a599ca05d18fe95dcd3ee42
# good: [432d9ecb9628bdcb20670b2cf0678f3738bd40a5] MIPS: R3000: Remove
redundant parentheses
git bisect good 432d9ecb9628bdcb20670b2cf0678f3738bd40a5
# bad: [3526f74fa925e44335b94ed0c9f93648e26058ef] clk: ls1x: Update
relationship among all clocks
git bisect bad 3526f74fa925e44335b94ed0c9f93648e26058ef
# bad: [d175ed2bd6544474dcc99d74f8155c2ba44e8db2] MIPS: Ensure Config5.UFE is
clear on boot
git bisect bad d175ed2bd6544474dcc99d74f8155c2ba44e8db2
# bad: [e292ccde216e571faad475e4331c188f22a28182] MIPS: Loongson-3: Add
RS780/SBX00 HPET support
git bisect bad e292ccde216e571faad475e4331c188f22a28182
# good: [ec0f8d3fbb7ea12cfd10083e340381b96e7c34f8] MIPS: Loongson: Allow
booting from any core
git bisect good ec0f8d3fbb7ea12cfd10083e340381b96e7c34f8
# bad: [89467e73d3881a470ce4ffdcba1d5a5ed618379a] MIPS: Loongson-3: Add
oprofile support
git bisect bad 89467e73d3881a470ce4ffdcba1d5a5ed618379a
# bad: [3adeb2566b9bc1dbf579ed515265c6aad756a5cd] MIPS: Loongson: Improve LEFI
firmware interface
git bisect bad 3adeb2566b9bc1dbf579ed515265c6aad756a5cd
# first bad commit: [3adeb2566b9bc1dbf579ed515265c6aad756a5cd] MIPS: Loongson:
Improve LEFI firmware interface
---
Test script follows. "make-mips" in the script
translates to
PATH=/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/mips32-poky-linux:${PATH}
make -j12 ARCH=mips CROSS_COMPILE=mips-poky-linux- $*
qemu is the latest version (v2.4.0-rc3).
I'll be happy to make the root file system available if needed.
It was built with a recent version of buildroot with mips1 support
re-enabled, with some changes to reboot immediately.
---
echo -n "Configuring ... "
make-mips fuloong2e_defconfig >/dev/null 2>&1
cp .config /tmp/config.save
sed -i -e 's/# CONFIG_DEVTMPFS is not set/CONFIG_DEVTMPFS=y/' .config
echo "CONFIG_DEVTMPFS_MOUNT=y" >> .config
make-mips olddefconfig >/dev/null 2>&1
echo -n "Building ... "
make-mips >/dev/null 2>&1
if [ $? -ne 0 ]
then
echo "Failed."
exit 1
fi
echo -n "Running ... "
qemu-system-mips64el -machine fulong2e -cpu Loongson-2E \
-kernel vmlinux -append 'root=/dev/hda console=ttyS0' \
-hda rootfs.mipsel.ext3 -m 512 -nographic -serial stdio \
-monitor null -no-reboot 2>/dev/null \
| grep "Restarting system" >/dev/null
rv=$?
if [ ${rv} -eq 0 ]
then
echo Passed.
else
echo Failed.
fi
exit ${rv}
--
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: [4.2-rc1][PATCH] gpio: omap: add missed spin_unlock_irqrestore in omap_gpio_irq_type
* Linus Walleij [150716 01:38]:
> On Wed, Jun 24, 2015 at 4:54 PM, Grygorii Strashko
> wrote:
>
> > From: Grygorii Strashko
> >
> > Add missed spin_unlock_irqrestore in omap_gpio_irq_type when
> > omap_set_gpio_triggering() is failed.
> >
> > It fixes static checker warning:
> >
> > drivers/gpio/gpio-omap.c:523 omap_gpio_irq_type()
> > warn: inconsistent returns 'spin_lock:>lock'.
> >
> > This fixes commit:
> > 1562e4618ded ('gpio: omap: fix error handling in omap_gpio_irq_type')
> >
> > Reported-by: Javier Martinez Canillas
> > Signed-off-by: Grygorii Strashko
>
> Patch applied for fixes.
Linus, looks like we now have a new build warning in Linux next
with the fixes and raw_spinlock_t change, so a merge or a commit
is needed. If you prefer a patch, here's one below.
Regards,
Tony
8< ---
From: Tony Lindgren
Date: Thu, 6 Aug 2015 20:32:24 -0700
Subject: [PATCH] gpio: omap: Fix build warning for raw_spinlock_t conversion
and unlock fix
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Looks like we now have a new build warning in Linux next with fix
977bd8a94c40 ("gpio: omap: add missed spin_unlock_irqrestore in
omap_gpio_irq_type") and raw_spinlock changes done in commit
4dbada2be460 ("gpio: omap: use raw locks for locking"):
drivers/gpio/gpio-omap.c: In function ‘omap_gpio_irq_type’:
drivers/gpio/gpio-omap.c:504:26: warning: passing argument 1 of
‘spin_unlock_irqrestore’ from incompatible pointer type
[-Wincompatible-pointer-types]
spin_unlock_irqrestore(>lock, flags);
^
In file included from include/linux/seqlock.h:35:0,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from drivers/gpio/gpio-omap.c:16:
include/linux/spinlock.h:370:122: note: expected
‘spinlock_t * {aka struct spinlock *}’ but argument is of type
‘raw_spinlock_t * {aka struct raw_spinlock *}’
Fix the issue with using raw_spinlock_t instead.
Signed-off-by: Tony Lindgren
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -501,7 +501,7 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned
type)
raw_spin_lock_irqsave(>lock, flags);
retval = omap_set_gpio_triggering(bank, offset, type);
if (retval) {
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
goto error;
}
omap_gpio_init_irq(bank, offset);
--
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/1] X86: mshyperv.c: Fix a compilation issue.
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, August 6, 2015 2:11 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> vkuzn...@redhat.com; s...@canb.auug.org.au; t...@linutronix.de;
> mi...@redhat.com; h...@zytor.com; x...@kernel.org; Haiyang Zhang
>
> Subject: Re: [PATCH 1/1] X86: mshyperv.c: Fix a compilation issue.
>
> On Thu, Aug 06, 2015 at 02:41:24PM -0700, K. Y. Srinivasan wrote:
> > Building with a random configuration file, this build failure
> > was reported:
> >
> > arch/x86/built-in.o: In function `hv_machine_crash_shutdown':
> > arch/x86/kernel/cpu/mshyperv.c:112: undefined
> > reference to `native_machine_crash_shutdown'
> >
> > This patch fixes the problem
> >
> > Reported-by: Jim Davis
> > Signed-off-by: K. Y. Srinivasan
> > ---
> > arch/x86/kernel/cpu/mshyperv.c |2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> b/arch/x86/kernel/cpu/mshyperv.c
> > index f794bfa..0faed5e0 100644
> > --- a/arch/x86/kernel/cpu/mshyperv.c
> > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > @@ -109,7 +109,9 @@ static void hv_machine_crash_shutdown(struct
> pt_regs *regs)
> > {
> > if (hv_crash_handler)
> > hv_crash_handler(regs);
> > +#ifdef CONFIG_KEXEC_CORE
> > native_machine_crash_shutdown(regs);
> > +#endif
>
> Why is kexec the factor here? And if it really does, can't it just be
> CONFIG_KEXEC, or, can kexec provide a "dummy" inline function so that
> you don't have to have a #ifdef in a .c file?
Greg,
I am on vacation till next Tuesday. I will address your concern after I get
back if Vitaly
has not addressed it by then.
Regards,
K. Y
--
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/3] zpool: add zpool_has_pool()
On Thu, Aug 06, 2015 at 04:50:23PM -0500, Seth Jennings wrote: > On Wed, Aug 05, 2015 at 03:06:59PM -0700, Andrew Morton wrote: > > On Wed, 5 Aug 2015 18:00:26 -0400 Dan Streetman wrote: > > > > > > > > > > If there's some reason why this can't happen, can we please have a code > > > > comment which reveals that reason? > > > > > > zpool_create_pool() should work if this returns true, unless as you > > > say the module is rmmod'ed *and* removed from the system - since > > > zpool_create_pool() will call request_module() just as this function > > > does. I can add a comment explaining that. > > > > I like comments ;) > > > > Seth, I'm planning on sitting on these patches until you've had a > > chance to review them. > > Thanks Andrew. I'm reviewing now. Patch 2/3 is pretty huge. I've got > the gist of the changes now. I'm also building and testing for myself > as this creates a lot more surface area for issues, alternating between > compressors and allocating new compression transforms on the fly. > > I'm kinda with Sergey on this in that it adds yet another complexity to > an already complex feature. This adds more locking, more RCU, more > refcounting. It's becoming harder to review, test, and verify. > > I should have results tomorrow. So I gave it a test run turning all the knobs (compressor, enabled, max_pool_percent, and zpool) like a crazy person and it was stable, and all the adjustments had the expected result. Dan, you might follow up with an update to Documentation/vm/zswap.txt noting that these parameters are runtime adjustable now. The growing complexity is a concern, but it is nice to have the flexibility. Thanks for the good work! To patchset: Acked-by: Seth Jennings > > Thanks, > Seth -- 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] KVM: x86: Use adjustment in guest cycles when handling MSR_IA32_TSC_ADJUST
When kvm_set_msr_common() handles a guest's write to
MSR_IA32_TSC_ADJUST, it will calcuate an adjustment based on the data
written by guest and then use it to adjust TSC offset by calling a
call-back adjust_tsc_offset(). The 3rd parameter of adjust_tsc_offset()
indicates whether the adjustment is in host TSC cycles or in guest TSC
cycles. If SVM TSC scaling is enabled, adjust_tsc_offset()
[i.e. svm_adjust_tsc_offset()] will first scale the adjustment;
otherwise, it will just use the unscaled one. As the MSR write here
comes from the guest, the adjustment is in guest TSC cycles. However,
the current kvm_set_msr_common() uses it as a value in host TSC
cycles (by using true as the 3rd parameter of adjust_tsc_offset()),
which can result in an incorrect adjustment of TSC offset if SVM TSC
scaling is enabled. This patch fixes this problem.
Signed-off-by: Haozhong Zhang
---
arch/x86/kvm/x86.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 5ef2560..3cd6cd2 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2105,7 +2105,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
if (guest_cpuid_has_tsc_adjust(vcpu)) {
if (!msr_info->host_initiated) {
s64 adj = data - vcpu->arch.ia32_tsc_adjust_msr;
- kvm_x86_ops->adjust_tsc_offset(vcpu, adj, true);
+ adjust_tsc_offset_guest(vcpu, adj);
}
vcpu->arch.ia32_tsc_adjust_msr = data;
}
--
1.7.9.5
--
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] usb: chipidea: imx: properly check for usbmisc
On Thu, Aug 06, 2015 at 03:09:54PM +0200, Tomeu Vizoso wrote: > If usbmisc hasn't probed yet, defer the probe. > > It's not enough to check if the platform device for the OF node of the > usbmisc has been registered, but it also needs to have been probed > already before we can call imx_usbmisc_init(). > > This can happen if the order in which devices are probed change due to > async probing or on-demand probing of dependencies. > > Signed-off-by: Tomeu Vizoso > --- > drivers/usb/chipidea/ci_hdrc_imx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c > b/drivers/usb/chipidea/ci_hdrc_imx.c > index 504554e41922..e3c61d5e9270 100644 > --- a/drivers/usb/chipidea/ci_hdrc_imx.c > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c > @@ -104,7 +104,7 @@ static struct imx_usbmisc_data > *usbmisc_get_init_data(struct device *dev) > misc_pdev = of_find_device_by_node(args.np); > of_node_put(args.np); > > - if (!misc_pdev) > + if (!misc_pdev || !platform_get_drvdata(misc_pdev)) > return ERR_PTR(-EPROBE_DEFER); "||"? or "&&"? You want usbmisc has already been probed. > > data->dev = _pdev->dev; > -- > 2.4.3 > -- Best Regards, Peter Chen -- 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/3] Powerpc: mpc85xx: refactor the PM operations
On Fri, Aug 7, 2015 at 2:02 AM, Scott Wood wrote: On Thu, 2015-08-06 at 13:54 +0800, Chenhui Zhao wrote: On Thu, Aug 6, 2015 at 1:46 PM, Scott Wood wrote: > On Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote: > > On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood > > > > wrote: > > > On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote: > > > > On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood > > > > > > wrote: > > > > > On Mon, 2015-08-03 at 19:32 +0800, Chenhui Zhao wrote: > > > > > > > > > > > > > > > > > > On Sat, Aug 1, 2015 at 7:59 AM, Scott Wood > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Could you explain irq_mask()? Why would there still be > > IRQs > > > > > > destined > > > > > > > for > > > > > > > this CPU at this point? > > > > > > > > > > > > This function just masks irq by setting the registers in > > RCPM > > > > (for > > > > > > example, RCPM_CPMIMR, RCPM_CPMCIMR). Actually, all irqs to > > > > this CPU > > > > > > have been migrated to other CPUs. > > > > > > > > > > So why do we need to set those bits in RCPM? Is it just > > caution? > > > > > > > > Setting these bits can mask interrupts signalled to RCPM from > > MPIC > > > > as a > > > > means of > > > > waking up from a lower power state. So, cores will not be > > waked up > > > > unexpectedly. > > > > > > Why would the MPIC be signalling those interrupts if they've been > > > masked at > > > the MPIC? > > > > > > -Scott > > > > > > > The interrupts to RCPM from MPIC are IRQ, Machine Check, NMI and > > Critical interrupts. Some of them didn't be masked in MPIC. > > What interrupt could actually happen to a sleeping cpu that this > protects > against? > > -Scott Not sure. Maybe spurious interrupts or hardware exceptions. Spurious interrupts happen due to race conditions. They don't happen because the MPIC is bored and decides to ring a CPU's doorbell and hide in the bushes. If by "hardware exceptions" you mean machine checks, how would such a machine check be generated by a core that is off? However, setting them make sure dead cpus can not be waked up unexpectedly. I'm not seeing enough value here to warrant resurrecting the old sleep node stuff. -Scott My guess maybe not accurate. My point is that electronic parts don't always work as expected. Taking preventative measures can make the system more robust. In addition, this step is required in deep sleep procedure. -Chenhui -- 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] cxl: Add alternate MMIO error handling
On Thu, 2015-07-23 at 16:43 +1000, Ian Munsie wrote:
> From: Ian Munsie
>
> userspace programs using cxl currently have to use two strategies for
> dealing with MMIO errors simultaneously. They have to check every read
> for a return of all Fs in case the adapter has gone away and the kernel
> has not yet noticed, and they have to deal with SIGBUS in case the
> kernel has already noticed, invalidated the mapping and marked the
> context as failed.
>
> In order to simplify things, this patch adds an alternative approach
> where the kernel will return a page filled with Fs instead of delivering
> a SIGBUS. This allows userspace to only need to deal with one of these
> two error paths, and is intended for use in libraries that use cxl
> transparently and may not be able to safely install a signal handler.
>
> This approach will only work if certain constraints are met. Namely, if
> the application is both reading and writing to an address in the problem
> state area it cannot assume that a non-FF read is OK, as it may just be
> reading out a value it has previously written. Further - since only one
> page is used per context a write to a given offset would be visible when
> reading the same offset from a different page in the mapping (this only
> applies within a single context, not between contexts).
>
> An application could deal with this by e.g. making sure it also reads
> from a read-only offset after any reads to a read/write offset.
>
> Due to these constraints, this functionality must be explicitly
> requested by userspace when starting the context by passing in the
> CXL_START_WORK_ERR_FF flag.
>
> Signed-off-by: Ian Munsie
Acked-by: Michael Neuling
> ---
> drivers/misc/cxl/context.c | 14 ++
> drivers/misc/cxl/cxl.h | 4 +++-
> drivers/misc/cxl/file.c| 4 +++-
> include/uapi/misc/cxl.h| 4 +++-
> 4 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/misc/cxl/context.c b/drivers/misc/cxl/context.c
> index 1287148..6570f10 100644
> --- a/drivers/misc/cxl/context.c
> +++ b/drivers/misc/cxl/context.c
> @@ -126,6 +126,18 @@ static int cxl_mmap_fault(struct vm_area_struct *vma,
> struct vm_fault *vmf)
> if (ctx->status != STARTED) {
> mutex_unlock(>status_mutex);
> pr_devel("%s: Context not started, failing problem state
> access\n", __func__);
> + if (ctx->mmio_err_ff) {
> + if (!ctx->ff_page) {
> + ctx->ff_page = alloc_page(GFP_USER);
> + if (!ctx->ff_page)
> + return VM_FAULT_OOM;
> + memset(page_address(ctx->ff_page), 0xff,
> PAGE_SIZE);
> + }
> + get_page(ctx->ff_page);
> + vmf->page = ctx->ff_page;
> + vma->vm_page_prot = pgprot_cached(vma->vm_page_prot);
> + return 0;
> + }
> return VM_FAULT_SIGBUS;
> }
>
> @@ -253,6 +265,8 @@ static void reclaim_ctx(struct rcu_head *rcu)
> struct cxl_context *ctx = container_of(rcu, struct cxl_context, rcu);
>
> free_page((u64)ctx->sstp);
> + if (ctx->ff_page)
> + __free_page(ctx->ff_page);
> ctx->sstp = NULL;
>
> kfree(ctx);
> diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
> index 4fd66ca..b7293a4 100644
> --- a/drivers/misc/cxl/cxl.h
> +++ b/drivers/misc/cxl/cxl.h
> @@ -34,7 +34,7 @@ extern uint cxl_verbose;
> * Bump version each time a user API change is made, whether it is
> * backwards compatible ot not.
> */
> -#define CXL_API_VERSION 1
> +#define CXL_API_VERSION 2
> #define CXL_API_VERSION_COMPATIBLE 1
>
> /*
> @@ -418,6 +418,8 @@ struct cxl_context {
> /* Used to unmap any mmaps when force detaching */
> struct address_space *mapping;
> struct mutex mapping_lock;
> + struct page *ff_page;
> + bool mmio_err_ff;
>
> spinlock_t sste_lock; /* Protects segment table entries */
> struct cxl_sste *sstp;
> diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c
> index e3f4b69..34c7a5e 100644
> --- a/drivers/misc/cxl/file.c
> +++ b/drivers/misc/cxl/file.c
> @@ -179,6 +179,8 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
> if (work.flags & CXL_START_WORK_AMR)
> amr = work.amr & mfspr(SPRN_UAMOR);
>
> + ctx->mmio_err_ff = !!(work.flags & CXL_START_WORK_ERR_FF);
> +
> /*
>* We grab the PID here and not in the file open to allow for the case
>* where a process (master, some daemon, etc) has opened the chardev on
> @@ -519,7 +521,7 @@ int __init cxl_file_init(void)
>* If these change we really need to update API. Either change some
>* flags or update API version number CXL_API_VERSION.
>*/
> - BUILD_BUG_ON(CXL_API_VERSION != 1);
> + BUILD_BUG_ON(CXL_API_VERSION != 2);
>
linux-next: build failure after merge of the wireless-drivers-next tree
Hi Kalle,
After merging the wireless-drivers-next tree, today's linux-next build
(x86_64 allmodconfig) failed like this:
drivers/net/wireless/ath/ath9k/debug_sta.c: In function 'read_file_node_aggr':
drivers/net/wireless/ath/ath9k/debug_sta.c:54:25: error: 'struct ath_node' has
no member named 'ac'
for (acno = 0, ac = >ac[acno];
^
drivers/net/wireless/ath/ath9k/debug_sta.c:55:43: error: increment of pointer
to unknown structure
acno < IEEE80211_NUM_ACS; acno++, ac++) {
^
drivers/net/wireless/ath/ath9k/debug_sta.c:55:7: error: arithmetic on pointer
to an incomplete type
acno < IEEE80211_NUM_ACS; acno++, ac++) {
^
drivers/net/wireless/ath/ath9k/debug_sta.c:56:11: error: dereferencing pointer
to incomplete type
txq = ac->txq;
^
drivers/net/wireless/ath/ath9k/debug_sta.c:60:14: error: dereferencing pointer
to incomplete type
acno, ac->sched);
^
drivers/net/wireless/ath/ath9k/debug_sta.c:71:12: error: 'struct ath_atx_tid'
has no member named 'ac'
txq = tid->ac->txq;
^
drivers/net/wireless/ath/ath9k/debug_sta.c:83:10: error: 'struct ath_atx_tid'
has no member named 'sched'
tid->sched);
^
Caused by commits
592fa228f213 ("ath9k: remove struct ath_atx_ac")
d70d848a75fd ("ath9k: remove the sched field in struct ath_atx_tid")
I have used the wireless-drivers-next tree from next-20150806 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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 07/13] twl4030_charger: distinguish between USB current and 'AC' current
* NeilBrown [150729 17:28]:
> --- a/drivers/power/twl4030_charger.c
> +++ b/drivers/power/twl4030_charger.c
> static int twl4030_charger_update_current(struct twl4030_bci *bci)
> {
> int status;
> + int cur;
> unsigned reg, cur_reg;
> u8 bcictl1, oldreg, fullreg;
> bool cgain = false;
> u8 boot_bci;
>
> + /*
> + * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
> + * and AC is enabled, set current for 'ac'
> + */
> + if (twl4030_get_madc_conversion(11) > 4500) {
> + cur = bci->ac_cur;
> + bci->ac_is_active = true;
> + } else {
> + cur = bci->usb_cur;
> + bci->ac_is_active = false;
> + }
> +
> /* First, check thresholds and see if cgain is needed */
> if (bci->ichg_eoc >= 20)
> cgain = true;
Neil, you need a stub or something for twl4030_get_madc_conversion
if madc is not selected. Now at least omap2plus_defconfig and
ARM allmodconfig fails in Linux next.
Regards,
Tony
--
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: [GIT PULL] ASN.1 fixes
On Wed, 5 Aug 2015, David Howells wrote: > Hi James, > > Can you pull these fixes for the ASN.1 compiler and decoder into the > security/next tree and also pass them onto Linus for immediate inclusion? > Pulled to my -next branch, but it's too late really for 4.2, for this class of bugfix. -- James Morris -- 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] powerpc/vdso: Emit GNU & SysV hashes
Andy Lutomirski says: Some dynamic loaders may be slightly faster if a GNU hash is available. This is unlikely to have any measurable effect on the time it takes to resolve vdso symbols (since there are so few of them). In some contexts, it can be a win for a different reason: if every DSO has a GNU hash section, then libc can avoid calculating SysV hashes at all. Both musl and glibc appear to have this optimization. Signed-off-by: Michael Ellerman --- arch/powerpc/kernel/vdso32/Makefile | 2 +- arch/powerpc/kernel/vdso64/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/vdso32/Makefile b/arch/powerpc/kernel/vdso32/Makefile index 53e6c9b979ec..6abffb7a8cd9 100644 --- a/arch/powerpc/kernel/vdso32/Makefile +++ b/arch/powerpc/kernel/vdso32/Makefile @@ -18,7 +18,7 @@ GCOV_PROFILE := n ccflags-y := -shared -fno-common -fno-builtin ccflags-y += -nostdlib -Wl,-soname=linux-vdso32.so.1 \ - $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) + $(call cc-ldoption, -Wl$(comma)--hash-style=both) asflags-y := -D__VDSO32__ -s obj-y += vdso32_wrapper.o diff --git a/arch/powerpc/kernel/vdso64/Makefile b/arch/powerpc/kernel/vdso64/Makefile index effca9404b17..8c8f2ae43935 100644 --- a/arch/powerpc/kernel/vdso64/Makefile +++ b/arch/powerpc/kernel/vdso64/Makefile @@ -11,7 +11,7 @@ GCOV_PROFILE := n ccflags-y := -shared -fno-common -fno-builtin ccflags-y += -nostdlib -Wl,-soname=linux-vdso64.so.1 \ - $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) + $(call cc-ldoption, -Wl$(comma)--hash-style=both) asflags-y := -D__VDSO64__ -s obj-y += vdso64_wrapper.o -- 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 RFC V9 3/3] perf,tests: Add tests to callgraph and time parse
From: Kan Liang
Add tests in tests/parse-events.c to check call-graph and time option
Signed-off-by: Kan Liang
---
tools/perf/tests/parse-events.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index f65bb89..9b6b2b63 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -479,6 +479,39 @@ static int test__checkevent_pmu_name(struct perf_evlist
*evlist)
return 0;
}
+static int test__checkevent_pmu_partial_time_callgraph(struct perf_evlist
*evlist)
+{
+ struct perf_evsel *evsel = perf_evlist__first(evlist);
+
+ /* cpu/config=1,call-graph=fp,time,period=10/ */
+ TEST_ASSERT_VAL("wrong number of entries", 2 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_RAW == evsel->attr.type);
+ TEST_ASSERT_VAL("wrong config", 1 == evsel->attr.config);
+ /*
+* The period, time and callgraph value gets configured
+* within perf_evlist__config,
+* while this test executes only parse events method.
+*/
+ TEST_ASSERT_VAL("wrong period", 0 == evsel->attr.sample_period);
+ TEST_ASSERT_VAL("wrong callgraph", !(PERF_SAMPLE_CALLCHAIN &
evsel->attr.sample_type));
+ TEST_ASSERT_VAL("wrong time", !(PERF_SAMPLE_TIME &
evsel->attr.sample_type));
+
+ /* cpu/config=2,call-graph=no,time=0,period=2000/ */
+ evsel = perf_evsel__next(evsel);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_RAW == evsel->attr.type);
+ TEST_ASSERT_VAL("wrong config", 2 == evsel->attr.config);
+ /*
+* The period, time and callgraph value gets configured
+* within perf_evlist__config,
+* while this test executes only parse events method.
+*/
+ TEST_ASSERT_VAL("wrong period", 0 == evsel->attr.sample_period);
+ TEST_ASSERT_VAL("wrong callgraph", !(PERF_SAMPLE_CALLCHAIN &
evsel->attr.sample_type));
+ TEST_ASSERT_VAL("wrong time", !(PERF_SAMPLE_TIME &
evsel->attr.sample_type));
+
+ return 0;
+}
+
static int test__checkevent_pmu_events(struct perf_evlist *evlist)
{
struct perf_evsel *evsel = perf_evlist__first(evlist);
@@ -1555,6 +1588,11 @@ static struct evlist_test test__events_pmu[] = {
.check = test__checkevent_pmu_name,
.id= 1,
},
+ {
+ .name =
"cpu/config=1,call-graph=fp,time,period=10/,cpu/config=2,call-graph=no,time=0,period=2000/",
+ .check = test__checkevent_pmu_partial_time_callgraph,
+ .id= 2,
+ },
};
struct terms_test {
--
1.8.3.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/
[PATCH RFC V9 1/3] perf,tools: move callchain option parse code to util.c
From: Kan Liang
Move callchain option parse related code to util.c
Signed-off-by: Kan Liang
---
Changes since V8:
- Fix the link problems found by perf python test case.
Introduce the patch to move callchain option parse related code to util.c
tools/perf/util/callchain.c | 89 +---
tools/perf/util/callchain.h | 1 +
tools/perf/util/util.c | 90 +
tools/perf/util/util.h | 2 +
4 files changed, 94 insertions(+), 88 deletions(-)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 931cca8..773fe13 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -25,96 +25,9 @@
__thread struct callchain_cursor callchain_cursor;
-#ifdef HAVE_DWARF_UNWIND_SUPPORT
-static int get_stack_size(const char *str, unsigned long *_size)
-{
- char *endptr;
- unsigned long size;
- unsigned long max_size = round_down(USHRT_MAX, sizeof(u64));
-
- size = strtoul(str, , 0);
-
- do {
- if (*endptr)
- break;
-
- size = round_up(size, sizeof(u64));
- if (!size || size > max_size)
- break;
-
- *_size = size;
- return 0;
-
- } while (0);
-
- pr_err("callchain: Incorrect stack dump size (max %ld): %s\n",
- max_size, str);
- return -1;
-}
-#endif /* HAVE_DWARF_UNWIND_SUPPORT */
-
int parse_callchain_record_opt(const char *arg, struct callchain_param *param)
{
- char *tok, *name, *saveptr = NULL;
- char *buf;
- int ret = -1;
-
- /* We need buffer that we know we can write to. */
- buf = malloc(strlen(arg) + 1);
- if (!buf)
- return -ENOMEM;
-
- strcpy(buf, arg);
-
- tok = strtok_r((char *)buf, ",", );
- name = tok ? : (char *)buf;
-
- do {
- /* Framepointer style */
- if (!strncmp(name, "fp", sizeof("fp"))) {
- if (!strtok_r(NULL, ",", )) {
- param->record_mode = CALLCHAIN_FP;
- ret = 0;
- } else
- pr_err("callchain: No more arguments "
- "needed for --call-graph fp\n");
- break;
-
-#ifdef HAVE_DWARF_UNWIND_SUPPORT
- /* Dwarf style */
- } else if (!strncmp(name, "dwarf", sizeof("dwarf"))) {
- const unsigned long default_stack_dump_size = 8192;
-
- ret = 0;
- param->record_mode = CALLCHAIN_DWARF;
- param->dump_size = default_stack_dump_size;
-
- tok = strtok_r(NULL, ",", );
- if (tok) {
- unsigned long size = 0;
-
- ret = get_stack_size(tok, );
- param->dump_size = size;
- }
-#endif /* HAVE_DWARF_UNWIND_SUPPORT */
- } else if (!strncmp(name, "lbr", sizeof("lbr"))) {
- if (!strtok_r(NULL, ",", )) {
- param->record_mode = CALLCHAIN_LBR;
- ret = 0;
- } else
- pr_err("callchain: No more arguments "
- "needed for --call-graph lbr\n");
- break;
- } else {
- pr_err("callchain: Unknown --call-graph option "
- "value: %s\n", arg);
- break;
- }
-
- } while (0);
-
- free(buf);
- return ret;
+ return parse_callchain_record(arg, param);
}
static int parse_callchain_mode(const char *value)
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 68a32c2..acee2b3 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -177,6 +177,7 @@ int fill_callchain_info(struct addr_location *al, struct
callchain_cursor_node *
bool hide_unresolved);
extern const char record_callchain_help[];
+extern int parse_callchain_record(const char *arg, struct callchain_param
*param);
int parse_callchain_record_opt(const char *arg, struct callchain_param *param);
int parse_callchain_report_opt(const char *arg);
int perf_callchain_config(const char *var, const char *value);
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index edc2d63..f7adf12 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -566,6 +566,96 @@ unsigned long parse_tag_value(const char *str, struct
parse_tag *tags)
return (unsigned long) -1;
}
+int get_stack_size(const char *str, unsigned long *_size)
+{
+ char *endptr;
+ unsigned long size;
+ unsigned long max_size
[PATCH RFC V9 2/3] perf,tools: per-event callgraph support
From: Kan Liang
When multiple events are sampled it may not be needed to collect
callgraphs for all of them. The sample sites are usually nearby, and
it's enough to collect the callgraphs on a reference event (such as
precise cycles or precise instructions).
This patchkit adds the ability to turn off callgraphs and time stamp
per event. This in term can reduce sampling overhead and the size of the
perf.data. Furthermore, it makes collecting back traces and timestamps
possible when PEBS threshold > 1, which significantly reducing the
sampling overhead especially for frequently occurring events
(https://lkml.org/lkml/2015/5/10/196). For example, A slower event with
a larger period collects back traces/timestamps. Other more events run
fast with multi-pebs. The time stamps from the slower events can be used
to order the faster events. Their backtraces can give the user enough
hint to find the right spot.
Here are some examples and test results.
1. Comparing the elapsed time and perf.data size from "kernbench -M -H".
The test command for FULL callgraph and time support.
"perf record -e
'{cpu/cpu-cycles,period=10/,cpu/instructions,period=2/p}'
--call-graph fp --time"
The test command for PARTIAL callgraph and time support.
"perf record -e
'{cpu/cpu-cycles,call-graph=fp,time,period=10/,
cpu/instructions,call-graph=no,time=0,period=2/p}'"
The elapsed time for FULL is 24.3 Sec, while for PARTIAL is 16.9 Sec.
The perf.data size for FULL is 22.1 Gb, while for PARTIAL is 12.4 Gb.
2. Comparing the perf.data size and callgraph results.
The test command for FULL callgraph and time support.
"perf record -e
'{cpu/cpu-cycles,period=10/pp,cpu/instructions,period=2/p}'
--call-graph fp -- ./tchain_edit"
The test command for PARTIAL callgraph and time support.
"perf record -e
'{cpu/cpu-cycles,call-graph=fp,time,period=10/pp,
cpu/instructions,call-graph=no,time=0,period=2/p}'
-- ./tchain_edit"
The perf.data size for FULL is 43.2 MB, while for PARTIAL is 21.1 MB.
The callgraph is roughly the same.
The callgraph from FULL
# Samples: 87K of event
'cpu/cpu-cycles,call-graph=fp,time,period=10/pp'
# Event count (approx.): 876000
#
# Children Self Command Shared Object Symbol
# ... ..
..
#
99.98% 0.00% tchain_edit libc-2.15.so[.]
__libc_start_main
|
---__libc_start_main
99.97% 0.00% tchain_edit tchain_edit [.] main
|
---main
__libc_start_main
99.97% 0.00% tchain_edit tchain_edit [.] f1
|
---f1
main
__libc_start_main
99.85%87.01% tchain_edit tchain_edit [.] f3
|
---f3
|
|--99.74%-- f2
| f1
| main
| __libc_start_main
--0.26%-- [...]
99.71% 0.12% tchain_edit tchain_edit [.] f2
|
---f2
f1
main
__libc_start_main
The callgraph from PARTIAL
# Samples: 417K of event
'cpu/instructions,call-graph=no,time=0,period=2/p'
# Event count (approx.): 834698
#
# Children Self Command Shared Object Symbol
# ...
..
#
98.82% 0.00% tchain_edit libc-2.15.so [.]
__libc_start_main
|
---__libc_start_main
98.82% 0.00% tchain_edit tchain_edit [.] main
|
---main
__libc_start_main
98.82% 0.00% tchain_edit tchain_edit [.] f1
|
---f1
main
__libc_start_main
98.82%98.28% tchain_edit tchain_edit [.] f3
|
---f3
|
|--0.53%-- f2
| f1
| main
| __libc_start_main
|
|--0.01%-- f1
| main
| __libc_start_main
--99.46%-- [...]
97.63% 0.03% tchain_edit tchain_edit [.] f2
|
---f2
f1
main
__libc_start_main
7.13% 0.03% tchain_edit [kernel.vmlinux] [k] do_nmi
|
---do_nmi
end_repeat_nmi
f3
f2
f1
main
__libc_start_main
Signed-off-by: Kan Liang
---
Changes since V8:
- Same as global dump_size caculation, round_up dump_size for per-event
dump_size.
tools/perf/Documentation/perf-record.txt | 4 ++
tools/perf/util/evsel.c |
[PATCH 1/1] Staging: media: davinci_vpfe: fix over 80 characters coding style issue.
This is a patch to the dm365_ipipe.c that fixes over 80 characters warning
detected by checkpatch.pl.
Signed-off-by: Junsu Shin
---
drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 1bbb90c..57cd274 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1536,8 +1536,9 @@ ipipe_get_format(struct v4l2_subdev *sd, struct
v4l2_subdev_pad_config *cfg,
* @fse: pointer to v4l2_subdev_frame_size_enum structure.
*/
static int
-ipipe_enum_frame_size(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config
*cfg,
- struct v4l2_subdev_frame_size_enum *fse)
+ipipe_enum_frame_size(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
{
struct vpfe_ipipe_device *ipipe = v4l2_get_subdevdata(sd);
struct v4l2_mbus_framefmt format;
--
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] user_ns: use correct check for single-threadedness
On 08/05, Eric W. Biederman wrote: > > So I have to ask. I hope you are asking someone else, not me ;) I never understood what exactly we try to restrict and why. > Is it possible to rework these checks such that we > look at the sighand struct and signal sharing handling sharing instead > of the count on the mm_struct? Then why we can't simply check thread_group_empty() == T ? Why should we worry about CLONE_SIGHAND at all? Oleg. -- 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: QEMU fw_cfg DMA interface
On Thu, 6 Aug 2015 11:30:43 -0400 "Kevin O'Connor" wrote: > On Thu, Aug 06, 2015 at 02:37:45PM +0200, Marc Marí wrote: > > On Thu, 6 Aug 2015 13:27:16 +0100 > > Stefan Hajnoczi wrote: > > > > > On Thu, Aug 6, 2015 at 12:00 PM, Marc Marí > > > wrote: > > > > When running a Linux guest on top of QEMU, using the -kernel > > > > options, this is the timing improvement for x86: > > > > > > > > QEMU commit 2be4f242b50a8 and SeaBIOS commit 908a58c1d5ff > > > > QEMU startup time: .078 > > > > BIOS startup time: .060 > > > > Kernel setup time: .578 > > > > Total time: .716 > > > > > > > > QEMU with this patch series and SeaBIOS with this patch series > > > > QEMU startup time: .080 > > > > BIOS startup time: .039 > > > > Kernel setup time: .002 > > > > Total time: .121 > > > > > > Impressive results! > > > > > > Is this a fully-featured QEMU build or did you disable things? > > > > > > Is this the default SeaBIOS build or did you disable things? > > > > > > > This is the default QEMU configuration I get for my system. It's > > not a fully-featured QEMU, but it has a lot of things enabled. > > SeaBIOS has a default configuration (with debugging disabled). > > Thanks! > > What qemu command-line did you use during testing? Also, do you have > a quick primer on how to use the kvm trace stuff to obtain timings? > The command line I used is: x86_64-softmmu/qemu-system-x86_64 --enable-kvm \ -kernel /boot/vmlinuz-4.0.7-300.fc22.x86_64 \ -L pc-bios/optionrom/ \ -bios roms/seabios/out/bios.bin -nographic And I used perf (and two out instructions in the BIOS) to measure the times: perf record -a -e kvm:\* -e sched:sched_process_exec And searching for sched:sched_process_exec, kvm:kvm_entry, pio_write at 0xf5 and pio_write at 0xf4. Out at 0xf5 is the one in "do_boot" function, and out at 0xf4 is the one just before the jump to the Linux kernel. I attach the script I've been using. It can be improved, but it works. It can be run like this: sudo ../../results/run_test.sh x86_64-softmmu/qemu-system-x86_64 \ --enable-kvm -kernel /boot/vmlinuz-4.0.8-300.fc22.x86_64 \ -L pc-bios/optionrom/ \ -bios roms/seabios/out/bios.bin -nographic Thanks Marc run_test.sh Description: application/shellscript
Re: [PATCH v8 00/21] Compile-time stack validation
On Thu, Aug 06, 2015 at 12:23:32PM -0500, Josh Poimboeuf wrote: > On Thu, Aug 06, 2015 at 10:07:50AM +0200, Ingo Molnar wrote: > > > > * Josh Poimboeuf wrote: > > > > > This is v8 of the compile-time stack validation patch set, based on the > > > tip/master branch. > > > > > > The frame pointer macros are still called FRAME and ENDFRAME because I > > > don't think we converged on anything else yet. Otherwise I tried to > > > address all the other review comments from v7. > > > > So I think: > > > > FRAME_START > > FRAME_END > > (One last tweak to the bikeshed) > > The antonym of END is BEGIN. So how about: > > FRAME_BEGIN > FRAME_END Ok, so thesaurus.com reminds me that words can have more than one antonym, and that START and BEGIN are both antonyms of END. Personally, when I START something I usually FINISH it or even STOP it. So I'll stop the bikeshedding I started and go with BEGIN/END. -- Josh -- 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 v8 00/21] Compile-time stack validation
On Thu, Aug 06, 2015 at 10:07:50AM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > This is v8 of the compile-time stack validation patch set, based on the > > tip/master branch. > > > > The frame pointer macros are still called FRAME and ENDFRAME because I > > don't think we converged on anything else yet. Otherwise I tried to > > address all the other review comments from v7. > > So I think: > > FRAME_START > FRAME_END (One last tweak to the bikeshed) The antonym of END is BEGIN. So how about: FRAME_BEGIN FRAME_END -- Josh -- 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 4/5] KVM: add KVM_USER_EXIT vcpu ioctl for userspace exit
2015-08-06 15:52+0200, Paolo Bonzini: > On 06/08/2015 15:44, Radim Krčmář wrote: >> The two obvious extensions are flags to skip kvm_make_request() or >> kvm_vcpu_kick(), both of dubious use. > > Skipping kvm_make_request() would make some sense if you can set > vcpu->run->request_interrupt_window asynchronously. So you could do > > vcpu->run->request_interrupt_window = 1; > ioctl(vcpu_fd, KVM_USER_EXIT, KVM_USER_EXIT_LAZY); > > and only cause a lightweight vmexit if the interrupt window is currently > closed. I haven't thought of any races that could happen, but it looks > like it could work. Seems doable, kvm_run should have been better protected :) > Skipping kvm_vcpu_kick() makes much less sense. Could save some cycles when queuing an early exit from the VCPU thread. >> Another possibility is setting up >> conditional exits, but that would be better as a separate control, like >> most other sophisticated extensions. >> >> I think that u32 flags would be sufficient -- is casting the 'unsigned >> long arg' (data pointer) to a value still an accepted solution? > > Yeah, that would work for me as well. Also because, for now, you'd > return EINVAL if the unsigned long is not zero, which boils down to > "return EINVAL if the parameter is not NULL". :) Exactly, only the ioctl number will change. -- 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 V9 3/3] audit: add audit by children of executable path
On Wednesday, August 05, 2015 04:29:38 PM Richard Guy Briggs wrote:
> This adds the ability to audit the actions of children of a not-yet-running
> process.
>
> This is a split-out of a heavily modified version of a patch originally
> submitted by Eric Paris with some ideas from Peter Moody.
>
> Cc: Peter Moody
> Cc: Eric Paris
> Signed-off-by: Richard Guy Briggs
> ---
> include/uapi/linux/audit.h |1 +
> kernel/auditfilter.c |5 +
> kernel/auditsc.c | 11 +++
> 3 files changed, 17 insertions(+), 0 deletions(-)
I'm still not really comfortable with that loop and since there hasn't been a
really convincing use case I'm going to pass on this patch for right now. If
someone comes up with a *really* compelling case in the future I'll reconsider
it.
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index e2ca600..55a8dec 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -267,6 +267,7 @@
> #define AUDIT_OBJ_GID110
> #define AUDIT_FIELD_COMPARE 111
> #define AUDIT_EXE112
> +#define AUDIT_EXE_CHILDREN 113
>
> #define AUDIT_ARG0 200
> #define AUDIT_ARG1 (AUDIT_ARG0+1)
> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> index c662638..802f0cc 100644
> --- a/kernel/auditfilter.c
> +++ b/kernel/auditfilter.c
> @@ -406,6 +406,7 @@ static int audit_field_valid(struct audit_entry *entry,
> struct audit_field *f) return -EINVAL;
> break;
> case AUDIT_EXE:
> + case AUDIT_EXE_CHILDREN:
> if (f->op != Audit_equal)
> return -EINVAL;
> if (entry->rule.listnr != AUDIT_FILTER_EXIT)
> @@ -547,6 +548,7 @@ static struct audit_entry *audit_data_to_entry(struct
> audit_rule_data *data, entry->rule.filterkey = str;
> break;
> case AUDIT_EXE:
> + case AUDIT_EXE_CHILDREN:
> if (entry->rule.exe || f->val > PATH_MAX)
> goto exit_free;
> str = audit_unpack_string(, , f->val);
> @@ -643,6 +645,7 @@ static struct audit_rule_data
> *audit_krule_to_data(struct audit_krule *krule) audit_pack_string(,
> krule->filterkey);
> break;
> case AUDIT_EXE:
> + case AUDIT_EXE_CHILDREN:
> data->buflen += data->values[i] =
> audit_pack_string(,
> audit_mark_path(krule->exe));
> break;
> @@ -710,6 +713,7 @@ static int audit_compare_rule(struct audit_krule *a,
> struct audit_krule *b) return 1;
> break;
> case AUDIT_EXE:
> + case AUDIT_EXE_CHILDREN:
> /* both paths exist based on above type compare */
> if (strcmp(audit_mark_path(a->exe),
> audit_mark_path(b->exe)))
> @@ -838,6 +842,7 @@ struct audit_entry *audit_dupe_rule(struct audit_krule
> *old) new->filterkey = fk;
> break;
> case AUDIT_EXE:
> + case AUDIT_EXE_CHILDREN:
> err = audit_dupe_exe(new, old);
> break;
> }
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index e9bac2b..4f2b515 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -469,6 +469,17 @@ static int audit_filter_rules(struct task_struct *tsk,
> case AUDIT_EXE:
> result = audit_exe_compare(tsk, rule->exe);
> break;
> + case AUDIT_EXE_CHILDREN:
> + {
> + struct task_struct *ptsk;
> + for (ptsk = tsk; ptsk->parent->pid > 0; ptsk =
> find_task_by_vpid(ptsk->parent->pid)) { + if
(audit_exe_compare(ptsk,
> rule->exe)) {
> + ++result;
> + break;
> + }
> + }
> + }
> + break;
> case AUDIT_UID:
> result = audit_uid_comparator(cred->uid, f->op, f->uid);
> break;
--
paul moore
security @ redhat
--
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 V9 1/3] audit: clean simple fsnotify implementation
On Wednesday, August 05, 2015 04:29:36 PM Richard Guy Briggs wrote:
> This is to be used to audit by executable path rules, but audit watches
> should be able to share this code eventually.
>
> At the moment the audit watch code is a lot more complex. That code only
> creates one fsnotify watch per parent directory. That 'audit_parent' in
> turn has a list of 'audit_watches' which contain the name, ino, dev of
> the specific object we care about. This just creates one fsnotify watch
> per object we care about. So if you watch 100 inodes in /etc this code
> will create 100 fsnotify watches on /etc. The audit_watch code will
> instead create 1 fsnotify watch on /etc (the audit_parent) and then 100
> individual watches chained from that fsnotify mark.
>
> We should be able to convert the audit_watch code to do one fsnotify
> mark per watch and simplify things/remove a whole lot of code. After
> that conversion we should be able to convert the audit_fsnotify code to
> support that hierarchy if the optimization is necessary.
>
> Move the access to the entry for audit_match_signal() to the beginning of
> the audit_del_rule() function in case the entry found is the same one passed
> in. This will enable it to be used by audit_autoremove_mark_rule(),
> kill_rules() and audit_remove_parent_watches().
>
> This is a heavily modified and merged version of two patches originally
> submitted by Eric Paris.
>
> Cc: Peter Moody
> Cc: Eric Paris
> Signed-off-by: Richard Guy Briggs
> ---
> kernel/Makefile |2 +-
> kernel/audit.h | 14 +++
> kernel/audit_fsnotify.c | 215 +++
> kernel/auditfilter.c|2 +-
> 4 files changed, 231 insertions(+), 2 deletions(-)
> create mode 100644 kernel/audit_fsnotify.c
Merged, although I had to add a line of whitespace to keep checkpatch happy.
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 60c302c..58b5b52 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -64,7 +64,7 @@ obj-$(CONFIG_SMP) += stop_machine.o
> obj-$(CONFIG_KPROBES_SANITY_TEST) += test_kprobes.o
> obj-$(CONFIG_AUDIT) += audit.o auditfilter.o
> obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
> -obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o
> +obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o audit_fsnotify.o
> obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
> obj-$(CONFIG_GCOV_KERNEL) += gcov/
> obj-$(CONFIG_KPROBES) += kprobes.o
> diff --git a/kernel/audit.h b/kernel/audit.h
> index d641f9b..46d10dd 100644
> --- a/kernel/audit.h
> +++ b/kernel/audit.h
> @@ -50,6 +50,7 @@ enum audit_state {
>
> /* Rule lists */
> struct audit_watch;
> +struct audit_fsnotify_mark;
> struct audit_tree;
> struct audit_chunk;
>
> @@ -252,6 +253,7 @@ struct audit_net {
> extern int selinux_audit_rule_update(void);
>
> extern struct mutex audit_filter_mutex;
> +extern int audit_del_rule(struct audit_entry *);
> extern void audit_free_rule_rcu(struct rcu_head *);
> extern struct list_head audit_filter_list[];
>
> @@ -269,6 +271,13 @@ extern int audit_add_watch(struct audit_krule *krule,
> struct list_head **list); extern void audit_remove_watch_rule(struct
> audit_krule *krule);
> extern char *audit_watch_path(struct audit_watch *watch);
> extern int audit_watch_compare(struct audit_watch *watch, unsigned long
> ino, dev_t dev); +
> +extern struct audit_fsnotify_mark *audit_alloc_mark(struct audit_krule
> *krule, char *pathname, int len); +extern char *audit_mark_path(struct
> audit_fsnotify_mark *mark);
> +extern void audit_remove_mark(struct audit_fsnotify_mark *audit_mark);
> +extern void audit_remove_mark_rule(struct audit_krule *krule);
> +extern int audit_mark_compare(struct audit_fsnotify_mark *mark, unsigned
> long ino, dev_t dev); +
> #else
> #define audit_put_watch(w) {}
> #define audit_get_watch(w) {}
> @@ -278,6 +287,11 @@ extern int audit_watch_compare(struct audit_watch
> *watch, unsigned long ino, dev #define audit_watch_path(w) ""
> #define audit_watch_compare(w, i, d) 0
>
> +#define audit_alloc_mark(k, p, l) (ERR_PTR(-EINVAL))
> +#define audit_mark_path(m) ""
> +#define audit_remove_mark(m)
> +#define audit_remove_mark_rule(k)
> +#define audit_mark_compare(m, i, d) 0
> #endif /* CONFIG_AUDIT_WATCH */
>
> #ifdef CONFIG_AUDIT_TREE
> diff --git a/kernel/audit_fsnotify.c b/kernel/audit_fsnotify.c
> new file mode 100644
> index 000..654c6c7
> --- /dev/null
> +++ b/kernel/audit_fsnotify.c
> @@ -0,0 +1,215 @@
> +/* audit_fsnotify.c -- tracking inodes
> + *
> + * Copyright 2003-2009,2014-2015 Red Hat, Inc.
> + * Copyright 2005 Hewlett-Packard Development Company, L.P.
> + * Copyright 2005 IBM Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it
Re: [PATCH V5] audit: use macros for unset inode and device values
On Wednesday, August 05, 2015 11:48:20 PM Richard Guy Briggs wrote:
> Clean up a number of places were casted magic numbers are used to represent
> unset inode and device numbers in preparation for the audit by executable
> path patch set.
>
> Signed-off-by: Richard Guy Briggs
> ---
> v6: Change dev macro cast from unsigned int to dev_t.
>
> v5: Move macros from include/uapi/linux/audit.h to include/linux/audit.h
> Use "unsigned int" rather than bare "unsigned".
>
> include/linux/audit.h |3 +++
> kernel/audit.c|2 +-
> kernel/audit_watch.c |8
> kernel/auditsc.c |6 +++---
> 4 files changed, 11 insertions(+), 8 deletions(-)
Great, thank you.
... and since we were just talking about modifications while I apply the
patches, here are two examples of changes I'm "OK" making:
* There was a minor conflict in audit_log_name() that caused that
AUDIT_INO_UNSET to be dropped so I restored it. This is just par for the
course when you're applying patches to a tree; I don't think twice about these
changes so long as the merge is trivially understood.
* The AUDIT_{INO,DEV}_UNSET macros needed to be wrapped in parentheses to keep
./scripts/checkpatch happy. I consider that trivial and not a functional
change so I made that change after noting it in the description metadata.
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index c2e7e3a..1514412 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -27,6 +27,9 @@
> #include
> #include
>
> +#define AUDIT_INO_UNSET (unsigned long)-1
> +#define AUDIT_DEV_UNSET (dev_t)-1
> +
> struct audit_sig_info {
> uid_t uid;
> pid_t pid;
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 1c13e42..d546003 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1761,7 +1761,7 @@ void audit_log_name(struct audit_context *context,
> struct audit_names *n, } else
> audit_log_format(ab, " name=(null)");
>
> - if (n->ino != (unsigned long)-1)
> + if (n->ino != AUDIT_INO_UNSET)
> audit_log_format(ab, " inode=%lu"
>" dev=%02x:%02x mode=%#ho"
>" ouid=%u ogid=%u rdev=%02x:%02x",
> diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
> index 8f123d7..c668bfc 100644
> --- a/kernel/audit_watch.c
> +++ b/kernel/audit_watch.c
> @@ -138,7 +138,7 @@ char *audit_watch_path(struct audit_watch *watch)
>
> int audit_watch_compare(struct audit_watch *watch, unsigned long ino, dev_t
> dev) {
> - return (watch->ino != (unsigned long)-1) &&
> + return (watch->ino != AUDIT_INO_UNSET) &&
> (watch->ino == ino) &&
> (watch->dev == dev);
> }
> @@ -179,8 +179,8 @@ static struct audit_watch *audit_init_watch(char *path)
> INIT_LIST_HEAD(>rules);
> atomic_set(>count, 1);
> watch->path = path;
> - watch->dev = (dev_t)-1;
> - watch->ino = (unsigned long)-1;
> + watch->dev = AUDIT_DEV_UNSET;
> + watch->ino = AUDIT_INO_UNSET;
>
> return watch;
> }
> @@ -493,7 +493,7 @@ static int audit_watch_handle_event(struct
> fsnotify_group *group, if (mask & (FS_CREATE|FS_MOVED_TO) && inode)
> audit_update_watch(parent, dname, inode->i_sb->s_dev,
> inode->i_ino, 0);
> else if (mask & (FS_DELETE|FS_MOVED_FROM))
> - audit_update_watch(parent, dname, (dev_t)-1, (unsigned long)-1,
> 1);
> + audit_update_watch(parent, dname, AUDIT_DEV_UNSET,
> AUDIT_INO_UNSET, 1);
> else if (mask & (FS_DELETE_SELF|FS_UNMOUNT|FS_MOVE_SELF))
> audit_remove_parent_watches(parent);
>
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 9fb9d1c..701ea5c 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -180,7 +180,7 @@ static int audit_match_filetype(struct audit_context
> *ctx, int val) return 0;
>
> list_for_each_entry(n, >names_list, list) {
> - if ((n->ino != -1) &&
> + if ((n->ino != AUDIT_INO_UNSET) &&
> ((n->mode & S_IFMT) == mode))
> return 1;
> }
> @@ -1683,7 +1683,7 @@ static struct audit_names *audit_alloc_name(struct
> audit_context *context, aname->should_free = true;
> }
>
> - aname->ino = (unsigned long)-1;
> + aname->ino = AUDIT_INO_UNSET;
> aname->type = type;
> list_add_tail(>list, >names_list);
>
> @@ -1925,7 +1925,7 @@ void __audit_inode_child(const struct inode *parent,
> if (inode)
> audit_copy_inode(found_child, dentry, inode);
> else
> - found_child->ino = (unsigned long)-1;
> + found_child->ino = AUDIT_INO_UNSET;
> }
> EXPORT_SYMBOL_GPL(__audit_inode_child);
--
paul moore
security @ redhat
--
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
Re: [lkp] [staging] 68905a14e49: kernel BUG at drivers/base/driver.c:153!
On Sat, Aug 01, 2015 at 01:12:05PM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit 68905a14e49c97bf49dacd753e40ddd5b254e2ad ("staging: unisys: Add s-Par
> visornic ethernet driver")
>
>
> +--+++
> | |
> dbb9d61994 | 68905a14e4 |
> +--+++
> | boot_successes | 0
> | 0 |
> | boot_failures| 11
> | 11 |
> | invoked_oom-killer:gfp_mask=0x | 11
> ||
> | Mem-Info | 11
> ||
> | Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 11
> ||
> | backtrace:lock_torture_stats | 11
> ||
> | kernel_BUG_at_drivers/base/driver.c | 0
> | 11 |
> | invalid_opcode | 0
> | 11 |
> | RIP:driver_register | 0
> | 11 |
> | Kernel_panic-not_syncing:Fatal_exception | 0
> | 11 |
> | backtrace:visornic_init | 0
> | 11 |
> | backtrace:kernel_init_freeable | 0
> | 11 |
> +--+++
>
>
> [ 12.273990] GPIO INIT FAIL!!
> [ 12.275607] [ cut here ]
> [ 12.275607] [ cut here ]
> [ 12.276231] kernel BUG at drivers/base/driver.c:153!
> [ 12.276231] kernel BUG at drivers/base/driver.c:153!
> [ 12.276231] invalid opcode: [#1]
> [ 12.276231] invalid opcode: [#1] PREEMPT PREEMPT SMP SMP
>
> [ 12.276231] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.1.0-rc7-01053-g68905a1 #1
> [ 12.276231] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.1.0-rc7-01053-g68905a1 #1
> [ 12.276231] task: 8819c000 ti: 881a task.ti:
> 881a
> [ 12.276231] task: 8819c000 ti: 881a task.ti:
> 881a
> [ 12.276231] RIP: 0010:[]
> [ 12.276231] RIP: 0010:[] []
> driver_register+0xa8/0xe0
> [] driver_register+0xa8/0xe0
> [ 12.276231] RSP: 0018:881a3e30 EFLAGS: 00010246
> [ 12.276231] RSP: 0018:881a3e30 EFLAGS: 00010246
> [ 12.276231] RAX: RBX: 82faef80 RCX:
>
> [ 12.276231] RAX: RBX: 82faef80 RCX:
>
> [ 12.276231] RDX: RSI: 82fae400 RDI:
> 82faefe0
> [ 12.276231] RDX: RSI: 82fae400 RDI:
> 82faefe0
> [ 12.276231] RBP: 881a3e78 R08: 880011279b00 R09:
>
> [ 12.276231] RBP: 881a3e78 R08: 880011279b00 R09:
>
> [ 12.276231] R10: 880011279b00 R11: R12:
> 82faefe0
> [ 12.276231] R10: 880011279b00 R11: R12:
> 82faefe0
> [ 12.276231] R13: R14: 8205aab0 R15:
>
> [ 12.276231] R13: R14: 8205aab0 R15:
>
> [ 12.276231] FS: () GS:88001380()
> knlGS:
> [ 12.276231] FS: () GS:88001380()
> knlGS:
> [ 12.276231] CS: 0010 DS: ES: CR0: 80050033
> [ 12.276231] CS: 0010 DS: ES: CR0: 80050033
> [ 12.276231] CR2: 7f594be968ec CR3: 02e08000 CR4:
> 000406b0
> [ 12.276231] CR2: 7f594be968ec CR3: 02e08000 CR4:
> 000406b0
> [ 12.276231] Stack:
> [ 12.276231] Stack:
> [ 12.276231] 82055977
> [ 12.276231] 82055977 0100 0100
> 8205aab0 8205aab0
>
> [ 12.276231]
> [ 12.276231] 881a3e78 881a3e78
> 811d0df6 811d0df6 830c0910 830c0910
>
> [ 12.276231] 880010561d50
> [ 12.276231] 880010561d50 881a3e88 881a3e88
> 8205ac53 8205ac53 881a3f08 881a3f08
>
> [ 12.276231] Call Trace:
> [ 12.276231] Call Trace:
> [ 12.276231] [] ?
> visorbus_register_visor_driver+0x47/0x100
> [ 12.276231] [] ?
>
Re: [PATCH v3 5/8] ARM: mediatek: add smp bringup code for MT6580
On Wed, 2015-08-05 at 10:44 +0100, Russell King - ARM Linux wrote: > On Tue, Aug 04, 2015 at 09:54:21PM +0800, Scott Shu wrote: > > Add support for cpu enable-method "mediatek,mt6580-smp" for booting > > secondary CPUs on MT6580. > > If you have CPU power domain support, and you power up and power down the > CPUs, why do you need the boot_lock and pen_release stuff? Isn't keeping > the power off on a CPU sufficient to prevent it entering the kernel? > Thanks Russell. Yes, the system works well after removing boot_lock and pen_release. Will be fixed in next version. Scott -- 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] Input: do not emit unneeded EV_SYN when suspending
Do not emit EV_SYN/SYN_REPORT on suspend if there were no keys that are
still pressed as we are suspending the device.
Signed-off-by: Dmitry Torokhov
---
drivers/input/input.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 78d2499..5391abd 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -674,13 +674,19 @@ EXPORT_SYMBOL(input_close_device);
*/
static void input_dev_release_keys(struct input_dev *dev)
{
+ bool need_sync = false;
int code;
if (is_event_supported(EV_KEY, dev->evbit, EV_MAX)) {
- for_each_set_bit(code, dev->key, KEY_CNT)
+ for_each_set_bit(code, dev->key, KEY_CNT) {
input_pass_event(dev, EV_KEY, code, 0);
+ need_sync = true;
+ }
+
+ if (need_sync)
+ input_pass_event(dev, EV_SYN, SYN_REPORT, 1);
+
memset(dev->key, 0, sizeof(dev->key));
- input_pass_event(dev, EV_SYN, SYN_REPORT, 1);
}
}
--
2.5.0.rc2.392.g76e840b
--
Dmitry
--
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: brcmstb: select ARCH_DMA_ADDR_T_64BIT for LPAE
Broadcom STB (BRCMSTB) has some 64-bit capable DMA and therefore needs dma_addr_t to be a 64-bit size. One user is the Broadcom SATA3 AHCI controller driver. Signed-off-by: Gregory Fong --- arch/arm/mach-bcm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig index 0ac9e4b3..833b2d5 100644 --- a/arch/arm/mach-bcm/Kconfig +++ b/arch/arm/mach-bcm/Kconfig @@ -144,6 +144,7 @@ config ARCH_BRCMSTB select BRCMSTB_GISB_ARB select BRCMSTB_L2_IRQ select BCM7120_L2_IRQ + select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE select ARCH_WANT_OPTIONAL_GPIOLIB help Say Y if you intend to run the kernel on a Broadcom ARM-based STB -- 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 v6 7/9] clk: mediatek: Add subsystem clocks of MT8173
Hi Sascha,
On Thu, 2015-08-06 at 12:20 +0200, Sascha Hauer wrote:
> On Thu, Aug 06, 2015 at 05:13:21PM +0800, Daniel Kurtz wrote:
> > On Thu, Aug 6, 2015 at 5:00 PM, James Liao
> > wrote:
> > > Hi Sascha,
> > >
> > > On Thu, 2015-08-06 at 10:53 +0200, Sascha Hauer wrote:
> > >> On Thu, Aug 06, 2015 at 04:23:51PM +0800, James Liao wrote:
> > >> > On Wed, 2015-08-05 at 08:46 +0200, Sascha Hauer wrote:
> > >> > > On Tue, Aug 04, 2015 at 04:16:56PM +0800, James Liao wrote:
> > >> > > > static const struct mtk_fixed_clk fixed_clks[] __initconst = {
> > >> > > > FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m",
> > >> > > > 400 * MHZ),
> > >> > > > FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m",
> > >> > > > "clk26m", 125 * MHZ),
> > >> > > > + FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 *
> > >> > > > MHZ),
> > >> > > > + FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 *
> > >> > > > MHZ),
> > >> > > > + FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5 *
> > >> > > > MHZ),
> > >> > > > + FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975
> > >> > > > * MHZ),
> > >> > >
> > >> > > I would expect 51975 * KHZ here to avoid fractional numbers. Probably
> > >> > > gcc calculates that during compile time so this will work as
> > >> > > expected,
> > >> > > still I'm not sure this is good style to use fractional numbers here.
> > >> >
> > >> > As I know all constants will be calculated in compile time, so there
> > >> > should be no difference between 51.975 * MHZ and 51975 * KHz.
> > >> >
> > >> > > Anyway, on my system lvdspll is running at 150MHz. Are you sure
> > >> > > there is
> > >> > > a clock derived from this running at 148.5MHz? Is it really correct
> > >> > > to
> > >> > > use a fixed clock here or should it rather be lvdspll directly?
> > >> >
> > >> > Here is the clock hierarchy between lvdspll and lvds_pxl:
> > >> >
> > >> > AD_VPLL_DPIX_CK lvds_pxl -
> > >> >||->||-->|
> > >> >|| | cksys | |
> > >> > LVDSPLL -->| LVDSTX | | buffer | | MMSYS
> > >> >|| AD_LVDSTX_CLKDIG_CTS | test | lvds_cts |
> > >> >||->||-->|
> > >> > -
> > >> >
> > >> > Some clocks and blocks are not modeled into CCF. But we prefer to
> > >> > enable
> > >> > lvdspll before enabling lvds_pxl. So I modeled lvds_pxl (and lvds_cts)
> > >> > as a fixed-rate clock with a source from lvdspll.
> > >> >
> > >> > The frequency of these fixed-rate clocks (such as 148.5 MHz) are
> > >> > typical
> > >> > rate. In fact, we don't care about the actual rate of these clocks. We
> > >> > just care about the enable / disable sequence of them.
> > >>
> > >> Please either use the real rate or 0 (along with a explaining why). Using
> > >> a frequency with four to five significant digits makes me think that the
> > >> actual rate is very important.
> > >
> > > Oops, your suggestion is much different from Daniel's.
> > >
> > > Daniel, could you help to comment about how we model these clocks?
> >
> > First of all, for clocks where the rate doesn't matter, it doesn't
> > matters to what rate we set the clock.
> >
> > As for the color of our shed, "the designer says these are the typical
> > rates" sounds good enough to me for a "real rate", so I prefer using
> > the rates in James' patch.
> >
> > If not sure what Sascha's concern is, but if he insists on 0, I'm fine
> > with that too.
>
> I only find it confusing. I'd expect either the correct rate or an
> obviously dummy rate. Whatever we choose a comment explaining the
> background would really help here. Otherwise we won't know later
> whether this 148.5 MHz rate was introduced because a) The consumers
> depend on this rate being reported, b) It really is the correct rate or
> c) we don't care about the rate.
So the proper setting should be:
clk_name, parent,rate
-
"clkph_mck_o", "clk26m", 0
"usb_syspll_125m", "clk26m", 125 * MHZ
"dsi0_dig","clk26m", 0
"dsi1_dig","clk26m", 0
"lvds_pxl","lvdspll", 0
"lvds_cts","lvdspll", 0
usb_syspll_125m will keep in 125 MHz event in different products.Others
may be changed by DRAM or display settings.
Daniel, do you think it's OK to model these clocks like above?
Best regards,
James
--
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/
[GIT] Sparc
Please pull to get this FPU register corruption bug fix. Thanks! The following changes since commit 4469942bbbe5ebf845e04971d8c74e9b6178f9fa: Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm (2015-08-05 18:50:38 +0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc for you to fetch changes up to 44922150d87cef616fd183220d43d8fde4d41390: sparc64: Fix userspace FPU register corruptions. (2015-08-06 19:13:25 -0700) David S. Miller (1): sparc64: Fix userspace FPU register corruptions. arch/sparc/include/asm/visasm.h | 16 +--- arch/sparc/lib/NG4memcpy.S | 5 - arch/sparc/lib/VISsave.S| 67 ++- arch/sparc/lib/ksyms.c | 4 4 files changed, 11 insertions(+), 81 deletions(-) -- 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 0/3] zram: Replace pr_* with dev_*
On (08/07/15 11:03), Sergey Senozhatsky wrote:
> [..]
> > because dmesg is not an ABI.
>
> I absolutely agree, this is debatable and controversial. I saw people
> grepping dmesg and they treated error messages just like errno codes or
> like additional info to attach to errno. Whether we like or not, but, it
> seems, for that cases error message is more or less part of ABI. It's
> fine when we change _info message, but touching _warn or _err message
> is a bit different thing, *I think*. Let's hear from Minchan.
>
A side note (not to forget).
If Minchan agress that messages are free come and go, then I'd probably
like to remove this one
meta->table = vzalloc(num_pages * sizeof(*meta->table));
if (!meta->table) {
pr_err("Error allocating zram address table\n");
^^
goto out_error;
}
because __vmalloc_node_range() will warn_alloc_failed() anyway.
-ss
--
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 V8 11/25] perf auxtrace: Fix period type 'i' not working
Em Fri, Jul 17, 2015 at 07:33:46PM +0300, Adrian Hunter escreveu:
> PERF_ITRACE_PERIOD_INSTRUCTIONS is zero so it
> got overwritten by the default period type.
> Fix by checking if the period type was set
> rather than if the value was zero when applying
> the default.
Applied
> Signed-off-by: Adrian Hunter
> ---
> tools/perf/util/auxtrace.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
> index 3f3b40fa87c8..4ec3acf6fabb 100644
> --- a/tools/perf/util/auxtrace.c
> +++ b/tools/perf/util/auxtrace.c
> @@ -949,6 +949,7 @@ int itrace_parse_synth_opts(const struct option *opt,
> const char *str,
> struct itrace_synth_opts *synth_opts = opt->value;
> const char *p;
> char *endptr;
> + bool period_type_set = false;
>
> synth_opts->set = true;
>
> @@ -977,10 +978,12 @@ int itrace_parse_synth_opts(const struct option *opt,
> const char *str,
> case 'i':
> synth_opts->period_type =
> PERF_ITRACE_PERIOD_INSTRUCTIONS;
> + period_type_set = true;
> break;
> case 't':
> synth_opts->period_type =
> PERF_ITRACE_PERIOD_TICKS;
> + period_type_set = true;
> break;
> case 'm':
> synth_opts->period *= 1000;
> @@ -993,6 +996,7 @@ int itrace_parse_synth_opts(const struct option *opt,
> const char *str,
> goto out_err;
> synth_opts->period_type =
> PERF_ITRACE_PERIOD_NANOSECS;
> + period_type_set = true;
> break;
> case '\0':
> goto out;
> @@ -1046,7 +1050,7 @@ int itrace_parse_synth_opts(const struct option *opt,
> const char *str,
> }
> out:
> if (synth_opts->instructions) {
> - if (!synth_opts->period_type)
> + if (!period_type_set)
> synth_opts->period_type =
> PERF_ITRACE_DEFAULT_PERIOD_TYPE;
> if (!synth_opts->period)
> --
> 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: tools/perf: Add empty Build files for architectures lacking them
Em Tue, Aug 04, 2015 at 05:10:27PM +0100, Ben Hutchings escreveu: > perf currently fails to build on MIPS as there is no > tools/perf/arch/mips/Build file. Adding an empty file fixes this as > there are no MIPS-specific sources to build. > > It looks like the same is needed for Alpha and PA-RISC, though I > haven't been able to test those. Thanks, applied. -- 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 v2] mm/slub: don't wait for high-order page allocation
Almost description is copied from commit fb05e7a89f50
("net: don't wait for order-3 page allocation").
I saw excessive direct memory reclaim/compaction triggered by slub.
This causes performance issues and add latency. Slub uses high-order
allocation to reduce internal fragmentation and management overhead. But,
direct memory reclaim/compaction has high overhead and the benefit of
high-order allocation can't compensate the overhead of both work.
This patch makes auxiliary high-order allocation atomic. If there is
no memory pressure and memory isn't fragmented, the alloction will still
success, so we don't sacrifice high-order allocation's benefit here.
If the atomic allocation fails, direct memory reclaim/compaction will not
be triggered, allocation fallback to low-order immediately, hence
the direct memory reclaim/compaction overhead is avoided. In the
allocation failure case, kswapd is waken up and trying to make high-order
freepages, so allocation could success next time.
Following is the test to measure effect of this patch.
System: QEMU, CPU 8, 512 MB
Mem: 25% memory is allocated at random position to make fragmentation.
Memory-hogger occupies 150 MB memory.
Workload: hackbench -g 20 -l 1000
Average result by 10 runs (Base va Patched)
elapsed_time(s): 4.3468 vs 2.9838
compact_stall: 461.7 vs 73.6
pgmigrate_success: 28315.9 vs 7256.1
Signed-off-by: Joonsoo Kim
---
mm/slub.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/slub.c b/mm/slub.c
index 257283f..52b9025 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1364,6 +1364,8 @@ static struct page *allocate_slab(struct kmem_cache *s,
gfp_t flags, int node)
* so we fall-back to the minimum order allocation.
*/
alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL;
+ if ((alloc_gfp & __GFP_WAIT) && oo_order(oo) > oo_order(s->min))
+ alloc_gfp = (alloc_gfp | __GFP_NOMEMALLOC) & ~__GFP_WAIT;
page = alloc_slab_page(s, alloc_gfp, node, oo);
if (unlikely(!page)) {
--
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 V8 12/25] perf tools: Fix perf-with-kcore handling of arguments containing spaces
Em Fri, Jul 17, 2015 at 07:33:47PM +0300, Adrian Hunter escreveu:
> Fix the perf-with-kcore script so that it doesn't
> split arguments that contain spaces.
Applied
> Signed-off-by: Adrian Hunter
> ---
> tools/perf/perf-with-kcore.sh | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/tools/perf/perf-with-kcore.sh b/tools/perf/perf-with-kcore.sh
> index c7ff90a90e4e..7e47a7cbc195 100644
> --- a/tools/perf/perf-with-kcore.sh
> +++ b/tools/perf/perf-with-kcore.sh
> @@ -50,7 +50,7 @@ copy_kcore()
> fi
>
> rm -f perf.data.junk
> - ("$PERF" record -o perf.data.junk $PERF_OPTIONS -- sleep 60) >/dev/null
> 2>/dev/null &
> + ("$PERF" record -o perf.data.junk "${PERF_OPTIONS[@]}" -- sleep 60)
> >/dev/null 2>/dev/null &
> PERF_PID=$!
>
> # Need to make sure that perf has started
> @@ -160,18 +160,18 @@ record()
> echo "*** WARNING *** /proc/sys/kernel/kptr_restrict
> prevents access to kernel addresses" >&2
> fi
>
> - if echo "$PERF_OPTIONS" | grep -q ' -a \|^-a \| -a$\|^-a$\|
> --all-cpus \|^--all-cpus \| --all-cpus$\|^--all-cpus$' ; then
> + if echo "${PERF_OPTIONS[@]}" | grep -q ' -a \|^-a \|
> -a$\|^-a$\| --all-cpus \|^--all-cpus \| --all-cpus$\|^--all-cpus$' ; then
> echo "*** WARNING *** system-wide tracing without root
> access will not be able to read all necessary information from /proc" >&2
> fi
>
> - if echo "$PERF_OPTIONS" | grep -q 'intel_pt\|intel_bts\|
> -I\|^-I' ; then
> + if echo "${PERF_OPTIONS[@]}" | grep -q 'intel_pt\|intel_bts\|
> -I\|^-I' ; then
> if [ "$(cat /proc/sys/kernel/perf_event_paranoid)" -gt
> -1 ] ; then
> echo "*** WARNING ***
> /proc/sys/kernel/perf_event_paranoid restricts buffer size and tracepoint
> (sched_switch) use" >&2
> fi
>
> - if echo "$PERF_OPTIONS" | grep -q ' --per-thread
> \|^--per-thread \| --per-thread$\|^--per-thread$' ; then
> + if echo "${PERF_OPTIONS[@]}" | grep -q ' --per-thread
> \|^--per-thread \| --per-thread$\|^--per-thread$' ; then
> true
> - elif echo "$PERF_OPTIONS" | grep -q ' -t \|^-t \|
> -t$\|^-t$' ; then
> + elif echo "${PERF_OPTIONS[@]}" | grep -q ' -t \|^-t \|
> -t$\|^-t$' ; then
> true
> elif [ ! -r /sys/kernel/debug -o ! -x /sys/kernel/debug
> ] ; then
> echo "*** WARNING *** /sys/kernel/debug
> permissions prevent tracepoint (sched_switch) use" >&2
> @@ -193,8 +193,8 @@ record()
>
> mkdir "$PERF_DATA_DIR"
>
> - echo "$PERF record -o $PERF_DATA_DIR/perf.data $PERF_OPTIONS -- $*"
> - "$PERF" record -o "$PERF_DATA_DIR/perf.data" $PERF_OPTIONS -- $* || true
> + echo "$PERF record -o $PERF_DATA_DIR/perf.data ${PERF_OPTIONS[@]} -- $@"
> + "$PERF" record -o "$PERF_DATA_DIR/perf.data" "${PERF_OPTIONS[@]}" --
> "$@" || true
>
> if rmdir "$PERF_DATA_DIR" > /dev/null 2>/dev/null ; then
> exit 1
> @@ -209,8 +209,8 @@ subcommand()
> {
> find_perf
> check_buildid_cache_permissions
> - echo "$PERF $PERF_SUB_COMMAND -i $PERF_DATA_DIR/perf.data
> --kallsyms=$PERF_DATA_DIR/kcore_dir/kallsyms $*"
> - "$PERF" $PERF_SUB_COMMAND -i "$PERF_DATA_DIR/perf.data"
> "--kallsyms=$PERF_DATA_DIR/kcore_dir/kallsyms" $*
> + echo "$PERF $PERF_SUB_COMMAND -i $PERF_DATA_DIR/perf.data
> --kallsyms=$PERF_DATA_DIR/kcore_dir/kallsyms $@"
> + "$PERF" $PERF_SUB_COMMAND -i "$PERF_DATA_DIR/perf.data"
> "--kallsyms=$PERF_DATA_DIR/kcore_dir/kallsyms" "$@"
> }
>
> if [ "$1" = "fix_buildid_cache_permissions" ] ; then
> @@ -234,7 +234,7 @@ fi
> case "$PERF_SUB_COMMAND" in
> "record")
> while [ "$1" != "--" ] ; do
> - PERF_OPTIONS+="$1 "
> + PERF_OPTIONS+=("$1")
> shift || break
> done
> if [ "$1" != "--" ] ; then
> @@ -242,16 +242,16 @@ case "$PERF_SUB_COMMAND" in
> usage
> fi
> shift
> - record $*
> + record "$@"
> ;;
> "script")
> - subcommand $*
> + subcommand "$@"
> ;;
> "report")
> - subcommand $*
> + subcommand "$@"
> ;;
> "inject")
> - subcommand $*
> + subcommand "$@"
> ;;
> *)
> usage
> --
> 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/
[PATCH 22/26] perf auxtrace: Fix period type 'i' not working
From: Adrian Hunter
PERF_ITRACE_PERIOD_INSTRUCTIONS is zero so it got overwritten by the
default period type.
Fix by checking if the period type was set rather than if the value was
zero when applying the default.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1437150840-31811-12-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/auxtrace.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index 83d9dd96fe08..a25b3609cef8 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -942,6 +942,7 @@ int itrace_parse_synth_opts(const struct option *opt, const
char *str,
struct itrace_synth_opts *synth_opts = opt->value;
const char *p;
char *endptr;
+ bool period_type_set = false;
synth_opts->set = true;
@@ -970,10 +971,12 @@ int itrace_parse_synth_opts(const struct option *opt,
const char *str,
case 'i':
synth_opts->period_type =
PERF_ITRACE_PERIOD_INSTRUCTIONS;
+ period_type_set = true;
break;
case 't':
synth_opts->period_type =
PERF_ITRACE_PERIOD_TICKS;
+ period_type_set = true;
break;
case 'm':
synth_opts->period *= 1000;
@@ -986,6 +989,7 @@ int itrace_parse_synth_opts(const struct option *opt, const
char *str,
goto out_err;
synth_opts->period_type =
PERF_ITRACE_PERIOD_NANOSECS;
+ period_type_set = true;
break;
case '\0':
goto out;
@@ -1039,7 +1043,7 @@ int itrace_parse_synth_opts(const struct option *opt,
const char *str,
}
out:
if (synth_opts->instructions) {
- if (!synth_opts->period_type)
+ if (!period_type_set)
synth_opts->period_type =
PERF_ITRACE_DEFAULT_PERIOD_TYPE;
if (!synth_opts->period)
--
2.1.0
--
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 V8 15/25] perf tools: Validate config term maximum value
Em Fri, Jul 17, 2015 at 07:33:50PM +0300, Adrian Hunter escreveu:
> Currently the value of a PMU config term is silently
> truncated if it is too big. This is an impediment to
> validating the value for other criteria later on i.e.
> the user provides an invalid value that gets truncated
> to a valid one.
Applied
> The maximum value validation is only done for the
> parser where the error is passed back to the user. In
> other cases the silent truncation continues so as not
> to affect tools that perhaps rely on it.
>
> Signed-off-by: Adrian Hunter
> ---
> tools/perf/util/pmu.c | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index d26ff0ab8410..29797fd9bedc 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c
> @@ -585,6 +585,18 @@ static void pmu_format_value(unsigned long *format,
> __u64 value, __u64 *v,
> }
> }
>
> +static __u64 pmu_format_max_value(const unsigned long *format)
> +{
> + int w;
> +
> + w = bitmap_weight(format, PERF_PMU_FORMAT_BITS);
> + if (!w)
> + return 0;
> + if (w < 64)
> + return (1ULL << w) - 1;
> + return -1;
> +}
> +
> /*
> * Term is a string term, and might be a param-term. Try to look up it's
> value
> * in the remaining terms.
> @@ -658,7 +670,7 @@ static int pmu_config_term(struct list_head *formats,
> {
> struct perf_pmu_format *format;
> __u64 *vp;
> - __u64 val;
> + __u64 val, max_val;
>
> /*
>* If this is a parameter we've already used for parameterized-eval,
> @@ -724,6 +736,22 @@ static int pmu_config_term(struct list_head *formats,
> } else
> return -EINVAL;
>
> + max_val = pmu_format_max_value(format->bits);
> + if (val > max_val) {
> + if (err) {
> + err->idx = term->err_val;
> + if (asprintf(>str,
> + "value too big for format, maximum is
> %llu",
> + (unsigned long long)max_val) < 0)
> + err->str = strdup("value too big for format");
> + return -EINVAL;
> + }
> + /*
> + * Assume we don't care if !err, in which case the value will be
> + * silently truncated.
> + */
> + }
> +
> pmu_format_value(format->bits, val, vp, zero);
> 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/
Re: [PATCH v2 07/13] xtensa: implement counting and sampling perf events
Em Sat, Jul 18, 2015 at 11:30:10AM +0300, Max Filippov escreveu:
> Xtensa Performance Monitor Module has up to 8 32 bit wide performance
> counters. Each counter may be enabled independently and can count any
> single type of hardware performance events. Event counting may be enabled
> and disabled globally (per PMM).
> Each counter has status register with bits indicating if the counter has
> been overflown and may be programmed to raise profiling IRQ on overflow.
> This IRQ is used to rewind counters and allow for counting more than 2^32
> samples for counting events and to report samples for sampling events.
>
> For more details see Tensilica Debug User's Guide, chapter 8
> "Performance monitor module".
Has this gone via PeterZ? I added the tools/ bits in my perf/core
branch, will go in next pull req,
- Arnaldo
> Cc: Peter Zijlstra
> Cc: Paul Mackerras
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Signed-off-by: Max Filippov
> ---
> Changes v1->v2:
> - use -EINVAL instead of -ENOENT for invalid PMU event configuratons.
>
> arch/xtensa/Kconfig | 10 +
> arch/xtensa/kernel/Makefile | 1 +
> arch/xtensa/kernel/perf_event.c | 450
>
> 3 files changed, 461 insertions(+)
> create mode 100644 arch/xtensa/kernel/perf_event.c
>
> diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
> index 3c57934..0e92885 100644
> --- a/arch/xtensa/Kconfig
> +++ b/arch/xtensa/Kconfig
> @@ -126,6 +126,16 @@ config XTENSA_VARIANT_MMU
> Build a Conventional Kernel with full MMU support,
> ie: it supports a TLB with auto-loading, page protection.
>
> +config XTENSA_VARIANT_HAVE_PERF_EVENTS
> + bool "Core variant has Performance Monitor Module"
> + depends on XTENSA_VARIANT_CUSTOM
> + default n
> + help
> + Enable if core variant has Performance Monitor Module with
> + External Registers Interface.
> +
> + If unsure, say N.
> +
> config XTENSA_UNALIGNED_USER
> bool "Unaligned memory access in use space"
> help
> diff --git a/arch/xtensa/kernel/Makefile b/arch/xtensa/kernel/Makefile
> index d3a0f0f..547a757 100644
> --- a/arch/xtensa/kernel/Makefile
> +++ b/arch/xtensa/kernel/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_PCI) += pci.o
> obj-$(CONFIG_MODULES) += xtensa_ksyms.o module.o
> obj-$(CONFIG_FUNCTION_TRACER) += mcount.o
> obj-$(CONFIG_SMP) += smp.o mxhead.o
> +obj-$(CONFIG_XTENSA_VARIANT_HAVE_PERF_EVENTS) += perf_event.o
>
> AFLAGS_head.o += -mtext-section-literals
>
> diff --git a/arch/xtensa/kernel/perf_event.c b/arch/xtensa/kernel/perf_event.c
> new file mode 100644
> index 000..b44df3c
> --- /dev/null
> +++ b/arch/xtensa/kernel/perf_event.c
> @@ -0,0 +1,450 @@
> +/*
> + * Xtensa Performance Monitor Module driver
> + * See Tensilica Debug User's Guide for PMU registers documentation.
> + *
> + * Copyright (C) 2015 Cadence Design Systems Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +/* Global control/status for all perf counters */
> +#define XTENSA_PMU_PMG 0x1000
> +/* Perf counter values */
> +#define XTENSA_PMU_PM(i) (0x1080 + (i) * 4)
> +/* Perf counter control registers */
> +#define XTENSA_PMU_PMCTRL(i) (0x1100 + (i) * 4)
> +/* Perf counter status registers */
> +#define XTENSA_PMU_PMSTAT(i) (0x1180 + (i) * 4)
> +
> +#define XTENSA_PMU_PMG_PMEN 0x1
> +
> +#define XTENSA_PMU_COUNTER_MASK 0xULL
> +#define XTENSA_PMU_COUNTER_MAX 0x7fff
> +
> +#define XTENSA_PMU_PMCTRL_INTEN 0x0001
> +#define XTENSA_PMU_PMCTRL_KRNLCNT0x0008
> +#define XTENSA_PMU_PMCTRL_TRACELEVEL 0x00f0
> +#define XTENSA_PMU_PMCTRL_SELECT_SHIFT 8
> +#define XTENSA_PMU_PMCTRL_SELECT 0x1f00
> +#define XTENSA_PMU_PMCTRL_MASK_SHIFT 16
> +#define XTENSA_PMU_PMCTRL_MASK 0x
> +
> +#define XTENSA_PMU_MASK(select, mask) \
> + (((select) << XTENSA_PMU_PMCTRL_SELECT_SHIFT) | \
> + ((mask) << XTENSA_PMU_PMCTRL_MASK_SHIFT) | \
> + XTENSA_PMU_PMCTRL_TRACELEVEL | \
> + XTENSA_PMU_PMCTRL_INTEN)
> +
> +#define XTENSA_PMU_PMSTAT_OVFL 0x0001
> +#define XTENSA_PMU_PMSTAT_INTASRT0x0010
> +
> +struct xtensa_pmu_events {
> + /* Array of events currently on this core */
> + struct perf_event *event[XCHAL_NUM_PERF_COUNTERS];
> + /* Bitmap of used hardware counters */
> + unsigned long used_mask[BITS_TO_LONGS(XCHAL_NUM_PERF_COUNTERS)];
> +};
> +static DEFINE_PER_CPU(struct xtensa_pmu_events, xtensa_pmu_events);
> +
> +static const u32 xtensa_hw_ctl[] = {
> + [PERF_COUNT_HW_CPU_CYCLES] = XTENSA_PMU_MASK(0,
Re: [PATCH V8 16/25] perf tools: Extend the event parser maximum error index
Em Fri, Jul 17, 2015 at 07:33:51PM +0300, Adrian Hunter escreveu: > Extend the event parser maximum error index from 10 > to 13. That allows PMU config terms of up to 10 > characters to display un-truncated in the error > message. Applied > Signed-off-by: Adrian Hunter > --- > tools/perf/util/parse-events.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c > index a71eeb279ed2..dbe43acb5fe0 100644 > --- a/tools/perf/util/parse-events.c > +++ b/tools/perf/util/parse-events.c > @@ -1105,7 +1105,7 @@ static void parse_events_print_error(struct > parse_events_error *err, >* Maximum error index indent, we will cut >* the event string if it's bigger. >*/ > - int max_err_idx = 10; > + int max_err_idx = 13; > > /* >* Let's be specific with the message when > -- > 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 RFC V8 3/4] perf,tools: per-event callgraph support
Em Wed, Aug 05, 2015 at 03:45:27PM +, Liang, Kan escreveu:
> > hum, calling parse_callchain_record_opt from evsel hurts the python code:
> >
> > 17: Try 'import perf' in python, checking link problems :
> > --- start ---
> > test child forked, pid 25751
> > Traceback (most recent call last):
> > File "", line 1, in
> > ImportError: python/perf.so: undefined symbol:
> > parse_callchain_record_opt test child finished with -1
> > end
> > Try 'import perf' in python, checking link problems: FAILED!
> >
> >
> > not sure if we can call it from some place else (I guess not), then we'd
> > need
> > to either put the util/callchain.c under python objects,
>
> We cannot only put the util/callchain.c under python objects, since
> there are too many dependency for callchain.c.
>
> > or somehow refine
> > needed parsing code..
>
> Could we just move the related code to util.c as below?
Looks sensible, can you resend this as a separate patch, plus the two
remaining ones? I.e. patch below is the first on this new series, then
this per event callchain selection one, then the 'perf test' patch.
The first two already are in tip.git
Thanks,
- Arnaldo
> ---
> diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> index 931cca8..773fe13 100644
> --- a/tools/perf/util/callchain.c
> +++ b/tools/perf/util/callchain.c
> @@ -25,96 +25,9 @@
>
> __thread struct callchain_cursor callchain_cursor;
>
> -#ifdef HAVE_DWARF_UNWIND_SUPPORT
> -static int get_stack_size(const char *str, unsigned long *_size)
> -{
> - char *endptr;
> - unsigned long size;
> - unsigned long max_size = round_down(USHRT_MAX, sizeof(u64));
> -
> - size = strtoul(str, , 0);
> -
> - do {
> - if (*endptr)
> - break;
> -
> - size = round_up(size, sizeof(u64));
> - if (!size || size > max_size)
> - break;
> -
> - *_size = size;
> - return 0;
> -
> - } while (0);
> -
> - pr_err("callchain: Incorrect stack dump size (max %ld): %s\n",
> -max_size, str);
> - return -1;
> -}
> -#endif /* HAVE_DWARF_UNWIND_SUPPORT */
> -
> int parse_callchain_record_opt(const char *arg, struct callchain_param
> *param)
> {
> - char *tok, *name, *saveptr = NULL;
> - char *buf;
> - int ret = -1;
> -
> - /* We need buffer that we know we can write to. */
> - buf = malloc(strlen(arg) + 1);
> - if (!buf)
> - return -ENOMEM;
> -
> - strcpy(buf, arg);
> -
> - tok = strtok_r((char *)buf, ",", );
> - name = tok ? : (char *)buf;
> -
> - do {
> - /* Framepointer style */
> - if (!strncmp(name, "fp", sizeof("fp"))) {
> - if (!strtok_r(NULL, ",", )) {
> - param->record_mode = CALLCHAIN_FP;
> - ret = 0;
> - } else
> - pr_err("callchain: No more arguments "
> -"needed for --call-graph fp\n");
> - break;
> -
> -#ifdef HAVE_DWARF_UNWIND_SUPPORT
> - /* Dwarf style */
> - } else if (!strncmp(name, "dwarf", sizeof("dwarf"))) {
> - const unsigned long default_stack_dump_size = 8192;
> -
> - ret = 0;
> - param->record_mode = CALLCHAIN_DWARF;
> - param->dump_size = default_stack_dump_size;
> -
> - tok = strtok_r(NULL, ",", );
> - if (tok) {
> - unsigned long size = 0;
> -
> - ret = get_stack_size(tok, );
> - param->dump_size = size;
> - }
> -#endif /* HAVE_DWARF_UNWIND_SUPPORT */
> - } else if (!strncmp(name, "lbr", sizeof("lbr"))) {
> - if (!strtok_r(NULL, ",", )) {
> - param->record_mode = CALLCHAIN_LBR;
> - ret = 0;
> - } else
> - pr_err("callchain: No more arguments "
> - "needed for --call-graph lbr\n");
> - break;
> - } else {
> - pr_err("callchain: Unknown --call-graph option "
> -"value: %s\n", arg);
> - break;
> - }
> -
> - } while (0);
> -
> - free(buf);
> - return ret;
> + return parse_callchain_record(arg, param);
> }
>
> static int parse_callchain_mode(const char *value)
> diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
> index 68a32c2..acee2b3 100644
> --- a/tools/perf/util/callchain.h
> +++ b/tools/perf/util/callchain.h
> @@ -177,6 +177,7 @@ int fill_callchain_info(struct addr_location *al, struct
> callchain_cursor_node *
> bool hide_unresolved);
>
>
Re: [RFC 00/47] perf stat: Add scripting support
Em Tue, Jul 21, 2015 at 02:31:20PM +0200, Jiri Olsa escreveu: > hi, > sending RFC on another attempt for stat scripting. > > The initial attempt defined its own formula lang and allowed > triggering user's script on the end of the stat command: > http://marc.info/?l=linux-kernel=136742146322273=2 > > This patchset abandons the idea of new formula language > and rather adds support to: > - store stat data into perf.data file > - add python support to process stat events Applied the first 11, some in a previous pull req, the ones moving stuff to perf_stat_config now, but the 12nd fails, please check when I get these merged by Ingo. Also do you intend to do some rework on this due to the conversation with Kan? The ones I merged are good anyway, merged. Thanks, - Arnaldo -- 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: perf eBPF patch ordering. was: Re: perf test LLVM was: Re: [GIT PULL 00/39] perf tools: filtering events using eBPF programs
Em Thu, Aug 06, 2015 at 11:46:52AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Aug 06, 2015 at 09:44:33AM +0800, Wangnan (F) escreveu: > > Have you tried 'perf test BPF'? Is that okay on your environment? > Freshly checked out from your github repo, 'ebpf' branch, looks good, see > output below, back to reading patches... I have replaced the contents of my perf/ebpf branch with what I have so far read/edited-changelog-comments/compile-tested/tested-to-some-degree, will continue. https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/log/?h=perf/ebpf - Arnaldo -- 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 03/26] tracing, perf: Implement BPF programs attached to uprobes
From: Wang Nan
By copying BPF related operation to uprobe processing path, this patch
allow users attach BPF programs to uprobes like what they are already
doing on kprobes.
After this patch, users are allowed to use PERF_EVENT_IOC_SET_BPF on a
uprobe perf event. Which make it possible to profile user space programs
and kernel events together using BPF.
Because of this patch, CONFIG_BPF_EVENTS should be selected by
CONFIG_UPROBE_EVENT to ensure trace_call_bpf() is compiled even if
KPROBE_EVENT is not set.
Signed-off-by: Wang Nan
Acked-by: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1435716878-189507-3-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
include/linux/trace_events.h | 5 +
kernel/events/core.c | 4 ++--
kernel/trace/Kconfig | 2 +-
kernel/trace/trace_uprobe.c | 5 +
4 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 180dbf8720f9..ed27917cabc9 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -243,6 +243,7 @@ enum {
TRACE_EVENT_FL_USE_CALL_FILTER_BIT,
TRACE_EVENT_FL_TRACEPOINT_BIT,
TRACE_EVENT_FL_KPROBE_BIT,
+ TRACE_EVENT_FL_UPROBE_BIT,
};
/*
@@ -257,6 +258,7 @@ enum {
* USE_CALL_FILTER - For trace internal events, don't use file filter
* TRACEPOINT- Event is a tracepoint
* KPROBE- Event is a kprobe
+ * UPROBE- Event is a uprobe
*/
enum {
TRACE_EVENT_FL_FILTERED = (1 << TRACE_EVENT_FL_FILTERED_BIT),
@@ -267,8 +269,11 @@ enum {
TRACE_EVENT_FL_USE_CALL_FILTER = (1 <<
TRACE_EVENT_FL_USE_CALL_FILTER_BIT),
TRACE_EVENT_FL_TRACEPOINT = (1 << TRACE_EVENT_FL_TRACEPOINT_BIT),
TRACE_EVENT_FL_KPROBE = (1 << TRACE_EVENT_FL_KPROBE_BIT),
+ TRACE_EVENT_FL_UPROBE = (1 << TRACE_EVENT_FL_UPROBE_BIT),
};
+#define TRACE_EVENT_FL_UKPROBE (TRACE_EVENT_FL_KPROBE | TRACE_EVENT_FL_UPROBE)
+
struct trace_event_call {
struct list_headlist;
struct trace_event_class *class;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index bdea12924b11..77f9e5d0e2d1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6846,8 +6846,8 @@ static int perf_event_set_bpf_prog(struct perf_event
*event, u32 prog_fd)
if (event->tp_event->prog)
return -EEXIST;
- if (!(event->tp_event->flags & TRACE_EVENT_FL_KPROBE))
- /* bpf programs can only be attached to kprobes */
+ if (!(event->tp_event->flags & TRACE_EVENT_FL_UKPROBE))
+ /* bpf programs can only be attached to u/kprobes */
return -EINVAL;
prog = bpf_prog_get(prog_fd);
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 3b9a48ae153a..1153c43428f3 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -434,7 +434,7 @@ config UPROBE_EVENT
config BPF_EVENTS
depends on BPF_SYSCALL
- depends on KPROBE_EVENT
+ depends on KPROBE_EVENT || UPROBE_EVENT
bool
default y
help
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index aa1ea7b36fa8..f97479f1ce35 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -1095,11 +1095,15 @@ static void __uprobe_perf_func(struct trace_uprobe *tu,
{
struct trace_event_call *call = >tp.call;
struct uprobe_trace_entry_head *entry;
+ struct bpf_prog *prog = call->prog;
struct hlist_head *head;
void *data;
int size, esize;
int rctx;
+ if (prog && !trace_call_bpf(prog, regs))
+ return;
+
esize = SIZEOF_TRACE_ENTRY(is_ret_probe(tu));
size = esize + tu->tp.size + dsize;
@@ -1289,6 +1293,7 @@ static int register_uprobe_event(struct trace_uprobe *tu)
return -ENODEV;
}
+ call->flags = TRACE_EVENT_FL_UPROBE;
call->class->reg = trace_uprobe_register;
call->data = tu;
ret = trace_add_event_call(call);
--
2.1.0
--
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 04/26] perf tools: Introduce veprintf
From: Wang Nan
va_args alternative to eprintf().
Signed-off-by: Wang Nan
Acked-by: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/n/1436445342-1402-19-git-send-email-wangn...@huawei.com
[ split from another patch ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/debug.c | 5 +
tools/perf/util/debug.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index 2da5581ec74d..86d9c7302598 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -36,6 +36,11 @@ static int _eprintf(int level, int var, const char *fmt,
va_list args)
return ret;
}
+int veprintf(int level, int var, const char *fmt, va_list args)
+{
+ return _eprintf(level, var, fmt, args);
+}
+
int eprintf(int level, int var, const char *fmt, ...)
{
va_list args;
diff --git a/tools/perf/util/debug.h b/tools/perf/util/debug.h
index caac2fdc6105..8b9a088c32ab 100644
--- a/tools/perf/util/debug.h
+++ b/tools/perf/util/debug.h
@@ -50,6 +50,7 @@ void pr_stat(const char *fmt, ...);
int eprintf(int level, int var, const char *fmt, ...)
__attribute__((format(printf, 3, 4)));
int eprintf_time(int level, int var, u64 t, const char *fmt, ...)
__attribute__((format(printf, 4, 5)));
+int veprintf(int level, int var, const char *fmt, va_list args);
int perf_debug_option(const char *str);
--
2.1.0
--
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 15/26] perf report: Add infrastructure for a cycles histogram
From: Andi Kleen
This adds the basic infrastructure to keep track of cycle counts per
basic block for annotate. We allocate an array similar to the normal
accounting, and then account branch cycles there.
We handle two cases:
cycles per basic block with start and cycles per branch (these are later
used for either IPC or just cycles per BB)
In the start case we cannot handle overlaps, so always the longest basic
block wins.
For the cycles per branch case everything is accurately accounted.
v2: Remove unnecessary checks. Slight restructure. Move
symbol__get_annotation to another patch. Move histogram allocation.
v3: Merged with current tree
Signed-off-by: Andi Kleen
Acked-by: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1437233094-12844-4-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-annotate.c | 1 +
tools/perf/util/annotate.c| 127 +-
tools/perf/util/annotate.h| 17 ++
3 files changed, 142 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 2c1bec39c30e..467a23b14e2f 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -187,6 +187,7 @@ find_next:
* symbol, free he->ms.sym->src to signal we already
* processed this symbol.
*/
+ zfree(>src->cycles_hist);
zfree(>src);
}
}
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 03b7bc70eb66..e0b614648044 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -473,17 +473,73 @@ int symbol__alloc_hist(struct symbol *sym)
return 0;
}
+/* The cycles histogram is lazily allocated. */
+static int symbol__alloc_hist_cycles(struct symbol *sym)
+{
+ struct annotation *notes = symbol__annotation(sym);
+ const size_t size = symbol__size(sym);
+
+ notes->src->cycles_hist = calloc(size, sizeof(struct cyc_hist));
+ if (notes->src->cycles_hist == NULL)
+ return -1;
+ return 0;
+}
+
void symbol__annotate_zero_histograms(struct symbol *sym)
{
struct annotation *notes = symbol__annotation(sym);
pthread_mutex_lock(>lock);
- if (notes->src != NULL)
+ if (notes->src != NULL) {
memset(notes->src->histograms, 0,
notes->src->nr_histograms * notes->src->sizeof_sym_hist);
+ if (notes->src->cycles_hist)
+ memset(notes->src->cycles_hist, 0,
+ symbol__size(sym) * sizeof(struct cyc_hist));
+ }
pthread_mutex_unlock(>lock);
}
+static int __symbol__account_cycles(struct annotation *notes,
+ u64 start,
+ unsigned offset, unsigned cycles,
+ unsigned have_start)
+{
+ struct cyc_hist *ch;
+
+ ch = notes->src->cycles_hist;
+ /*
+* For now we can only account one basic block per
+* final jump. But multiple could be overlapping.
+* Always account the longest one. So when
+* a shorter one has been already seen throw it away.
+*
+* We separately always account the full cycles.
+*/
+ ch[offset].num_aggr++;
+ ch[offset].cycles_aggr += cycles;
+
+ if (!have_start && ch[offset].have_start)
+ return 0;
+ if (ch[offset].num) {
+ if (have_start && (!ch[offset].have_start ||
+ ch[offset].start > start)) {
+ ch[offset].have_start = 0;
+ ch[offset].cycles = 0;
+ ch[offset].num = 0;
+ if (ch[offset].reset < 0x)
+ ch[offset].reset++;
+ } else if (have_start &&
+ ch[offset].start < start)
+ return 0;
+ }
+ ch[offset].have_start = have_start;
+ ch[offset].start = start;
+ ch[offset].cycles += cycles;
+ ch[offset].num++;
+ return 0;
+}
+
static int __symbol__inc_addr_samples(struct symbol *sym, struct map *map,
struct annotation *notes, int evidx, u64
addr)
{
@@ -506,7 +562,7 @@ static int __symbol__inc_addr_samples(struct symbol *sym,
struct map *map,
return 0;
}
-static struct annotation *symbol__get_annotation(struct symbol *sym)
+static struct annotation *symbol__get_annotation(struct symbol *sym, bool
cycles)
{
struct annotation *notes = symbol__annotation(sym);
@@ -514,6 +570,10 @@ static struct annotation *symbol__get_annotation(struct
symbol *sym)
if (symbol__alloc_hist(sym) < 0)
return NULL;
}
+ if
[PATCH 16/26] perf report: Add processing for cycle histograms
From: Andi Kleen
Call the earlier added cycle histogram infrastructure from the perf
report hist iter callback. For this we walk the branch records.
This allows to use cycle histograms when browsing perf report annotate.
v2: Rename flag
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1437233094-12844-5-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 3 +++
tools/perf/util/hist.c | 33 +
tools/perf/util/hist.h | 3 +++
3 files changed, 39 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 3ba0e9737dc5..3a9d1b659fcd 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -103,6 +103,9 @@ static int hist_iter__report_callback(struct
hist_entry_iter *iter,
if (!ui__has_annotation())
return 0;
+ hist__account_cycles(iter->sample->branch_stack, al, iter->sample,
+rep->nonany_branch_mode);
+
if (sort__mode == SORT_MODE__BRANCH) {
bi = he->branch_info;
err = addr_map_symbol__inc_samples(>from, evsel->idx);
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 54fc0033dd6a..a6e9ddd37913 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -1415,6 +1415,39 @@ int hists__link(struct hists *leader, struct hists
*other)
return 0;
}
+void hist__account_cycles(struct branch_stack *bs, struct addr_location *al,
+ struct perf_sample *sample, bool nonany_branch_mode)
+{
+ struct branch_info *bi;
+
+ /* If we have branch cycles always annotate them. */
+ if (bs && bs->nr && bs->entries[0].flags.cycles) {
+ int i;
+
+ bi = sample__resolve_bstack(sample, al);
+ if (bi) {
+ struct addr_map_symbol *prev = NULL;
+
+ /*
+* Ignore errors, still want to process the
+* other entries.
+*
+* For non standard branch modes always
+* force no IPC (prev == NULL)
+*
+* Note that perf stores branches reversed from
+* program order!
+*/
+ for (i = bs->nr - 1; i >= 0; i--) {
+ addr_map_symbol__account_cycles([i].from,
+ nonany_branch_mode ? NULL : prev,
+ bi[i].flags.cycles);
+ prev = [i].to;
+ }
+ free(bi);
+ }
+ }
+}
size_t perf_evlist__fprintf_nr_events(struct perf_evlist *evlist, FILE *fp)
{
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 3881d9815309..e2f712f85d2e 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -350,6 +350,9 @@ static inline int script_browse(const char *script_opt
__maybe_unused)
unsigned int hists__sort_list_width(struct hists *hists);
+void hist__account_cycles(struct branch_stack *bs, struct addr_location *al,
+ struct perf_sample *sample, bool nonany_branch_mode);
+
struct option;
int parse_filter_percentage(const struct option *opt __maybe_unused,
const char *arg, int unset __maybe_unused);
--
2.1.0
--
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 07/26] perf stat: Move 'scale' into struct perf_stat_config
From: Jiri Olsa
Moving 'scale' into struct perf_stat_config. The point is to centralize
the base stat config so it could be used localy together with other stat
routines in other parts of perf code.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1437481927-29538-4-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 12 ++--
tools/perf/util/stat.h| 1 +
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index bafb830b1bd9..3fb2865e519a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -101,7 +101,6 @@ static struct target target = {
static int run_count = 1;
static boolno_inherit = false;
-static boolscale = true;
static volatile pid_t child_pid = -1;
static boolnull_run= false;
static int detailed_run= 0;
@@ -127,6 +126,7 @@ static volatile int done = 0;
static struct perf_stat_config stat_config = {
.aggr_mode = AGGR_GLOBAL,
+ .scale = true,
};
static inline void diff_timespec(struct timespec *r, struct timespec *a,
@@ -151,7 +151,7 @@ static int create_perf_stat_counter(struct perf_evsel
*evsel)
{
struct perf_event_attr *attr = >attr;
- if (scale)
+ if (stat_config.scale)
attr->read_format = PERF_FORMAT_TOTAL_TIME_ENABLED |
PERF_FORMAT_TOTAL_TIME_RUNNING;
@@ -240,13 +240,13 @@ process_counter_values(struct perf_evsel *evsel, int cpu,
int thread,
case AGGR_NONE:
if (!evsel->snapshot)
perf_evsel__compute_deltas(evsel, cpu, thread, count);
- perf_counts_values__scale(count, scale, NULL);
+ perf_counts_values__scale(count, stat_config.scale, NULL);
if (stat_config.aggr_mode == AGGR_NONE)
perf_stat__update_shadow_stats(evsel, count->values,
cpu);
break;
case AGGR_GLOBAL:
aggr->val += count->val;
- if (scale) {
+ if (stat_config.scale) {
aggr->ena += count->ena;
aggr->run += count->run;
}
@@ -299,7 +299,7 @@ static int process_counter(struct perf_evsel *counter)
if (!counter->snapshot)
perf_evsel__compute_deltas(counter, -1, -1, aggr);
- perf_counts_values__scale(aggr, scale, >counts->scaled);
+ perf_counts_values__scale(aggr, stat_config.scale,
>counts->scaled);
for (i = 0; i < 3; i++)
update_stats(>res_stats[i], count[i]);
@@ -1274,7 +1274,7 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
"system-wide collection from all CPUs"),
OPT_BOOLEAN('g', "group", ,
"put the counters into a counter group"),
- OPT_BOOLEAN('c', "scale", , "scale/normalize counters"),
+ OPT_BOOLEAN('c', "scale", _config.scale, "scale/normalize
counters"),
OPT_INCR('v', "verbose", ,
"be more verbose (show counter open errors, etc)"),
OPT_INTEGER('r', "repeat", _count,
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index 078bee49ccad..0a1d83faa7b9 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -52,6 +52,7 @@ struct perf_counts {
struct perf_stat_config {
enum aggr_mode aggr_mode;
+ boolscale;
};
static inline struct perf_counts_values*
--
2.1.0
--
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 TRIVIAL] README: GTK+ is a acronym
I should have referred to this as an initialism, not acronym. Diego On Wed, Jul 22, 2015 at 8:37 AM, Diego Viola wrote: > Thanks :-) > > Diego > > On Wed, Jul 22, 2015 at 3:38 AM, Jonathan Corbet wrote: >> On Tue, 21 Jul 2015 12:19:17 -0300 >> Diego Viola wrote: >> >>> When will my patch get merged with the Linus tree? >> >> It's in the general queue, so it will find its way in during the 4.3 >> merge window. >> >> Thanks, >> >> jon -- 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 01/26] perf trace: Add total time column to summary.
From: Milian Wolff
It is cumbersome to manually calculate the total time spent in a given
syscall by multiplying the average value with the number of calls.
Instead, we now do this directly inside perf trace.
Note that this is also done by 'strace', which even adds a column with
relative numbers - something we could do in the future.
Example:
perf trace -s find /some/folder > /dev/null
Summary of events:
find (19976), 700123 events, 100.0%, 0.000 msec
syscallcallstotal min avg max stddev
(msec)(msec)(msec)(msec)(%)
--- - - - - --
read 4 0.006 0.001 0.002 0.003 27.42%
write 8046 9.617 0.001 0.001 0.035 0.56%
open 3419640.384 0.001 0.001 0.071 0.30%
close 6837557.104 0.001 0.001 0.076 0.25%
stat 4 0.004 0.001 0.001 0.001 3.14%
fstat 3418927.518 0.001 0.001 0.060 0.34%
mmap 13 0.029 0.001 0.002 0.003 10.74%
mprotect 6 0.018 0.002 0.003 0.005 17.04%
munmap 3 0.014 0.003 0.005 0.006 24.87%
brk 87 0.490 0.001 0.006 0.016 6.50%
ioctl 3 0.004 0.001 0.001 0.003 36.39%
access 1 0.004 0.004 0.004 0.004 0.00%
uname 1 0.001 0.001 0.001 0.001 0.00%
getdents 68393 143.600 0.001 0.002 0.187 0.95%
fchdir 6837156.980 0.001 0.001 0.111 0.39%
arch_prctl 1 0.001 0.001 0.001 0.001 0.00%
openat 3418441.737 0.001 0.001 0.102 0.41%
newfstatat 3418441.180 0.001 0.001 0.064 0.34%
Signed-off-by: Milian Wolff
Tested-by: Arnaldo Carvalho de Melo
LPU-Reference: 1438853069-5902-1-git-send-email-milian.wo...@kdab.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-trace.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index a47497011c93..a25048c85b76 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2773,9 +2773,9 @@ static size_t thread__dump_stats(struct thread_trace
*ttrace,
printed += fprintf(fp, "\n");
- printed += fprintf(fp, " syscallcalls min avg
max stddev\n");
- printed += fprintf(fp, " (msec)(msec)
(msec)(%%)\n");
- printed += fprintf(fp, " --- - -
- --\n");
+ printed += fprintf(fp, " syscallcallstotal min
avg max stddev\n");
+ printed += fprintf(fp, " (msec)(msec)
(msec)(msec)(%%)\n");
+ printed += fprintf(fp, " --- - -
- - --\n");
/* each int_node is a syscall */
while (inode) {
@@ -2792,8 +2792,8 @@ static size_t thread__dump_stats(struct thread_trace
*ttrace,
sc = >syscalls.table[inode->i];
printed += fprintf(fp, " %-15s", sc->name);
- printed += fprintf(fp, " %8" PRIu64 " %9.3f %9.3f",
- n, min, avg);
+ printed += fprintf(fp, " %8" PRIu64 " %9.3f %9.3f
%9.3f",
+ n, avg * n, min, avg);
printed += fprintf(fp, " %9.3f %9.2f%%\n", max, pct);
}
--
2.1.0
--
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 11/26] perf stat: Move counter processing code into stat object
From: Jiri Olsa
Moving counter processing code into stat object as
perf_stat__process_counter.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1437481927-29538-8-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 141 +-
tools/perf/util/stat.c| 139 +
tools/perf/util/stat.h| 3 +
3 files changed, 143 insertions(+), 140 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 5a781718c09f..a054ddc0b2a0 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -179,145 +179,6 @@ static inline int nsec_counter(struct perf_evsel *evsel)
return 0;
}
-static void zero_per_pkg(struct perf_evsel *counter)
-{
- if (counter->per_pkg_mask)
- memset(counter->per_pkg_mask, 0, MAX_NR_CPUS);
-}
-
-static int check_per_pkg(struct perf_evsel *counter, int cpu, bool *skip)
-{
- unsigned long *mask = counter->per_pkg_mask;
- struct cpu_map *cpus = perf_evsel__cpus(counter);
- int s;
-
- *skip = false;
-
- if (!counter->per_pkg)
- return 0;
-
- if (cpu_map__empty(cpus))
- return 0;
-
- if (!mask) {
- mask = zalloc(MAX_NR_CPUS);
- if (!mask)
- return -ENOMEM;
-
- counter->per_pkg_mask = mask;
- }
-
- s = cpu_map__get_socket(cpus, cpu);
- if (s < 0)
- return -1;
-
- *skip = test_and_set_bit(s, mask) == 1;
- return 0;
-}
-
-static int
-process_counter_values(struct perf_stat_config *config, struct perf_evsel
*evsel,
- int cpu, int thread,
- struct perf_counts_values *count)
-{
- struct perf_counts_values *aggr = >counts->aggr;
- static struct perf_counts_values zero;
- bool skip = false;
-
- if (check_per_pkg(evsel, cpu, )) {
- pr_err("failed to read per-pkg counter\n");
- return -1;
- }
-
- if (skip)
- count =
-
- switch (config->aggr_mode) {
- case AGGR_THREAD:
- case AGGR_CORE:
- case AGGR_SOCKET:
- case AGGR_NONE:
- if (!evsel->snapshot)
- perf_evsel__compute_deltas(evsel, cpu, thread, count);
- perf_counts_values__scale(count, config->scale, NULL);
- if (config->aggr_mode == AGGR_NONE)
- perf_stat__update_shadow_stats(evsel, count->values,
cpu);
- break;
- case AGGR_GLOBAL:
- aggr->val += count->val;
- if (config->scale) {
- aggr->ena += count->ena;
- aggr->run += count->run;
- }
- default:
- break;
- }
-
- return 0;
-}
-
-static int process_counter_maps(struct perf_stat_config *config,
- struct perf_evsel *counter)
-{
- int nthreads = thread_map__nr(counter->threads);
- int ncpus = perf_evsel__nr_cpus(counter);
- int cpu, thread;
-
- if (counter->system_wide)
- nthreads = 1;
-
- for (thread = 0; thread < nthreads; thread++) {
- for (cpu = 0; cpu < ncpus; cpu++) {
- if (process_counter_values(config, counter, cpu, thread,
- perf_counts(counter->counts,
cpu, thread)))
- return -1;
- }
- }
-
- return 0;
-}
-
-static int process_counter(struct perf_stat_config *config,
- struct perf_evsel *counter)
-{
- struct perf_counts_values *aggr = >counts->aggr;
- struct perf_stat *ps = counter->priv;
- u64 *count = counter->counts->aggr.values;
- int i, ret;
-
- aggr->val = aggr->ena = aggr->run = 0;
- init_stats(ps->res_stats);
-
- if (counter->per_pkg)
- zero_per_pkg(counter);
-
- ret = process_counter_maps(_config, counter);
- if (ret)
- return ret;
-
- if (config->aggr_mode != AGGR_GLOBAL)
- return 0;
-
- if (!counter->snapshot)
- perf_evsel__compute_deltas(counter, -1, -1, aggr);
- perf_counts_values__scale(aggr, config->scale,
>counts->scaled);
-
- for (i = 0; i < 3; i++)
- update_stats(>res_stats[i], count[i]);
-
- if (verbose) {
- fprintf(config->output, "%s: %" PRIu64 " %" PRIu64 " %" PRIu64
"\n",
- perf_evsel__name(counter), count[0], count[1],
count[2]);
- }
-
- /*
-* Save the full runtime - to allow normalization during printout:
-*/
- perf_stat__update_shadow_stats(counter, count, 0);
-
- return 0;
-}
-
/*
* Read out
[PATCH 26/26] perf tools: Extend the event parser maximum error index
From: Adrian Hunter Extend the event parser maximum error index from 10 to 13. That allows PMU config terms of up to 10 characters to display un-truncated in the error message. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1437150840-31811-17-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/parse-events.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c index a6cb9afc20e2..828936dc3f1e 100644 --- a/tools/perf/util/parse-events.c +++ b/tools/perf/util/parse-events.c @@ -1168,7 +1168,7 @@ static void parse_events_print_error(struct parse_events_error *err, * Maximum error index indent, we will cut * the event string if it's bigger. */ - int max_err_idx = 10; + int max_err_idx = 13; /* * Let's be specific with the message when -- 2.1.0 -- 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 14/26] perf report: Add flag for non ANY branch mode
From: Andi Kleen
Later patches need to cheaply check that the branch mode is in ANY. Add
a new function to check all event attrs and add a flag to the report
state, which is then initialized.
v2: Rename flag
Signed-off-by: Andi Kleen
Acked-by: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1437233094-12844-3-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 7 +++
tools/perf/util/evlist.c| 10 ++
tools/perf/util/evlist.h| 1 +
3 files changed, 18 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 95a47719aec3..3ba0e9737dc5 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -53,6 +53,7 @@ struct report {
boolmem_mode;
boolheader;
boolheader_only;
+ boolnonany_branch_mode;
int max_stack;
struct perf_read_values show_threads_values;
const char *pretty_printing_style;
@@ -258,6 +259,12 @@ static int report__setup_sample_type(struct report *rep)
else
callchain_param.record_mode = CALLCHAIN_FP;
}
+
+ /* ??? handle more cases than just ANY? */
+ if (!(perf_evlist__combined_branch_type(session->evlist) &
+ PERF_SAMPLE_BRANCH_ANY))
+ rep->nonany_branch_mode = true;
+
return 0;
}
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 3b9f411a6b46..373f65b02545 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1273,6 +1273,16 @@ u64 perf_evlist__combined_sample_type(struct perf_evlist
*evlist)
return __perf_evlist__combined_sample_type(evlist);
}
+u64 perf_evlist__combined_branch_type(struct perf_evlist *evlist)
+{
+ struct perf_evsel *evsel;
+ u64 branch_type = 0;
+
+ evlist__for_each(evlist, evsel)
+ branch_type |= evsel->attr.branch_sample_type;
+ return branch_type;
+}
+
bool perf_evlist__valid_read_format(struct perf_evlist *evlist)
{
struct perf_evsel *first = perf_evlist__first(evlist), *pos = first;
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index a8930b68456b..397757063da1 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -165,6 +165,7 @@ void perf_evlist__set_leader(struct perf_evlist *evlist);
u64 perf_evlist__read_format(struct perf_evlist *evlist);
u64 __perf_evlist__combined_sample_type(struct perf_evlist *evlist);
u64 perf_evlist__combined_sample_type(struct perf_evlist *evlist);
+u64 perf_evlist__combined_branch_type(struct perf_evlist *evlist);
bool perf_evlist__sample_id_all(struct perf_evlist *evlist);
u16 perf_evlist__id_hdr_size(struct perf_evlist *evlist);
--
2.1.0
--
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 19/26] perf top: Add branch annotation code to top
From: Andi Kleen
Now that we can process branch data in annotate it makes sense to
support enabling branch recording from top too. Most of the code needed
for this is already in shared code with report. But we need to add:
- The option parsing code (using shared code from the previous patch)
- Document the options
- Set up the IPC/cycles accounting state in the top session
- Call the accounting code in the hist iter callback
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1437233094-12844-8-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-top.txt | 21 +
tools/perf/builtin-top.c | 9 +
2 files changed, 30 insertions(+)
diff --git a/tools/perf/Documentation/perf-top.txt
b/tools/perf/Documentation/perf-top.txt
index 776aec4d0927..f6a23eb294e7 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -208,6 +208,27 @@ Default is to monitor all CPUS.
This option sets the time out limit. The default value is 500 ms.
+-b::
+--branch-any::
+ Enable taken branch stack sampling. Any type of taken branch may be
sampled.
+ This is a shortcut for --branch-filter any. See --branch-filter for
more infos.
+
+-j::
+--branch-filter::
+ Enable taken branch stack sampling. Each sample captures a series of
consecutive
+ taken branches. The number of branches captured with each sample
depends on the
+ underlying hardware, the type of branches of interest, and the executed
code.
+ It is possible to select the types of branches captured by enabling
filters.
+ For a full list of modifiers please see the perf record manpage.
+
+ The option requires at least one branch type among any, any_call,
any_ret, ind_call, cond.
+ The privilege levels may be omitted, in which case, the privilege
levels of the associated
+ event are applied to the branch filter. Both kernel (k) and hypervisor
(hv) privilege
+ levels are subject to permissions. When sampling on multiple events,
branch stack sampling
+ is enabled for all the sampling events. The sampled branch type is the
same for all events.
+ The various filters must be specified as a comma separated list:
--branch-filter any_ret,u,k
+ Note that this feature may not be available on all processors.
+
INTERACTIVE PROMPTING KEYS
--
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index ecf319728f25..bfe24f1e362f 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -40,6 +40,7 @@
#include "util/xyarray.h"
#include "util/sort.h"
#include "util/intlist.h"
+#include "util/parse-branch-options.h"
#include "arch/common.h"
#include "util/debug.h"
@@ -695,6 +696,8 @@ static int hist_iter__top_callback(struct hist_entry_iter
*iter,
perf_top__record_precise_ip(top, he, evsel->idx, ip);
}
+ hist__account_cycles(iter->sample->branch_stack, al, iter->sample,
+!(top->record_opts.branch_stack & PERF_SAMPLE_BRANCH_ANY));
return 0;
}
@@ -1171,6 +1174,12 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
"don't try to adjust column width, use these fixed values"),
OPT_UINTEGER(0, "proc-map-timeout", >proc_map_timeout,
"per thread proc mmap processing timeout in ms"),
+ OPT_CALLBACK_NOOPT('b', "branch-any", >branch_stack,
+"branch any", "sample any taken branches",
+parse_branch_stack),
+ OPT_CALLBACK('j', "branch-filter", >branch_stack,
+"branch filter mask", "branch stack filter modes",
+parse_branch_stack),
OPT_END()
};
const char * const top_usage[] = {
--
2.1.0
--
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 10/26] perf stat: Pass 'struct perf_stat_config' into process_counter()
From: Jiri Olsa
Passing 'struct perf_stat_config' into process_counter(), so that we can
make process_counter() non static and use it from other places.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1437481927-29538-7-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 1bdfec8f5fe6..5a781718c09f 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -216,7 +216,8 @@ static int check_per_pkg(struct perf_evsel *counter, int
cpu, bool *skip)
}
static int
-process_counter_values(struct perf_evsel *evsel, int cpu, int thread,
+process_counter_values(struct perf_stat_config *config, struct perf_evsel
*evsel,
+ int cpu, int thread,
struct perf_counts_values *count)
{
struct perf_counts_values *aggr = >counts->aggr;
@@ -231,20 +232,20 @@ process_counter_values(struct perf_evsel *evsel, int cpu,
int thread,
if (skip)
count =
- switch (stat_config.aggr_mode) {
+ switch (config->aggr_mode) {
case AGGR_THREAD:
case AGGR_CORE:
case AGGR_SOCKET:
case AGGR_NONE:
if (!evsel->snapshot)
perf_evsel__compute_deltas(evsel, cpu, thread, count);
- perf_counts_values__scale(count, stat_config.scale, NULL);
- if (stat_config.aggr_mode == AGGR_NONE)
+ perf_counts_values__scale(count, config->scale, NULL);
+ if (config->aggr_mode == AGGR_NONE)
perf_stat__update_shadow_stats(evsel, count->values,
cpu);
break;
case AGGR_GLOBAL:
aggr->val += count->val;
- if (stat_config.scale) {
+ if (config->scale) {
aggr->ena += count->ena;
aggr->run += count->run;
}
@@ -255,7 +256,8 @@ process_counter_values(struct perf_evsel *evsel, int cpu,
int thread,
return 0;
}
-static int process_counter_maps(struct perf_evsel *counter)
+static int process_counter_maps(struct perf_stat_config *config,
+ struct perf_evsel *counter)
{
int nthreads = thread_map__nr(counter->threads);
int ncpus = perf_evsel__nr_cpus(counter);
@@ -266,7 +268,7 @@ static int process_counter_maps(struct perf_evsel *counter)
for (thread = 0; thread < nthreads; thread++) {
for (cpu = 0; cpu < ncpus; cpu++) {
- if (process_counter_values(counter, cpu, thread,
+ if (process_counter_values(config, counter, cpu, thread,
perf_counts(counter->counts,
cpu, thread)))
return -1;
}
@@ -275,7 +277,8 @@ static int process_counter_maps(struct perf_evsel *counter)
return 0;
}
-static int process_counter(struct perf_evsel *counter)
+static int process_counter(struct perf_stat_config *config,
+ struct perf_evsel *counter)
{
struct perf_counts_values *aggr = >counts->aggr;
struct perf_stat *ps = counter->priv;
@@ -288,22 +291,22 @@ static int process_counter(struct perf_evsel *counter)
if (counter->per_pkg)
zero_per_pkg(counter);
- ret = process_counter_maps(counter);
+ ret = process_counter_maps(_config, counter);
if (ret)
return ret;
- if (stat_config.aggr_mode != AGGR_GLOBAL)
+ if (config->aggr_mode != AGGR_GLOBAL)
return 0;
if (!counter->snapshot)
perf_evsel__compute_deltas(counter, -1, -1, aggr);
- perf_counts_values__scale(aggr, stat_config.scale,
>counts->scaled);
+ perf_counts_values__scale(aggr, config->scale,
>counts->scaled);
for (i = 0; i < 3; i++)
update_stats(>res_stats[i], count[i]);
if (verbose) {
- fprintf(stat_config.output, "%s: %" PRIu64 " %" PRIu64 " %"
PRIu64 "\n",
+ fprintf(config->output, "%s: %" PRIu64 " %" PRIu64 " %" PRIu64
"\n",
perf_evsel__name(counter), count[0], count[1],
count[2]);
}
@@ -352,7 +355,7 @@ static void read_counters(bool close_counters)
if (read_counter(counter))
pr_warning("failed to read counter %s\n",
counter->name);
- if (process_counter(counter))
+ if (process_counter(_config, counter))
pr_warning("failed to process counter %s\n",
counter->name);
if (close_counters) {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
[PATCH 20/26] perf report: Display cycles in branch sort mode
From: Andi Kleen Display the cycles by default in branch sort mode. To make enough room for the new column I removed dso_to. It is usually redundant with dso_from. Signed-off-by: Andi Kleen Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/1437233094-12844-9-git-send-email-a...@firstfloor.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/sort.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c index 5b7a50c04e45..5177088a71d3 100644 --- a/tools/perf/util/sort.c +++ b/tools/perf/util/sort.c @@ -9,7 +9,7 @@ regex_t parent_regex; const char default_parent_pattern[] = "^sys_|^do_page_fault"; const char *parent_pattern = default_parent_pattern; const char default_sort_order[] = "comm,dso,symbol"; -const char default_branch_sort_order[] = "comm,dso_from,symbol_from,dso_to,symbol_to"; +const char default_branch_sort_order[] = "comm,dso_from,symbol_from,symbol_to,cycles"; const char default_mem_sort_order[] = "local_weight,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked"; const char default_top_sort_order[] = "dso,symbol"; const char default_diff_sort_order[] = "dso,symbol"; -- 2.1.0 -- 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 02/26] bpf: Use correct #ifdef controller for trace_call_bpf()
From: Wang Nan
Commit e1abf2cc8d5d80b41c4419368ec743ccadbb131e ("bpf: Fix the build on
BPF_SYSCALL=y && !CONFIG_TRACING kernels, make it more configurable")
updated the building condition of bpf_trace.o from CONFIG_BPF_SYSCALL
to CONFIG_BPF_EVENTS, but the corresponding #ifdef controller in
trace_events.h for trace_call_bpf() was not changed. Which, in theory,
is incorrect.
With current Kconfigs, we can create a .config with CONFIG_BPF_SYSCALL=y
and CONFIG_BPF_EVENTS=n by unselecting CONFIG_KPROBE_EVENT and
selecting CONFIG_BPF_SYSCALL. With these options, trace_call_bpf() will
be defined as an extern function, but if anyone calls it a symbol missing
error will be triggered since bpf_trace.o was not built.
This patch changes the #ifdef controller for trace_call_bpf() from
CONFIG_BPF_SYSCALL to CONFIG_BPF_EVENTS. I'll show its correctness:
Before this patch:
BPF_SYSCALL BPF_EVENTS trace_call_bpf bpf_trace.o
y y normal compiled
n n inline not compiled
y n normal not compiled (incorrect)
n y impossible (BPF_EVENTS depends on BPF_SYSCALL)
After this patch:
BPF_SYSCALL BPF_EVENTS trace_call_bpf bpf_trace.o
y y normal compiled
n n inline not compiled
y n inline not compiled (fixed)
n y impossible (BPF_EVENTS depends on BPF_SYSCALL)
So this patch doesn't break anything. QED.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1435716878-189507-2-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
include/linux/trace_events.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 1063c850dbab..180dbf8720f9 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -542,7 +542,7 @@ event_trigger_unlock_commit_regs(struct trace_event_file
*file,
event_triggers_post_call(file, tt);
}
-#ifdef CONFIG_BPF_SYSCALL
+#ifdef CONFIG_BPF_EVENTS
unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx);
#else
static inline unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx)
--
2.1.0
--
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 23/26] perf tools: Fix perf-with-kcore handling of arguments containing spaces
From: Adrian Hunter
Fix the perf-with-kcore script so that it doesn't split arguments that
contain spaces.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1437150840-31811-13-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/perf-with-kcore.sh | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/perf/perf-with-kcore.sh b/tools/perf/perf-with-kcore.sh
index c7ff90a90e4e..7e47a7cbc195 100644
--- a/tools/perf/perf-with-kcore.sh
+++ b/tools/perf/perf-with-kcore.sh
@@ -50,7 +50,7 @@ copy_kcore()
fi
rm -f perf.data.junk
- ("$PERF" record -o perf.data.junk $PERF_OPTIONS -- sleep 60) >/dev/null
2>/dev/null &
+ ("$PERF" record -o perf.data.junk "${PERF_OPTIONS[@]}" -- sleep 60)
>/dev/null 2>/dev/null &
PERF_PID=$!
# Need to make sure that perf has started
@@ -160,18 +160,18 @@ record()
echo "*** WARNING *** /proc/sys/kernel/kptr_restrict
prevents access to kernel addresses" >&2
fi
- if echo "$PERF_OPTIONS" | grep -q ' -a \|^-a \| -a$\|^-a$\|
--all-cpus \|^--all-cpus \| --all-cpus$\|^--all-cpus$' ; then
+ if echo "${PERF_OPTIONS[@]}" | grep -q ' -a \|^-a \|
-a$\|^-a$\| --all-cpus \|^--all-cpus \| --all-cpus$\|^--all-cpus$' ; then
echo "*** WARNING *** system-wide tracing without root
access will not be able to read all necessary information from /proc" >&2
fi
- if echo "$PERF_OPTIONS" | grep -q 'intel_pt\|intel_bts\|
-I\|^-I' ; then
+ if echo "${PERF_OPTIONS[@]}" | grep -q 'intel_pt\|intel_bts\|
-I\|^-I' ; then
if [ "$(cat /proc/sys/kernel/perf_event_paranoid)" -gt
-1 ] ; then
echo "*** WARNING ***
/proc/sys/kernel/perf_event_paranoid restricts buffer size and tracepoint
(sched_switch) use" >&2
fi
- if echo "$PERF_OPTIONS" | grep -q ' --per-thread
\|^--per-thread \| --per-thread$\|^--per-thread$' ; then
+ if echo "${PERF_OPTIONS[@]}" | grep -q ' --per-thread
\|^--per-thread \| --per-thread$\|^--per-thread$' ; then
true
- elif echo "$PERF_OPTIONS" | grep -q ' -t \|^-t \|
-t$\|^-t$' ; then
+ elif echo "${PERF_OPTIONS[@]}" | grep -q ' -t \|^-t \|
-t$\|^-t$' ; then
true
elif [ ! -r /sys/kernel/debug -o ! -x /sys/kernel/debug
] ; then
echo "*** WARNING *** /sys/kernel/debug
permissions prevent tracepoint (sched_switch) use" >&2
@@ -193,8 +193,8 @@ record()
mkdir "$PERF_DATA_DIR"
- echo "$PERF record -o $PERF_DATA_DIR/perf.data $PERF_OPTIONS -- $*"
- "$PERF" record -o "$PERF_DATA_DIR/perf.data" $PERF_OPTIONS -- $* || true
+ echo "$PERF record -o $PERF_DATA_DIR/perf.data ${PERF_OPTIONS[@]} -- $@"
+ "$PERF" record -o "$PERF_DATA_DIR/perf.data" "${PERF_OPTIONS[@]}" --
"$@" || true
if rmdir "$PERF_DATA_DIR" > /dev/null 2>/dev/null ; then
exit 1
@@ -209,8 +209,8 @@ subcommand()
{
find_perf
check_buildid_cache_permissions
- echo "$PERF $PERF_SUB_COMMAND -i $PERF_DATA_DIR/perf.data
--kallsyms=$PERF_DATA_DIR/kcore_dir/kallsyms $*"
- "$PERF" $PERF_SUB_COMMAND -i "$PERF_DATA_DIR/perf.data"
"--kallsyms=$PERF_DATA_DIR/kcore_dir/kallsyms" $*
+ echo "$PERF $PERF_SUB_COMMAND -i $PERF_DATA_DIR/perf.data
--kallsyms=$PERF_DATA_DIR/kcore_dir/kallsyms $@"
+ "$PERF" $PERF_SUB_COMMAND -i "$PERF_DATA_DIR/perf.data"
"--kallsyms=$PERF_DATA_DIR/kcore_dir/kallsyms" "$@"
}
if [ "$1" = "fix_buildid_cache_permissions" ] ; then
@@ -234,7 +234,7 @@ fi
case "$PERF_SUB_COMMAND" in
"record")
while [ "$1" != "--" ] ; do
- PERF_OPTIONS+="$1 "
+ PERF_OPTIONS+=("$1")
shift || break
done
if [ "$1" != "--" ] ; then
@@ -242,16 +242,16 @@ case "$PERF_SUB_COMMAND" in
usage
fi
shift
- record $*
+ record "$@"
;;
"script")
- subcommand $*
+ subcommand "$@"
;;
"report")
- subcommand $*
+ subcommand "$@"
;;
"inject")
- subcommand $*
+ subcommand "$@"
;;
*)
usage
--
2.1.0
--
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 09/26] perf stat: Move 'interval' into struct perf_stat_config
From: Jiri Olsa
Moving 'interval' into struct perf_stat_config. The point is to
centralize the base stat config so it could be used localy together with
other stat routines in other parts of perf code.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1437481927-29538-6-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 14 +-
tools/perf/util/stat.h| 1 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index e3ea8b67703d..1bdfec8f5fe6 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -113,7 +113,6 @@ static bool group
= false;
static const char *pre_cmd= NULL;
static const char *post_cmd = NULL;
static boolsync_run= false;
-static unsigned intinterval= 0;
static unsigned intinitial_delay = 0;
static unsigned intunit_width = 4; /*
strlen("unit") */
static boolforever = false;
@@ -404,6 +403,7 @@ static void workload_exec_failed_signal(int signo
__maybe_unused, siginfo_t *inf
static int __run_perf_stat(int argc, const char **argv)
{
+ int interval = stat_config.interval;
char msg[512];
unsigned long long t0, t1;
struct perf_evsel *counter;
@@ -646,7 +646,7 @@ static void nsec_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
if (evsel->cgrp)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
- if (csv_output || interval)
+ if (csv_output || stat_config.interval)
return;
if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK))
@@ -689,7 +689,7 @@ static void abs_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
if (evsel->cgrp)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
- if (csv_output || interval)
+ if (csv_output || stat_config.interval)
return;
perf_stat__print_shadow_stats(output, evsel, avg, cpu,
@@ -990,6 +990,7 @@ static void print_footer(void)
static void print_counters(struct timespec *ts, int argc, const char **argv)
{
+ int interval = stat_config.interval;
struct perf_evsel *counter;
char buf[64], *prefix = NULL;
@@ -1029,7 +1030,7 @@ static volatile int signr = -1;
static void skip_signal(int signo)
{
- if ((child_pid == -1) || interval)
+ if ((child_pid == -1) || stat_config.interval)
done = 1;
signr = signo;
@@ -1313,7 +1314,7 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
"command to run prior to the measured command"),
OPT_STRING(0, "post", _cmd, "command",
"command to run after to the measured command"),
- OPT_UINTEGER('I', "interval-print", ,
+ OPT_UINTEGER('I', "interval-print", _config.interval,
"print counts at regular interval in ms (>= 100)"),
OPT_SET_UINT(0, "per-socket", _config.aggr_mode,
"aggregate counts per processor socket", AGGR_SOCKET),
@@ -1332,6 +1333,7 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
int status = -EINVAL, run_idx;
const char *mode;
FILE *output = stderr;
+ unsigned int interval;
setlocale(LC_ALL, "");
@@ -1342,6 +1344,8 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
argc = parse_options(argc, argv, options, stat_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
+ interval = stat_config.interval;
+
if (output_name && strcmp(output_name, "-"))
output = NULL;
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index ed0e05829cb0..1da706d848fb 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -54,6 +54,7 @@ struct perf_stat_config {
enum aggr_mode aggr_mode;
boolscale;
FILE*output;
+ unsigned intinterval;
};
static inline struct perf_counts_values*
--
2.1.0
--
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 0/3] zram: Replace pr_* with dev_*
On (08/06/15 18:48), Joe Perches wrote: [..] > > And I saw some time ago people doing that type of thing. So I'd like > > to avoid unnecessary pain for zram users even if the messages are not > > guaranteed to remain stable between kernel releases. Just my opinion. [..] > because dmesg is not an ABI. I absolutely agree, this is debatable and controversial. I saw people grepping dmesg and they treated error messages just like errno codes or like additional info to attach to errno. Whether we like or not, but, it seems, for that cases error message is more or less part of ABI. It's fine when we change _info message, but touching _warn or _err message is a bit different thing, *I think*. Let's hear from Minchan. -ss -- 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/
[GIT PULL 00/26] perf/core improvements and fixes
Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit b6b6c18fcd9af2a71d7b2cfca0388a928308f963: Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2015-08-06 08:51:18 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo for you to fetch changes up to 141b2d3161f19a774b3ceaa8faed5e63484a4684: perf tools: Extend the event parser maximum error index (2015-08-06 16:49:44 -0300) perf/core improvements and fixes: User visible: - IPC and cycle accounting in 'perf annotate' (Andi Kleen) - Display cycles in branch sort mode in 'perf report' (Andi Kleen) - Add total time column to 'perf trace' syscall stats summary (Milian Woff) Infrastructure: - PMU helpers to use in Intel PT (Adrian Hunter) - Fix perf-with-kcore script not to split args with spaces (Adrian Hunter) - Add empty Build files for some more architectures (Ben Hutchings) - Move 'perf stat' config variables to a struct to allow using some of its functions in more places (Jiri Olsa) - Add DWARF register names for 'xtensa' arch (Max Filippov) - Implement BPF programs attached to uprobes (Wang Nan) Signed-off-by: Arnaldo Carvalho de Melo Adrian Hunter (5): perf auxtrace: Fix period type 'i' not working perf tools: Fix perf-with-kcore handling of arguments containing spaces perf tools: Add perf_pmu__format_bits() perf tools: Validate config term maximum value perf tools: Extend the event parser maximum error index Andi Kleen (8): perf tools: Add support for cycles, weight branch_info field perf report: Add flag for non ANY branch mode perf report: Add infrastructure for a cycles histogram perf report: Add processing for cycle histograms perf annotate: Compute IPC and basic block cycles perf annotate: Finally display IPC and cycle accounting perf top: Add branch annotation code to top perf report: Display cycles in branch sort mode Ben Hutchings (1): perf tools: Add empty Build files for architectures lacking them Jiri Olsa (6): perf stat: Introduce struct perf_stat_config perf stat: Move 'scale' into struct perf_stat_config perf stat: Move 'output' into struct perf_stat_config perf stat: Move 'interval' into struct perf_stat_config perf stat: Pass 'struct perf_stat_config' into process_counter() perf stat: Move counter processing code into stat object Max Filippov (1): perf tools xtensa: Add DWARF register names Milian Wolff (1): perf trace: Add total time column to summary. Wang Nan (4): bpf: Use correct #ifdef controller for trace_call_bpf() tracing, perf: Implement BPF programs attached to uprobes perf tools: Introduce veprintf perf tools: Add missing forward declaration of struct map to probe-event.h include/linux/trace_events.h | 7 +- kernel/events/core.c | 4 +- kernel/trace/Kconfig | 2 +- kernel/trace/trace_uprobe.c | 5 + tools/perf/Documentation/perf-report.txt | 1 + tools/perf/Documentation/perf-top.txt| 21 +++ tools/perf/arch/alpha/Build | 1 + tools/perf/arch/mips/Build | 1 + tools/perf/arch/parisc/Build | 1 + tools/perf/arch/xtensa/Build | 1 + tools/perf/arch/xtensa/Makefile | 3 + tools/perf/arch/xtensa/util/Build| 1 + tools/perf/arch/xtensa/util/dwarf-regs.c | 25 tools/perf/builtin-annotate.c| 1 + tools/perf/builtin-report.c | 10 ++ tools/perf/builtin-stat.c| 224 --- tools/perf/builtin-top.c | 9 ++ tools/perf/builtin-trace.c | 10 +- tools/perf/perf-with-kcore.sh| 28 ++-- tools/perf/ui/browsers/annotate.c| 130 +++--- tools/perf/util/annotate.c | 127 +- tools/perf/util/annotate.h | 19 +++ tools/perf/util/auxtrace.c | 6 +- tools/perf/util/debug.c | 5 + tools/perf/util/debug.h | 1 + tools/perf/util/event.h | 3 +- tools/perf/util/evlist.c | 10 ++ tools/perf/util/evlist.h | 1 + tools/perf/util/hist.c | 36 - tools/perf/util/hist.h | 4 + tools/perf/util/parse-events.c | 2 +- tools/perf/util/pmu.c| 47 ++- tools/perf/util/pmu.h| 1 + tools/perf/util/probe-event.h| 2 + tools/perf/util/session.c| 16 ++- tools/perf/util/sort.c | 26 +++-
[PATCH 08/26] perf stat: Move 'output' into struct perf_stat_config
From: Jiri Olsa
Moving 'output' into struct perf_stat_config. The point is to centralize
the base stat config so it could be used localy together with other stat
routines in other parts of perf code.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1437481927-29538-5-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 35 +++
tools/perf/util/stat.h| 1 +
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 3fb2865e519a..e3ea8b67703d 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -110,7 +110,6 @@ static int big_num_opt
= -1;
static const char *csv_sep= NULL;
static boolcsv_output = false;
static boolgroup = false;
-static FILE*output = NULL;
static const char *pre_cmd= NULL;
static const char *post_cmd = NULL;
static boolsync_run= false;
@@ -305,7 +304,7 @@ static int process_counter(struct perf_evsel *counter)
update_stats(>res_stats[i], count[i]);
if (verbose) {
- fprintf(output, "%s: %" PRIu64 " %" PRIu64 " %" PRIu64 "\n",
+ fprintf(stat_config.output, "%s: %" PRIu64 " %" PRIu64 " %"
PRIu64 "\n",
perf_evsel__name(counter), count[0], count[1],
count[2]);
}
@@ -548,13 +547,13 @@ static int run_perf_stat(int argc, const char **argv)
static void print_running(u64 run, u64 ena)
{
if (csv_output) {
- fprintf(output, "%s%" PRIu64 "%s%.2f",
+ fprintf(stat_config.output, "%s%" PRIu64 "%s%.2f",
csv_sep,
run,
csv_sep,
ena ? 100.0 * run / ena : 100.0);
} else if (run != ena) {
- fprintf(output, " (%.2f%%)", 100.0 * run / ena);
+ fprintf(stat_config.output, " (%.2f%%)", 100.0 * run / ena);
}
}
@@ -563,9 +562,9 @@ static void print_noise_pct(double total, double avg)
double pct = rel_stddev_stats(total, avg);
if (csv_output)
- fprintf(output, "%s%.2f%%", csv_sep, pct);
+ fprintf(stat_config.output, "%s%.2f%%", csv_sep, pct);
else if (pct)
- fprintf(output, " ( +-%6.2f%% )", pct);
+ fprintf(stat_config.output, " ( +-%6.2f%% )", pct);
}
static void print_noise(struct perf_evsel *evsel, double avg)
@@ -583,7 +582,7 @@ static void aggr_printout(struct perf_evsel *evsel, int id,
int nr)
{
switch (stat_config.aggr_mode) {
case AGGR_CORE:
- fprintf(output, "S%d-C%*d%s%*d%s",
+ fprintf(stat_config.output, "S%d-C%*d%s%*d%s",
cpu_map__id_to_socket(id),
csv_output ? 0 : -8,
cpu_map__id_to_cpu(id),
@@ -593,7 +592,7 @@ static void aggr_printout(struct perf_evsel *evsel, int id,
int nr)
csv_sep);
break;
case AGGR_SOCKET:
- fprintf(output, "S%*d%s%*d%s",
+ fprintf(stat_config.output, "S%*d%s%*d%s",
csv_output ? 0 : -5,
id,
csv_sep,
@@ -602,12 +601,12 @@ static void aggr_printout(struct perf_evsel *evsel, int
id, int nr)
csv_sep);
break;
case AGGR_NONE:
- fprintf(output, "CPU%*d%s",
+ fprintf(stat_config.output, "CPU%*d%s",
csv_output ? 0 : -4,
perf_evsel__cpus(evsel)->map[id], csv_sep);
break;
case AGGR_THREAD:
- fprintf(output, "%*s-%*d%s",
+ fprintf(stat_config.output, "%*s-%*d%s",
csv_output ? 0 : 16,
thread_map__comm(evsel->threads, id),
csv_output ? 0 : -8,
@@ -622,6 +621,7 @@ static void aggr_printout(struct perf_evsel *evsel, int id,
int nr)
static void nsec_printout(int id, int nr, struct perf_evsel *evsel, double avg)
{
+ FILE *output = stat_config.output;
double msecs = avg / 1e6;
const char *fmt_v, *fmt_n;
char name[25];
@@ -658,6 +658,7 @@ static void nsec_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
static void abs_printout(int id, int nr, struct perf_evsel *evsel, double avg)
{
+ FILE *output = stat_config.output;
double sc = evsel->scale;
[PATCH 25/26] perf tools: Validate config term maximum value
From: Adrian Hunter
Currently the value of a PMU config term is silently truncated if it is
too big. This is an impediment to validating the value for other
criteria later on i.e. the user provides an invalid value that gets
truncated to a valid one.
The maximum value validation is only done for the parser where the error
is passed back to the user. In other cases the silent truncation
continues so as not to affect tools that perhaps rely on it.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1437150840-31811-16-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/pmu.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index c548ec89c8bc..d4b0e6454bc6 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -589,6 +589,18 @@ static void pmu_format_value(unsigned long *format, __u64
value, __u64 *v,
}
}
+static __u64 pmu_format_max_value(const unsigned long *format)
+{
+ int w;
+
+ w = bitmap_weight(format, PERF_PMU_FORMAT_BITS);
+ if (!w)
+ return 0;
+ if (w < 64)
+ return (1ULL << w) - 1;
+ return -1;
+}
+
/*
* Term is a string term, and might be a param-term. Try to look up it's value
* in the remaining terms.
@@ -662,7 +674,7 @@ static int pmu_config_term(struct list_head *formats,
{
struct perf_pmu_format *format;
__u64 *vp;
- __u64 val;
+ __u64 val, max_val;
/*
* If this is a parameter we've already used for parameterized-eval,
@@ -728,6 +740,22 @@ static int pmu_config_term(struct list_head *formats,
} else
return -EINVAL;
+ max_val = pmu_format_max_value(format->bits);
+ if (val > max_val) {
+ if (err) {
+ err->idx = term->err_val;
+ if (asprintf(>str,
+"value too big for format, maximum is
%llu",
+(unsigned long long)max_val) < 0)
+ err->str = strdup("value too big for format");
+ return -EINVAL;
+ }
+ /*
+* Assume we don't care if !err, in which case the value will be
+* silently truncated.
+*/
+ }
+
pmu_format_value(format->bits, val, vp, zero);
return 0;
}
--
2.1.0
--
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 05/26] perf tools: Add missing forward declaration of struct map to probe-event.h
From: Wang Nan
Commit 7b6ff0bdbf4f7f429c2116cca92a6d171217449e ("perf probe ppc64le:
Fixup function entry if using kallsyms lookup") adds 'struct map' into
probe-event.h but not forward declares it. This patch fixes it.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Fixes: 7b6ff0bdbf4f ("perf probe ppc64le: Fixup function entry if using
kallsyms lookup")
Link:
http://lkml.kernel.org/n/1436445342-1402-30-git-send-email-wangn...@huawei.com
[ No need to include map.h, just forward declare 'struct map' ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-event.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index 20f555d1ae1c..83ee95e9743b 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -106,6 +106,8 @@ struct variable_list {
struct strlist *vars; /* Available variables */
};
+struct map;
+
/* Command string to events */
extern int parse_perf_probe_command(const char *cmd,
struct perf_probe_event *pev);
--
2.1.0
--
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 21/26] perf tools xtensa: Add DWARF register names
From: Max Filippov
Signed-off-by: Max Filippov
Cc: Chris Zankel
Cc: Marc Gauthier
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: linux-xte...@linux-xtensa.org
Link:
http://lkml.kernel.org/r/1437208216-15729-9-git-send-email-jcmvb...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/xtensa/Build | 1 +
tools/perf/arch/xtensa/Makefile | 3 +++
tools/perf/arch/xtensa/util/Build| 1 +
tools/perf/arch/xtensa/util/dwarf-regs.c | 25 +
4 files changed, 30 insertions(+)
create mode 100644 tools/perf/arch/xtensa/Build
create mode 100644 tools/perf/arch/xtensa/Makefile
create mode 100644 tools/perf/arch/xtensa/util/Build
create mode 100644 tools/perf/arch/xtensa/util/dwarf-regs.c
diff --git a/tools/perf/arch/xtensa/Build b/tools/perf/arch/xtensa/Build
new file mode 100644
index ..54afe4a467e7
--- /dev/null
+++ b/tools/perf/arch/xtensa/Build
@@ -0,0 +1 @@
+libperf-y += util/
diff --git a/tools/perf/arch/xtensa/Makefile b/tools/perf/arch/xtensa/Makefile
new file mode 100644
index ..7fbca175099e
--- /dev/null
+++ b/tools/perf/arch/xtensa/Makefile
@@ -0,0 +1,3 @@
+ifndef NO_DWARF
+PERF_HAVE_DWARF_REGS := 1
+endif
diff --git a/tools/perf/arch/xtensa/util/Build
b/tools/perf/arch/xtensa/util/Build
new file mode 100644
index ..954e287bbb89
--- /dev/null
+++ b/tools/perf/arch/xtensa/util/Build
@@ -0,0 +1 @@
+libperf-$(CONFIG_DWARF) += dwarf-regs.o
diff --git a/tools/perf/arch/xtensa/util/dwarf-regs.c
b/tools/perf/arch/xtensa/util/dwarf-regs.c
new file mode 100644
index ..4dba76bfb4ce
--- /dev/null
+++ b/tools/perf/arch/xtensa/util/dwarf-regs.c
@@ -0,0 +1,25 @@
+/*
+ * Mapping of DWARF debug register numbers into register names.
+ *
+ * Copyright (c) 2015 Cadence Design Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+
+#define XTENSA_MAX_REGS 16
+
+const char *xtensa_regs_table[XTENSA_MAX_REGS] = {
+ "a0", "a1", "a2", "a3", "a4", "a5", "a6", "a7",
+ "a8", "a9", "a10", "a11", "a12", "a13", "a14", "a15",
+};
+
+const char *get_arch_regstr(unsigned int n)
+{
+ return n < XTENSA_MAX_REGS ? xtensa_regs_table[n] : NULL;
+}
--
2.1.0
--
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/
