[PATCH RFC v2 2/2] simplefb: Claim and enable regulators

[Chen-Yu Tsai]

This claims and enables regulators listed in the simple framebuffer dt
node. This is needed so that regulators powering the display pipeline
and external hardware, described in the device node and known by the
kernel code, will remain properly enabled.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/video/fbdev/simplefb.c | 122 -
 1 file changed, 121 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 52c5c7e63b52..c4ee10d83a70 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -28,7 +28,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 
 static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -174,6 +177,10 @@ struct simplefb_par {
int clk_count;
struct clk **clks;
 #endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+   u32 regulator_count;
+   struct regulator **regulators;
+#endif
 };
 
 #if defined CONFIG_OF && defined CONFIG_COMMON_CLK
@@ -269,6 +276,112 @@ static int simplefb_clocks_init(struct simplefb_par *par,
 static void simplefb_clocks_destroy(struct simplefb_par *par) { }
 #endif
 
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_regulators_init(struct simplefb_par *par,
+   struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct property *prop;
+   struct regulator *regulator;
+   const char *p;
+   int count = 0, i = 0, ret;
+
+   if (dev_get_platdata(>dev) || !np)
+   return 0;
+
+   /* Count the number of regulator supplies */
+   for_each_property_of_node(np, prop) {
+   p = strstr(prop->name, SUPPLY_SUFFIX);
+   if (p && p != prop->name)
+   count++;
+   }
+
+   if (!count)
+   return 0;
+
+   par->regulators = devm_kcalloc(>dev, count,
+  sizeof(struct regulator *), GFP_KERNEL);
+   if (!par->regulators)
+   return -ENOMEM;
+
+   /* Get all the regulators */
+   for_each_property_of_node(np, prop) {
+   char name[32]; /* 32 is max size of property name */
+
+   p = strstr(prop->name, SUPPLY_SUFFIX);
+   if (p && p != prop->name)
+   continue;
+
+   strlcpy(name, prop->name,
+   strlen(prop->name) - sizeof(SUPPLY_SUFFIX) + 1);
+   regulator = devm_regulator_get_optional(>dev, name);
+   if (IS_ERR(regulator)) {
+   if (PTR_ERR(regulator) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(>dev, "regulator %s not found: %ld\n",
+   name, PTR_ERR(regulator));
+   continue;
+   }
+   par->regulators[i++] = regulator;
+   }
+   par->regulator_count = i;
+
+   /* Enable all the regulators */
+   for (i = 0; i < par->regulator_count; i++) {
+   if (par->regulators[i]) {
+   ret = regulator_enable(par->regulators[i]);
+   if (ret) {
+   dev_err(>dev,
+   "failed to enable regulator %d: %d\n",
+   i, ret);
+   devm_regulator_put(par->regulators[i]);
+   par->regulators[i] = NULL;
+   }
+   }
+   }
+
+   return 0;
+}
+
+static void simplefb_regulators_destroy(struct simplefb_par *par)
+{
+   int i;
+
+   if (!par->regulators)
+   return;
+
+   for (i = 0; i < par->regulator_count; i++)
+   if (par->regulators[i])
+   regulator_disable(par->regulators[i]);
+}
+#else
+static int simplefb_regulators_init(struct simplefb_par 

Re: [PATCH RESEND v6 3/4] irqchip:create irq domain for each mbigen device

[majun (F)]

在 2015/10/21 2:43, kbuild test robot 写道:
> Hi Ma,
> 
> [auto build test ERROR on tip/irq/core -- if it's inappropriate base, please 
> suggest rules for selecting the more suitable base]
> 
> url:
> https://github.com/0day-ci/linux/commits/MaJun/irqchip-support-mbigen-interrupt-controller/20151020-202450
> config: arm64-allyesconfig (attached as .config)
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm64 
> 
> All error/warnings (new ones prefixed by >>):
> 
>drivers/irqchip/irq-mbigen.c:84:14: error: 'mbigen_eoi_irq' undeclared 
> here (not in a function)
>  .irq_eoi =  mbigen_eoi_irq,
>  ^
>drivers/irqchip/irq-mbigen.c:85:19: error: 'mbigen_set_type' undeclared 
> here (not in a function)
>  .irq_set_type =  mbigen_set_type,
>   ^

I'll fix this error in v7

>drivers/irqchip/irq-mbigen.c: In function 'mbigen_irq_domain_alloc':
>>> drivers/irqchip/irq-mbigen.c:150:2: error: implicit declaration of function 
>>> 'platform_msi_domain_alloc' [-Werror=implicit-function-declaration]
>  err = platform_msi_domain_alloc(domain, virq, nr_irqs);
>  ^
>>> drivers/irqchip/irq-mbigen.c:159:2: error: implicit declaration of function 
>>> 'platform_msi_get_host_data' [-Werror=implicit-function-declaration]
>  mgn_chip = platform_msi_get_host_data(domain);
>  ^
>>> drivers/irqchip/irq-mbigen.c:159:11: warning: assignment makes pointer from 
>>> integer without a cast
>  mgn_chip = platform_msi_get_host_data(domain);
>   ^
>drivers/irqchip/irq-mbigen.c: In function 'mbigen_device_probe':
>>> drivers/irqchip/irq-mbigen.c:202:2: error: implicit declaration of function 
>>> 'platform_msi_create_device_domain' [-Werror=implicit-function-declaration]
>  domain = platform_msi_create_device_domain(>dev, num_msis,
>  ^
>drivers/irqchip/irq-mbigen.c:202:9: warning: assignment makes pointer from 
> integer without a cast
>  domain = platform_msi_create_device_domain(>dev, num_msis,

My patch based on Marc's patch
https://lkml.org/lkml/2015/10/15/545

So, please apply this patch first.

Thanks!
Ma Jun

--
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 22/22] of/platform: Defer probes of registered devices

[Scott Wood]

On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
> Instead of trying to match and probe platform and AMBA devices right
> after each is registered, delay their probes until device_initcall_sync.
> 
> This means that devices will start probing once all built-in drivers
> have registered, and after all platform and AMBA devices from the DT
> have been registered already.
> 
> This allows us to prevent deferred probes by probing dependencies on
> demand.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
> 
> Changes in v4:
> - Also defer probes of AMBA devices registered from the DT as they can
>   also request resources.
> 
>  drivers/of/platform.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)

This breaks arch/powerpc/sysdev/fsl_pci.c.  The PCI bus is an OF platform 
device, and it must be probed before pcibios_init() which is a 
subsys_initcall(), or else the PCI bus never gets scanned.

-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/

Re: [RFC PATCH] qspinlock: Improve performance by reducing load instruction rollback

[Ling Ma]

>
> I did see some performance improvement when I used your test program on a
> Haswell-EX system. It seems like the use of cmpxchg has forced the changed
> memory values to be visible to other processors earlier. I also ran your
> test on an older machine with Westmere-EX processors. This time, I didn't
> see any performance improvement. In fact, your change actually make it a
> tiny bit slower. So the benefit of your patch can be highly processor
> sensitive.
>
> As other architectures like ARM & AA64 are going to adopt qspinlock in the
> near future, we will also need to make sure that it won't cause a regression
> there. So I don't see your patch has a big chance of being merged upstream
> unless you can provide a real world workload that can benefit from your
> patch. Even then, proving that it won't cause regression in other processors
> or architectures can be tedious.
>

The optimization will be closely related with CPU arch and cache
coherence implementation.
so we will test it for real world workload on Haswell, and send out the result.

Thanks
Ling
--
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] qspinlock: Improve performance by reducing load instruction rollback

[Ling Ma]

2015-10-20 17:16 GMT+08:00 Peter Zijlstra :
> On Tue, Oct 20, 2015 at 11:24:02AM +0800, Ling Ma wrote:
>> 2015-10-19 17:46 GMT+08:00 Peter Zijlstra :
>> > On Mon, Oct 19, 2015 at 10:27:22AM +0800, ling.ma.prog...@gmail.com wrote:
>> >> From: Ma Ling 
>> >>
>> >> All load instructions can run speculatively but they have to follow
>> >> memory order rule in multiple cores as below:
>> >> _x = _y = 0
>> >>
>> >> Processor 0   Processor 1
>> >>
>> >> mov r1, [ _y]  //M1   mov [ _x], 1  //M3
>> >> mov r2, [ _x]  //M2   mov [ _y], 1  //M4
>> >>
>> >> If r1 = 1, r2 must be 1
>> >>
>> >> In order to guarantee above rule, although Processor 0 execute
>> >> M1 and M2 instruction out of order, they are kept in ROB,
>> >> when load buffer for _x in Processor 0 received the update
>> >> message from Processor 1, Processor 0 need to roll back
>> >> from M2 instruction, which will flush the whole pipeline,
>> >> the latency is over the penalty from branch prediction miss.
>> >>
>> >> In this patch we use lock cmpxchg instruction to force load
>> >
>> > "lock cmpxchg" makes me think you're working on x86.
>> >
>> >> instructions to be serialization,
>> >
>> > smp_rmb() does that, and that's 'free' on x86. Because x86 doesn't do
>> > read reordering.
>> >
>> >> the destination operand
>> >> receives a write cycle without regard to the result of
>> >> the comparison, which can help us to reduce the penalty
>> >> from load instruction roll back.
>> >
>> > And that makes me think I'm not understanding what you're getting at. If
>> > you need to force memory order, a "fence" (or smp_mb()) would still be
>> > cheaper than endlessly pulling the line into exclusive state for no
>> > reason, right?
>>
>> Peter,
>>
>> we tested instruction lfence, but we hard to see any benefit, lfence
>> only force load instruction ,
>> but load instruction still will rollback ,actually cmpxchg behavior is
>> more like write operation,
>> so we choose it.
>
> But why? I'm just not getting this.
>
> Also LOCK CMPXCHG is 24 cycles when hot, that's almost as bad as
> a pipeline flush, and it can be many times worse when it needs to
> actually fetch memory from further than L1.

We will clarify the root cause about this question soon.

Thanks
Ling
--
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/

kernel oops on mmotm-2015-10-15-15-20

[Minchan Kim]

I detach this report from my patchset thread because I see below
problem with removing MADV_FREE related code and I can reproduce
same oops with MADV_FREE + recent patches(both my SetPageDirty
and Kirill's pte_mkdirty) within 7 hours.

I can not be sure it's THP refcount redesign's problem but it was
one of big change in MM between mmotm-2015-10-15-15-20 and
mmotm-2015-10-06-16-30 so it could be a culprit.

In page_lock_anon_vma_read, anon_vma_root was NULL.
I added VM_BUG_ON_PAGE(!root_anon_vma, page) in there and got the result.

..
..
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
page:ea0001b81140 count:3 mapcount:1 mapping:88007e806461 
index:0x61445
page:ea0001b87bc0 count:3 mapcount:1 mapping:88007e806461 
index:0x615ef
flags: 0x40048019(locked|uptodate|dirty|swapcache|swapbacked)
page dumped because: VM_BUG_ON_PAGE(1)
page->mem_cgroup:88007f2de000
[ cut here ]
kernel BUG at mm/rmap.c:517!
invalid opcode:  [#1] SMP 
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 24935 Comm: madvise_test Not tainted 
4.3.0-rc5-mm1-THP-ref-madv_free+ #1555
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88ce8000 ti: 8800ada28000 task.ti: 8800ada28000
RIP: 0010:[]  [] 
page_lock_anon_vma_read+0x18e/0x190
RSP: :8800ada2b868  EFLAGS: 00010296
RAX: 0021 RBX: ea0001b87bc0 RCX: 
RDX: 0001 RSI: 0282 RDI: 81830db0
RBP: 8800ada2b888 R08: 0021 R09: 8800ba40eb75
R10: 01ff14bc R11:  R12: 88007e806461
R13: 88007e806460 R14:  R15: 818464c0
FS:  7f6d93212740() GS:8800bfa0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 63c14000 CR3: a674b000 CR4: 06b0
Stack:
 ea0001b87bc0 8800ada2b8f8 88007f2de000 
 8800ada2b8d0 81129593 8800 8105f8c0
 ea0001b87bc0 8800ada2b9f8 88007f2de000 
Call Trace:
 [] rmap_walk+0x1b3/0x3f0
 [] ? finish_task_switch+0x70/0x260
 [] page_referenced+0x1a3/0x220
 [] ? __page_check_address+0x1d0/0x1d0
 [] ? page_get_anon_vma+0xd0/0xd0
 [] ? anon_vma_ctor+0x40/0x40
 [] shrink_page_list+0x5ce/0xdc0
 [] shrink_inactive_list+0x18c/0x4b0
 [] shrink_lruvec+0x58f/0x730
 [] shrink_zone+0xd4/0x280
 [] do_try_to_free_pages+0x12d/0x3b0
 [] try_to_free_mem_cgroup_pages+0x9d/0x120
 [] try_charge+0x175/0x720
 [] ? __activate_page+0x230/0x230
 [] mem_cgroup_try_charge+0x85/0x1d0
 [] handle_mm_fault+0xc9a/0x1000
 [] ? __set_cpus_allowed_ptr+0x9b/0x1a0
 [] __do_page_fault+0x189/0x400
 [] do_page_fault+0xc/0x10
 [] page_fault+0x22/0x30
Code: c9 0f 84 b9 fe ff ff 8d 51 01 89 c8 f0 0f b1 16 39 c1 0f 84 11 ff ff ff 
89 c1 eb e3 48 c7 c6 88 02 78 81 48 89 df e8 02 f3 fe ff <0f> 0b 0f 1f 44 00 00 
55 48 89 e5 41 57 41 56 45 31 f6 
41 55 4c 
RIP  [] page_lock_anon_vma_read+0x18e/0x190
 RSP 
---[ end trace cfbb87f54f12290e ]---
Kernel panic - not syncing: Fatal exception
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled

On Tue, Oct 20, 2015 at 10:38:54AM +0900, Minchan Kim wrote:
> On Mon, Oct 19, 2015 at 07:01:50PM +0900, Minchan Kim wrote:
> > On Mon, Oct 19, 2015 at 03:31:42PM +0900, Minchan Kim wrote:
> > > Hello, it's too late since I sent previos patch.
> > > https://lkml.org/lkml/2015/6/3/37
> > > 
> > > This patch is alomost new compared to previos approach.
> > > I think this is more simple, clear and easy to review.
> > > 
> > > One thing I should notice is that I have tested this patch
> > > and couldn't find any critical problem so I rebased patchset
> > > onto recent mmotm(ie, mmotm-2015-10-15-15-20) to send formal
> > > patchset. Unfortunately, I start to see sudden discarding of
> > > the page we shouldn't do. IOW, application's valid anonymous page
> > > was disappeared suddenly.
> > > 
> > > When I look through THP changes, I think we could lose
> > > dirty bit of pte between freeze_page and unfreeze_page
> > > when we mark it as migration entry and restore it.
> > > So, I added below simple code without enough considering
> > > and cannot see the problem any more.
> > > I hope it's good hint to find right fix this problem.
> > > 
> > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > > index d5ea516ffb54..e881c04f5950 100644
> > > --- a/mm/huge_memory.c
> > > +++ b/mm/huge_memory.c
> > > @@ -3138,6 +3138,9 @@ static void unfreeze_page_vma(struct vm_area_struct 
> > > *vma, struct page *page,
> > >   if (is_write_migration_entry(swp_entry))
> > >   entry = maybe_mkwrite(entry, vma);
> > >  
> > > + if (PageDirty(page))
> > > + SetPageDirty(page);
> > 
> > The condition of PageDirty was typo. I didn't add the condition.
> > Just added.
> > 
> > 

Re: [RFC PATCH] qspinlock: Improve performance by reducing load instruction rollback

[Ling Ma]

Ok, we will put the spinlock test into the perf bench.

Thanks
Ling

2015-10-20 16:48 GMT+08:00 Ingo Molnar :
>
> * Ling Ma  wrote:
>
>> > So it would be nice to create a new user-space spinlock testing facility, 
>> > via
>> > a new 'perf bench spinlock' feature or so. That way others can test and
>> > validate your results on different hardware as well.
>>
>> Attached the spinlock test module . Queued spinlock will run very slowly in 
>> user
>> space because process switch context, it is OK for spinlock-test 
>> implementation
>> with kernel module ?
>
> Not sure what you mean by 'because process switch context': if you pin the 
> test
> tasks to individual CPUs and make sure there's nothing else running it should 
> be
> equivalent to kernel-space execution.
>
> Thanks,
>
> Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][v6] PM / hibernate: Print the possible panic reason when resuming with inconsistent e820 map

[Chen Yu]

On some platforms, there is occasional panic triggered when trying to
resume from hibernation, a typical panic looks like:

"BUG: unable to handle kernel paging request at 880085894000
IP: [] load_image_lzo+0x8c2/0xe70"

This is because e820 map has been changed by BIOS before/after
hibernation, and one of the page frames from first kernel
is right located in second kernel's unmapped region, so panic
comes out when accessing unmapped kernel address.

In order to tell the user why this happeneded, and for scalability,
we introduce a framework(a new file named hibernation_e820.c) to
compare the e820 maps before/after hibernation. If these two
e820 maps are not compatible with each other, we will print
warning about the first corrupt e820 entry's information
(there might be more than one broken e820 entries) once the
system goes into panic, for example:

BUG: unable to handle kernel paging request at 8800a9688000
IP: [] load_image_lzo+0x8c2/0xe70
PM: Hibernation Caution! Oops might be due to inconsistent e820 table.
PM: mem [0xa963b000-0xa963d000][ACPI Table] is an invalid old e820 region.
PM: Inconsistent with current [mem 0xa963b000-0xa963e000][ACPI Table].
PM: Please update your BIOS, or do not use hibernation on this machine.

The following kind of e820 entries will be regarded as invalid ones:
1.E820_RAM:  old region is not a subset of any current region.
2.E820_ACPI: old region is not strictly the same as any current
 region(example above).

Signed-off-by: Chen Yu 
---
v6:
 - Fix some compiling errors reported by 0day/LKP, adjust
   Kconfig/variable namings.
v5:
 - Rewrite this patch to just warn user of the broken BIOS
   when panic.
v4:
 - Add __attribute__ ((unused)) for swsusp_page_is_valid,
   to eliminate the warnning of:
   'swsusp_page_is_valid' defined but not used
   on non-x86 platforms.

v3:
 - Adjust the logic to exclude the end_pfn boundary in pfn_mapped
   when invoking mark_valid_pages, because the end_pfn is not
   a mapped page frame, we should not regard it as a valid page.

   Move the sanity check of valid pages to a early stage in resuming
   process(moved to mark_unsafe_pages), in this way, we can avoid
   unnecessarily accessing these invalid pages in later stage(yes,
   move to the original position Joey once introduced in:
   Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820
   reserved regions")

   With v3 patch applied, I did 30 cycles on my problematic platform,
   no panic triggered anymore(50% reproducible before patched, by
   plugging/unplugging memory peripheral during hibernation), and it
   just warns of invalid pages.
   
v2:
 - According to Ingo's suggestion, rewrite this patch.

   New version just checks each page frame according to pfn_mapped array.
   So that we do not need to touch existing code related to
   E820_RESERVED_KERN. And this method can naturely guarantee
   that the system before/after hibernation do not need to be of
   the same memory size on x86_64.
---
 arch/x86/Kconfig|   1 +
 arch/x86/power/Makefile |   2 +-
 arch/x86/power/hibernate_e820.c | 243 
 include/linux/suspend.h |  19 
 kernel/power/Kconfig|   4 +
 kernel/power/power.h|   8 ++
 kernel/power/snapshot.c |   8 ++
 7 files changed, 284 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/power/hibernate_e820.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 96d058a..9f72144 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -30,6 +30,7 @@ config X86
select ARCH_HAS_PMEM_APIif X86_64
select ARCH_HAS_MMIO_FLUSH
select ARCH_HAS_SG_CHAIN
+   select ARCH_HAS_RESUME_IMAGE_CHECKERif HIBERNATION
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
select ARCH_MIGHT_HAVE_PC_PARPORT
diff --git a/arch/x86/power/Makefile b/arch/x86/power/Makefile
index a6a198c..8877cfb 100644
--- a/arch/x86/power/Makefile
+++ b/arch/x86/power/Makefile
@@ -4,4 +4,4 @@ nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_cpu.o   := $(nostackp)
 
 obj-$(CONFIG_PM_SLEEP) += cpu.o
-obj-$(CONFIG_HIBERNATION)  += hibernate_$(BITS).o hibernate_asm_$(BITS).o
+obj-$(CONFIG_HIBERNATION)  += hibernate_$(BITS).o hibernate_asm_$(BITS).o 
hibernate_e820.o
diff --git a/arch/x86/power/hibernate_e820.c b/arch/x86/power/hibernate_e820.c
new file mode 100644
index 000..f51a892
--- /dev/null
+++ b/arch/x86/power/hibernate_e820.c
@@ -0,0 +1,243 @@
+/*
+ * Hibernation e820 consistence checking for x86.
+ *
+ * Copyright (C) 2015, Intel Corporation
+ * Authors: Chen Yu 
+ *
+ * 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 
+
+/*
+ * The following code is to check whether the old e820 map

Re: [PATCH v7 3/7] perf config: Add a option 'list-all' to perf-config

[Namhyung Kim]

On Sun, Oct 04, 2015 at 04:35:06PM +0900, Taeung Song wrote:
> A option 'list-all' is to display both current config variables and
> all possible config variables with default values.
> The syntax examples are like below
> 
> perf config [] [options]
> 
> display all perf config with default values.
> # perf config -a | --list-all
> 
> Signed-off-by: Taeung Song 
> ---
>  tools/perf/Documentation/perf-config.txt |   6 +
>  tools/perf/builtin-config.c  | 339 
> ++-
>  2 files changed, 343 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/Documentation/perf-config.txt 
> b/tools/perf/Documentation/perf-config.txt
> index a42d409..15fbbd9 100644
> --- a/tools/perf/Documentation/perf-config.txt
> +++ b/tools/perf/Documentation/perf-config.txt
> @@ -9,6 +9,8 @@ SYNOPSIS
>  
>  [verse]
>  'perf config' [] -l | --list
> +or
> +'perf config' [] -a | --list-all
>  
>  DESCRIPTION
>  ---
> @@ -29,6 +31,10 @@ OPTIONS
>   For writing and reading options: write to system-wide
>   '$(sysconfdir)/perfconfig' or read it.
>  
> +-a::
> +--list-all::
> + Show current and all possible config variables with default values.
> +
>  CONFIGURATION FILE
>  --
>  
> diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
> index 92be3eb..8e16e18 100644
> --- a/tools/perf/builtin-config.c
> +++ b/tools/perf/builtin-config.c
> @@ -21,7 +21,8 @@ static const char * const config_usage[] = {
>  };
>  
>  enum actions {
> - ACTION_LIST = 1
> + ACTION_LIST = 1,
> + ACTION_LIST_ALL
>  } actions;
>  
>  static struct option config_options[] = {
> @@ -31,8 +32,292 @@ static struct option config_options[] = {
>   OPT_GROUP("Action"),
>   OPT_SET_UINT('l', "list", ,
>"show current config variables", ACTION_LIST),
> + OPT_SET_UINT('a', "list-all", ,
> +  "show current and all possible config variables with 
> default values",
> +  ACTION_LIST_ALL),
>   OPT_END()
>  };
> +
> +/* section names */
> +#define COLORS "colors"
> +#define TUI "tui"
> +#define BUILDID "buildid"
> +#define ANNOTATE "annotate"
> +#define GTK "gtk"
> +#define PAGER "pager"
> +#define HELP "help"
> +#define HIST "hist"
> +#define UI "ui"
> +#define CALL_GRAPH "call-graph"
> +#define REPORT "report"
> +#define TOP "top"
> +#define MAN "man"
> +#define KMEM "kmem"
> +
> +/* config variable types */
> +#define TYPE_INT "int"
> +#define TYPE_LONG "long"
> +#define TYPE_DIRNAME "dirname"
> +#define TYPE_BOOL "bool"
> +
> +static struct default_configset {
> + const char *section_name;
> + const char *name, *value, *type;
> +
> +} default_configsets[] = {

I think it should in sync with the actual value.  So how about
changing the code to use this table instead of hard-coded value?

Maybe something like this?  (untested!!)

  enum config_idx {
CONFIG_COLORS_TOP,
CONFIG_COLORS_MEDIUM,
CONFIG_COLORS_NORMAL,
...
CONFIG_ITEM_MAX,
  };

  enum config_type {
CONFIG_TYPE_BOOL,
CONFIG_TYPE_INT,
CONFIG_TYPE_STRING,
...
  };

  struct config_item {
const char *section;
const char *name;
union {
  bool   b;
  inti;
  char   *s;
  ...
} value;
enum config_type type;
  }

  #define CONF_VAR(_sec, _name, _field, _val, _type) \
  { .section = _sec, .name = name, .value._field = _val, .type = _type }

  #define CONF_BOOL_VAR(_idx, _sec, _name, _val) \
[CONFIG_##_idx] = CONF_VAR(_sec, _name, b, _val, CONFIG_TYPE_BOOL)
  #define CONF_INT_VAR(_idx, _sec, _name, _val) \
[CONFIG_##_idx] = CONF_VAR(_sec, _name, i, _val, CONFIG_TYPE_INT)
  #define CONF_STR_VAR(_idx, _sec, _name, _val) \
[CONFIG_##_idx] = CONF_VAR(_sec, _name, s, _val, CONFIG_TYPE_STRING)


  struct config_item default_configs[] = {
CONF_STR_VAR(COLORS_TOP, "colors", "top", "red, default"),
CONF_STR_VAR(COLORS_TOP, "colors", "medium", "green, default"),
...
CONF_BOOL_VAR(UI_SHOW_HEADERS, "ui", "show-headers", true),
...
  };


And then we can use it, for example, like below..

util/symbol.c:

struct symbol_conf symbol_conf = {
  ...
  .show_hist_headers = default_configs[CONFIG_UI_SHOW_HEADERS].value.b,
  ...
};

or

#define CONFIG_DEFAULT_BOOL(_sec, _name) \
  default_configs[CONFIG_##_sec##_##_name].value.b
...

struct symbol_conf symbol_conf = {
  ...
  .show_hist_headers = CONFIG_DEFAULT_BOOL(UI, SHOW_HEADERS),
  ...
};


Thanks,
Namhyung


> + {
> + .section_name = COLORS,
> + .name = "top",
> + .value = "red, default",
> + .type = NULL,
> + },
> + {
> + .section_name = COLORS,
> + .name = "medium",
> + .value = "green, default",
> + .type = NULL,
> + },
> + {
> + .section_name = COLORS,
> + .name = "normal",
> + .value = "lightgray, default",
> + .type = 

Re: [PATCH 0/5] MADV_FREE refactoring and fix KSM page

[Minchan Kim]

On Wed, Oct 21, 2015 at 01:43:53AM +0300, Kirill A. Shutemov wrote:
> On Tue, Oct 20, 2015 at 02:36:51PM -0700, Andrew Morton wrote:
> > On Tue, 20 Oct 2015 16:21:09 +0900 Minchan Kim  wrote:
> > 
> > > 
> > > I reviewed THP refcount redesign patch and It seems below patch fixes
> > > MADV_FREE problem. It works well for hours.
> > > 
> > > >From 104a0940b4c0f97e61de9fee0fd602926ff28312 Mon Sep 17 00:00:00 2001
> > > From: Minchan Kim 
> > > Date: Tue, 20 Oct 2015 16:00:52 +0900
> > > Subject: [PATCH] mm: mark head page dirty in split_huge_page
> > > 
> > > In thp split in old THP refcount, we mappped all of pages
> > > (ie, head + tails) to pte_mkdirty and mark PG_flags to every
> > > tail pages.
> > > 
> > > But with THP refcount redesign, we can lose dirty bit in page table
> > > and PG_dirty for head page if we want to free the THP page using
> > > migration_entry.
> > > 
> > > It ends up discarding head page by madvise_free suddenly.
> > > This patch fixes it by mark the head page PG_dirty when VM splits
> > > the THP page.
> > > 
> > > Signed-off-by: Minchan Kim 
> > > ---
> > >  mm/huge_memory.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > > index adccfb48ce57..7fbbd42554a1 100644
> > > --- a/mm/huge_memory.c
> > > +++ b/mm/huge_memory.c
> > > @@ -3258,6 +3258,7 @@ static void __split_huge_page(struct page *page, 
> > > struct list_head *list)
> > >   atomic_sub(tail_mapcount, >_count);
> > >  
> > >   ClearPageCompound(head);
> > > + SetPageDirty(head);
> > >   spin_unlock_irq(>lru_lock);
> > >  
> > >   unfreeze_page(page_anon_vma(head), head);
>  
> Sorry, I've missed the email at first.
> 
> > This appears to be a bugfix against Kirill's "thp: reintroduce
> > split_huge_page()"?
> > 
> > Yes, __split_huge_page() is marking the tail pages dirty but forgot
> > about the head page
> > 
> > You say "we can lose dirty bit in page table" but I don't see how the
> > above patch fixes that?
> 
> I think the problem is in unfreeze_page_vma(), where I missed dirtying
> pte.
> 
> > Why does __split_huge_page() unconditionally mark the pages dirty, btw?
> > Is it because the THP page was known to be dirty?
> 
> THP doesn't have backing storage and cannot be swapped out without
> splitting, therefore always dirty. (huge zero page is exception, I guess).

It's right until now but I think we need more(e.g. is_dirty_migration_entry,
make_migration_entry(struct page *page, int write, int dirty) in terms of
MADV_FREE to keep dirty bit of pte rather than making pages dirty
unconditionally.

For example, we could call madvise_free to THP page so madvise_free clears
dirty bit of pmd without split THP pages(ie, lazy split, maybe you suggest
it, thanks!) instantly. Then, when VM tries to reclaim the THP page and
splits it, every page will be marked PG_dirty or pte_mkdirty even if
there is no write ever since then so madvise_free can never discard it
although we could.

Anyway it shouldn't be party-pooper. It could be enhanced and I will check
it.


> 
> > If so, the head page already had PG_dirty, so this patch doesn't do
> > anything.
> 
> PG_dirty appears on struct page as result of transferring from dirty bit
> in page tables. There's no guarantee that it's happened.
> 
> > freeze_page(), unfreeze_page() and their callees desperately need some
> > description of what they're doing.  Kirill, could you cook somethnig up
> > please?
> 
> Minchan, could you test patch below instead?

I think it will definitely work and more right fix than mine because
it covers split_huge_page_to_list's error path(ie,

unfreeze_page(anon_vma, head);
ret = -EBUSY;
}


I will queue it to test machine.

..
Zzzz
..

After 2 hours, I don't see any problemso far but I have a question below.

> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 86924cc34bac..ea1f3805afa3 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3115,7 +3115,7 @@ static void unfreeze_page_vma(struct vm_area_struct 
> *vma, struct page *page,
>  
> entry = pte_mkold(mk_pte(page, vma->vm_page_prot));
> if (is_write_migration_entry(swp_entry))
> -   entry = maybe_mkwrite(entry, vma);
> +   entry = maybe_mkwrite(pte_mkdirty(entry), vma);

Why should we do pte_mkdiry only if is_write_migration_entry is true?
Doesn't it lose a dirty bit again if someone changes protection
from RW to R?

>  
> flush_dcache_page(page);
> set_pte_at(vma->vm_mm, address, pte + i, entry);
> -- 
>  Kirill A. Shutemov
--
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] libata: add support for NCQ commands for SG interface

[Vinayak Kale]

Hi Tejun,

On Sat, Oct 17, 2015 at 5:18 PM,   wrote:
> From: Vinayak Kale 
>
> This patch is needed to make NCQ commands with FPDMA protocol value
> (eg READ/WRITE FPDMA) work over SCSI Generic (SG) interface.
>
> Signed-off-by: Vinayak Kale 
> ---
>  drivers/ata/libata-scsi.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index 0d7f0da..5b0a5ab 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -2914,12 +2914,14 @@ ata_scsi_map_proto(u8 byte1)
> case 5: /* PIO Data-out */
> return ATA_PROT_PIO;
>
> +   case 12:/* FPDMA */
> +   return ATA_PROT_NCQ;
> +
> case 0: /* Hard Reset */
> case 1: /* SRST */
> case 8: /* Device Diagnostic */
> case 9: /* Device Reset */
> case 7: /* DMA Queued */
> -   case 12:/* FPDMA */
> case 15:/* Return Response Info */
> default:/* Reserved */
> break;
> @@ -2963,7 +2965,7 @@ static unsigned int ata_scsi_pass_thru(struct 
> ata_queued_cmd *qc)
> tf->hob_lbal = cdb[7];
> tf->hob_lbam = cdb[9];
> tf->hob_lbah = cdb[11];
> -   tf->flags |= ATA_TFLAG_LBA48;
> +   tf->flags |= (ATA_TFLAG_LBA48 | ATA_TFLAG_LBA);
> } else
> tf->flags &= ~ATA_TFLAG_LBA48;
>
> @@ -2992,6 +2994,10 @@ static unsigned int ata_scsi_pass_thru(struct 
> ata_queued_cmd *qc)
> tf->command = cdb[9];
> }
>
> +   /* For NCQ commands with FPDMA protocol, copy the tag value */
> +   if (tf->protocol == ATA_PROT_NCQ)
> +   tf->nsect = qc->tag << 3;
> +
> /* enforce correct master/slave bit */
> tf->device = dev->devno ?
> tf->device | ATA_DEV1 : tf->device & ~ATA_DEV1;
> --
> 1.9.1
>
Any comments on this?

Regards,
Vinayak
--
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] drivers/pinctrl: Add the concept of an "init" state

[Greg KH]

On Tue, Oct 20, 2015 at 09:15:06PM -0700, Douglas Anderson wrote:
> For pinctrl the "default" state is applied to pins before the driver's
> probe function is called.  This is normally a sensible thing to do,
> but in some cases can cause problems.  That's because the pins will
> change state before the driver is given a chance to program how those
> pins should behave.
> 
> As an example you might have a regulator that is controlled by a PWM
> (output high = high voltage, output low = low voltage).  The firmware
> might leave this pin as driven high.  If we allow the driver core to
> reconfigure this pin as a PWM pin before the PWM's probe function runs
> then you might end up running at too low of a voltage while we probe.
> 
> Let's introudce a new "init" state.  If this is defined we'll set
> pinctrl to this state before probe and then "default" after probe
> (unless the driver explicitly changed states already).
> 
> An alternative idea that was thought of was to use the pre-existing
> "sleep" or "idle" states and add a boolean property that we should
> start in that mode.  This was not done because the "init" state is
> needed for correctness and those other states are only present (and
> only transitioned in to and out of) when (optional) power management
> is enabled.
> 
> Signed-off-by: Douglas Anderson 
> Acked-by: Greg Kroah-Hartman 
> Tested-by: Caesar Wang 
> ---
> Changes in v3:
> - Moved declarations to pinctrl/devinfo.h
> - Fixed author/SoB
> 
> Changes in v2:
> - Added comment to pinctrl_init_done() as per Linus W.
> 
> As mentioned in v2 repost, reposted after 1 year of no activity since
> Caesar Wang found a use for this.  See
> .  I hope it's OK that I
> left Greg KH's Ack...

The ack from me is fine.

thanks,

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] module: Prevent recursion bug caused by module RCU check

[Rusty Russell]

Peter Zijlstra  writes:
> On Tue, Oct 20, 2015 at 06:53:31PM +0200, Peter Zijlstra wrote:
>> Also, would it not be better to fix WARN_ON_ONCE() instead?
>> 
>
> Clearly I'm an idiot and should stay away from the computer...

Acked-by: Rusty Russell 

(I mean, the patch, not the comment on Peter's intellect!  If he's too
 dumb to go near computers, most of us should probably shy away from
 anything with buttons)

Thanks,
Rusty.

> ---
>  include/asm-generic/bug.h | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 630dd2372238..d0972fc8433f 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -110,9 +110,10 @@ extern void warn_slowpath_null(const char *file, const 
> int line);
>   static bool __section(.data.unlikely) __warned; \
>   int __ret_warn_once = !!(condition);\
>   \
> - if (unlikely(__ret_warn_once))  \
> - if (WARN_ON(!__warned)) \
> - __warned = true;\
> + if (unlikely(__ret_warn_once && !__warned)) {   \
> + __warned = true;\
> + WARN_ON(1); \
> + }   \
>   unlikely(__ret_warn_once);  \
>  })
>  
> @@ -120,9 +121,10 @@ extern void warn_slowpath_null(const char *file, const 
> int line);
>   static bool __section(.data.unlikely) __warned; \
>   int __ret_warn_once = !!(condition);\
>   \
> - if (unlikely(__ret_warn_once))  \
> - if (WARN(!__warned, format))\
> - __warned = true;\
> + if (unlikely(__ret_warn_once && !__warned)) {   \
> + __warned = true;\
> + WARN(1, format);\
> + }   \
>   unlikely(__ret_warn_once);  \
>  })
>  
--
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/

平时最多也就联系了三千家，全球还有十几万客户在哪里？

[Rehanna]

您好:
您还在用ali平台开发外贸客户?
   还在使用展会宣传企业和产品?
 你out了!!!
 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 
 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？
 加QQ2652697913给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。
 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。
--
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 4/7] ARM: dts: qcom: msm8974-honami: Add sdhci1 node

[Bjorn Andersson]

Introduce the eMMC sdhci node and its pinctrl state.

Signed-off-by: Bjorn Andersson 
---
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   | 27 ++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 8c0753a32b20..de3529d1a8ca 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -277,6 +277,19 @@
 };
 
  {
+   sdhci@f9824900 {
+   status = "ok";
+
+   vmmc-supply = <_l20>;
+   vqmmc-supply = <_s3>;
+
+   bus-width = <8>;
+   non-removable;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_a>;
+   };
+
serial@f991e000 {
status = "ok";
 
@@ -302,6 +315,20 @@
bias-disable;
};
};
+
+   sdhc1_pin_a: sdhc1-pin-active {
+   clk {
+   pins = "sdc1_clk";
+   drive-strength = <16>;
+   bias-disable;
+   };
+
+   cmd-data {
+   pins = "sdc1_cmd", "sdc1_data";
+   drive-strength = <10>;
+   bias-pull-up;
+   };
+   };
};
 };
 
-- 
2.4.2

--
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 3/7] ARM: dts: qcom: msm8974-honami: Introduce gpio-keys

[Bjorn Andersson]

Introduce a gpio-keys node defining the physical keys of the Honami and
the associated pinctrl state.

Signed-off-by: Bjorn Andersson 
---
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   | 45 ++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 5768c97bb124..8c0753a32b20 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -2,6 +2,7 @@
 #include "qcom-pm8841.dtsi"
 #include "qcom-pm8941.dtsi"
 #include 
+#include 
 #include 
 
 / {
@@ -16,6 +17,42 @@
stdout-path = "serial0:115200n8";
};
 
+   gpio-keys {
+   compatible = "gpio-keys";
+   input-name = "gpio-keys";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_keys_pin_a>;
+
+   volume-down {
+   label = "volume_down";
+   gpios = <_gpios 2 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+
+   camera-snapshot {
+   label = "camera_snapshot";
+   gpios = <_gpios 3 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+
+   camera-focus {
+   label = "camera_focus";
+   gpios = <_gpios 4 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+
+   volume-up {
+   label = "volume_up";
+   gpios = <_gpios 5 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+   };
+
memory@0 {
reg = <0 0x4000>, <0x4000 0x4000>;
device_type = "memory";
@@ -275,6 +312,14 @@
pins = "gpio21";
function = "normal";
};
+
+   gpio_keys_pin_a: gpio-keys-active {
+   pins = "gpio2", "gpio3", "gpio4", "gpio5";
+   function = "normal";
+
+   bias-pull-up;
+   power-source = ;
+   };
};
 
coincell@2800 {
-- 
2.4.2

--
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 2/7] ARM: dts: qcom: msm8974-honami: Add regulator nodes for Honami

[Bjorn Andersson]

Signed-off-by: Bjorn Andersson 
---

This patch was previously submitted standalone, minor updates has been
done to correct the 8841 voltage ranges and the logic surrounding
vreg_boost.

l20 is marked for 200mA current consumption to force the eMMC supply
into HPM, to allow reliable mounting.

 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   | 226 +
 1 file changed, 226 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 6f7e4ef4ccf7..5768c97bb124 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -1,6 +1,8 @@
 #include "qcom-msm8974.dtsi"
 #include "qcom-pm8841.dtsi"
 #include "qcom-pm8941.dtsi"
+#include 
+#include 
 
 / {
model = "Sony Xperia Z1";
@@ -18,6 +20,223 @@
reg = <0 0x4000>, <0x4000 0x4000>;
device_type = "memory";
};
+
+   smd {
+   rpm {
+   rpm_requests {
+   pm8841-regulators {
+   s1 {
+   regulator-min-microvolt = 
<675000>;
+   regulator-max-microvolt = 
<105>;
+   };
+
+   s2 {
+   regulator-min-microvolt = 
<50>;
+   regulator-max-microvolt = 
<105>;
+   };
+
+   s3 {
+   regulator-min-microvolt = 
<50>;
+   regulator-max-microvolt = 
<105>;
+   };
+
+   s4 {
+   regulator-min-microvolt = 
<50>;
+   regulator-max-microvolt = 
<105>;
+   };
+   };
+
+   pm8941-regulators {
+   vdd_l1_l3-supply = <_s1>;
+   vdd_l2_lvs1_2_3-supply = <_s3>;
+   vdd_l4_l11-supply = <_s1>;
+   vdd_l5_l7-supply = <_s2>;
+   vdd_l6_l12_l14_l15-supply = 
<_s2>;
+   vdd_l9_l10_l17_l22-supply = 
<_boost>;
+   vdd_l13_l20_l23_l24-supply = 
<_boost>;
+   vdd_l21-supply = <_boost>;
+   vin_5vs-supply = <_5v>;
+
+   s1 {
+   regulator-min-microvolt = 
<130>;
+   regulator-max-microvolt = 
<130>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   s2 {
+   regulator-min-microvolt = 
<215>;
+   regulator-max-microvolt = 
<215>;
+   regulator-boot-on;
+   };
+
+   s3 {
+   regulator-min-microvolt = 
<180>;
+   regulator-max-microvolt = 
<180>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   s4 {
+   regulator-min-microvolt = 
<500>;
+   regulator-max-microvolt = 
<500>;
+   };
+
+   l1 {
+   regulator-min-microvolt = 
<1225000>;
+   regulator-max-microvolt = 
<1225000>;
+
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   l2 {
+   regulator-min-microvolt = 
<120>;
+   regulator-max-microvolt = 
<120>;
+   };
+
+   l3 {
+ 

[PATCH 7/7] ARM: defconfig: Update qcom_defconfig

[Bjorn Andersson]

This enables smem, smd, rpm, regulators, pmic pinctrl and hwspinlock as
these platform features are now merged. It enables gpio-keys as this is
used by most boards and enables fhandle and cgroups, so we can boot
systemd.

Signed-off-by: Bjorn Andersson 
---

MSM_IOMMU is marked as BROKEN as of next-20151020, the other options
that is disabled are done so because they are now default on.

 arch/arm/configs/qcom_defconfig | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index ff7985ba226e..0efe0741b5be 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -1,8 +1,10 @@
 CONFIG_SYSVIPC=y
+CONFIG_FHANDLE=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
+CONFIG_CGROUPS=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_SYSCTL_SYSCALL=y
 CONFIG_KALLSYMS_ALL=y
@@ -25,7 +27,6 @@ CONFIG_SMP=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
-CONFIG_HIGHPTE=y
 CONFIG_CLEANCACHE=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
@@ -78,6 +79,7 @@ CONFIG_USB_USBNET=y
 # CONFIG_USB_NET_ZAURUS is not set
 CONFIG_INPUT_EVDEV=y
 # CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
 # CONFIG_MOUSE_PS2 is not set
 CONFIG_INPUT_JOYSTICK=y
 CONFIG_INPUT_TOUCHSCREEN=y
@@ -99,16 +101,21 @@ CONFIG_PINCTRL_APQ8084=y
 CONFIG_PINCTRL_IPQ8064=y
 CONFIG_PINCTRL_MSM8960=y
 CONFIG_PINCTRL_MSM8X74=y
+CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
+CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
 CONFIG_GPIOLIB=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
+CONFIG_CHARGER_QCOM_SMBB=y
 CONFIG_POWER_RESET=y
 CONFIG_POWER_RESET_MSM=y
 CONFIG_THERMAL=y
 CONFIG_MFD_QCOM_RPM=y
+CONFIG_MFD_SPMI_PMIC=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_QCOM_RPM=y
+CONFIG_REGULATOR_QCOM_SMD_RPM=y
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_FB=y
 CONFIG_SOUND=y
@@ -145,16 +152,17 @@ CONFIG_MSM_GCC_8660=y
 CONFIG_MSM_LCC_8960=y
 CONFIG_MSM_MMCC_8960=y
 CONFIG_MSM_MMCC_8974=y
-CONFIG_MSM_IOMMU=y
+CONFIG_HWSPINLOCK_QCOM=y
 CONFIG_QCOM_GSBI=y
 CONFIG_QCOM_PM=y
+CONFIG_QCOM_SMEM=y
+CONFIG_QCOM_SMD=y
+CONFIG_QCOM_SMD_RPM=y
 CONFIG_PHY_QCOM_APQ8064_SATA=y
 CONFIG_PHY_QCOM_IPQ806X_SATA=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT3_FS=y
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
-CONFIG_EXT4_FS=y
 CONFIG_FUSE_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
-- 
2.4.2

--
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 5/7] ARM: dts: qcom: msm8974-honami: Add uSD slot nodes

[Bjorn Andersson]

Add and enable the sdhci2 slot, the pinctrl configuration and card
detect.

Signed-off-by: Bjorn Andersson 
---
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   | 37 ++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index de3529d1a8ca..113cc18ee2f5 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -290,6 +290,20 @@
pinctrl-0 = <_pin_a>;
};
 
+   sdhci@f98a4900 {
+   status = "ok";
+
+   bus-width = <4>;
+
+   vmmc-supply = <_l21>;
+   vqmmc-supply = <_l13>;
+
+   cd-gpios = < 62 GPIO_ACTIVE_LOW>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_a>, <_cd_pin_a>;
+   };
+
serial@f991e000 {
status = "ok";
 
@@ -329,6 +343,29 @@
bias-pull-up;
};
};
+
+   sdhc2_cd_pin_a: sdhc2-cd-pin-active {
+   pins = "gpio62";
+   function = "gpio";
+
+   drive-strength = <2>;
+   bias-disable;
+};
+
+   sdhc2_pin_a: sdhc2-pin-active {
+   clk {
+   pins = "sdc2_clk";
+   drive-strength = <10>;
+   bias-disable;
+   };
+
+   cmd-data {
+   pins = "sdc2_cmd", "sdc2_data";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+   };
+
};
 };
 
-- 
2.4.2

--
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 6/7] ARM: dts: qcom: msm8974-honami: Specify charging parameters

[Bjorn Andersson]

Signed-off-by: Bjorn Andersson 
---

Echoing a reasonable limit into [1] is required as there's currently no
way for this value to be propagated from the USB stack to the charging
driver.  Otherwise the block will pull maximum 100mA off USB, which is
not enough to actually charge the running platform.

[1] /sys/class/power_supply/smbb-usbin/charge_control_limit

 arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 113cc18ee2f5..1cf455fff3c2 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -371,6 +371,17 @@
 
 _bus {
pm8941@0 {
+   charger@1000 {
+   qcom,fast-charge-safe-current = <150>;
+   qcom,fast-charge-current-limit = <150>;
+   qcom,dc-current-limit = <180>;
+   qcom,fast-charge-safe-voltage = <440>;
+   qcom,fast-charge-high-threshold-voltage = <435>;
+   qcom,fast-charge-low-threshold-voltage = <340>;
+   qcom,auto-recharge-threshold-voltage = <420>;
+   qcom,minimum-input-voltage = <430>;
+   };
+
gpios@c000 {
boost_bypass_n_pin: boost-bypass {
pins = "gpio21";
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/7] ARM: dts: qcom: msm8974-honami: Define pinctrl state for blsp_uart2

[Bjorn Andersson]

Make sure the blsp1_uart2 pins are in the correct state for the uart.

Signed-off-by: Bjorn Andersson 
---
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   | 23 ++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 016f9ad9392a..6f7e4ef4ccf7 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -23,6 +23,29 @@
  {
serial@f991e000 {
status = "ok";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart2_pin_a>;
+   };
+
+   pinctrl@fd51 {
+   blsp1_uart2_pin_a: blsp1-uart2-pin-active {
+   rx {
+   pins = "gpio5";
+   function = "blsp_uart2";
+
+   drive-strength = <2>;
+   bias-pull-up;
+   };
+
+   tx {
+   pins = "gpio4";
+   function = "blsp_uart2";
+
+   drive-strength = <4>;
+   bias-disable;
+   };
+   };
};
 };
 
-- 
2.4.2

--
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 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Jassi Brar]

On Wed, Sep 23, 2015 at 5:44 AM, Dave Gerlach  wrote:
> The mailbox framework controls the transmission queue and requires
> either its controller implementations or clients to run the state
> machine for the Tx queue. The OMAP mailbox controller uses a Tx-ready
> interrupt as the equivalent of a Tx-done interrupt to run this Tx
> queue state-machine.
>
> The WkupM3 processor on AM33xx and AM43xx SoCs is used to offload
> certain PM tasks, like doing the necessary operations for Device
> PM suspend/resume or for entering lower c-states during cpuidle.
>
> The CPUIdle on AM33xx requires the messages to be sent without
> having to trigger the Tx-ready interrupts, as the interrupt
> would immediately terminate the CPUIdle operation. Support for
> this has been added by introducing a DT quirk, "ti,mbox-send-noirq"
> and using it to modify the normal OMAP mailbox controller behavior
> on the sub-mailboxes used to communicate with the WkupM3 remote
> processor. This also requires the wkup_m3_ipc driver to adjust
> its mailbox usage logic to run the Tx state machine.
>
Probably Suman already updated you on what was discussed about this
patch at Connect-SFO. My suggestion was to drive TX poll-based (I
know, I know...) because the "interrupt-driven" is just an impression,
it is not really. You get the interrupt as soon as you enable it
because it is the "FIFO not-full" interrupt which is always because
there is always space left after writing to the fifo. The cons are
that it buffers messages hidden from the client while abusing the irq.
If you guys could break away from the "interrupt-driven" illusion and
use polling which it actually is, everything falls into place and you
avoid the "ti,mbox-send-noirq" quirk.

  Anyways I am OK too, if you guys want to fix it with a platform
specific quirk. Let me know I'll pick this patch.

Cheers!
--
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] extcon: gpio: Add the support for Device tree bindings

[Chanwoo Choi]

This patch adds the support for Device tree bindings of extcon-gpio driver.
The extcon-gpio device tree node must include the both 'extcon-id' and
'extcon-gpio' property.

For exmaple:
usb_cable: extcon-gpio-0 {
compatible = "extcon-gpio";
extcon-id = ;
extcon-gpio = < 1 GPIO_ACTIVE_HIGH>;
}

ta_cable: extcon-gpio-1 {
compatible = "extcon-gpio";
extcon-id = ;
extcon-gpio = < 2 GPIO_ACTIVE_LOW>;
debounce-ms = <50>; /* 50 millisecond */
wakeup-source;
}

_usb {
extcon = <_cable>;
};

 {
extcon = <_cable>;
};

Signed-off-by: Chanwoo Choi 
Signed-off-by: MyungJoo Ham 
---
Changes from v2:
- Add the more description for 'extcon-id' property in documentation

Changes from v1:
- Create the include/dt-bindings/extcon/extcon.h including the identification
of external connector. These definitions are used in dts file.
- Fix error if CONFIG_OF is disabled.
- Add signed-off tag by Myungjoo Ham

 .../devicetree/bindings/extcon/extcon-gpio.txt |  43 
 drivers/extcon/extcon-gpio.c   | 116 -
 include/dt-bindings/extcon/extcon.h|  47 +
 include/linux/extcon/extcon-gpio.h |   8 +-
 4 files changed, 184 insertions(+), 30 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
 create mode 100644 include/dt-bindings/extcon/extcon.h

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
new file mode 100644
index ..1e011f9c8536
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -0,0 +1,43 @@
+GPIO Extcon device
+
+This is a virtual device used to generate the specific cable states from the
+GPIO pin.
+
+Required properties:
+- compatible: Must be "extcon-gpio".
+- extcon-id: The extcon support the various type of external connector to check
+  whether connector is attached or detached. The each external connector has
+  the unique number to identify it. So this property includes the unique number
+  which indicates the specific external connector. When external connector is
+  attached or detached, GPIO pin detect the changed state. See include/
+  dt-bindings/extcon/extcon.h which defines the unique number for supported
+  external connector from extcon framework.
+- extcon-gpio: GPIO pin to detect the external connector. See gpio binding.
+
+Optional properties:
+- debounce-ms: the debounce dealy for GPIO pin in millisecond.
+- wakeup-source: Boolean, extcon can wake-up the system.
+
+Example: Examples of extcon-gpio node as listed below:
+
+   usb_cable: extcon-gpio-0 {
+   compatible = "extcon-gpio";
+   extcon-id = ;
+   extcon-gpio = < 1 GPIO_ACTIVE_HIGH>;
+   }
+
+   ta_cable: extcon-gpio-1 {
+   compatible = "extcon-gpio";
+   extcon-id = ;
+   extcon-gpio = < 2 GPIO_ACTIVE_LOW>;
+   debounce-ms = <50>; /* 50 millisecond */
+   wakeup-source;
+   }
+
+   _usb {
+   extcon = <_cable>;
+   };
+
+{
+   extcon = <_cable>;
+   };
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 279ff8f6637d..69b560d136cd 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -1,11 +1,9 @@
 /*
  * extcon_gpio.c - Single-state GPIO extcon driver based on extcon class
  *
- * Copyright (C) 2008 Google, Inc.
- * Author: Mike Lockwood 
- *
- * Modified by MyungJoo Ham  to support extcon
- * (originally switch class is supported)
+ * Copyright (C) 2015 Chanwoo Choi , Samsung Electronics
+ * Copyright (C) 2012 MyungJoo Ham , Samsung 
Electronics
+ * Copyright (C) 2008 Mike Lockwood , Google, Inc.
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -26,12 +24,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 struct gpio_extcon_data {
struct extcon_dev *edev;
int irq;
+   bool irq_wakeup;
struct delayed_work work;
unsigned long debounce_jiffies;
 
@@ -49,7 +49,7 @@ static void gpio_extcon_work(struct work_struct *work)
state = gpiod_get_value_cansleep(data->id_gpiod);
if (data->pdata->gpio_active_low)
state = !state;
-   extcon_set_state(data->edev, state);
+   extcon_set_cable_state_(data->edev, data->pdata->extcon_id, state);
 }
 
 static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
@@ -61,19 +61,50 @@ static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-static int gpio_extcon_init(struct device *dev, struct gpio_extcon_data 

[PATCH v3] powerpc/prom: Avoid reference to potentially freed memory

[Christophe JAILLET]

of_get_property() is used inside the loop, but then the reference to the
node is dropped before dereferencing the prop pointer, which could by then
point to junk if the node has been freed.
Instead use of_property_read_u32() to actually read the property
value before dropping the reference.

Use of_get_next_parent to simplify code.

Signed-off-by: Christophe JAILLET 
---
v2: Fix missing '{'
v3: Use of_get_next_parent to simply code
*** COMPILE-TESTED ONLY ***
---
 arch/powerpc/kernel/prom.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index bef76c5..ba29c0d 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -783,17 +783,14 @@ void __init early_get_first_memblock_info(void *params, 
phys_addr_t *size)
 int of_get_ibm_chip_id(struct device_node *np)
 {
of_node_get(np);
-   while(np) {
-   struct device_node *old = np;
-   const __be32 *prop;
+   while (np) {
+   u32 chip_id;
 
-   prop = of_get_property(np, "ibm,chip-id", NULL);
-   if (prop) {
+   if (!of_property_read_u32(np, "ibm,chip-id", _id)) {
of_node_put(np);
-   return be32_to_cpup(prop);
+   return chip_id;
}
-   np = of_get_parent(np);
-   of_node_put(old);
+   np = of_get_next_parent(np);
}
return -1;
 }
-- 
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 v1 2/2] ARM: dts: rockchip: Add the OTP gpio pinctrl

[Doug Anderson]

Caesar,

On Tue, Oct 20, 2015 at 7:43 PM, Caesar Wang  wrote:
> We need the OTP pin is gpio state before resetting the TSADC controller,
> since the tshut polarity will generate a high signal.

It might or might not be "high" depending on polarity, right?  It's
just possible that it could glitch during probe.  Other than that nit,
this seems fine to me.

If it's not too much trouble it'd be nice if you could spin with the
description change.  Otherwise:

Reviewed-by: Douglas Anderson 
--
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 v1 1/2] dt-bindings: Sync the dts to this document

[Doug Anderson]

Hi,

On Tue, Oct 20, 2015 at 7:42 PM, Caesar Wang  wrote:
> Add the OTP gpio state, we need switch the pin to gpio state
> before the TSADC controller is reset.
>
> Signed-off-by: Caesar Wang 
> ---
>
> Changes in v1:
>   - As the Doug comments, add the 'init' property to sync document.
>
>  Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Seems reasonable to me.  I do wonder if we need to make it more
obvious that things might glitch if the "init" pinctrl isn't there?
...probably not too critical unless others think it needs to be more
obvious...

Reviewed-by: Douglas Anderson 
--
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 v7 2/7] perf config: Add '--system' and '--user' options to select which config file is used

[Namhyung Kim]

On Sun, Oct 04, 2015 at 04:35:05PM +0900, Taeung Song wrote:
> Which config file is used is decided in only perf_config().
> And a perf-config command depend on perf_config() to list
> config variables with values. So add '--system' and '--user'
> options to select which config file to be used without perf_config().
> 
> The file-options '--system' means $(sysconfdir)/perfconfig and
> '--user' means $HOME/.perfconfig. If file-option isn't used,
> both system and user config file is read
> but user config have priority. The syntax examples are like below
> 
> perf config [] [options]
> 
> a specific config file.
> # perf config --user | --system
> or
> both user and system config file.
> # perf config
> 
> In addition, use List data structure which has config info.
> Because perf_config() isn't used any more and directly collect
> config info by perf_config_from_file() with a specific config
> file path. Whichever config file or both are used, list is required
> to keep and handle config variables and values.
> 
> Signed-off-by: Taeung Song 
> ---

Hmm.. Isn't it just a matter of setting of config_exclusive_filename
variable?  And then we can still use perf_config() no?

I think it'd be better to split the collecting configs part into a
separate patch.

Thanks,
Namhyung


>  tools/perf/Documentation/perf-config.txt |  14 ++-
>  tools/perf/builtin-config.c  | 163 
> +--
>  tools/perf/util/cache.h  |  15 +++
>  tools/perf/util/config.c |   4 +-
>  4 files changed, 187 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/perf/Documentation/perf-config.txt 
> b/tools/perf/Documentation/perf-config.txt
> index e8013b3..a42d409 100644
> --- a/tools/perf/Documentation/perf-config.txt
> +++ b/tools/perf/Documentation/perf-config.txt
> @@ -8,7 +8,7 @@ perf-config - Get and set variables in a configuration file.
>  SYNOPSIS
>  
>  [verse]
> -'perf config' -l | --list
> +'perf config' [] -l | --list
>  
>  DESCRIPTION
>  ---
> @@ -21,6 +21,14 @@ OPTIONS
>  --list::
>   Show current config variables, name and value, for all sections.
>  
> +--user::
> + For writing and reading options: write to user
> + '$HOME/.perfconfig' file or read it.
> +
> +--system::
> + For writing and reading options: write to system-wide
> + '$(sysconfdir)/perfconfig' or read it.
> +
>  CONFIGURATION FILE
>  --
>  
> @@ -33,6 +41,10 @@ store a system-wide default configuration.
>  The variables are divided into sections. In each section, the variables
>  that are composed of a name and value.
>  
> +When reading or writing, the values are read from the system and user
> +configuration files by default, and options '--system' and '--user'
> +can be used to tell the command to read from or write to only that location.
> +
>  Syntax
>  ~~
>  
> diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
> index 30b1500..92be3eb 100644
> --- a/tools/perf/builtin-config.c
> +++ b/tools/perf/builtin-config.c
> @@ -13,8 +13,10 @@
>  #include "util/util.h"
>  #include "util/debug.h"
>  
> +static bool use_system_config, use_user_config;
> +
>  static const char * const config_usage[] = {
> - "perf config [options]",
> + "perf config [] [options]",
>   NULL
>  };
>  
> @@ -23,19 +25,150 @@ enum actions {
>  } actions;
>  
>  static struct option config_options[] = {
> + OPT_GROUP("Config file location"),
> + OPT_BOOLEAN(0, "system", _system_config, "use system config file"),
> + OPT_BOOLEAN(0, "user", _user_config, "use user config file"),
>   OPT_GROUP("Action"),
>   OPT_SET_UINT('l', "list", ,
>"show current config variables", ACTION_LIST),
>   OPT_END()
>  };
> +static int show_config(struct list_head *sections)
> +{
> + struct config_section *section;
> + struct config_element *element;
> +
> + list_for_each_entry(section, sections, list) {
> + list_for_each_entry(element, >element_head, list) {
> + printf("%s.%s=%s\n", section->name,
> +element->name, element->value);
> + }
> + }
> +
> + return 0;
> +}
>  
> -static int show_config(const char *key, const char *value,
> -void *cb __maybe_unused)
> +static struct config_section *find_section(struct list_head *sections,
> +const char *section_name)
>  {
> + struct config_section *section;
> +
> + list_for_each_entry(section, sections, list)
> + if (!strcmp(section->name, section_name))
> + return section;
> +
> + return NULL;
> +}
> +
> +static struct config_element *find_element(const char *name,
> +struct config_section *section)
> +{
> + struct config_element *element;
> +
> + list_for_each_entry(element, >element_head, list)
> +

Re: [PATCH v3 0/3] pstore: add pstore unregister

[Geliang Tang]

On Tue, Oct 20, 2015 at 08:01:20PM -0700, Kees Cook wrote:
> On Tue, Oct 20, 2015 at 7:52 PM, Geliang Tang  wrote:
> > On Tue, Oct 20, 2015 at 10:19:09AM -0700, Kees Cook wrote:
> >> On Tue, Oct 20, 2015 at 12:39 AM, Geliang Tang  wrote:
> >> > On Mon, Oct 19, 2015 at 10:56:54PM +, Luck, Tony wrote:
> >> >> Thanks for looking to close out this TODO item.
> >> >>
> >> >> The thing that scared me about unloading pstore was what happens to
> >> >> a process that is in the middle of reading some 
> >> >> /sys/fs/pstore/file-name-here
> >>
> >> Were you able to verify that this reading-while-rmmod case works correctly?
> >>
> >> -Kees
> >
> > $ sudo insmod zlib_deflate.ko
> > $ sudo insmod pstore.ko
> > $ lsmod
> > Module  Size  Used by
> > pstore 11225  0
> > zlib_deflate   18292  1 pstore
> >
> > $ sudo mount -t pstore pstore /sys/fs/pstore
> > $ lsmod
> > Module  Size  Used by
> > pstore 11225  1
> > zlib_deflate   18292  1 pstore
> >
> > $ sudo insmod reed_solomon.ko
> > $ sudo insmod ramoops.ko mem_address=0x4000 mem_size=0x40
> > $ lsmod
> > Module  Size  Used by
> > ramoops 9638  0
> > reed_solomon5150  1 ramoops
> > pstore 11225  2 ramoops
> > zlib_deflate   18292  1 pstore
> >
> > $ tail -f /sys/fs/pstore/console-ramoops-0 &
> > [1] 3483
> > $ lsmod
> > Module  Size  Used by
> > ramoops 9638  0
> > reed_solomon5150  1 ramoops
> > pstore 11225  3 ramoops
> > zlib_deflate   18292  1 pstore
> >
> > $ kill -9 3483
> > $ lsmod
> > Module  Size  Used by
> > ramoops 9638  0
> > reed_solomon5150  1 ramoops
> > pstore 11225  2 ramoops
> > zlib_deflate   18292  1 pstore
> >
> > $ sudo rmmod ramoops
> > $ lsmod
> > Module  Size  Used by
> > reed_solomon5150  0
> > pstore 11225  1
> > zlib_deflate   18292  1 pstore
> 
> What happens if you leave the tail running and try to rmmod ramoops?
> (I assume it'll just refuse.)
> 

It'll refuse if we try to unload pstore module. But we can unload
ramoops module. Because we only increase a reference count of pstore
module when the file is opened. We didn't increase ramoops module's
reference count.

Thanks.
Geliang Tang

--
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: [REPOST PATCH v2] drivers/pinctrl: Add the concept of an "init" state

[Doug Anderson]

Hi,

On Tue, Oct 20, 2015 at 7:46 PM, kbuild test robot  wrote:
> Hi Doug,
>
> [auto build test ERROR on pinctrl/for-next -- if it's inappropriate base, 
> please suggest rules for selecting the more suitable base]
>
> url:
> https://github.com/0day-ci/linux/commits/Douglas-Anderson/drivers-pinctrl-Add-the-concept-of-an-init-state/20151021-101131
> config: i386-randconfig-x004-10191220 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>drivers/base/dd.c: In function 'really_probe':
>>> drivers/base/dd.c:325:2: error: implicit declaration of function 
>>> 'pinctrl_init_done' [-Werror=implicit-function-declaration]
>  pinctrl_init_done(dev);
>  ^
>cc1: some warnings being treated as errors
>
> vim +/pinctrl_init_done +325 drivers/base/dd.c
>
>319  } else if (drv->probe) {
>320  ret = drv->probe(dev);
>321  if (ret)
>322  goto probe_failed;
>323  }
>324
>  > 325  pinctrl_init_done(dev);
>326
>327  if (dev->pm_domain && dev->pm_domain->sync)
>328  dev->pm_domain->sync(dev);

Yup, good catch Mr. Robot.  I think I've got it all fixed up in:
https://patchwork.kernel.org/patch/7454311/
--
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] drivers/pinctrl: Add the concept of an "init" state

[Douglas Anderson]

For pinctrl the "default" state is applied to pins before the driver's
probe function is called.  This is normally a sensible thing to do,
but in some cases can cause problems.  That's because the pins will
change state before the driver is given a chance to program how those
pins should behave.

As an example you might have a regulator that is controlled by a PWM
(output high = high voltage, output low = low voltage).  The firmware
might leave this pin as driven high.  If we allow the driver core to
reconfigure this pin as a PWM pin before the PWM's probe function runs
then you might end up running at too low of a voltage while we probe.

Let's introudce a new "init" state.  If this is defined we'll set
pinctrl to this state before probe and then "default" after probe
(unless the driver explicitly changed states already).

An alternative idea that was thought of was to use the pre-existing
"sleep" or "idle" states and add a boolean property that we should
start in that mode.  This was not done because the "init" state is
needed for correctness and those other states are only present (and
only transitioned in to and out of) when (optional) power management
is enabled.

Signed-off-by: Douglas Anderson 
Acked-by: Greg Kroah-Hartman 
Tested-by: Caesar Wang 
---
Changes in v3:
- Moved declarations to pinctrl/devinfo.h
- Fixed author/SoB

Changes in v2:
- Added comment to pinctrl_init_done() as per Linus W.

As mentioned in v2 repost, reposted after 1 year of no activity since
Caesar Wang found a use for this.  See
.  I hope it's OK that I
left Greg KH's Ack...

 drivers/base/dd.c |  2 ++
 drivers/base/pinctrl.c| 15 +--
 drivers/pinctrl/core.c| 32 
 include/linux/pinctrl/devinfo.h   | 10 ++
 include/linux/pinctrl/pinctrl-state.h |  8 
 5 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index c4a3f298e..217eafc 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -322,6 +322,8 @@ static int really_probe(struct device *dev, struct 
device_driver *drv)
goto probe_failed;
}
 
+   pinctrl_init_done(dev);
+
if (dev->pm_domain && dev->pm_domain->sync)
dev->pm_domain->sync(dev);
 
diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
index 5fb74b4..0762975 100644
--- a/drivers/base/pinctrl.c
+++ b/drivers/base/pinctrl.c
@@ -42,9 +42,20 @@ int pinctrl_bind_pins(struct device *dev)
goto cleanup_get;
}
 
-   ret = pinctrl_select_state(dev->pins->p, dev->pins->default_state);
+   dev->pins->init_state = pinctrl_lookup_state(dev->pins->p,
+   PINCTRL_STATE_INIT);
+   if (IS_ERR(dev->pins->init_state)) {
+   /* Not supplying this state is perfectly legal */
+   dev_dbg(dev, "no init pinctrl state\n");
+
+   ret = pinctrl_select_state(dev->pins->p,
+  dev->pins->default_state);
+   } else {
+   ret = pinctrl_select_state(dev->pins->p, dev->pins->init_state);
+   }
+
if (ret) {
-   dev_dbg(dev, "failed to activate default pinctrl state\n");
+   dev_dbg(dev, "failed to activate initial pinctrl state\n");
goto cleanup_get;
}
 
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 9638a00..2686a44 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1240,6 +1240,38 @@ int pinctrl_force_default(struct pinctrl_dev *pctldev)
 }
 EXPORT_SYMBOL_GPL(pinctrl_force_default);
 
+/**
+ * pinctrl_init_done() - tell pinctrl probe is done
+ *
+ * We'll use this time to switch the pins from "init" to "default" unless the
+ * driver selected some other state.
+ *
+ * @dev: device to that's done probing
+ */
+int pinctrl_init_done(struct device *dev)
+{
+   struct dev_pin_info *pins = dev->pins;
+   int ret;
+
+   if (!pins)
+   return 0;
+
+   if (IS_ERR(pins->init_state))
+   return 0; /* No such state */
+
+   if (pins->p->state != pins->init_state)
+   return 0; /* Not at init anyway */
+
+   if (IS_ERR(pins->default_state))
+   return 0; /* No default state */
+
+   ret = pinctrl_select_state(pins->p, pins->default_state);
+   if (ret)
+   dev_err(dev, "failed to activate default pinctrl state\n");
+
+   return ret;
+}
+
 #ifdef CONFIG_PM
 
 /**
diff --git a/include/linux/pinctrl/devinfo.h b/include/linux/pinctrl/devinfo.h
index 281cb91..05082e4 100644
--- a/include/linux/pinctrl/devinfo.h
+++ b/include/linux/pinctrl/devinfo.h
@@ -24,10 +24,14 @@
  * struct dev_pin_info - pin state container for devices
  * @p: pinctrl handle for the containing device
  * @default_state: the default state for the handle, if found
+ * 

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
>> Hi Russell,
>>
>> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
>>  wrote:
> What you can do is print those devices which have failed to probe at
> late_initcall() time - possibly augmenting that with reports from
> subsystems showing what resources are not available, but that's only
> a guide, because of the "it might or might not be in a kernel module"
> problem.

 Well, adding those reports would give you a changelog similar to the
 one in this series...
>>>
>>> I'm not sure about that, because what I was thinking of is adding
>>> a flag which would be set at late_initcall() time prior to running
>>> a final round of deferred device probing.
>>
>> Which round is the final round?
>> That's the one which didn't manage to bind any new devices to drivers,
>> which is something you only know _after_ the round has been run.
>>
>> So I think we need one extra round to handle this.
>>
>>> This flag would then be used in a deferred_warn() printk function
>>> which would normally be silent, but when this flag is set, it would
>>> print the reason for the deferral - and this would replace (or be
>>> added) to the subsystems and drivers which return -EPROBE_DEFER.
>>>
>>> That has the effect of hiding all the deferrals up until just before
>>> launching into userspace, which should then acomplish two things -
>>> firstly, getting rid of the rather useless deferred messages up to
>>> that point, and secondly printing the reason why the remaining
>>> deferrals are happening.
>>>
>>> That should be a small number of new lines plus a one-line change
>>> in subsystems and drivers.
>>
>> Apart from the extra round we probably can't get rid of, that sounds OK to 
>> me.
> 
> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.
> 
> We could make driver_deferred_probe_report something that can be
> deactivated again after the last deferred probe run, and provide the
> user with a knob that they can turn it back on again.
> 
> I've tried this out on two of my platforms, including forcing
> driver_deferred_probe_report to be enabled, and I get exactly one
> deferred probe, so not a particularly good test.
> 
> The patch won't apply as-is to mainline for all files; it's based on my
> tree which has some 360 additional patches (which seems to be about
> normal for my tree now.)

I like the concept (I have been thinking along similar lines lately).
But I think this might make the console messages more confusing than
they are now.  The problem is that debug, warn, and error messages
come from a somewhat random set of locations at the moment.  Some
come from the driver probe routines and some come from the subsystems
that the probe routines call.  So the patch is suppressing some
messages, but not others.

One thing that seemed pretty obvious from the patches is that the
current probe routines are somewhat inconsistent in terms of messages,
and that there is room for a set of best practices for messaging.  That
is on my long term wish list, but I'm not sure I'll ever chase after
those windmills.

A couple of specific comments below.


> 
>  drivers/base/dd.c   | 29 +
>  drivers/base/power/domain.c |  7 +--
>  drivers/clk/clkdev.c|  9 -
>  drivers/gpio/gpiolib-of.c   |  5 +
>  drivers/gpu/drm/bridge/dw_hdmi.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
>  drivers/gpu/drm/imx/imx-ldb.c   |  5 +++--
>  drivers/gpu/drm/msm/dsi/dsi.c   |  2 +-
>  drivers/gpu/drm/msm/msm_drv.c   |  3 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
>  drivers/of/irq.c|  5 -
>  drivers/pci/host/pci-mvebu.c|  1 +
>  drivers/pinctrl/core.c  |  5 +++--
>  drivers/pinctrl/devicetree.c|  4 ++--
>  drivers/regulator/core.c|  5 +++--
>  include/linux/device.h  |  1 +
>  16 files changed, 71 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index be0eb4639128..bb12224f2901 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
>   mutex_unlock(_probe_mutex);
>  }
>  
> +static bool driver_deferred_probe_report;
> +
> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, 

Re: [PATCH 1/2] wait/ptrace: always assume __WALL if the child is traced

[Vasily Averin]

On 21.10.2015 01:31, Andrew Morton wrote:
> On Tue, 20 Oct 2015 19:17:54 +0200 Oleg Nesterov  wrote:
> 
>> The following program (simplified version of generated by syzkaller)
>>
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>
>>  void *thread_func(void *arg)
>>  {
>>  ptrace(PTRACE_TRACEME, 0,0,0);
>>  return 0;
>>  }
>>
>>  int main(void)
>>  {
>>  pthread_t thread;
>>
>>  if (fork())
>>  return 0;
>>
>>  while (getppid() != 1)
>>  ;
>>
>>  pthread_create(, NULL, thread_func, NULL);
>>  pthread_join(thread, NULL);
>>  return 0;
>>  }
>>
>> creates the unreapable zombie if /sbin/init doesn't use __WALL.
>>
>> This is not a kernel bug, at least in a sense that everything works as
>> expected: debugger should reap a traced sub-thread before it can reap
>> the leader, but without __WALL/__WCLONE do_wait() ignores sub-threads.
>>
>> Unfortunately, it seems that /sbin/init in most (all?) distributions
>> doesn't use it and we have to change the kernel to avoid the problem.
> 
> Well, to fix this a distro needs to roll out a new kernel.  Or a new
> init(8).  Is there any reason to believe that distributing/deploying a
> new kernel is significantly easier for everyone?  Because fixing init
> sounds like a much preferable solution to this problem.

Patched kernel allows to run obsoleted distro inside containers.
--
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] driver core: Disable late probes by default

[Greg Kroah-Hartman]

On Tue, Oct 20, 2015 at 06:17:39PM +0200, Tomeu Vizoso wrote:
> On 20 October 2015 at 16:05, Greg Kroah-Hartman
>  wrote:
> > On Tue, Oct 20, 2015 at 09:40:48AM +0200, Tomeu Vizoso wrote:
> >> On 19 October 2015 at 17:19, Greg Kroah-Hartman
> >>  wrote:
> >> > On Mon, Oct 19, 2015 at 05:13:22PM +0200, Tomeu Vizoso wrote:
> >> >> To smooth the transition to late probes, make disabled the default for
> >> >> DELAY_DEVICE_PROBES and let individual SoCs enable the option as they
> >> >> get fixed.
> >> >>
> >> >> Signed-off-by: Tomeu Vizoso 
> >> >> Link: https://lkml.kernel.org/g/20151016181129.ga1...@gradator.net
> >> >>
> >> >> ---
> >> >>
> >> >> Hi Rob,
> >> >>
> >> >> I'm sending this in case you think it would be best to leave the
> >> >> on-demand probe series in -next for now but have late probes disabled to
> >> >> avoid hassle to some people.
> >> >
> >> > I would like Rob to just drop this series please, I don't agree with it
> >> > at all at the moment.
> >>
> >> Hi Greg,
> >>
> >> is it the case that you are satisfied with deferred probes as a way of
> >> ordering device probing and that I should look at how to solve my
> >> problem by improving it?
> >
> > Yes, especially given that you have said this does not speed up your
> > boot times, which I thought was your main goal here :(
> 
> Sorry if I'm repeating myself too often, but I have two goals: change
> the probing order to not send deferred probes to the back of the queue
> (getting the display up as fast as possible), and making easier to
> understand the boot process on embedded platforms.
> 
> The concrete issue that would be fixed by achieving the first goal was
> explained in this email from last year:
> 
> http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
> 
> Because of that, ChromeOS had to use their own bindings for the panel
> node so that the panel probe wouldn't be deferred, introducing a
> sizable delta that is a barrier to rebasing on newer mainline releases
> and for vendors to upstream their HW adaptation for chrome devices.

1.5 second delay is crazy (again, my laptop boots to X in less time than
that), if there are a zillion probe deferrs, then maybe you can blame
this type of system, but I would _strongly_ suggest fixing the broken
driver that is causing such a delay instead, as that's the real problem
here.

And again, you say you did this to save boot time, yet you didn't
actually test to see if you fixed this issue, sorry, but I need to see
real numbers.

> The goal of the project I'm working on is to help reduce the delta so
> that ChromeOS (but will also help other downstreams) can rebase more
> often and so that vendors have one excuse less to upstream support for
> their SoCs in a timely way.

That's great, and wonderful, and should be done, but again, find the
broken driver here and fix it.  We have the tools to determine what is
going wrong here, please use them.  Without that data, I'm going to
insist that it is not the deferred probe logic (hint, how many probe
functions can a processor make in 1.5 seconds?)

> About simplifying the boot processes, I was really convinced that
> people were as tired as me of debugging probing issues with deferred
> probes in the middle and I'm very surprised that you and Russell don't
> see any problem with it.

I don't see the problems on the hardware that I run, and if there are
problems, people don't tell me exactly what they are (hint, like what
I'm asking for here...)

thanks,

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] Staging: comedi: removing useless init/exit

[Greg KH]

On Wed, Oct 21, 2015 at 08:41:52AM +0530, Ronit Halder wrote:
> Removing init and exit functions as they do nothing.

Really?  Did you test this?

--
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 04/31] perf record, bpf: Create probe points for BPF programs

[Wangnan (F)]

On 2015/10/21 3:12, Arnaldo Carvalho de Melo wrote:

Em Wed, Oct 14, 2015 at 12:41:15PM +, Wang Nan escreveu:

This patch introduces bpf__{un,}probe() functions to enable callers to
create kprobe points based on section names a BPF program. It parses
the section names in the program and creates corresponding 'struct
perf_probe_event' structures. The parse_perf_probe_command() function is
used to do the main parsing work. The resuling 'struct perf_probe_event'
is stored into program private data for further using.

By utilizing the new probing API, this patch creates probe points during
event parsing.

To ensure probe points be removed correctly, register an atexit hook
so even perf quit through exit() bpf__clear() is still called, so probing
points are cleared. Note that bpf_clear() should be registered before
bpf__probe() is called, so failure of bpf__probe() can still trigger
bpf__clear() to remove probe points which are already probed.

strerror style error reporting scaffold is created by this patch.
bpf__strerror_probe() is the first error reporting function in bpf-loader.c.

So, this one, for a non-root user gives me:

[acme@felicio linux]$ perf record --event /tmp/foo.o sleep 1
event syntax error: '/tmp/foo.o'
  \___ Invalid argument

(add -v to see detail)
Run 'perf list' for a list of valid events

  Usage: perf record [] []
 or: perf record [] --  []

 -e, --eventevent selector. use 'perf list' to list available 
events
[acme@felicio linux]$



I.e. no libbpf error (good!) but then, just an -EINVAL as the "event syntax
error", which clearly isn't a syntax error, we need to tell the user that he or 
she
needs special perfmissions for using sys_bpf() :-)

As root:

[root@felicio ~]# perf record --event /tmp/foo.o sleep
event syntax error: '/tmp/foo.o'
  \___ Invalid argument

(add -v to see detail)
Run 'perf list' for a list of valid events

  Usage: perf record [] []
 or: perf record [] --  []

 -e, --eventevent selector. use 'perf list' to list available 
events
[root@felicio ~]# ls -la /tmp/foo.o
-rw-rw-r--. 1 acme acme 824 Oct 20 12:35 /tmp/foo.o
[root@felicio ~]# file /tmp/foo.o
/tmp/foo.o: ELF 64-bit LSB relocatable, no machine, version 1 (SYSV), not 
stripped


Humm, its something else, this is an ancient kernel, 4.2.0, probably without
eBPF support? Nope, its there:

[root@felicio ~]# grep -i sys_bpf /proc/kallsyms
811829d0 T SyS_bpf
811829d0 T sys_bpf
[root@felicio ~]#

Its something else, we need to improve this error reporting:

[root@felicio ~]# perf record -v --event /tmp/foo.o sleep 1
libbpf: loading /tmp/foo.o
libbpf: section .strtab, size 60, link 0, flags 0, type=3
libbpf: section .text, size 0, link 0, flags 6, type=1
libbpf: section .data, size 0, link 0, flags 3, type=1
libbpf: section .bss, size 0, link 0, flags 3, type=8
libbpf: section do_fork, size 16, link 0, flags 6, type=1
libbpf: found program do_fork
libbpf: section license, size 4, link 0, flags 3, type=1
libbpf: license of /tmp/foo.o is GPL
libbpf: section version, size 4, link 0, flags 3, type=1
libbpf: kernel version of /tmp/foo.o is 40100
libbpf: section .symtab, size 96, link 1, flags 0, type=2
bpf: config program 'do_fork'
symbol:do_fork file:(null) line:0 offset:0 return:0 lazy:(null)
bpf: 'do_fork': event name is missing


BPF report the problem, but it is a little bit hard to understand...


event syntax error: '/tmp/foo.o'
  \___ Invalid argument

(add -v to see detail)
Run 'perf list' for a list of valid events

  Usage: perf record [] []
 or: perf record [] --  []

 -e, --eventevent selector. use 'perf list' to list available 
events
[root@felicio ~]#

[root@felicio ~]# grep do_fork /proc/kallsyms
81099ab0 T _do_fork
81ccc800 d do_fork_test
[root@felicio ~]#

$ echo '__attribute__((section("_do_fork"), used)) int fork(void *ctx) {return 0;} char _license[] 
__attribute__((section("license"), used)) = "GPL";int _version 
__attribute__((section("version"), used)) = 0x40100;' | clang -D__KERNEL__ $CLANG_OPTIONS $KERNEL_INC_OPTIONS 
-Wno-unused-value -Wno-pointer-sign -working-directory $WORKING_DIR -c - -target bpf -O2 -o /tmp/foo.o


In your program you only provide "do_fork", but we need "key=value" syntax.
"key" will become the name of created kprobe. Please try 
"__attribute__((section("func=do_fork"), used)) "

instead.

I think when event name is missing we'd better construct one name for it
like perf probe, but then we need to deal with perf probe code again. It
may require another patch.

For this patch, I think we can assign a new errorno so bpf__strerror_probe()
can give more information to let user know whether the problem is reside 
in bpf

program or perf configuration. Do you think ENOEXEC is a good choice?

Thank you.



[root@felicio ~]# perf record  -v --event /tmp/foo.o sleep 1
libbpf: loading /tmp/foo.o
libbpf: section .strtab, size 61, 

Re: what's in nvdimm.git for v4.4?

[Dan Williams]

On Tue, Oct 20, 2015 at 7:38 PM, Dave Chinner  wrote:
> On Tue, Oct 20, 2015 at 05:31:18PM -0700, Dan Williams wrote:
>> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner  wrote:
>> > On Tue, Oct 20, 2015 at 11:31:45PM +, Williams, Dan J wrote:
>> >> Here is a status summary of the topic-branches nvdimm.git is tracking
>> >> for v4.4.  Unless indicated these branches are not present in -next.
>> >> Please ACK, NAK, or ask for a re-post of any of the below to disposition
>> >> it for the merge window.
>> >>
>> >> ===
>> >> for-4.4/dax-fixes:
>> >> ===
>> > ...
>> >> Dave Chinner (5):
>> >>   xfs: fix inode size update overflow in xfs_map_direct()
>> >>   xfs: introduce BMAPI_ZERO for allocating zeroed extents
>> >>   xfs: Don't use unwritten extents for DAX
>> >>   xfs: DAX does not use IO completion callbacks
>> >>   xfs: add ->pfn_mkwrite support for DAX
>> >
>> > Please drop these. They have not been reviewed yet, and because
>> > the changes affect more than just DAX (core XFS allocator
>> > functionality was changed) these need to go through the XFS tree.
>> >
>>
>> Ok, thanks for the heads up.  For the get_user_pages() patches that
>> build on these fixes I'm assuming your review bandwidth is in short
>> supply to also give an XFS sign-off on those changes for 4.4?
>
> I'm not aware of any other patches that touch XFS. AFAIA, you
> haven't cc'd anything to x...@oss.sgi.com, so it's not on my radar...
>

I can cc x...@oss.sgi.com on fs/dax.c changes going forward, but for
these I figure it was off topic since nothing touched fs/xfs/.

>> I'm wondering if we can take a conservative step forward with those
>> patches for 4.4.  if XFS and EXT4 interactions need more time to get
>> worked out, which I believe they do, I can conceive just turning on
>> get_user_pages() support for DAX-mappings of the raw block device.
>
> Regardless of the ext4/XFS status, isn't it a bit late to be
> proposing brand new stuff that nobody has had time to think about
> for the next merge window?
>

The "dax-for-raw-block support" is indeed new, but it's a fairly
straightforward extension of these patches that have been out for
review since 4.3-rc2, or 4.1-rc6 in the case of the pfn_t enabling.
Cutting out the filesystem interactions makes it that much simpler to
comprehend.
--
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 4/8] crypto: ux500: Use precalculated hash from headers

[kbuild test robot]

Hi LABBE,

[auto build test ERROR on crypto/master -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/LABBE-Corentin/crypto-hash-add-zero-length-message-hash-for-shax-and-md5/20151020-154222
config: arm-u8500_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `get_empty_message_digest':
>> drivers/crypto/ux500/hash/hash_core.c:229: undefined reference to 
>> `sha1_zero_message_hash'
>> drivers/crypto/ux500/hash/hash_core.c:229: undefined reference to 
>> `sha1_zero_message_hash'

vim +229 drivers/crypto/ux500/hash/hash_core.c

   223  /**
   224   * Caller responsible for ctx != NULL.
   225   */
   226  
   227  if (HASH_OPER_MODE_HASH == ctx->config.oper_mode) {
   228  if (HASH_ALGO_SHA1 == ctx->config.algorithm) {
 > 229  memcpy(zero_hash, _zero_message_hash[0],
   230 SHA1_DIGEST_SIZE);
   231  *zero_hash_size = SHA1_DIGEST_SIZE;
   232  *zero_digest = true;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] Staging: comedi: removing useless init/exit

[Ronit Halder]

Removing init and exit functions as they do nothing.

Signed-off-by: Ronit Halder 
---
 drivers/staging/comedi/comedi_usb.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/staging/comedi/comedi_usb.c 
b/drivers/staging/comedi/comedi_usb.c
index 9c946d4..ed13bf6 100644
--- a/drivers/staging/comedi/comedi_usb.c
+++ b/drivers/staging/comedi/comedi_usb.c
@@ -144,16 +144,6 @@ void comedi_usb_driver_unregister(struct comedi_driver 
*comedi_driver,
 }
 EXPORT_SYMBOL_GPL(comedi_usb_driver_unregister);
 
-static int __init comedi_usb_init(void)
-{
-   return 0;
-}
-module_init(comedi_usb_init);
-
-static void __exit comedi_usb_exit(void)
-{
-}
-module_exit(comedi_usb_exit);
 
 MODULE_AUTHOR("http://www.comedi.org;);
 MODULE_DESCRIPTION("Comedi USB interface module");
-- 
2.6.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 v7 1/7] perf tools: Add 'perf-config' command

[Namhyung Kim]

Hi Taeung,

sorry for late!

On Sun, Oct 04, 2015 at 04:35:04PM +0900, Taeung Song wrote:
> The perf configuration file contains many variables which can make
> the perf command's action more effective.
> But looking through state of configuration is difficult and there's no knowing
> what kind of other variables except variables in perfconfig.example exist.
> So This patch adds 'perf-config' command with '--list' option and a document 
> for it.
> 
> perf config [options]
> 
> display current perf config variables.
> # perf config
> or
> # perf config -l | --list
> 
> Signed-off-by: Taeung Song 

Some nitpicks below, other than that

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  tools/perf/Build |   1 +
>  tools/perf/Documentation/perf-config.txt | 396 
> +++
>  tools/perf/builtin-config.c  |  62 +
>  tools/perf/builtin.h |   1 +
>  tools/perf/command-list.txt  |   1 +
>  tools/perf/perf.c|   1 +
>  6 files changed, 462 insertions(+)
>  create mode 100644 tools/perf/Documentation/perf-config.txt
>  create mode 100644 tools/perf/builtin-config.c
> 
> diff --git a/tools/perf/Build b/tools/perf/Build
> index 7223745..2c7aaf2 100644
> --- a/tools/perf/Build
> +++ b/tools/perf/Build
> @@ -1,5 +1,6 @@
>  perf-y += builtin-bench.o
>  perf-y += builtin-annotate.o
> +perf-y += builtin-config.o
>  perf-y += builtin-diff.o
>  perf-y += builtin-evlist.o
>  perf-y += builtin-help.o
> diff --git a/tools/perf/Documentation/perf-config.txt 
> b/tools/perf/Documentation/perf-config.txt
> new file mode 100644
> index 000..e8013b3
> --- /dev/null
> +++ b/tools/perf/Documentation/perf-config.txt
> @@ -0,0 +1,396 @@
> +perf-config(1)
> +==
> +
> +NAME
> +
> +perf-config - Get and set variables in a configuration file.
> +
> +SYNOPSIS
> +
> +[verse]
> +'perf config' -l | --list
> +
> +DESCRIPTION
> +---
> +You can manage variables in a configuration file with this command.
> +
> +OPTIONS
> +---
> +
> +-l::
> +--list::
> + Show current config variables, name and value, for all sections.
> +
> +CONFIGURATION FILE
> +--
> +
> +The Perf configuration file contains many variables which can make
> +the perf command's action more effective.
> +The '$HOME/.perfconfig' file is used to store a per-user configuration.
> +The file '$(sysconfdir)/perfconfig' can be used to
> +store a system-wide default configuration.
> +
> +The variables are divided into sections. In each section, the variables
> +that are composed of a name and value.
> +
> +Syntax
> +~~
> +
> +The file consist of sections. A section starts with its name
> +surrounded by square brackets and continues till the next section
> +begins. Each variable belong to a section, which means that
> +there must be a section header before the first variable, as below:
> +Each variable are in the form 'name = value'.
> +
> + [section]
> + name1 = value1
> + name2 = value2
> +
> +Section names are case sensitive and can contain any characters except
> +newline (double quote `"` and backslash have to be escaped as `\"` and `\\`,
> +respectively). Section headers can't span multiple lines.
> +
> +Example
> +~~~
> +
> +Given a $HOME/.perfconfig like this:
> +
> +#
> +# This is the config file, and
> +# a '#' and ';' character indicates a comment
> +#
> +
> +[colors]
> + # Color variables
> + top = red, default
> + medium = green, default
> + normal = lightgray, default
> + selected = white, lightgray
> + code = blue, default
> + addr = magenta, default
> + root = white, blue
> +
> +[tui]
> + # Defaults if linked with libslang
> + report = on
> + annotate = on
> + top = on
> +
> +[buildid]
> + # Default, disable using /dev/null
> + dir = ~/.debug
> +
> +[annotate]
> + # Defaults
> + hide_src_code = false
> + use_offset = true
> + jump_arrows = true
> + show_nr_jumps = false
> +
> +[help]
> + # Format can be man, info, web or html
> + format = man
> + autocorrect = 0
> +
> +[ui]
> + show-headers= true
> +
> +[call-graph]
> + # fp (framepointer), dwarf
> + record-mode = fp
> + print-type = graph
> + order = caller
> + sort-key = function
> +
> +Variables
> +~
> +
> +colors.*::
> + Color variables can customize colors of the output which is printed out
> + from ‘report’, ‘top’, ’annotate’ on tui.
> + Color variables are composed of foreground and background
> + and should have two values, comma separated as below.
> +
> + medium = green, lightgray
> +
> + If you want to keep the background or the foregroud color set for your
> + terminal, replace the desired value with 'default'. For instance:
> +
> + medium = default, default
> +
> + Available colors:
> + red, green, default, 

Re: [PATCH v2 05/10] hwmon: (fam15h_power) Add compute unit accumulated power

[Huang Rui]

On Tue, Oct 20, 2015 at 07:49:53PM -0700, Guenter Roeck wrote:
> On 10/20/2015 07:40 PM, Huang Rui wrote:
> >On Tue, Oct 20, 2015 at 07:15:25PM -0700, Guenter Roeck wrote:
> >>On 10/20/2015 06:42 PM, Huang Rui wrote:
> >>>On Tue, Oct 20, 2015 at 03:24:09PM +0800, kbuild test robot wrote:
> >>>>Hi Huang,
> >>>>
> >>>>[auto build test ERROR on hwmon/hwmon-next -- if it's inappropriate base, 
> >>>>please suggest rules for selecting the more suitable base]
> >>>>
> >>>>url:
> >>>>https://github.com/0day-ci/linux/commits/Huang-Rui/hwmon-fam15h_power-Introduce-an-accumulated-power-reporting-algorithm/20151020-110712
> >>>>config: x86_64-randconfig-s2-10201413 (attached as .config)
> >>>>reproduce:
> >>>> # save the attached .config to linux build tree
> >>>> make ARCH=x86_64
> >>>>
> >>>>All errors (new ones prefixed by >>):
> >>>>
> >>>>drivers/built-in.o: In function `fam15h_power_probe':
> >>>>>>fam15h_power.c:(.text+0x26e3a3): undefined reference to 
> >>>>>>`amd_get_cores_per_cu'
> >>>>fam15h_power.c:(.text+0x26e41e): undefined reference to 
> >>>> `amd_get_cores_per_cu'
> >>>>
> >>>
> >>>Thanks to report this issue. :)
> >>>The root cause is that the test config doesn't enable
> >>>CONFIG_CPU_SUP_AMD.
> >>>
> >>>How about below fix:
> >>>
> >>
> >>Guess you don't have a choice.
> >>
> >
> >Yes, if I use test config, fam15h_power isn't chosen. :)
> >
> >And if I use the "select" flag like below, fam15h_power can be built
> >successfully.
> >
> That is another possibility, though that isn't how CPU_SUP_AMD
> is handled by its other users. Matter of philosophy, I guess.
> 

Err, sorry. Could you please point out the other possibility?

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/

[PATCH net-next 1/3] perf: pad raw data samples automatically

[Alexei Starovoitov]

Instead of WARN_ON in perf_event_output() on unpaded raw samples,
pad them automatically.

Signed-off-by: Alexei Starovoitov 
---
 kernel/events/core.c |   15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index b11756f9b6dc..64754bfecd70 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5286,9 +5286,15 @@ void perf_output_sample(struct perf_output_handle 
*handle,
 
if (sample_type & PERF_SAMPLE_RAW) {
if (data->raw) {
-   perf_output_put(handle, data->raw->size);
-   __output_copy(handle, data->raw->data,
-  data->raw->size);
+   u32 raw_size = data->raw->size;
+   u32 real_size = round_up(raw_size + sizeof(u32),
+sizeof(u64)) - sizeof(u32);
+   u64 zero = 0;
+
+   perf_output_put(handle, real_size);
+   __output_copy(handle, data->raw->data, raw_size);
+   if (real_size - raw_size)
+   __output_copy(handle, , real_size - 
raw_size);
} else {
struct {
u32 size;
@@ -5420,8 +5426,7 @@ void perf_prepare_sample(struct perf_event_header *header,
else
size += sizeof(u32);
 
-   WARN_ON_ONCE(size & (sizeof(u64)-1));
-   header->size += size;
+   header->size += round_up(size, sizeof(u64));
}
 
if (sample_type & PERF_SAMPLE_BRANCH_STACK) {
-- 
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/

[PATCH net-next 3/3] samples: bpf: add bpf_perf_event_output example

[Alexei Starovoitov]

Performance test and example of bpf_perf_event_output().
kprobe is attached to sys_write() and trivial bpf program streams
pid+cookie into userspace via PERF_COUNT_SW_BPF_OUTPUT event.

Usage:
$ sudo ./bld_x64/samples/bpf/trace_output
recv 2968913 events per sec

Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/Makefile|7 ++
 samples/bpf/bpf_helpers.h   |2 +
 samples/bpf/trace_output_kern.c |   31 +++
 samples/bpf/trace_output_user.c |  196 +++
 4 files changed, 236 insertions(+)
 create mode 100644 samples/bpf/trace_output_kern.c
 create mode 100644 samples/bpf/trace_output_user.c

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 63e7d50e6a4f..b30514514e37 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -13,6 +13,7 @@ hostprogs-y += tracex3
 hostprogs-y += tracex4
 hostprogs-y += tracex5
 hostprogs-y += tracex6
+hostprogs-y += trace_output
 hostprogs-y += lathist
 
 test_verifier-objs := test_verifier.o libbpf.o
@@ -27,6 +28,7 @@ tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
 tracex4-objs := bpf_load.o libbpf.o tracex4_user.o
 tracex5-objs := bpf_load.o libbpf.o tracex5_user.o
 tracex6-objs := bpf_load.o libbpf.o tracex6_user.o
+trace_output-objs := bpf_load.o libbpf.o trace_output_user.o
 lathist-objs := bpf_load.o libbpf.o lathist_user.o
 
 # Tell kbuild to always build the programs
@@ -40,6 +42,7 @@ always += tracex3_kern.o
 always += tracex4_kern.o
 always += tracex5_kern.o
 always += tracex6_kern.o
+always += trace_output_kern.o
 always += tcbpf1_kern.o
 always += lathist_kern.o
 
@@ -55,6 +58,7 @@ HOSTLOADLIBES_tracex3 += -lelf
 HOSTLOADLIBES_tracex4 += -lelf -lrt
 HOSTLOADLIBES_tracex5 += -lelf
 HOSTLOADLIBES_tracex6 += -lelf
+HOSTLOADLIBES_trace_output += -lelf -lrt
 HOSTLOADLIBES_lathist += -lelf
 
 # point this to your LLVM backend with bpf support
@@ -64,3 +68,6 @@ $(obj)/%.o: $(src)/%.c
clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
-D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
-O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
+   clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
+   -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
+   -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=asm -o 
$@.s
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index 21aa1b44c30c..b35c21e0b43f 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -37,6 +37,8 @@ static int (*bpf_clone_redirect)(void *ctx, int ifindex, int 
flags) =
(void *) BPF_FUNC_clone_redirect;
 static int (*bpf_redirect)(int ifindex, int flags) =
(void *) BPF_FUNC_redirect;
+static int (*bpf_perf_event_output)(void *ctx, void *map, int index, void 
*data, int size) =
+   (void *) BPF_FUNC_perf_event_output;
 
 /* llvm builtin functions that eBPF C program may use to
  * emit BPF_LD_ABS and BPF_LD_IND instructions
diff --git a/samples/bpf/trace_output_kern.c b/samples/bpf/trace_output_kern.c
new file mode 100644
index ..8d8d1ec429eb
--- /dev/null
+++ b/samples/bpf/trace_output_kern.c
@@ -0,0 +1,31 @@
+#include 
+#include 
+#include 
+#include "bpf_helpers.h"
+
+struct bpf_map_def SEC("maps") my_map = {
+   .type = BPF_MAP_TYPE_PERF_EVENT_ARRAY,
+   .key_size = sizeof(int),
+   .value_size = sizeof(u32),
+   .max_entries = 2,
+};
+
+SEC("kprobe/sys_write")
+int bpf_prog1(struct pt_regs *ctx)
+{
+   struct S {
+   u64 pid;
+   u64 cookie;
+   } data;
+
+   memset(, 0, sizeof(data));
+   data.pid = bpf_get_current_pid_tgid();
+   data.cookie = 0x12345678;
+
+   bpf_perf_event_output(ctx, _map, 0, , sizeof(data));
+
+   return 0;
+}
+
+char _license[] SEC("license") = "GPL";
+u32 _version SEC("version") = LINUX_VERSION_CODE;
diff --git a/samples/bpf/trace_output_user.c b/samples/bpf/trace_output_user.c
new file mode 100644
index ..661a7d052f2c
--- /dev/null
+++ b/samples/bpf/trace_output_user.c
@@ -0,0 +1,196 @@
+/* This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "libbpf.h"
+#include "bpf_load.h"
+
+static int pmu_fd;
+
+int page_size;
+int page_cnt = 8;
+volatile struct perf_event_mmap_page *header;
+
+typedef void (*print_fn)(void *data, int size);
+
+static int perf_event_mmap(int fd)
+{
+   void *base;
+   int mmap_size;
+
+   page_size = getpagesize();
+   mmap_size = page_size * (page_cnt + 1);
+
+   base = mmap(NULL, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
+   if (base == MAP_FAILED) {
+   

[PATCH net-next 0/3] bpf_perf_event_output helper

[Alexei Starovoitov]

Over the last year there were multiple attempts to let eBPF programs
output data into perf events by He Kuang and Wangnan.
The last one was:
https://lkml.org/lkml/2015/7/20/736
It was almost perfect with exception that all bpf programs would sent
data into one global perf_event.
This patch set takes different approach by letting user space
open independent PERF_COUNT_SW_BPF_OUTPUT events, so that program
output won't collide.

Wangnan is working on corresponding perf patches.

Alexei Starovoitov (3):
  perf: pad raw data samples automatically
  bpf: introduce bpf_perf_event_output() helper
  samples: bpf: add bpf_perf_event_output example

 include/uapi/linux/bpf.h|   11 +++
 include/uapi/linux/perf_event.h |1 +
 kernel/bpf/arraymap.c   |2 +
 kernel/bpf/verifier.c   |3 +-
 kernel/events/core.c|   15 ++-
 kernel/trace/bpf_trace.c|   46 +
 samples/bpf/Makefile|7 ++
 samples/bpf/bpf_helpers.h   |2 +
 samples/bpf/trace_output_kern.c |   31 +++
 samples/bpf/trace_output_user.c |  196 +++
 10 files changed, 308 insertions(+), 6 deletions(-)
 create mode 100644 samples/bpf/trace_output_kern.c
 create mode 100644 samples/bpf/trace_output_user.c

-- 
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/

[PATCH net-next 2/3] bpf: introduce bpf_perf_event_output() helper

[Alexei Starovoitov]

This helper is used to send raw data from eBPF program into
special PERF_TYPE_SOFTWARE/PERF_COUNT_SW_BPF_OUTPUT perf_event.
User space needs to perf_event_open() it (either for one or all cpus) and
store FD into perf_event_array (similar to bpf_perf_event_read() helper)
before eBPF program can send data into it.

Today the programs triggered by kprobe collect the data and either store
it into the maps or print it via bpf_trace_printk() where latter is the debug
facility and not suitable to stream the data. This new helper replaces
such bpf_trace_printk() usage and allows programs to have dedicated
channel into user space for post-processing of the raw data collected.

Signed-off-by: Alexei Starovoitov 
---
 include/uapi/linux/bpf.h|   11 ++
 include/uapi/linux/perf_event.h |1 +
 kernel/bpf/arraymap.c   |2 ++
 kernel/bpf/verifier.c   |3 ++-
 kernel/trace/bpf_trace.c|   46 +++
 5 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 564f1f091991..2e032426cfb7 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -287,6 +287,17 @@ enum bpf_func_id {
 * Return: realm if != 0
 */
BPF_FUNC_get_route_realm,
+
+   /**
+* bpf_perf_event_output(ctx, map, index, data, size) - output perf raw 
sample
+* @ctx: struct pt_regs*
+* @map: pointer to perf_event_array map
+* @index: index of event in the map
+* @data: data on stack to be output as raw data
+* @size: size of data
+* Return: 0 on success
+*/
+   BPF_FUNC_perf_event_output,
__BPF_FUNC_MAX_ID,
 };
 
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 2881145cda86..d3c417615361 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -110,6 +110,7 @@ enum perf_sw_ids {
PERF_COUNT_SW_ALIGNMENT_FAULTS  = 7,
PERF_COUNT_SW_EMULATION_FAULTS  = 8,
PERF_COUNT_SW_DUMMY = 9,
+   PERF_COUNT_SW_BPF_OUTPUT= 10,
 
PERF_COUNT_SW_MAX,  /* non-ABI */
 };
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index f2d9e698c753..e3cfe46b074f 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -295,6 +295,8 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map 
*map, int fd)
return (void *)attr;
 
if (attr->type != PERF_TYPE_RAW &&
+   !(attr->type == PERF_TYPE_SOFTWARE &&
+ attr->config == PERF_COUNT_SW_BPF_OUTPUT) &&
attr->type != PERF_TYPE_HARDWARE) {
perf_event_release_kernel(event);
return ERR_PTR(-EINVAL);
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 1d6b97be79e1..b56cf51f8d42 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -245,6 +245,7 @@ static const struct {
 } func_limit[] = {
{BPF_MAP_TYPE_PROG_ARRAY, BPF_FUNC_tail_call},
{BPF_MAP_TYPE_PERF_EVENT_ARRAY, BPF_FUNC_perf_event_read},
+   {BPF_MAP_TYPE_PERF_EVENT_ARRAY, BPF_FUNC_perf_event_output},
 };
 
 static void print_verifier_state(struct verifier_env *env)
@@ -910,7 +911,7 @@ static int check_map_func_compatibility(struct bpf_map 
*map, int func_id)
 * don't allow any other map type to be passed into
 * the special func;
 */
-   if (bool_map != bool_func)
+   if (bool_func && bool_map != bool_func)
return -EINVAL;
}
 
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 0fe96c7c8803..47febbe7998e 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -215,6 +215,50 @@ const struct bpf_func_proto bpf_perf_event_read_proto = {
.arg2_type  = ARG_ANYTHING,
 };
 
+static u64 bpf_perf_event_output(u64 r1, u64 r2, u64 index, u64 r4, u64 size)
+{
+   struct pt_regs *regs = (struct pt_regs *) (long) r1;
+   struct bpf_map *map = (struct bpf_map *) (long) r2;
+   struct bpf_array *array = container_of(map, struct bpf_array, map);
+   void *data = (void *) (long) r4;
+   struct perf_sample_data sample_data;
+   struct perf_event *event;
+   struct perf_raw_record raw = {
+   .size = size,
+   .data = data,
+   };
+
+   if (unlikely(index >= array->map.max_entries))
+   return -E2BIG;
+
+   event = (struct perf_event *)array->ptrs[index];
+   if (unlikely(!event))
+   return -ENOENT;
+
+   if (unlikely(event->attr.type != PERF_TYPE_SOFTWARE ||
+event->attr.config != PERF_COUNT_SW_BPF_OUTPUT))
+   return -EINVAL;
+
+   if (unlikely(event->oncpu != smp_processor_id()))
+   return -EOPNOTSUPP;
+
+   perf_sample_data_init(_data, 0, 0);

Re: [PATCH v3 0/3] pstore: add pstore unregister

[Kees Cook]

On Tue, Oct 20, 2015 at 7:52 PM, Geliang Tang  wrote:
> On Tue, Oct 20, 2015 at 10:19:09AM -0700, Kees Cook wrote:
>> On Tue, Oct 20, 2015 at 12:39 AM, Geliang Tang  wrote:
>> > On Mon, Oct 19, 2015 at 10:56:54PM +, Luck, Tony wrote:
>> >> Thanks for looking to close out this TODO item.
>> >>
>> >> The thing that scared me about unloading pstore was what happens to
>> >> a process that is in the middle of reading some 
>> >> /sys/fs/pstore/file-name-here
>>
>> Were you able to verify that this reading-while-rmmod case works correctly?
>>
>> -Kees
>
> $ sudo insmod zlib_deflate.ko
> $ sudo insmod pstore.ko
> $ lsmod
> Module  Size  Used by
> pstore 11225  0
> zlib_deflate   18292  1 pstore
>
> $ sudo mount -t pstore pstore /sys/fs/pstore
> $ lsmod
> Module  Size  Used by
> pstore 11225  1
> zlib_deflate   18292  1 pstore
>
> $ sudo insmod reed_solomon.ko
> $ sudo insmod ramoops.ko mem_address=0x4000 mem_size=0x40
> $ lsmod
> Module  Size  Used by
> ramoops 9638  0
> reed_solomon5150  1 ramoops
> pstore 11225  2 ramoops
> zlib_deflate   18292  1 pstore
>
> $ tail -f /sys/fs/pstore/console-ramoops-0 &
> [1] 3483
> $ lsmod
> Module  Size  Used by
> ramoops 9638  0
> reed_solomon5150  1 ramoops
> pstore 11225  3 ramoops
> zlib_deflate   18292  1 pstore
>
> $ kill -9 3483
> $ lsmod
> Module  Size  Used by
> ramoops 9638  0
> reed_solomon5150  1 ramoops
> pstore 11225  2 ramoops
> zlib_deflate   18292  1 pstore
>
> $ sudo rmmod ramoops
> $ lsmod
> Module  Size  Used by
> reed_solomon5150  0
> pstore 11225  1
> zlib_deflate   18292  1 pstore

What happens if you leave the tail running and try to rmmod ramoops?
(I assume it'll just refuse.)

Nice!

Acked-by: Kees Cook 

-Kees

>
> $ sudo umount /sys/fs/pstore/
> $ lsmod
> Module  Size  Used by
> reed_solomon5150  0
> pstore 11225  0
> zlib_deflate   18292  1 pstore
>
> $ sudo rmmod pstore
> $ lsmod
> Module  Size  Used by
> reed_solomon5150  0
> zlib_deflate   18292  0
>
> Thanks.
> Geliang Tang
>



-- 
Kees Cook
Chrome OS Security
--
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] perf annotate/tui: Fix 'annotate.use_offset' config variable usage

[Namhyung Kim]

The annotate__configs should be sorted so that it can use bsearch(3).
However commit 0c4a5bcea460 ("perf annotate: Display total number of
samples with --show-total-period") added a new config item at the end.
This resulted in the 'annotate.use_offset' config variable cannot be
found and perf terminated like below:

  $ perf report
  bad config file line 6 in ~/.perfconfig

Cc: Martin Liška 
Cc: Taeung Song 
Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/annotate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 29739b347599..6a2b5fe64a9b 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -1125,8 +1125,8 @@ static struct annotate_config {
ANNOTATE_CFG(jump_arrows),
ANNOTATE_CFG(show_linenr),
ANNOTATE_CFG(show_nr_jumps),
-   ANNOTATE_CFG(use_offset),
ANNOTATE_CFG(show_total_period),
+   ANNOTATE_CFG(use_offset),
 };
 
 #undef ANNOTATE_CFG
-- 
2.6.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 v3 0/3] pstore: add pstore unregister

[Geliang Tang]

On Tue, Oct 20, 2015 at 10:19:09AM -0700, Kees Cook wrote:
> On Tue, Oct 20, 2015 at 12:39 AM, Geliang Tang  wrote:
> > On Mon, Oct 19, 2015 at 10:56:54PM +, Luck, Tony wrote:
> >> Thanks for looking to close out this TODO item.
> >>
> >> The thing that scared me about unloading pstore was what happens to
> >> a process that is in the middle of reading some 
> >> /sys/fs/pstore/file-name-here
> 
> Were you able to verify that this reading-while-rmmod case works correctly?
> 
> -Kees

$ sudo insmod zlib_deflate.ko
$ sudo insmod pstore.ko
$ lsmod
Module  Size  Used by
pstore 11225  0
zlib_deflate   18292  1 pstore

$ sudo mount -t pstore pstore /sys/fs/pstore
$ lsmod
Module  Size  Used by
pstore 11225  1
zlib_deflate   18292  1 pstore

$ sudo insmod reed_solomon.ko
$ sudo insmod ramoops.ko mem_address=0x4000 mem_size=0x40
$ lsmod
Module  Size  Used by
ramoops 9638  0
reed_solomon5150  1 ramoops
pstore 11225  2 ramoops
zlib_deflate   18292  1 pstore

$ tail -f /sys/fs/pstore/console-ramoops-0 &
[1] 3483
$ lsmod
Module  Size  Used by
ramoops 9638  0
reed_solomon5150  1 ramoops
pstore 11225  3 ramoops
zlib_deflate   18292  1 pstore

$ kill -9 3483
$ lsmod
Module  Size  Used by
ramoops 9638  0
reed_solomon5150  1 ramoops
pstore 11225  2 ramoops
zlib_deflate   18292  1 pstore

$ sudo rmmod ramoops
$ lsmod
Module  Size  Used by
reed_solomon5150  0
pstore 11225  1
zlib_deflate   18292  1 pstore

$ sudo umount /sys/fs/pstore/
$ lsmod
Module  Size  Used by
reed_solomon5150  0 
pstore 11225  0 
zlib_deflate   18292  1 pstore

$ sudo rmmod pstore
$ lsmod
Module  Size  Used by
reed_solomon5150  0 
zlib_deflate   18292  0

Thanks.
Geliang Tang

--
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] extcon: add MAX3355 driver

[Chanwoo Choi]

Hi Sergei,

I think this patch is too much delay. I recommend you better to develop
this driver based on latest extcon-next branch[1].
[1] 
https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-next

Thanks,
Chanwoo Choi

On 2015년 10월 21일 03:20, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/18/2014 12:58 AM, Sergei Shtylyov wrote:
> 
 MAX3355E chip integrates a charge pump and comparators to enable a system 
 with
 an integrated USB OTG dual-role transceiver to function as a USB OTG 
 dual-role
 device. In addition to sensing/controlling Vbus, the chip also passes thru 
 the
 ID signal from the USB OTG connector.  On some Renesas boards, this signal 
  is
 just  fed into the SoC thru a GPIO pin -- there's no real OTG controller, 
 only
 host and gadget USB controllers sharing the same USB bus; however,  we'd  
 like
 to allow host or gadget drivers to be loaded depending on the cable type,
 hence
 the need for the MAX3355 extcon driver. The Vbus status signals are also 
 wired
 to GPIOs (however, we're not currently intested in them), the  OFFVBUS# 
 signal
 is controlled  by the host controllers, there's also the SHDN# signal 
 wired to
 GPIO, which should be high for normal operation.
>>
 Signed-off-by: Sergei Shtylyov 
>>
 ---
 The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
>>
   Documentation/devicetree/bindings/extcon/extcon-max3355.txt |   21 ++
   drivers/extcon/Kconfig  |6
   drivers/extcon/Makefile |1
   drivers/extcon/extcon-max3355.c |  122
 
   4 files changed, 150 insertions(+)
>>
 Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
 ===
 --- /dev/null
 +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
 @@ -0,0 +1,21 @@
 +MAX3355 USB OTG chip
>>
>>> Need manufactor information as following :
>>>-> Maxim MAX3355
>>
>> Would be Maxim enough? Or perhaps I should use Maxim Integrated 
>> [Products]?
> 
>You haven't replied to my questions.
> 
 +
 +
 +MAX3355 integrates a charge pump and comparators to enable a system with 
 an
 +integrated USB OTG dual-role transceiver to function as a USB OTG 
 dual-role
 +device.
 +
 +Required properties:
 +- compatible: should be "maxim,max3355";
 +- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the
 GPIO pin
 +  connected to the MAX3355's SHDN# pin;
 +- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO 
 pin
 +  connected to the MAX3355's ID_OUT pin.
 +
 +Example (Koelsch board):
 +
 +usb-otg {
 +compatible = "maxim,max3355";
 +maxim,shdn-gpio = < 4 GPIO_ACTIVE_LOW>;
 +maxim,id-gpio = < 31 GPIO_ACTIVE_HIGH>;
>>
>>> Kernel already supported the gpio helper function to get gpio from 
>>> devicetree.
>>> I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
>>> include/linux/of_gpio.h.
>>
>>> gpios = < 4 GPIO_ACTIVE_LOW>, < 31 GPIO_ACTIVE_HIGH>;
>>
>> OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
>> to insist on using this one...
> 
>Moreover, it now says "gpios" isn't allowed for the new bindings. So I 
> have to strongly disagree here...
> 
> [...]
> 
 +static irqreturn_t max3355_id_irq(int irq, void *dev_id)
 +{
 +struct max3355_data *data = dev_id;
 +int id = gpio_get_value(data->id_gpio);
 +
 +extcon_set_cable_state(data->edev, "USB-HOST", !id);
>>
>>> You have to get the gpio flag in the devicetree by using of_get_gpio_flags()
>>> function
>>> and then you would set the cable state according to gpio state and flag.
>>
>> I'm sorry but I just don't see why I have to do it. This is not a generic
>> GPIO driver, and the polarities of the GPIOs are determined solely by the
>> MAX3355 specs.
> 
>Again, got not reply...
> 
>> [...]
 +static int max3355_probe(struct platform_device *pdev)
 +{
 +struct device_node *np = pdev->dev.of_node;
 +struct max3355_data *data;
 +int gpio, irq, ret;
 +
 +data = devm_kzalloc(>dev, sizeof(struct max3355_data),
 +GFP_KERNEL);
 +if (!data)
 +return -ENOMEM;
 +
 +data->edev = devm_extcon_dev_allocate(>dev, max3355_cable);
 +if (IS_ERR(data->edev)) {
 +dev_err(>dev, "failed to allocate extcon device\n");
 +return PTR_ERR(data->edev);
 +}
 +data->edev->name = kstrdup(np->name, GFP_KERNEL);
 +
 +gpio = of_get_named_gpio(np, "maxim,id-gpio", 0);
>>
>>> Use of_get_gpio() or 

Re: [PATCH v2 05/10] hwmon: (fam15h_power) Add compute unit accumulated power

[Guenter Roeck]

On 10/20/2015 07:40 PM, Huang Rui wrote:

On Tue, Oct 20, 2015 at 07:15:25PM -0700, Guenter Roeck wrote:

On 10/20/2015 06:42 PM, Huang Rui wrote:

On Tue, Oct 20, 2015 at 03:24:09PM +0800, kbuild test robot wrote:

Hi Huang,

[auto build test ERROR on hwmon/hwmon-next -- if it's inappropriate base, 
please suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Huang-Rui/hwmon-fam15h_power-Introduce-an-accumulated-power-reporting-algorithm/20151020-110712
config: x86_64-randconfig-s2-10201413 (attached as .config)
reproduce:
 # save the attached .config to linux build tree
 make ARCH=x86_64

All errors (new ones prefixed by >>):

drivers/built-in.o: In function `fam15h_power_probe':

fam15h_power.c:(.text+0x26e3a3): undefined reference to `amd_get_cores_per_cu'

fam15h_power.c:(.text+0x26e41e): undefined reference to 
`amd_get_cores_per_cu'



Thanks to report this issue. :)
The root cause is that the test config doesn't enable
CONFIG_CPU_SUP_AMD.

How about below fix:



Guess you don't have a choice.



Yes, if I use test config, fam15h_power isn't chosen. :)

And if I use the "select" flag like below, fam15h_power can be built
successfully.


That is another possibility, though that isn't how CPU_SUP_AMD
is handled by its other users. Matter of philosophy, I guess.

Guenter


---
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 796569ee..50b4fef 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -289,6 +289,7 @@ config SENSORS_K10TEMP
  config SENSORS_FAM15H_POWER
tristate "AMD Family 15h processor power"
depends on X86 && PCI
+   select CPU_SUP_AMD
help
  If you say yes here you get support for processor power
  information of your AMD family 15h CPU.
---

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: [REPOST PATCH v2] drivers/pinctrl: Add the concept of an "init" state

[kbuild test robot]

Hi Doug,

[auto build test ERROR on pinctrl/for-next -- if it's inappropriate base, 
please suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Douglas-Anderson/drivers-pinctrl-Add-the-concept-of-an-init-state/20151021-101131
config: i386-randconfig-x004-10191220 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/base/dd.c: In function 'really_probe':
>> drivers/base/dd.c:325:2: error: implicit declaration of function 
>> 'pinctrl_init_done' [-Werror=implicit-function-declaration]
 pinctrl_init_done(dev);
 ^
   cc1: some warnings being treated as errors

vim +/pinctrl_init_done +325 drivers/base/dd.c

   319  } else if (drv->probe) {
   320  ret = drv->probe(dev);
   321  if (ret)
   322  goto probe_failed;
   323  }
   324  
 > 325  pinctrl_init_done(dev);
   326  
   327  if (dev->pm_domain && dev->pm_domain->sync)
   328  dev->pm_domain->sync(dev);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v1 2/2] ARM: dts: rockchip: Add the OTP gpio pinctrl

[Caesar Wang]

We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.

Signed-off-by: Caesar Wang 
---

Changes in v1:
  - As the Doug comments, drop the thermal driver patchs since
we can with pinctrl changing to work.
  - As the Doug's patch to add the 'init' property.

 arch/arm/boot/dts/rk3288.dtsi | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 906e938..6ea89aa 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -447,8 +447,9 @@
clock-names = "tsadc", "apb_pclk";
resets = < SRST_TSADC>;
reset-names = "tsadc-apb";
-   pinctrl-names = "default";
-   pinctrl-0 = <_out>;
+   pinctrl-names = "init", "default";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
status = "disabled";
@@ -1273,6 +1274,10 @@
};
 
tsadc {
+   otp_gpio: otp-gpio {
+   rockchip,pins = <0 10 RK_FUNC_GPIO 
_pull_none>;
+   };
+
otp_out: otp-out {
rockchip,pins = <0 10 RK_FUNC_1 
_pull_none>;
};
-- 
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 v1 1/2] dt-bindings: Sync the dts to this document

[Caesar Wang]

Add the OTP gpio state, we need switch the pin to gpio state
before the TSADC controller is reset.

Signed-off-by: Caesar Wang 
---

Changes in v1:
  - As the Doug comments, add the 'init' property to sync document.

 Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index ef802de..28e84f7 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -27,8 +27,9 @@ tsadc: tsadc@ff28 {
clock-names = "tsadc", "apb_pclk";
resets = < SRST_TSADC>;
reset-names = "tsadc-apb";
-   pinctrl-names = "default";
-   pinctrl-0 = <_out>;
+   pinctrl-names = "init", "default";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
rockchip,hw-tshut-mode = <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/

[PATCH v1 0/2] fix the TSHUT issue on rockchip thermal

[Caesar Wang]

We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.

Says:
The TSHUT temperature is setting more than 80 degree, the default
tshut polarity is HIGH.

If T > 80C, the OTP output the High Signal.
If T < 80C, the OTP output the Low Signal.

On the moment, the TSADC controller is reset, the tshut polarity will be
Low in a short period of time.

So:
If T < 80C, the OTP output the High Signal.
If T > 80C, the OTP output the Low Signal.

In some cases, the OTP pin is connected to the PMIC, maybe the PMIC can
accept the reset response time to avoid this issue.

In other words, the system will be always reboot if we make the OTP pin
is connected the others IC to control the power.

This series patchs are depend on Doug's 
patch.(https://patchwork.kernel.org/patch/7454081/)

This series patchs are based on the Linus master branch.

c51a571 ARM: dts: rockchip: Add the OTP gpio pinctrl
e1ecae4 dt-bindings: Sync the dts to this document
150426c drivers/pinctrl: Add the concept of an "init" state
ce1fad2 Merge branch 'keys-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
1099f86 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
911b79c KEYS: Don't permit request_key() to construct a new keyring
37850e3 net: bcmgenet: Fix early link interrupt enabling
afc050d Merge tag 'wireless-drivers-for-davem-2015-10-17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
e277de5 tunnels: Don't require remote endpoint or ID during creation.
740dbc2 openvswitch: Scrub skb between namespaces


Tested on box board.


Changes in v1:
  - As the Doug comments, add the 'init' property to sync document.
  - As the Doug comments, drop the thermal driver patchs since
we can with pinctrl changing to work.
  - As the Doug's patch to add the 'init' property.

Caesar Wang (2):
  dt-bindings: Sync the dts to this document
  ARM: dts: rockchip: Add the OTP gpio pinctrl

 Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 5 +++--
 arch/arm/boot/dts/rk3288.dtsi  | 9 +++--
 2 files changed, 10 insertions(+), 4 deletions(-)

-- 
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 05/10] hwmon: (fam15h_power) Add compute unit accumulated power

[Huang Rui]

On Tue, Oct 20, 2015 at 07:15:25PM -0700, Guenter Roeck wrote:
> On 10/20/2015 06:42 PM, Huang Rui wrote:
> >On Tue, Oct 20, 2015 at 03:24:09PM +0800, kbuild test robot wrote:
> >>Hi Huang,
> >>
> >>[auto build test ERROR on hwmon/hwmon-next -- if it's inappropriate base, 
> >>please suggest rules for selecting the more suitable base]
> >>
> >>url:
> >>https://github.com/0day-ci/linux/commits/Huang-Rui/hwmon-fam15h_power-Introduce-an-accumulated-power-reporting-algorithm/20151020-110712
> >>config: x86_64-randconfig-s2-10201413 (attached as .config)
> >>reproduce:
> >> # save the attached .config to linux build tree
> >> make ARCH=x86_64
> >>
> >>All errors (new ones prefixed by >>):
> >>
> >>drivers/built-in.o: In function `fam15h_power_probe':
> >>>>fam15h_power.c:(.text+0x26e3a3): undefined reference to 
> >>>>`amd_get_cores_per_cu'
> >>fam15h_power.c:(.text+0x26e41e): undefined reference to 
> >> `amd_get_cores_per_cu'
> >>
> >
> >Thanks to report this issue. :)
> >The root cause is that the test config doesn't enable
> >CONFIG_CPU_SUP_AMD.
> >
> >How about below fix:
> >
> 
> Guess you don't have a choice.
> 

Yes, if I use test config, fam15h_power isn't chosen. :)

And if I use the "select" flag like below, fam15h_power can be built
successfully.

---
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 796569ee..50b4fef 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -289,6 +289,7 @@ config SENSORS_K10TEMP
 config SENSORS_FAM15H_POWER
tristate "AMD Family 15h processor power"
depends on X86 && PCI
+   select CPU_SUP_AMD
help
  If you say yes here you get support for processor power
  information of your AMD family 15h CPU.
---

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: what's in nvdimm.git for v4.4?

[Dave Chinner]

On Tue, Oct 20, 2015 at 05:31:18PM -0700, Dan Williams wrote:
> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner  wrote:
> > On Tue, Oct 20, 2015 at 11:31:45PM +, Williams, Dan J wrote:
> >> Here is a status summary of the topic-branches nvdimm.git is tracking
> >> for v4.4.  Unless indicated these branches are not present in -next.
> >> Please ACK, NAK, or ask for a re-post of any of the below to disposition
> >> it for the merge window.
> >>
> >> ===
> >> for-4.4/dax-fixes:
> >> ===
> > ...
> >> Dave Chinner (5):
> >>   xfs: fix inode size update overflow in xfs_map_direct()
> >>   xfs: introduce BMAPI_ZERO for allocating zeroed extents
> >>   xfs: Don't use unwritten extents for DAX
> >>   xfs: DAX does not use IO completion callbacks
> >>   xfs: add ->pfn_mkwrite support for DAX
> >
> > Please drop these. They have not been reviewed yet, and because
> > the changes affect more than just DAX (core XFS allocator
> > functionality was changed) these need to go through the XFS tree.
> >
> 
> Ok, thanks for the heads up.  For the get_user_pages() patches that
> build on these fixes I'm assuming your review bandwidth is in short
> supply to also give an XFS sign-off on those changes for 4.4?

I'm not aware of any other patches that touch XFS. AFAIA, you
haven't cc'd anything to x...@oss.sgi.com, so it's not on my radar...

> I'm wondering if we can take a conservative step forward with those
> patches for 4.4.  if XFS and EXT4 interactions need more time to get
> worked out, which I believe they do, I can conceive just turning on
> get_user_pages() support for DAX-mappings of the raw block device.

Regardless of the ext4/XFS status, isn't it a bit late to be
proposing brand new stuff that nobody has had time to think about
for the next merge window?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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 v7 03/60] sparc/PCI: Unify pci_register_region()

[Bjorn Helgaas]

On Tue, Oct 20, 2015 at 03:30:44PM -0700, Yinghai Lu wrote:
> On Tue, Oct 20, 2015 at 3:16 PM, Yinghai Lu  wrote:
> > On Tue, Oct 20, 2015 at 2:57 PM, Bjorn Helgaas  wrote:
> >> On Thu, Oct 08, 2015 at 02:38:22PM -0700, Yinghai Lu wrote:
> >>> We register regions for legacy and iommu and all have open code.
> >>>
> >>> Unify them to pci_register_region() and call it accordingly.
> >>>
> >>> + if (!mem_res->flags)
> >>>   return;
> >>>
> >>> - p->name = "Video RAM area";
> >>> - p->start = mem_res->start + 0xaUL;
> >>> - p->end = p->start + 0x1UL;
> >>> - p->flags = IORESOURCE_BUSY;
> >>> - request_resource(mem_res, p);
> >>> + mem_rstart = mem_res->start - offset;
> >>> + mem_rend = mem_res->end - offset;
> >>
> >> This is essentially doing pcibios_bus_to_resource(), except in an
> >> unnecessarily arch-dependent way.  Can you rework it to use
> >> pcibios_bus_to_resource()?  I think you'll have to do
> >> pci_register_legacy_regions() in pci_scan_one_pbm() instead of in
> >> pci_determine_mem_io_space(), so that you have a struct pci_bus to
> >> use, but your next patch does that anyway.
> >>
> >>>
> >>> - p = kzalloc(sizeof(*p), GFP_KERNEL);
> >>> - if (!p)
> >>> + /* contain checking */
> >>> + if (!(mem_rstart <= rstart && mem_rend >= rend))
> >>>   return;
> >
> > Difference is here.
> >
> > pcibios_bus_to_resource() would return resource even region is not 
> > contained.
> >
> >>> + res->name = name;
> >>> + res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> >>> + res->start = rstart + offset;
> >>> + res->end = rend + offset;
> >>> + conflict = request_resource_conflict(mem_res, res);
> >>> + if (conflict) {
> >>> + printk(KERN_DEBUG "PCI: %s can't claim %s %pR: address 
> >>> conflict with %s %pR\n",
> >>> + pbm->name, res->name, res, conflict->name, 
> >>> conflict);
> >>> + kfree(res);
> >>> + }
> >
> > also we will need to get parent resource to use request_resource_conflict.
> 
> so do you agree following change to pcibios_bus_to_resource() ?
> then we can use __pcibios_bus_resource().

I doubt I would agree with a change like this, but maybe, if you can
explain what's unique about the sparc architecture that would require
a change like this.

> diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
> index 5f4a2e0..6c73327 100644
> --- a/drivers/pci/host-bridge.c
> +++ b/drivers/pci/host-bridge.c
> @@ -70,12 +70,15 @@ static bool region_contains(struct pci_bus_region 
> *region1,
>  return region1->start <= region2->start && region1->end >= region2->end;
>  }
> 
> -void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
> - struct pci_bus_region *region)
> +int __pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
> + struct pci_bus_region *region,
> + struct resource **res_ret,
> + resource_size *off_ret)
>  {
>  struct pci_host_bridge *bridge = pci_find_host_bridge(bus);
>  struct resource_entry *window;
>  resource_size_t offset = 0;
> +int found = 0;
> 
>  resource_list_for_each_entry(window, >windows) {
>  struct pci_bus_region bus_region;
> @@ -88,11 +91,23 @@ void pcibios_bus_to_resource(struct pci_bus *bus,
> struct resource *res,
> 
>  if (region_contains(_region, region)) {
>  offset = window->offset;
> +if (off_ret)
> +*off_ret = offset;
> +if (res_ret)
> +*res_ret = window->res;
> +found = 1;
>  break;
>  }
>  }
> 
>  res->start = region->start + offset;
>  res->end = region->end + offset;
> +
> +return found;
> +}
> +void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
> + struct pci_bus_region *region)
> +{
> +__pcibios_bus_to_resource(bus, res, region, NULL, NULL);
>  }
>  EXPORT_SYMBOL(pcibios_bus_to_resource);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index b54fbf1..bec3eed 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -781,6 +781,10 @@ void pci_fixup_cardbus(struct pci_bus *);
> 
>  void pcibios_resource_to_bus(struct pci_bus *bus, struct
> pci_bus_region *region,
>   struct resource *res);
> +int __pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
> +  struct pci_bus_region *region,
> +  struct resource **res_ret,
> +  resource_size *off_ret);
>  void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
>   struct pci_bus_region *region);
>  void pcibios_scan_specific_bus(int busn);
> --
> 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

Re: [PATCH 04/31] perf record, bpf: Create probe points for BPF programs

[Wangnan (F)]

On 2015/10/21 3:12, Arnaldo Carvalho de Melo wrote:

Em Wed, Oct 14, 2015 at 12:41:15PM +, Wang Nan escreveu:

This patch introduces bpf__{un,}probe() functions to enable callers to
create kprobe points based on section names a BPF program. It parses
the section names in the program and creates corresponding 'struct
perf_probe_event' structures. The parse_perf_probe_command() function is
used to do the main parsing work. The resuling 'struct perf_probe_event'
is stored into program private data for further using.

By utilizing the new probing API, this patch creates probe points during
event parsing.

To ensure probe points be removed correctly, register an atexit hook
so even perf quit through exit() bpf__clear() is still called, so probing
points are cleared. Note that bpf_clear() should be registered before
bpf__probe() is called, so failure of bpf__probe() can still trigger
bpf__clear() to remove probe points which are already probed.

strerror style error reporting scaffold is created by this patch.
bpf__strerror_probe() is the first error reporting function in bpf-loader.c.

So, this one, for a non-root user gives me:

[acme@felicio linux]$ perf record --event /tmp/foo.o sleep 1
event syntax error: '/tmp/foo.o'
  \___ Invalid argument

(add -v to see detail)
Run 'perf list' for a list of valid events

  Usage: perf record [] []
 or: perf record [] --  []

 -e, --eventevent selector. use 'perf list' to list available 
events
[acme@felicio linux]$


It should be:

 # perf record -e ./test_config_map.o ls
 Failed to init vmlinux path.
 event syntax error: './test_config_map.o'
  \___ You need to be root, and 
/proc/sys/kernel/kptr_restrict should be 0



 (add -v to see detail)
 Run 'perf list' for a list of valid events

  usage: perf record [] []
 or: perf record [] --  []

 -e, --eventevent selector. use 'perf list' to list 
available events


So this is another problem related to probing. I'll have a look at your lot.

Thank you.




I.e. no libbpf error (good!) but then, just an -EINVAL as the "event syntax
error", which clearly isn't a syntax error, we need to tell the user that he or 
she
needs special perfmissions for using sys_bpf() :-)

As root:

[root@felicio ~]# perf record --event /tmp/foo.o sleep
event syntax error: '/tmp/foo.o'
  \___ Invalid argument

(add -v to see detail)
Run 'perf list' for a list of valid events

  Usage: perf record [] []
 or: perf record [] --  []

 -e, --eventevent selector. use 'perf list' to list available 
events
[root@felicio ~]# ls -la /tmp/foo.o
-rw-rw-r--. 1 acme acme 824 Oct 20 12:35 /tmp/foo.o
[root@felicio ~]# file /tmp/foo.o
/tmp/foo.o: ELF 64-bit LSB relocatable, no machine, version 1 (SYSV), not 
stripped


Humm, its something else, this is an ancient kernel, 4.2.0, probably without
eBPF support? Nope, its there:

[root@felicio ~]# grep -i sys_bpf /proc/kallsyms
811829d0 T SyS_bpf
811829d0 T sys_bpf
[root@felicio ~]#

Its something else, we need to improve this error reporting:

[root@felicio ~]# perf record -v --event /tmp/foo.o sleep 1
libbpf: loading /tmp/foo.o
libbpf: section .strtab, size 60, link 0, flags 0, type=3
libbpf: section .text, size 0, link 0, flags 6, type=1
libbpf: section .data, size 0, link 0, flags 3, type=1
libbpf: section .bss, size 0, link 0, flags 3, type=8
libbpf: section do_fork, size 16, link 0, flags 6, type=1
libbpf: found program do_fork
libbpf: section license, size 4, link 0, flags 3, type=1
libbpf: license of /tmp/foo.o is GPL
libbpf: section version, size 4, link 0, flags 3, type=1
libbpf: kernel version of /tmp/foo.o is 40100
libbpf: section .symtab, size 96, link 1, flags 0, type=2
bpf: config program 'do_fork'
symbol:do_fork file:(null) line:0 offset:0 return:0 lazy:(null)
bpf: 'do_fork': event name is missing
event syntax error: '/tmp/foo.o'
  \___ Invalid argument

(add -v to see detail)
Run 'perf list' for a list of valid events

  Usage: perf record [] []
 or: perf record [] --  []

 -e, --eventevent selector. use 'perf list' to list available 
events
[root@felicio ~]#

[root@felicio ~]# grep do_fork /proc/kallsyms
81099ab0 T _do_fork
81ccc800 d do_fork_test
[root@felicio ~]#

$ echo '__attribute__((section("_do_fork"), used)) int fork(void *ctx) {return 0;} char _license[] 
__attribute__((section("license"), used)) = "GPL";int _version 
__attribute__((section("version"), used)) = 0x40100;' | clang -D__KERNEL__ $CLANG_OPTIONS $KERNEL_INC_OPTIONS 
-Wno-unused-value -Wno-pointer-sign -working-directory $WORKING_DIR -c - -target bpf -O2 -o /tmp/foo.o

[root@felicio ~]# perf record  -v --event /tmp/foo.o sleep 1
libbpf: loading /tmp/foo.o
libbpf: section .strtab, size 61, link 0, flags 0, type=3
libbpf: section .text, size 0, link 0, flags 6, type=1
libbpf: section .data, size 0, link 0, flags 3, type=1
libbpf: section .bss, size 

Re:

[Mohammed]

Message from Saudi Arabia Prince Alwaleed bin Talal for his charity donation 
and You have been selected as recipient/benefactor for $5Million Dollars from 
Alwaleed Philanthropic Foundation Grant.for more information contact Via email  
ally00...@yandex.com

Thanks

Ally Mohammed

Please, reply should go to ally00...@yandex.com
--
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 1/2] dt-bindings: Add new SoCs to bcm4708 DT bindings

[Rob Herring]

On Thu, Oct 15, 2015 at 5:24 PM, Jon Mason  wrote:
> Add the 4708, 4709, and 53012 SoCs to the the documentation for the
> Broadcom Northstar device tree bindings.
>
> Signed-off-by: Jon Mason 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt 
> b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
> index 6b0f49f..8608a77 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
> +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
> @@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following 
> properties:
>
>  Required root node property:
>
> +bcm4708
>  compatible = "brcm,bcm4708";
> +
> +bcm4709
> +compatible = "brcm,bcm4709";
> +
> +bcm53012
> +compatible = "brcm,bcm53012";
> --
> 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 V7] mm: memory hot-add: memory can not be added to movable zone defaultly

[Changsheng Liu]

在 2015/10/15 0:18, Vlastimil Babka 写道:

On 10/12/2015 08:58 AM, Changsheng Liu wrote:

From: Changsheng Liu 

After the user config CONFIG_MOVABLE_NODE,
When the memory is hot added, should_add_memory_movable() return 0
because all zones including ZONE_MOVABLE are empty,
so the memory that was hot added will be assigned to ZONE_NORMAL
and ZONE_NORMAL will be created firstly.
But we want the whole node to be added to ZONE_MOVABLE by default.

So we change should_add_memory_movable(): if the user config
CONFIG_MOVABLE_NODE and sysctl parameter hotadd_memory_as_movable is 1
and the ZONE_NORMAL is empty or the pfn of the hot-added memory
is after the end of the ZONE_NORMAL it will always return 1
and then the whole node will be added to ZONE_MOVABLE by default.
If we want the node to be assigned to ZONE_NORMAL,
we can do it as follows:
"echo online_kernel > /sys/devices/system/memory/memoryXXX/state"

By the patch, the behavious of kernel is changed by sysctl,
user can automatically create movable memory
by only the following udev rule:
SUBSYSTEM=="memory", ACTION=="add",
ATTR{state}=="offline", ATTR{state}="online"

I'm sorry for replying you so late due to the busy business trip.

So just to be clear, we are adding a new sysctl, because the existing
movable_node kernel option, which is checked by movable_node_is_enabled(), and
does the same thing for non-hot-added-memory (?) cannot be reused for hot-added
memory, as that would be a potentially surprising behavior change? Correct? Then
this should be mentioned in the changelog too, and wherever "movable_node" is
documented should also mention the new sysctl. Personally, I would expect
movable_node to affect hot-added memory as well, and would be surprised that it
doesn't...

I think it can let the user decides when to use this feature.
The user can enable the feature when making the hot_added memory  
of a node movable and
make the feature disable to assign the hot_added memory of the next 
node to ZONE_NORMAL .



Signed-off-by: Changsheng Liu 
Signed-off-by: Xiaofeng Yan 
Tested-by: Dongdong Fan 
Cc: Wang Nan 
Cc: Dave Hansen 
Cc: Yinghai Lu 
Cc: Tang Chen 
Cc: Yasuaki Ishimatsu 
Cc: Toshi Kani 
Cc: Xishi Qiu 
---
  Documentation/memory-hotplug.txt |5 -
  kernel/sysctl.c  |   15 +++
  mm/memory_hotplug.c  |   24 
  3 files changed, 43 insertions(+), 1 deletions(-)

diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index ce2cfcf..7ac7485 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -277,7 +277,7 @@ And if the memory block is in ZONE_MOVABLE, you can change 
it to ZONE_NORMAL:
  After this, memory block XXX's state will be 'online' and the amount of
  available memory will be increased.
  
-Currently, newly added memory is added as ZONE_NORMAL (for powerpc, ZONE_DMA).

+Currently, newly added memory is added as ZONE_NORMAL or ZONE_MOVABLE (for 
powerpc, ZONE_DMA).
  This may be changed in future.
  
  
@@ -319,6 +319,9 @@ creates ZONE_MOVABLE as following.

Size of memory not for movable pages (not for offline) is TOTAL - .
Size of memory for movable pages (for offline) is .
  
+And a sysctl parameter for assigning the hot added memory to ZONE_MOVABLE is

+supported. If the value of "kernel/hotadd_memory_as_movable" is 1,the hot added
+memory will be assigned to ZONE_MOVABLE by default.
  
  Note: Unfortunately, there is no information to show which memory block belongs

  to ZONE_MOVABLE. This is TBD.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 19b62b5..16b1501 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -166,6 +166,10 @@ extern int unaligned_dump_stack;
  extern int no_unaligned_warning;
  #endif
  
+#ifdef CONFIG_MOVABLE_NODE

+extern int hotadd_memory_as_movable;
+#endif
+
  #ifdef CONFIG_PROC_SYSCTL
  
  #define SYSCTL_WRITES_LEGACY	-1

@@ -1139,6 +1143,17 @@ static struct ctl_table kern_table[] = {
.proc_handler   = timer_migration_handler,
},
  #endif
+/*If the value of "kernel/hotadd_memory_as_movable" is 1,the hot added
+ * memory will be assigned to ZONE_MOVABLE by default.*/
+#ifdef CONFIG_MOVABLE_NODE
+   {
+   .procname   = "hotadd_memory_as_movable",
+   .data   = _memory_as_movable,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
+#endif
{ }
  };
  
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c

index 26fbba7..eca5512 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -37,6 +37,11 @@
  
  #include "internal.h"
  
+/*If the global variable value is 1,

+ * the hot added memory will be assigned to ZONE_MOVABLE by default
+ */
+int hotadd_memory_as_movable;
+
  /*
   * online_page_callback contains pointer to current page onlining function.
   * Initially it is 

Re: [PATCH 3/4] thermal: rockchip: change the TSHUT default state

[Caesar Wang]

Doug,

在 2015年10月21日 10:14, Doug Anderson 写道:

Caesar,

On Tue, Oct 20, 2015 at 6:47 PM, Caesar Wang  wrote:

Doug,

在 2015年10月21日 00:01, Doug Anderson 写道:

Caesar,

On Tue, Oct 20, 2015 at 2:11 AM, Caesar Wang  wrote:

As the TRM says, the TSHUT default state is high active.
In general, the TSHUT state can get from the dts. Otherwise
it gets the state from this.

Can you point at where the TRM says that the default state is high active?

With the manual I have, I look at TSADC_AUTO_CON and I look at the
description of "Bit 8".  It says that "tshut polarity" is 0 for low
active and 1 for high active.  It then said that the Reset Value is 0.

...the "Reset Value" in tables like this is notoriously unreliable, so
I can totally believe that it's wrong.  If you can point me at the
part of the TRM that says that TSHUT is high active by default then I
can confirm that for you.  ;)


Okay, I know that's my wrong, the polarity is high or low can be selected.
:-(

I remember the veyron why is the default HiGH active, since the opt is
connected to the PMIC.(we need think about the devices)

Why is the evb board LOW active, since the opt didn't connected to the
devices. TSHUT is depend on the CRU to work.

I think we can drop this patch then, right?  Any boards that need a
change from the default can just set "rockchip,hw-tshut-polarity",
right?

Yep, we should drop this patch.
I'm ready resend the patchs.



-Doug



--
Thanks,
Caesar

--
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 05/10] hwmon: (fam15h_power) Add compute unit accumulated power

[Guenter Roeck]

On 10/20/2015 06:42 PM, Huang Rui wrote:

On Tue, Oct 20, 2015 at 03:24:09PM +0800, kbuild test robot wrote:

Hi Huang,

[auto build test ERROR on hwmon/hwmon-next -- if it's inappropriate base, 
please suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Huang-Rui/hwmon-fam15h_power-Introduce-an-accumulated-power-reporting-algorithm/20151020-110712
config: x86_64-randconfig-s2-10201413 (attached as .config)
reproduce:
 # save the attached .config to linux build tree
 make ARCH=x86_64

All errors (new ones prefixed by >>):

drivers/built-in.o: In function `fam15h_power_probe':

fam15h_power.c:(.text+0x26e3a3): undefined reference to `amd_get_cores_per_cu'

fam15h_power.c:(.text+0x26e41e): undefined reference to 
`amd_get_cores_per_cu'



Thanks to report this issue. :)
The root cause is that the test config doesn't enable
CONFIG_CPU_SUP_AMD.

How about below fix:



Guess you don't have a choice.

Guenter


---
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 796569ee..603eadd 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -288,7 +288,7 @@ config SENSORS_K10TEMP

  config SENSORS_FAM15H_POWER
tristate "AMD Family 15h processor power"
-   depends on X86 && PCI
+   depends on X86 && PCI && CPU_SUP_AMD
help
  If you say yes here you get support for processor power
  information of your AMD family 15h CPU.

---

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 3/4] thermal: rockchip: change the TSHUT default state

[Doug Anderson]

Caesar,

On Tue, Oct 20, 2015 at 6:47 PM, Caesar Wang  wrote:
> Doug,
>
> 在 2015年10月21日 00:01, Doug Anderson 写道:
>
> Caesar,
>
> On Tue, Oct 20, 2015 at 2:11 AM, Caesar Wang  wrote:
>
> As the TRM says, the TSHUT default state is high active.
> In general, the TSHUT state can get from the dts. Otherwise
> it gets the state from this.
>
> Can you point at where the TRM says that the default state is high active?
>
> With the manual I have, I look at TSADC_AUTO_CON and I look at the
> description of "Bit 8".  It says that "tshut polarity" is 0 for low
> active and 1 for high active.  It then said that the Reset Value is 0.
>
> ...the "Reset Value" in tables like this is notoriously unreliable, so
> I can totally believe that it's wrong.  If you can point me at the
> part of the TRM that says that TSHUT is high active by default then I
> can confirm that for you.  ;)
>
>
> Okay, I know that's my wrong, the polarity is high or low can be selected.
> :-(
>
> I remember the veyron why is the default HiGH active, since the opt is
> connected to the PMIC.(we need think about the devices)
>
> Why is the evb board LOW active, since the opt didn't connected to the
> devices. TSHUT is depend on the CRU to work.

I think we can drop this patch then, right?  Any boards that need a
change from the default can just set "rockchip,hw-tshut-polarity",
right?

-Doug
--
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/

[REPOST PATCH v2] drivers/pinctrl: Add the concept of an "init" state

[Douglas Anderson]

From: Doug Anderson 

For pinctrl the "default" state is applied to pins before the driver's
probe function is called.  This is normally a sensible thing to do,
but in some cases can cause problems.  That's because the pins will
change state before the driver is given a chance to program how those
pins should behave.

As an example you might have a regulator that is controlled by a PWM
(output high = high voltage, output low = low voltage).  The firmware
might leave this pin as driven high.  If we allow the driver core to
reconfigure this pin as a PWM pin before the PWM's probe function runs
then you might end up running at too low of a voltage while we probe.

Let's introudce a new "init" state.  If this is defined we'll set
pinctrl to this state before probe and then "default" after probe
(unless the driver explicitly changed states already).

An alternative idea that was thought of was to use the pre-existing
"sleep" or "idle" states and add a boolean property that we should
start in that mode.  This was not done because the "init" state is
needed for correctness and those other states are only present (and
only transitioned in to and out of) when (optional) power management
is enabled.

Signed-off-by: Doug Anderson 
Signed-off-by: Douglas Anderson 
Acked-by: Greg Kroah-Hartman 
Tested-by: Caesar Wang 
---
Changes in v2:
- Added comment to pinctrl_init_done() as per Linus W.

Reposted after 1 year of no activity since Caesar Wang found a use for
this.  See .

 drivers/base/dd.c |  2 ++
 drivers/base/pinctrl.c| 15 +--
 drivers/pinctrl/core.c| 32 
 include/linux/pinctrl/consumer.h  |  6 ++
 include/linux/pinctrl/devinfo.h   |  4 
 include/linux/pinctrl/pinctrl-state.h |  8 
 6 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index c4a3f298e..217eafc 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -322,6 +322,8 @@ static int really_probe(struct device *dev, struct 
device_driver *drv)
goto probe_failed;
}
 
+   pinctrl_init_done(dev);
+
if (dev->pm_domain && dev->pm_domain->sync)
dev->pm_domain->sync(dev);
 
diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
index 5fb74b4..0762975 100644
--- a/drivers/base/pinctrl.c
+++ b/drivers/base/pinctrl.c
@@ -42,9 +42,20 @@ int pinctrl_bind_pins(struct device *dev)
goto cleanup_get;
}
 
-   ret = pinctrl_select_state(dev->pins->p, dev->pins->default_state);
+   dev->pins->init_state = pinctrl_lookup_state(dev->pins->p,
+   PINCTRL_STATE_INIT);
+   if (IS_ERR(dev->pins->init_state)) {
+   /* Not supplying this state is perfectly legal */
+   dev_dbg(dev, "no init pinctrl state\n");
+
+   ret = pinctrl_select_state(dev->pins->p,
+  dev->pins->default_state);
+   } else {
+   ret = pinctrl_select_state(dev->pins->p, dev->pins->init_state);
+   }
+
if (ret) {
-   dev_dbg(dev, "failed to activate default pinctrl state\n");
+   dev_dbg(dev, "failed to activate initial pinctrl state\n");
goto cleanup_get;
}
 
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 9638a00..2686a44 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1240,6 +1240,38 @@ int pinctrl_force_default(struct pinctrl_dev *pctldev)
 }
 EXPORT_SYMBOL_GPL(pinctrl_force_default);
 
+/**
+ * pinctrl_init_done() - tell pinctrl probe is done
+ *
+ * We'll use this time to switch the pins from "init" to "default" unless the
+ * driver selected some other state.
+ *
+ * @dev: device to that's done probing
+ */
+int pinctrl_init_done(struct device *dev)
+{
+   struct dev_pin_info *pins = dev->pins;
+   int ret;
+
+   if (!pins)
+   return 0;
+
+   if (IS_ERR(pins->init_state))
+   return 0; /* No such state */
+
+   if (pins->p->state != pins->init_state)
+   return 0; /* Not at init anyway */
+
+   if (IS_ERR(pins->default_state))
+   return 0; /* No default state */
+
+   ret = pinctrl_select_state(pins->p, pins->default_state);
+   if (ret)
+   dev_err(dev, "failed to activate default pinctrl state\n");
+
+   return ret;
+}
+
 #ifdef CONFIG_PM
 
 /**
diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h
index d7e5d60..be6032a 100644
--- a/include/linux/pinctrl/consumer.h
+++ b/include/linux/pinctrl/consumer.h
@@ -39,6 +39,7 @@ extern int pinctrl_select_state(struct pinctrl *p, struct 
pinctrl_state *s);
 
 extern struct pinctrl * __must_check devm_pinctrl_get(struct device *dev);
 extern void devm_pinctrl_put(struct pinctrl *p);
+extern int 

Re: [PATCH V2 2/3] Add iommu driver for hi6220 SoC platform

[chenfeng]

On 2015/10/20 23:02, Robin Murphy wrote:
> On 20/10/15 09:45, Chen Feng wrote:
>> iommu/hisilicon: Add hi6220-SoC smmu driver
> 
> A brief description of the smmu and what capabilities it provides wouldn't go 
> amiss here.
> 
ok
>> Signed-off-by: Chen Feng 
>> Signed-off-by: Yu Dongbin 
>> ---
>>   drivers/iommu/Kconfig|   8 +
>>   drivers/iommu/Makefile   |   1 +
>>   drivers/iommu/hi6220_iommu.c | 482 
>> +++
>>   3 files changed, 491 insertions(+)
>>   create mode 100644 drivers/iommu/hi6220_iommu.c
>>
>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>> index 4664c2a..9b41708 100644
>> --- a/drivers/iommu/Kconfig
>> +++ b/drivers/iommu/Kconfig
>> @@ -343,6 +343,14 @@ config SPAPR_TCE_IOMMU
>> Enables bits of IOMMU API required by VFIO. The iommu_ops
>> is not implemented as it is not necessary for VFIO.
>>
>> +config HI6220_IOMMU
>> +bool "Hi6220 IOMMU Support"
>> +depends on ARM64
>> +select IOMMU_API
>> +select IOMMU_IOVA
>> +help
>> +  Enable IOMMU Driver for hi6220 SoC.
>> +
>>   # ARM IOMMU support
>>   config ARM_SMMU
>>   bool "ARM Ltd. System MMU (SMMU) Support"
>> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
>> index c6dcc51..ee4dfef 100644
>> --- a/drivers/iommu/Makefile
>> +++ b/drivers/iommu/Makefile
>> @@ -23,3 +23,4 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
>>   obj-$(CONFIG_SHMOBILE_IOMMU) += shmobile-iommu.o
>>   obj-$(CONFIG_SHMOBILE_IPMMU) += shmobile-ipmmu.o
>>   obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
>> +obj-$(CONFIG_HI6220_IOMMU) += hi6220_iommu.o
> 
> It would be nice to insert this before CONFIG_INTEL_IOMMU to try to maintain 
> some semblance of order.
> 
ok
>> diff --git a/drivers/iommu/hi6220_iommu.c b/drivers/iommu/hi6220_iommu.c
>> new file mode 100644
>> index 000..6c5198d
>> --- /dev/null
>> +++ b/drivers/iommu/hi6220_iommu.c
>> @@ -0,0 +1,482 @@
>> +/*
>> + * Hisilicon Hi6220 IOMMU driver
>> + *
>> + * Copyright (c) 2015 Hisilicon Limited.
>> + *
>> + * Author: Chen Feng 
>> + *
>> + * 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.
>> + */
>> +
>> +#define pr_fmt(fmt) "IOMMU: " fmt
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> Those last 3 spoil the ordering here. Plus, do you really need 
> linux/interrupt.h twice?
> 
Accept,remove this later.
>> +#define SMMU_CTRL_OFFSET (0x)
>> +#define SMMU_ENABLE_OFFSET   (0x0004)
>> +#define SMMU_PTBR_OFFSET (0x0008)
>> +#define SMMU_START_OFFSET(0x000C)
>> +#define SMMU_END_OFFSET  (0x0010)
>> +#define SMMU_INTMASK_OFFSET  (0x0014)
>> +#define SMMU_RINTSTS_OFFSET  (0x0018)
>> +#define SMMU_MINTSTS_OFFSET  (0x001C)
>> +#define SMMU_INTCLR_OFFSET   (0x0020)
>> +#define SMMU_STATUS_OFFSET   (0x0024)
>> +#define SMMU_AXIID_OFFSET(0x0028)
>> +#define SMMU_CNTCTRL_OFFSET  (0x002C)
>> +#define SMMU_TRANSCNT_OFFSET (0x0030)
>> +#define SMMU_L0TLBHITCNT_OFFSET  (0x0034)
>> +#define SMMU_L1TLBHITCNT_OFFSET  (0x0038)
>> +#define SMMU_WRAPCNT_OFFSET  (0x003C)
>> +#define SMMU_SEC_START_OFFSET(0x0040)
>> +#define SMMU_SEC_END_OFFSET  (0x0044)
>> +#define SMMU_VERSION_OFFSET  (0x0048)
>> +#define SMMU_IPTSRC_OFFSET   (0x004C)
>> +#define SMMU_IPTPA_OFFSET(0x0050)
>> +#define SMMU_TRBA_OFFSET (0x0054)
>> +#define SMMU_BYS_START_OFFSET(0x0058)
>> +#define SMMU_BYS_END_OFFSET  (0x005C)
>> +#define SMMU_RAM_OFFSET  (0x1000)
>> +#define SMMU_REGS_MAX(15)
> 
> This is confusing; I count 24 registers listed above, what is 15 the maximum 
> of?
> 
>> +#define SMMU_REGS_SGMT_END   (0x60)
>> +#define SMMU_CHIP_ID_V100(1)
>> +#define SMMU_CHIP_ID_V200(2)
>> +
>> +#define SMMU_REGS_OPS_SEGMT_START(0xf00)
>> +#define SMMU_REGS_OPS_SEGMT_NUMB (8)
>> +#define SMMU_REGS_AXI_SEGMT_START(0xf80)
>> +#define SMMU_REGS_AXI_SEGMT_NUMB (8)
>> +
>> +#define SMMU_INIT(0x1)
>> +#define SMMU_RUNNING (0x2)
>> +#define SMMU_SUSPEND (0x3)
>> +#define SMMU_STOP(0x4)
>> +#define SMMU_CTRL_INVALID(BIT(10))
>> +#define PAGE_ENTRY_VALID (0x1)
>> +
>> +#define IOVA_START_PFN   (1)
>> +#define IOPAGE_SHIFT (12)
>> +#define IOVA_PFN(addr)   ((addr) >> IOPAGE_SHIFT)
>> +#define IOVA_PAGE_SZ (SZ_4K)
>> +#define IOVA_START   (0x2000)
> 
> 

Re: [PATCHv4 00/57] perf stat: Add scripting support

[Namhyung Kim]

Hi Jiri,

On Fri, Oct 16, 2015 at 12:40:35PM +0200, Jiri Olsa wrote:
> hi,
> sending another version of stat scripting.
> 
> v4 changes:
>   - added attr update event for event's cpumask
>   - forbig aggregation on task workloads
>   - some minor reorders and changelog fixes
> 
> v3 changes:
>   - added attr update event to handle unit,scale,name for event
> it fixed the uncore_imc_1/cas_count_read/ record/report
>   - perf report -D now displays stat related events
>   - some minor and changelog fixes
> 
> v2 changes:
>   - rebased to latest Arnaldo's perf/core
>   - patches 1 to 11 already merged in
>   - added --per-core/--per-socket/-A options for perf stat report
> command to allow custom aggregation in stat report, please
> check new examples below
>   - couple changelogs changes
> 
> 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
> 
> Basically it allows to store stat data into perf.data and
> post process it with python scripts in a similar way we
> do for sampling data.

Nice.  I didn't review this patchset (yet) but I have a feature
request. :)  It'd be great if we have 'perf stat diff' to compare two
(or more) files in some way.

Thanks,
Namhyung
--
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 03/31] perf tools: Enable passing bpf object file to --event

[Wangnan (F)]

On 2015/10/20 23:42, Arnaldo Carvalho de Melo wrote:

Em Tue, Oct 20, 2015 at 12:15:58PM -0300, Arnaldo Carvalho de Melo escreveu:

Em Tue, Oct 20, 2015 at 12:12:55PM -0300, Arnaldo Carvalho de Melo escreveu:

Em Wed, Oct 14, 2015 at 12:41:14PM +, Wang Nan escreveu:


Managed after running:

  perf test LLVM

copy'n'pasting the output of those "set env" lines, replacing it with
export, etc to get to:

[acme@felicio linux]$ echo '__attribute__((section("do_fork"), used)) int fork(void *ctx) {return 0;} char _license[] 
__attribute__((section("license"), used)) = "GPL";int _version __attribute__((section("version"), 
used)) = 0x40100;' | $CLANG_EXEC -D__KERNEL__ $CLANG_OPTIONS $KERNEL_INC_OPTIONS -Wno-unused-value -Wno-pointer-sign 
-working-directory $WORKING_DIR -c "$CLANG_SOURCE" -target bpf -O2 -o /tmp/foo.o
[acme@felicio linux]$ file /tmp/foo.o
/tmp/foo.o: ELF 64-bit LSB relocatable, no machine, version 1 (SYSV), not 
stripped
[acme@felicio linux]$

And finally:


[acme@felicio linux]$ file /tmp/foo.o
/tmp/foo.o: ELF 64-bit LSB relocatable, no machine, version 1 (SYSV), not 
stripped
[acme@felicio linux]$ perf record --event /tmp/foo.o sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.013 MB perf.data ]
[acme@felicio linux]$ perf evlist  -v
/tmp/foo.o: type: 1, size: 112, config: 0x9, { sample_period, sample_freq }: 
4000, sample_type: IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 
1, freq: 1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest: 1, 
mmap2: 1, comm_exec: 1
[acme@felicio linux]$ perf evlist
/tmp/foo.o
[acme@felicio linux]$

So, type 1 is PERF_TYPE_SOFTWARE, config 0x9 is PERF_COUNT_SW_DUMMY, ok.


You won't see this dummy event after patch 'perf tools: Collect perf_evsel
in BPF object files'. I use dummy event here so we can test basic parsing
and loading before that enabler patch to avoid enable too much code by
one patch.

Thank you, and glad to see you start working on this patch set again!


And it behaves accordingly, no samples, etc.

Added the sequence of testing with a non-existing file, with a normal ELF file
and then with a valid eBPF ELF file as committer notes.

Continuing.

- 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: [PATCH] EDAC: Add AMD Seattle SoC EDAC

[Hanjun Guo]

Hi Boris, Mark,

On 2015/10/21 1:36, Borislav Petkov wrote:
> On Tue, Oct 20, 2015 at 06:26:55PM +0100, Mark Rutland wrote:
>>> Btw, how much of this is implementing generic A57 functionality?
>> The driver is entirely A57 generic.
>>
>>> If a lot, can we make this a generic a57_edac driver so that multiple
>>> vendors can use it?
>> Yes.
> Ok, cool.
>
>>> How fast and how ugly can something like that become?
>> Not sure I follow.
> In the sense that some vendor might require just a little bit different
> handling or maybe wants to read some vendor-specific registers in
> addition to the architectural ones.

Yes, you are right and foresight :)

>
> Then we'll start adding vendor-specific hacks to that generic driver.
> And therefore the question how fast and how ugly such hacks would
> become.
>
> I guess we'll worry about that when we get there...

So I think the meaning of those error register is the same, but the way
of handle it may different from SoCs, for single bit error:

 - SoC may trigger a interrupt;
 - SoC may just keep silent so we need to scan the registers using poll
   mechanism.

For Double bit error:
  - SoC may also keep silent
  - Trigger a interrupt
  - Trigger a SEI (system error)

Any suggestion to cover those cases?

Thanks
Hanjun

--
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 1/3] perf help: Add options description to 'perf -h'

[Namhyung Kim]

On Tue, Oct 20, 2015 at 10:13:17AM +0800, Yunlong Song wrote:
> On 2015/10/19 23:29, Namhyung Kim wrote:
> > Hi,
> > 
> > On Thu, Oct 15, 2015 at 03:39:50PM +0800, Yunlong Song wrote:
> >> Add options description to 'perf -h' to make it consistent with other 
> >> builtins
> >> (e.g., 'perf stat -h').
> >>
> >> Example:
> >>
> >> Before this patch:
> >>
> >>  # perf -h
> >>
> >>  usage: perf [--version] [--help] [OPTIONS] COMMAND [ARGS]
> >>
> >>   The most commonly used perf commands are:
> >> annotateRead perf.data (created by perf record) and display 
> >> annotated code
> >> archive Create archive with object files with build-ids found 
> >> in perf.data file
> >> bench   General framework for benchmark suites
> >> buildid-cache   Manage build-id cache.
> >> buildid-listList the buildids in a perf.data file
> >>  
> >> testRuns sanity tests.
> >> timechart   Tool to visualize total system behavior during a 
> >> workload
> >> top System profiling tool.
> >> trace   strace inspired tool
> >> probe   Define new dynamic tracepoints
> >>
> >>   See 'perf help COMMAND' for more information on a specific command.
> >>
> >> After this patch:
> >>
> >>  # perf -h
> >>
> >>   usage: perf [--version] [--help] [OPTIONS] COMMAND [ARGS]
> >>
> >>  --helphelp
> >>  --version version
> >>  --exec-path   exec-path
> >>  --html-path   html-path
> >>  --paginatepaginate
> >>  --no-pagerno-pager
> >>  --perf-dirperf-dir
> >>  --work-tree   work-tree
> >>  --debugfs-dir debugfs-dir
> >>  --buildid-dir buildid-dir
> >>  --list-cmds   list-cmds
> >>  --list-opts   list-opts
> >>  --debug   debug
> > 
> > IMHO this *help* message is not very useful in its current form.  Also
> > please consider updating Documentation/perf.txt too.
> > 
> > Thanks,
> > Namhyung
> 
> OK, I will update the struct option of perf to a more interpretative style 
> soon.

In addition, --help and --version options are duplicate.  And I think
--perf-dir and --work-tree options are never used.  Also I doubt
anyone uses html help page with --html-path.  Finally I think it'd be
better to hide --list-cmds and --list-opts options as they're only
intended to be used by completion scripts.

Thanks,
Namhyung
--
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 03/31] perf tools: Enable passing bpf object file to --event

[Wangnan (F)]

On 2015/10/20 23:15, Arnaldo Carvalho de Melo wrote:

Em Tue, Oct 20, 2015 at 12:12:55PM -0300, Arnaldo Carvalho de Melo escreveu:

Em Wed, Oct 14, 2015 at 12:41:14PM +, Wang Nan escreveu:

By introducing new rules in tools/perf/util/parse-events.[ly], this
patch enables 'perf record --event bpf_file.o' to select events by an
eBPF object file. It calls parse_events_load_bpf() to load that file,
which uses bpf__prepare_load() and finally calls bpf_object__open() for
the object files.

After applying this patch, commands like:

  # perf record --event foo.o sleep

become possible.

So, trying the above command I get almost perfect output:

   [root@felicio ~]# perf record --event foo.o sleep
   libbpf: failed to open foo.o: No such file or directory
   event syntax error: 'foo.o'
\___ BPF object file 'foo.o' is invalid

   (add -v to see detail)
   Run 'perf list' for a list of valid events

Usage: perf record [] []
   or: perf record [] --  []

   -e, --eventevent selector. use 'perf list' to list available 
events
   [root@felicio ~]#


Good thing would be to not have any message from libbpf and the right error
message from the parser, i.e. the first three lines become these two:


   event syntax error: 'foo.o'
\___ BPF object file 'foo.o' not found.o

But that can be fixed up in an upcoming patch, so I am applying this one now in
my new attempt at processing this patchkit.


I think fixing that is not very hard. When designing libbpf, I thought
the problem like this so makes libbpf output controled by caller using
'libbpf_set_print()'. What we need to do is to pass different output
functions to libbpf. We can easily disable all output from libbpf if
verbose is set 0. The only question is: do you want me to provide a new
version of patch 'perf ebpf: Add the libbpf glue' or you prefer another
patch to adjust the output functions?

Thank you.


Ditto for:

   [acme@felicio linux]$ perf record --event /tmp/build/perf/perf.o sleep
   libbpf: /tmp/build/perf/perf.o is not an eBPF object file
   event syntax error: '/tmp/build/perf/perf.o'
\___ BPF object file '/tmp/build/perf/perf.o' is invalid
   
   (add -v to see detail)

   Run 'perf list' for a list of valid events

Usage: perf record [] []
   or: perf record [] --  []

   -e, --eventevent selector. use 'perf list' to list available 
events
   [acme@felicio linux]$

Now trying to find a _valid_ ebpf object file to test with.

- 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: [PATCH] EDAC: Add AMD Seattle SoC EDAC

[Hanjun Guo]

On 2015/10/21 1:25, Mark Rutland wrote:
> On Tue, Oct 20, 2015 at 11:44:46AM -0500, Brijesh Singh wrote:
>> Hi Mark,
>>
>> Thanks for review. 
>>
>> -Brijesh
>>
>> On 10/19/2015 03:52 PM, Mark Rutland wrote:
>>> Hi,
>>>
>>> Please Cc the devicetree list (devicet...@vger.kernel.org) when sending
>>> binding patches. I see you've added the people from the MAINTAINERS
>>> entry; the list should also be Cc'd.
>>>
>> Noted.
>>> On Mon, Oct 19, 2015 at 02:23:17PM -0500, Brijesh Singh wrote:
 Add support for the AMD Seattle SoC EDAC driver.

 Signed-off-by: Brijesh Singh 
 ---
  .../devicetree/bindings/edac/amd-seattle-edac.txt  |  15 +
  drivers/edac/Kconfig   |   6 +
  drivers/edac/Makefile  |   1 +
  drivers/edac/seattle_edac.c| 306 
 +
  4 files changed, 328 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/edac/amd-seattle-edac.txt
  create mode 100644 drivers/edac/seattle_edac.c

 diff --git a/Documentation/devicetree/bindings/edac/amd-seattle-edac.txt 
 b/Documentation/devicetree/bindings/edac/amd-seattle-edac.txt
 new file mode 100644
 index 000..a0354e8
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/edac/amd-seattle-edac.txt
 @@ -0,0 +1,15 @@
 +* AMD Seattle SoC EDAC node
 +
 +EDAC node is defined to describe on-chip error detection and reporting.
 +
 +Required properties:
 +- compatible: Should be "amd,arm-seattle-edac"
 +- poll-delay-msec: Indicates how often the edac check callback should be 
 called.
 +  Time in msec.
>>> This second property doesn't describe the hardware in any way. It should
>>> be runtime-configurable and dpesn't belong in the DT.
>>>
>>> Regardless, the binding is wrong. This is in no way specific to AMD
>>> Seattle, and per the code is actually used to imply the presence of a
>>> Cortex-A57 feature. No reference to AMD Seattle belongs in the DT
>>> binding (with the exception of the example, perhaps), nor in the driver.
>>>
>>> NAK while this pretends to be something that it isn't. At minimum, you
>>> need to correctly describe the feature you are trying to add support
>>> for.
>>>
>> I will remove AMD specific string in compatibility field and make the
>> poll-delay-msec optional. Will also expose this as module parameter as
>> you suggested below.
> I don't think it should be optional; I don't think it should be there at
> all.
>
> I'm not sure if we even need a DT binding if we can derive the presence
> of the feature from the MIDR.
>
 + * The driver polls CPUMERRSR_EL1 and L2MERRSR_EL1 registers to logs the 
>>> These are IMPLEMENTATION DEFINED registers which are specific to
>>> Cortex-A57, and I note that L2MERRSR_EL1 changed in r1p0.
>>>
>>> Which revisions of Cortex-A57 does this work with?
>>>
>> I have tested my code on r1p2.
>>
>>> Generally we avoid touching IMPLEMENTATION DEFINED registers as they may
>>> not exist in some configurations or revisions, and could trap or undef.
>>> Is it always safe to access these registers (in current revisions of
>>> Cortex-A57)?
>>>
>> So far I have not ran into any trap error, was able to read/write
>> registers from EL1 all the times. I looked at TRM but could not find
>> reference that it would fail. As per doc the register should be
>> available at all EL's except EL0.
> Ok.

This also works on Hisilicon D02 board. but the mechanism to handle the error
is a little bit different, on D02, it use poll mechanism to scan the single bit 
ECC error
just as Seattle, but D02 will trigger SEI when double bit ECC error happened.

Thanks
Hanjun

--
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 13/16] perf callchain: Switch default to 'graph,0.5,caller'

[Namhyung Kim]

On Tue, Oct 20, 2015 at 11:38:16AM -0200, Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 20, 2015 at 09:23:12PM +0800, Wangnan (F) escreveu:
> > On 2015/10/6 5:03, Arnaldo Carvalho de Melo wrote:
> > >From: Arnaldo Carvalho de Melo 
> > >Which is the most common default found in other similar tools.
>  
> > Could you please show me some example about "other similar tools"?
> > For me, in most of the case I prefer callee order because most of my
> > task is to explain the reason why some code get executed too much times
> > than expected.
>  
> > Also, I think changing default settings should be careful.
>  
> > This is my story: after switching to new version of perf, in a period of
> > time there are plenty of perf users in my company be confused by the
> > first column of 'perf report' because the sum of the percentage listed
> > there is much higher than 100%. They find me because they think this is
> > a bug in perf which breaks their routinely profiling work.  The
> > "problem" is caused by the adding of "--children". New perf makes
> > '--children' as the default behavior at the first time it support that
> > option, but the old perf shows things similar to '--no-children'.
> > However, it is hard to explain the principle of call stack accumulation
> > and why we need '--children' to those perf users (they learned perf's
> > command line from others, and don't have enought to read perf
> > documentations or even help output. Althought the title of the first
> > column is changed to 'Children', I don't think they can understand the
> > meaning of it. I think some of them didn't even notice there's an
> > addition column in their output. They just confused and angry). Also,
> > and as you can expect, this change breaks some scripts. In those days I
> > have to make our IM tool response the information of "--no-children"
> > automatically.
> > 
> > This patch changes the default output again. Similar thing will happen
> > another time. I think this time I can make some preparation, for example,
> > prepare new script to restore old behavior?
> 
> I was bitten by the --children thing and took some time to get used to
> it, so I can relate to that...

I feel sorry about that.  I did worry about the existing users when
making the --children default and actually I didn't agree with making
it default at first. :-(


> 
> I think we should revert this change in callchain default, enough
> complaints...  Ingo, since you suggested that change, what are your
> thoughts?
> 
> Changing defaults is hard, there is also the horizontal scrolling that
> made we repurpose the right and left arrows, sigh, that one will cause
> some confusion as well...

Yeah, it worries me too.  That's why I used '<' and '>' key for
scrolling in my patch.  Maybe it's worth adding those keys again,
reverting arrows key actions, and show some message that it'll be
changed later?


> 
> It seems we'll need way more preparation for such changes, more
> infrastructure to ease the transition, questioning if the user wants
> that, etc, growing pains :-\

Yes, it reminds me of changing default push behavior in git 2.0.  We
need to provide info and wait for enough time before changing some
behavior IMHO.

Thanks,
Namhyung
--
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 05/10] hwmon: (fam15h_power) Add compute unit accumulated power

[Huang Rui]

On Tue, Oct 20, 2015 at 03:24:09PM +0800, kbuild test robot wrote:
> Hi Huang,
> 
> [auto build test ERROR on hwmon/hwmon-next -- if it's inappropriate base, 
> please suggest rules for selecting the more suitable base]
> 
> url:
> https://github.com/0day-ci/linux/commits/Huang-Rui/hwmon-fam15h_power-Introduce-an-accumulated-power-reporting-algorithm/20151020-110712
> config: x86_64-randconfig-s2-10201413 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/built-in.o: In function `fam15h_power_probe':
> >> fam15h_power.c:(.text+0x26e3a3): undefined reference to 
> >> `amd_get_cores_per_cu'
>fam15h_power.c:(.text+0x26e41e): undefined reference to 
> `amd_get_cores_per_cu'
> 

Thanks to report this issue. :)
The root cause is that the test config doesn't enable
CONFIG_CPU_SUP_AMD.

How about below fix:

---
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 796569ee..603eadd 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -288,7 +288,7 @@ config SENSORS_K10TEMP
 
 config SENSORS_FAM15H_POWER
tristate "AMD Family 15h processor power"
-   depends on X86 && PCI
+   depends on X86 && PCI && CPU_SUP_AMD
help
  If you say yes here you get support for processor power
  information of your AMD family 15h CPU.

---

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 v8 06/14] task_isolation: provide strict mode configurable signal

[Andy Lutomirski]

On Tue, Oct 20, 2015 at 6:30 PM, Chris Metcalf  wrote:
> On 10/20/2015 8:56 PM, Steven Rostedt wrote:
>>
>> On Tue, 20 Oct 2015 16:36:04 -0400
>> Chris Metcalf  wrote:
>>
>>> Allow userspace to override the default SIGKILL delivered
>>> when a task_isolation process in STRICT mode does a syscall
>>> or otherwise synchronously enters the kernel.
>>>
>> Is this really a good idea? This means that there's no way to terminate
>> a task in this mode, even if it goes astray.
>
>
> It doesn't map SIGKILL to some other signal unconditionally.  It just allows
> the "hey, you broke the STRICT contract and entered the kernel" signal
> to be something besides the default SIGKILL.
>

...which has the odd side effect that sending a non-fatal signal from
another process will cause the strict process to enter the kernel and
receive an extra signal.

I still dislike this thing.  It seems like a debugging feature being
implemented using signals instead of existing APIs.  I *still* don't
see why perf can't be used to accomplish your goal.

--Andy
--
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 06/14] task_isolation: provide strict mode configurable signal

[Steven Rostedt]

On Tue, 20 Oct 2015 21:30:36 -0400
Chris Metcalf  wrote:

> On 10/20/2015 8:56 PM, Steven Rostedt wrote:
> > On Tue, 20 Oct 2015 16:36:04 -0400
> > Chris Metcalf  wrote:
> >
> >> Allow userspace to override the default SIGKILL delivered
> >> when a task_isolation process in STRICT mode does a syscall
> >> or otherwise synchronously enters the kernel.
> >>
> > Is this really a good idea? This means that there's no way to terminate
> > a task in this mode, even if it goes astray.
> 
> It doesn't map SIGKILL to some other signal unconditionally.  It just allows
> the "hey, you broke the STRICT contract and entered the kernel" signal
> to be something besides the default SIGKILL.
> 

Ah, I misread the change log. Now looking at the actual code, it makes
sense. Sorry for the noise ;-)

-- Steve
--
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 2/4] thermal: rockchip: ensure the otp state before resetting the controller

[Caesar Wang]

Doug,

在 2015年10月20日 23:52, Doug Anderson 写道:

Caesar,

On Tue, Oct 20, 2015 at 2:11 AM, Caesar Wang  wrote:

We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.

Says:
The TSHUT temperature is setting more than 80 degree, the default tshut
polarity is high.

If T > 80C, the OTP output the High Signal.
If T < 80C, the OTP output the Low Signal.

On the moment, the TSADC controller is reset, the tshut polarity will be
low in a short period of time.
So:

If T < 80C, the OTP output the High Signal.
If T > 80C, the OTP output the Low Signal.

In some cases, the OTP pin is connected to the PMIC, maybe the PMIC can
accept the reset response time to avoid this issue.
In other words, the system will be always reboot if we make the OTP pin
is connected the others IC to control the power.

Signed-off-by: Caesar Wang 
---

  drivers/thermal/rockchip_thermal.c | 32 
  1 file changed, 32 insertions(+)

I think you could do this with no code changes to the thermal driver
if we simply convince Linus W. to apply a change that I posted up just
about a year ago.  See:

https://patchwork.kernel.org/patch/5055741/

In v1 of that patch at 
Linus said he liked it "A lot" and was willing to merge it with Greg
KH's Ack and with a small comment fix.  I obtained the Ack and fixed
the comment, but then the patch didn't end up being needed for me and
so I never bumped it and it got lost...

Maybe you could re-test that patch?  It looks like it has a merge
conflict with current linuxnext but it looks trivial to resolve.  You
could re-post my patch or I could repost it and you could add your
Tested-by.

You'd still want to have a bindings change to describe "init", but at
least you shouldn't need any code changes.


Okay, https://patchwork.kernel.org/patch/5055741/ that's working for me.
Fell free add my  test tag if you resend the patch. (Tested-by: Caesar 
Wang )



1634ed8 FROMLIST: drivers/pinctrl: Add the concept of an "init" state
15158f8 FROMLIST: ARM: dts: rockchip: Add the OTP gpio pinctrl
e7d3b88 FROMLIST: thermal: rockchip: change the TSHUT default state
184b154 FROMLIST: thermal: rockchip: ensure the otp state before 
resetting the controller

9edbe15 FROMLIST: dt-bindings: Sync the dts to this document

Meanwhile, I change the dts as follows.

-   pinctrl-names = "default", "otp_out";
+   pinctrl-names = "init", "default";
pinctrl-0 = <_gpio>;
pinctrl-1 = <_out>;



-Doug

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Thanks,
Caesar

--
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: Possible bug in DM-RAID.

[Neil Brown]

Added dm-devel, which is probably the more appropriate list for dm
things.

NeilBrown

Austin S Hemmelgarn  writes:

> I think I've stumbled upon a bug in DM-RAID.  The primary symptom is that when
> creating a new DM-RAID based device (using either LVM or dmsetup) in a RAID1
> configuration, it very quickly claims one by one that all of the disks failed
> except the first, and goes degraded.  When this happens on a given system, the
> disks always 'fail' in the reverse of the order of the mirror numbers.  All of
> the other RAID profiles work just fine.  Curiously, it also only seems to
> happen for 'big' devices (I haven't been able to determine exactly what the
> minimum size is, but I see it 100% of the time with 32G devices, never with 
> 16G
> ones, and only intermittently with 24G).
>
> Here's what I got from dmesg when creating a 32G LVM volume that exhibited
> this issue:
> [66318.401295] device-mapper: raid: Superblocks created for new array
> [66318.450452] md/raid1:mdX: active with 2 out of 2 mirrors
> [66318.450467] Choosing daemon_sleep default (5 sec)
> [66318.450482] created bitmap (32 pages) for device mdX
> [66318.450495] attempt to access beyond end of device
> [66318.450501] dm-91: rw=13329, want=0, limit=8192
> [66318.450506] md: super_written gets error=-5, uptodate=0
> [66318.450513] md/raid1:mdX: Disk failure on dm-92, disabling device.
>md/raid1:mdX: Operation continuing on 1 devices.
> [66318.459815] attempt to access beyond end of device
> [66318.459819] dm-89: rw=13329, want=0, limit=8192
> [66318.459822] md: super_written gets error=-5, uptodate=0
> [66318.492852] attempt to access beyond end of device
> [66318.492862] dm-89: rw=13329, want=0, limit=8192
> [66318.492868] md: super_written gets error=-5, uptodate=0
> [66318.627183] mdX: bitmap file is out of date, doing full recovery
> [66318.714107] mdX: bitmap initialized from disk: read 3 pages, set 65536 of 
> 65536 bits
> [66318.782045] RAID1 conf printout:
> [66318.782054]  --- wd:1 rd:2
> [66318.782061]  disk 0, wo:0, o:1, dev:dm-90
> [66318.782068]  disk 1, wo:1, o:0, dev:dm-92
> [66318.836598] RAID1 conf printout:
> [66318.836607]  --- wd:1 rd:2
> [66318.836614]  disk 0, wo:0, o:1, dev:dm-90
>
> And here's output for a 24G LVM volume that didn't display the issue.
> [66343.407954] device-mapper: raid: Superblocks created for new array
> [66343.479065] md/raid1:mdX: active with 2 out of 2 mirrors
> [66343.479078] Choosing daemon_sleep default (5 sec)
> [66343.479101] created bitmap (24 pages) for device mdX
> [66343.629329] mdX: bitmap file is out of date, doing full recovery
> [66343.677374] mdX: bitmap initialized from disk: read 2 pages, set 49152 of 
> 49152 bits
>
> I'm using a lightly patched version of 4.2.3
> (the source can be found at https://github.com/ferroin/linux)
> but none of the patches I'm using come anywhere near anything in the block 
> layer,
> let alone the DM/MD code.
>
> I've attempted to bisect this, although it got kind of complicated.  So far 
> I've
> determined that the first commit that I see this issue on is d3b178a: md: 
> Skip cluster setup for dm-raid
> Prior to that commit, I can't initialize any dm-raid devices due to the bug 
> it fixes.
> I have not tested anything prior to d51e4fe (the merge commit that pulled in 
> the md-cluster code),
> but I do distinctly remember that I did not see this issue in 3.19.
>
> I'll be happy to provide more info if needed.


signature.asc
Description: PGP signature

Re: [PATCH] EDAC: Add AMD Seattle SoC EDAC

[Hanjun Guo]

On 2015/10/21 5:26, Brijesh Singh wrote:
> Hi Hanjun,
>
> Thanks for review.
>
> -Brijesh 
> On 10/19/2015 09:21 PM, Hanjun Guo wrote:
>> Hi Brijesh,
>>
>> On 2015/10/20 3:23, Brijesh Singh wrote:
[...]
>> The codes above are common for all A57 architectures, other A57 SoCs will 
>> use the same
>> code for L1/L2 caches error report, can we put those codes in common place 
>> and reused
>> for all A57 architectures?
>>
> Code is generic to A57 and I will follow Mark Rutland suggestion to make it 
> cortex_a57_edac. If you have something else in mind then please let me know.

Sorry, I missed Mark's comments before I sent my email, I'm fine with
the file name suggested.

>
>>> +
>>> +static void cpu_check_errors(void *args)
>>> +{
>>> +   struct edac_device_ctl_info *edev_ctl = args;
>>> +
>>> +   check_cpumerrsr_el1_error(edev_ctl);
>>> +   check_l2merrsr_el1_error(edev_ctl);
>>> +}
>>> +
>>> +static void edac_check_errors(struct edac_device_ctl_info *edev_ctl)
>>> +{
>>> +   int cpu;
>>> +
>>> +   /* read L1 and L2 memory error syndrome register on possible CPU's */
>>> +   for_each_possible_cpu(cpu)
>>> +   smp_call_function_single(cpu, cpu_check_errors, edev_ctl, 0);
>> Seems that error syndrome registers for L2 cache are cluster lever (each 
>> cluster share the
>> L2 cache, you can refer to ARM doc: DDI0488D, Cortex-A57 Technical Reference 
>> Manual),
>> so for L2 cache, we need to check the error at cluster lever not the cpu 
>> core lever.
>>
> Yes L1 seems to be CPU specific and L2 is shared in a cluster. So I am 
> thinking of making the following changes in this function.
>
> static void edac_check_errors(struct edac_device_ctl_info *edev_ctl)
> {
> int cpu;
> struct cpumask cluster_mask, old_mask;
>
> cpumask_clear(_mask);
> cpumask_clear(_mask);
>
> for_each_possible_cpu(cpu) {
> smp_call_function_single(cpu, check_cpumerrsr_el1_error, 
>  edev_ctl, 0); 
> cpumask_copy(_mask, topology_core_cpumask(cpu));
> if (cpumask_equal(_mask, _mask))
> continue;
> cpumask_copy(_mask, _mask);
> smp_call_function_any(_mask, check_l2merrsr_el1_error,
>   edev_ctl, 0); 
> }   
> }
>
> Read L1 on each CPU and L2 once in a cluster. Does this address your feedback 
> ?

Yes, at least it will work as expected :)

Thanks
Hanjun

--
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] MAINTAINERS: ARM: EXYNOS: Add documentation and dt-bindings

[Krzysztof Kozlowski]

Extend the Samsung Exynos maintainer entry to match SoC documentation
and SoC dt-bindings directories. Without that some files, like
bindings/arm/samsung/pmu.txt, are not matched by existing patterns.

This also may serve as a hint where new documentation and bindings (not
matching specific subsystem) should be put.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kukjin Kim 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b556aad90930..cad7b6b628b2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1459,6 +1459,8 @@ F:drivers/*/*s3c2410*
 F: drivers/*/*/*s3c2410*
 F: drivers/spi/spi-s3c*
 F: sound/soc/samsung/*
+F: Documentation/arm/Samsung/
+F: Documentation/devicetree/bindings/arm/samsung/
 N: exynos
 
 ARM/SAMSUNG MOBILE MACHINE SUPPORT
-- 
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 2/2] dt-bindings: EXYNOS: Document compatibles from other vendors

[Krzysztof Kozlowski]

Document compatibles used on other Exynos-based boards (non-Samsung):
FriendlyARM, Google, Hardkernel and Insignal.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kukjin Kim 
Cc: Javier Martinez Canillas 
Cc: Hakjoo Kim 
---
 .../bindings/arm/samsung/samsung-boards.txt| 44 +-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt 
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
index 43589d2466a7..da078702ae73 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
@@ -16,7 +16,49 @@ Required root node properties:
- "samsung,sd5v1"   - for Exynos5440-based Samsung board.
- "samsung,ssdk5440"- for Exynos5440-based Samsung board.
 
-Optional:
+* Other companies Exynos SoC based
+  * FriendlyARM
+- "friendlyarm,tiny4412"  - for Exynos4412-based FriendlyARM
+TINY4412 board.
+
+  * Google
+- "google,pi" - for Exynos5800-based Google Peach Pi
+Rev 10+ board,
+  also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14",
+   "google,pi-rev13", "google,pi-rev12", "google,pi-rev11",
+"google,pi-rev10", "google,peach".
+
+- "google,pit"- for Exynos5420-based Google Peach Pit
+Rev 6+ (Exynos5420),
+  also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14",
+"google,pit-rev13", "google,pit-rev12", "google,pit-rev11",
+"google,pit-rev10", "google,pit-rev9", "google,pit-rev8",
+"google,pit-rev7", "google,pit-rev6", "google,peach".
+
+- "google,snow-rev4"  - for Exynos5250-based Google Snow board,
+  also: "google,snow"
+- "google,snow-rev5"  - for Exynos5250-based Google Snow
+Rev 5+ board.
+- "google,spring" - for Exynos5250-based Google Spring board.
+
+  * Hardkernel
+- "hardkernel,odroid-u3"  - for Exynos4412-based Hardkernel Odroid U3.
+- "hardkernel,odroid-x"   - for Exynos4412-based Hardkernel Odroid X.
+- "hardkernel,odroid-x2"  - for Exynos4412-based Hardkernel Odroid X2.
+- "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3.
+- "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel
+ Odroid XU3 Lite board.
+- "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4.
+
+  * Insignal
+- "insignal,arndale"  - for Exynos5250-based Insignal Arndale 
board.
+- "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale
+Octa board.
+- "insignal,origen"   - for Exynos4210-based Insignal Origen board.
+- "insignal,origen4412- for Exynos4412-based Insignal Origen board.
+
+
+Optional nodes:
 - firmware node, specifying presence and type of secure firmware:
 - compatible: only "samsung,secure-firmware" is currently supported
 - reg: address of non-secure SYSRAM used for communication with 
firmware
-- 
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 1/2] dt-bindings: Consolidate Exynos SoC bindings under Samsung directory

[Krzysztof Kozlowski]

Exynos SoC Device Tree bindings are spread over arm/exynos/ and
arm/samsung/ directories. There is no need for that separation and it
actually confuses. Put everything under arm/samsung/.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kukjin Kim 
---
 .../devicetree/bindings/arm/{exynos => samsung}/power_domain.txt  | 0
 Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt| 0
 Documentation/devicetree/bindings/arm/{exynos => samsung}/smp-sysram.txt  | 0
 3 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/arm/{exynos => 
samsung}/power_domain.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt 
(100%)
 rename Documentation/devicetree/bindings/arm/{exynos => 
samsung}/smp-sysram.txt (100%)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/samsung/power_domain.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/exynos/power_domain.txt
rename to Documentation/devicetree/bindings/arm/samsung/power_domain.txt
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt 
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/samsung-boards.txt
rename to Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt 
b/Documentation/devicetree/bindings/arm/samsung/smp-sysram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
rename to Documentation/devicetree/bindings/arm/samsung/smp-sysram.txt
-- 
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 06/14] task_isolation: provide strict mode configurable signal

[Chris Metcalf]

On 10/20/2015 8:56 PM, Steven Rostedt wrote:

On Tue, 20 Oct 2015 16:36:04 -0400
Chris Metcalf  wrote:


Allow userspace to override the default SIGKILL delivered
when a task_isolation process in STRICT mode does a syscall
or otherwise synchronously enters the kernel.


Is this really a good idea? This means that there's no way to terminate
a task in this mode, even if it goes astray.


It doesn't map SIGKILL to some other signal unconditionally.  It just allows
the "hey, you broke the STRICT contract and entered the kernel" signal
to be something besides the default SIGKILL.

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

--
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 5/5] ARM: keystone: defconfig: Enable CAN support

[santosh shilimkar]

On 10/20/2015 2:50 PM, Franklin S Cooper Jr wrote:

Newer Keystone 2 devices support CAN. Enable CAN support as modules.

Signed-off-by: Franklin S Cooper Jr 
---

Again. Please shown me the usecases before adding config
option. DTS nodes have to be there.


  arch/arm/configs/keystone_defconfig | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index ed3e83e..e9bd825 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -137,6 +137,9 @@ CONFIG_I2C_DAVINCI=y
  CONFIG_SPI=y
  CONFIG_SPI_DAVINCI=y
  CONFIG_SPI_SPIDEV=y
+CONFIG_CAN=m
+CONFIG_CAN_C_CAN=m
+CONFIG_CAN_C_CAN_PLATFORM=m
  CONFIG_MMC=y
  CONFIG_MMC_OMAP_HS=y
  # CONFIG_HWMON is not set


--
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 4/5] ARM: keystone: defconfig: Enable MMC support

[santosh shilimkar]

On 10/20/2015 2:50 PM, Franklin S Cooper Jr wrote:

Newer Keystone 2 devices support MMC and can boot from MMC. Therefore,
enable MMC support along with MMC OMAP HS whose driver is reused.

Signed-off-by: Franklin S Cooper Jr 
---

Please notify once MMC patch is accepted and I will
this one then.
--
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/5] ARM: Keystone: Enable PINCTRL for Keystone ARCH

[santosh shilimkar]

On 10/20/2015 2:50 PM, Franklin S Cooper Jr wrote:

From: Franklin Cooper 

Unlike other Keystone 2 devices, newer Keystone 2 SOCs may utilize
pinmuxing which requires PINCTRL to be enabled. Therefore, enable
PINCTRL for all Keystone 2 devices.

Signed-off-by: Franklin S Cooper Jr 
---
  arch/arm/mach-keystone/Kconfig | 1 +
  1 file changed, 1 insertion(+)


I would be happy to add this one when I see pin
control data in DTS and its actually going to be
used in upstream kernel. Till then I don't want
to add this one.

Regards,
Santosh
--
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 2/5] mmc: omap_hsmmc: Enable omap_hsmmc for Keystone 2

[santosh shilimkar]

On 10/20/2015 2:50 PM, Franklin S Cooper Jr wrote:

From: Lokesh Vutla 

Enable omap_hsmmc for Keystone 2 architecture which reuses the HSMMC
IP found on OMAP platforms.

Signed-off-by: Franklin S Cooper Jr 
---
  drivers/mmc/host/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a1e349..2ccec71 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -366,7 +366,7 @@ config MMC_OMAP
  config MMC_OMAP_HS
tristate "TI OMAP High Speed Multimedia Card Interface support"
depends on HAS_DMA
-   depends on ARCH_OMAP2PLUS || COMPILE_TEST
+   depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
help
  This selects the TI OMAP High Speed Multimedia card Interface.
  If you have an omap2plus board with a Multimedia Card slot,


Please send this to MMC tree.

Regards,
Santosh
--
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 3.4 52/65] ACPICA: Tables: Fix an issue that FACS initialization is performed twice

[Zheng, Lv]

Hi,

> From: Moore, Robert
> Sent: Tuesday, October 20, 2015 9:35 PM
> 
> 
> 
> > -Original Message-
> > From: l...@kernel.org [mailto:l...@kernel.org]
> > Sent: Monday, October 19, 2015 5:48 PM
> > To: sta...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org; Zheng, Lv; Moore, Robert; Wysocki,
> > Rafael J; Zefan Li
> > Subject: [PATCH 3.4 52/65] ACPICA: Tables: Fix an issue that FACS
> > initialization is performed twice
> >
> > From: Lv Zheng 
> >
> > 3.4.110-rc1 review patch.  If anyone has any objections, please let me
> > know.
> >
> > --
> >
> >
> > commit c04be18448355441a0c424362df65b6422e27bda upstream.
> >
> > ACPICA commit 90f5332a15e9d9ba83831ca700b2b9f708274658
> >
> > This patch adds a new FACS initialization flag for acpi_tb_initialize().
> > acpi_enable_subsystem() might be invoked several times in OS bootup
> > process, and we don't want FACS initialization to be invoked twice. Lv
> > Zheng.
> >
> 
> Isn't calling acpi_enable_subsystem more than once essentially an OS bug?
> 
> 

I'm not sure if this is an OS bug.
And don't know the history of this function.

IMO, acpi_enable_subsystem() contains several initialization steps.
And the calling order of such steps might be OSPM specific, that's why so many 
flags are needed for acpi_enable_subsystem().
Then invoking acpi_enable_subsystem() twice at different OS boot stage (early 
or late) might not be a problem.

The patch is a different story, it just fixes an issue that one of the step is 
called twice in Linux because ACPICA hasn't a flag around 
acpi_tb_initialize_facs().

Thanks and best regards
-Lv


> 
> 
> 
> 
> > Link: https://github.com/acpica/acpica/commit/90f5332a
> > Signed-off-by: Lv Zheng 
> > Signed-off-by: Bob Moore 
> > Signed-off-by: Rafael J. Wysocki 
> > [lizf: Backported to 3.4: adjust filename]
> > Signed-off-by: Zefan Li 
> > ---
> >  drivers/acpi/acpica/utxface.c | 10 ++
> >  include/acpi/actypes.h|  1 +
> >  2 files changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/utxface.c b/drivers/acpi/acpica/utxface.c
> > index afa94f5..0985ab7 100644
> > --- a/drivers/acpi/acpica/utxface.c
> > +++ b/drivers/acpi/acpica/utxface.c
> > @@ -166,10 +166,12 @@ acpi_status acpi_enable_subsystem(u32 flags)
> >  * Obtain a permanent mapping for the FACS. This is required for the
> >  * Global Lock and the Firmware Waking Vector
> >  */
> > -   status = acpi_tb_initialize_facs();
> > -   if (ACPI_FAILURE(status)) {
> > -   ACPI_WARNING((AE_INFO, "Could not map the FACS table"));
> > -   return_ACPI_STATUS(status);
> > +   if (!(flags & ACPI_NO_FACS_INIT)) {
> > +   status = acpi_tb_initialize_facs();
> > +   if (ACPI_FAILURE(status)) {
> > +   ACPI_WARNING((AE_INFO, "Could not map the FACS table"));
> > +   return_ACPI_STATUS(status);
> > +   }
> > }
> >  #endif /* !ACPI_REDUCED_HARDWARE */
> >
> > diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
> > 6d52429..0460073 100644
> > --- a/include/acpi/actypes.h
> > +++ b/include/acpi/actypes.h
> > @@ -495,6 +495,7 @@ typedef u64 acpi_integer;
> >  #define ACPI_NO_ACPI_ENABLE 0x10
> >  #define ACPI_NO_DEVICE_INIT 0x20
> >  #define ACPI_NO_OBJECT_INIT 0x40
> > +#define ACPI_NO_FACS_INIT   0x80
> >
> >  /*
> >   * Initialization state
> > --
> > 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 13/16] perf callchain: Switch default to 'graph,0.5,caller'

[Namhyung Kim]

Hi Arnaldo,

On Tue, Oct 20, 2015 at 03:44:04PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 20, 2015 at 07:21:16PM +0200, Frederic Weisbecker escreveu:
> > On Tue, Oct 20, 2015 at 10:06:51AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Tue, Oct 20, 2015 at 02:19:50PM +0200, Frederic Weisbecker escreveu:
> > > > On Tue, Oct 20, 2015 at 09:00:34AM -0300, Arnaldo Carvalho de Melo 
> > > > wrote:
> > > > > Em Mon, Oct 19, 2015 at 05:16:53PM -0700, Brendan Gregg escreveu:
> > > > > So are you advocating different defaults, one for --stdio (callee),
> > > > > another for --tui, --gtk (caller)?
> > > 
> > > > > This is all configurable via ~/.perfconfig :-\
> > > 
> > > > > Indeed, finding a default that is deemed adequate for most people is,
> > > > > ho-hum, difficult 8-)
> > >  
> > > > Most uses I've seen on LKML by the past involved callee because people
> > > > mostly look at the precise point where a performance issue is.
> > > 
> > > A good chunk of that was because that was the default?
> > 
> > I doubt it. When you need to find the culprit of a syscall of IRQ 
> > performance issue,
> > you don't care much to see __libc_start_main() / main() on the top of your 
> > callchain.
> 
> And I noticed some other shortcoming of this ordering (caller) the stack
> closer to userspace in a typical perf.data with callchains (perf record
> -g) can have bogus addresses (-fomit-frame-pointer) :-\

Maybe we need to add an option to ignore unresolved callchains?


>  
> > > > IMHO changing that order is not a good idea. Unless many users 
> > > > complained
> > > > about it.
> > > 
> > > Perhaps there are not that many users of callchains because the default
> > > is not what they're used to see?
> > > 
> > > Motivation for the change came from a video from Chandler, that
> > > resurfaced the callchain default issue, Chandler?
> > > 
> > > Anedoctally, he tweeted about it and people seemed to like it.
> > 
> > Well, I would prefer to hear from regular users than random twitter 
> > followers.
> > I could be wrong so lets ask some users first.
> 
> That is why I put the "anedoctaly" :-)
>  
> > > > > Ingo, what do you think?
> > > 
> > > What about providing a hotkey, in the tui, to toggle caller/callee
> > > views, and another hotkey to save that in ~/.perfconfig so that becomes
> > > the new default?
>  
> > That means rebuilding the whole tree, it might be costly and events need to
> > be processed again.
> 
> I never tried to reimplement that with going to/from caller/caller in
> mind, should do at some point, but yeah, reprocessing all entries can be
> way costly.

Right.  Anyway it seems useful to update config dynamically.  I really
need to take a look at Taeung's config patchset..


>  
> > > In the --stdio mode we need to add a warning in the first lines,
> > > something like:
> > > 
> > > # This is caller (or callee) based, please use --callchain ... to change 
> > > it
> > > 
> > > One way or the other people will disagree, so making it easy to switch
> > > to the preferred way would be nice to have?
> > 
> > Agreed.
> 
> I'll probably revert this change in default and provide some way to
> change it dynamically, just waiting a some more time for more comments.

Agreed.

Thanks,
Namhyung
--
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 2/2] serial: earlycon: allow to specify uartclk in earlycon kernel-parameter

[Masahiro Yamada]

Hi Peter,
(+ Rob Herring, Stefan Agner)

2015-10-20 23:00 GMT+09:00 Peter Hurley :
> On 10/19/2015 11:36 PM, Masahiro Yamada wrote:
>> The input clock frequency varies from device to device, but the
>> earlycon uses the fixed frequency (BASE_BAUD * 16).  It makes
>> impossible to set the correct divisor to the register.
>
> So the bootloader hasn't setup the serial port?

It does.
I use U-boot and the serial port is already set up by U-boot.


But, earlycon setup functions update hardware registers.
See  early_serial8250_setup(), ingenic_early_console_setup(), etc.


Without port->uartclk set to a valid value,
the init code in earlycon setup does not make sense.


What I want to clarify is,
what should we do in the earlycon setup function?

Currently, I see
 [1] set device->con->write callback
 [2] initialize UART port registers


For [2], we need to know baudrate and input clock frequency.
(and the latter is missing, that's why my patch is here.)


In order to be independent of a boot loader, we also need
  [3]  pinctrl (pin-muxing)

But, it is difficult to handle pinctrl in the earlycon framework.


If we depend on a boot loader, [2] is meaningless.   [1] is enough.




-- 
Best Regards
Masahiro Yamada
--
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] i2c: designware: register clkdev during acpi device configuration

[Ken Xue]

On Tue, 2015-10-20 at 14:17 +0300, Mika Westerberg wrote:
> On Tue, Oct 20, 2015 at 02:38:01PM +0800, Ken Xue wrote:
> > DW I2C driver tries to register a clk from id->driver_data as an
> > alternative way besides intel lpss. But code doesn't register the
> > clk to clkdev. So, devm_clk_get will fail during probe.
> > 
> > The patch can fix this issue.
> 
> Since you now have drivers/acpi/acpi_apd.c for AMD ACPI stuff, can you
> create the clock there just like we do for Intel stuff?
Sure. APD already creates the clock for AMD0010 as you expected. And the
next patch([PATCH 2/2] i2c: designware: remove freq definition for
"AMD0010" in acpi_device_id) is dropping the old way for getting freq.

--
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 2/4] mm/hugetlb: Setup hugetlb_falloc during fallocate hole punch

[Mike Kravetz]

On 10/20/2015 05:11 PM, Dave Hansen wrote:
> On 10/20/2015 04:52 PM, Mike Kravetz wrote:
>>  if (hole_end > hole_start) {
>>  struct address_space *mapping = inode->i_mapping;
>> +DECLARE_WAIT_QUEUE_HEAD_ONSTACK(hugetlb_falloc_waitq);
>> +/*
>> + * Page faults on the area to be hole punched must be stopped
>> + * during the operation.  Initialize struct and have
>> + * inode->i_private point to it.
>> + */
>> +struct hugetlb_falloc hugetlb_falloc = {
>> +.waitq = _falloc_waitq,
>> +.start = hole_start >> hpage_shift,
>> +.end = hole_end >> hpage_shift
>> +};
> ...
>> @@ -527,6 +550,12 @@ static long hugetlbfs_punch_hole(struct inode *inode, 
>> loff_t offset, loff_t len)
>>  hole_end  >> PAGE_SHIFT);
>>  i_mmap_unlock_write(mapping);
>>  remove_inode_hugepages(inode, hole_start, hole_end);
>> +
>> +spin_lock(>i_lock);
>> +inode->i_private = NULL;
>> +wake_up_all(_falloc_waitq);
>> +spin_unlock(>i_lock);
> 
> I see the shmem code doing something similar.  But, in the end, we're
> passing the stack-allocated 'hugetlb_falloc_waitq' over to the page
> faulting thread.  Is there something subtle that keeps
> 'hugetlb_falloc_waitq' from becoming invalid while the other task is
> sleeping?
> 
> That wake_up_all() obviously can't sleep, but it seems like the faulting
> thread's finish_wait() *HAS* to run before wake_up_all() can return.
> 

The 'trick' is noted in the comment in the shmem_fault code:

/*
 * shmem_falloc_waitq points into the
shmem_fallocate()
 * stack of the hole-punching task:
shmem_falloc_waitq
 * is usually invalid by the time we reach here, but
 * finish_wait() does not dereference it in that
case;
 * though i_lock needed lest racing with
wake_up_all().
 */

The faulting thread is removed from the waitq when awakened with
wake_up_all().  See the DEFINE_WAIT() and supporting code in the
faulting thread.  Because of this, when the faulting thread calls
finish_wait() it does not access the waitq that was/is on the stack.

At least I've convinced myself it works this way. :)

-- 
Mike Kravetz
--
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/4] dt-bindings: Document the STM32 DMA bindings

[Rob Herring]

On Fri, Oct 16, 2015 at 8:59 AM, M'boumba Cedric Madianga
 wrote:
> This patch adds documentation of device tree bindings for the STM32 dma
> controller.
>
> Signed-off-by: M'boumba Cedric Madianga 
> ---
>  .../devicetree/bindings/dma/stm32-dma.txt  | 82 
> ++

Acked-by: Rob Herring 

>  1 file changed, 82 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt 
> b/Documentation/devicetree/bindings/dma/stm32-dma.txt
> new file mode 100644
> index 000..70cd13f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt
> @@ -0,0 +1,82 @@
> +* STMicroelectronics STM32 DMA controller
> +
> +The STM32 DMA is a general-purpose direct memory access controller capable of
> +supporting 8 independent DMA channels. Each channel can have up to 8 
> requests.
> +
> +Required properties:
> +- compatible: Should be "st,stm32-dma"
> +- reg: Should contain DMA registers location and length. This should include
> +  all of the per-channel registers.
> +- interrupts: Should contain all of the per-channel DMA interrupts in
> +  ascending order with respect to the DMA channel index.
> +- clocks: Should contain the input clock of the DMA instance.
> +- #dma-cells : Must be <4>. See DMA client paragraph for more details.
> +
> +Optional properties:
> +- resets: Reference to a reset controller asserting the DMA controller
> +- st,mem2mem: boolean; if defined, it indicates that the controller supports
> +  memory-to-memory transfer
> +
> +Example:
> +
> +   dma2: dma-controller@40026400 {
> +   compatible = "st,stm32-dma";
> +   reg = <0x40026400 0x400>;
> +   interrupts = <56>,
> +<57>,
> +<58>,
> +<59>,
> +<60>,
> +<68>,
> +<69>,
> +<70>;
> +   clocks = <_hclk>;
> +   #dma-cells = <4>;
> +   st,mem2mem;
> +   resets = < 150>;
> +   };
> +
> +* DMA client
> +
> +DMA clients connected to the STM32 DMA controller must use the format
> +described in the dma.txt file, using a five-cell specifier for each
> +channel: a phandle plus four integer cells.
> +The four cells in order are:
> +
> +1. The channel id
> +2. The request line number
> +3. A 32bit mask specifying the DMA channel configuration which are device
> +   dependent:
> +  -bit 9: Peripheral Increment Address
> +   0x0: no address increment between transfers
> +   0x1: increment address between transfers
> + -bit 10: Memory Increment Address
> +   0x0: no address increment between transfers
> +   0x1: increment address between transfers
> + -bit 15: Peripheral Increment Offset Size
> +   0x0: offset size is linked to the peripheral bus width
> +   0x1: offset size is fixed to 4 (32-bit alignment)
> + -bit 16-17: Priority level
> +   0x0: low
> +   0x1: medium
> +   0x2: high
> +   0x3: very high
> +5. A 32bit mask specifying the DMA FIFO threshold configuration which are 
> device
> +   dependent:
> + -bit 0-1: Fifo threshold
> +   0x0: 1/4 full FIFO
> +   0x1: 1/2 full FIFO
> +   0x2: 3/4 full FIFO
> +   0x3: full FIFO
> +
> +Example:
> +
> +   usart1: serial@40011000 {
> +   compatible = "st,stm32-usart", "st,stm32-uart";
> +   reg = <0x40011000 0x400>;
> +   interrupts = <37>;
> +   clocks = <_pclk2>;
> +   dmas = < 2 4 0x10400 0x3>,
> +  < 7 5 0x10200 0x3>;
> +   dma-names = "rx", "tx";
> +   };
> --
> 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 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Steven Rostedt]

On Tue, 20 Oct 2015 17:18:13 -0400
Chris Metcalf  wrote:

> So perhaps a boot flag is an acceptable compromise between
> "nothing" and a debugfs tweak?  It certainly does make it easier
> to hack on the task-isolation code, and likely other things where
> people are trying out fixes to subsystems where they are attempting
> to remove the reliance on the tick.
> 

Just change the name to:

this_will_crash_your_kernel_and_kill_your_kittens_debug_1hz_tick

-- Steve
--
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 06/14] task_isolation: provide strict mode configurable signal

[Steven Rostedt]

On Tue, 20 Oct 2015 16:36:04 -0400
Chris Metcalf  wrote:

> Allow userspace to override the default SIGKILL delivered
> when a task_isolation process in STRICT mode does a syscall
> or otherwise synchronously enters the kernel.
> 

Is this really a good idea? This means that there's no way to terminate
a task in this mode, even if it goes astray.

-- Steve
--
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 v5 0/8] Add support for Exynos SROM Controller driver

[Krzysztof Kozlowski]

On 20.10.2015 18:15, Pankaj Dubey wrote:
> This patch set adds support for Exynos SROM controller DT based driver.
> Currently SROM register sets are used only during S2R, so driver
> basically added for taking care of S2R. It will help us in removing
> static mapping from exynos.c and other extra code handline during S2R.
> 
> This patch set also updated exynos4 and exynos5 dtsi files for with device
> node for srom, and added binding documentation for the same.
> 
> First two patches are some minor cleanup in mach-exynos.
> 
> Patchset v1 was posted here[1]
> [1]: https://lkml.org/lkml/2015/4/29/98
> Patchset v2 was posted here[2]
> [2]: https://lkml.org/lkml/2015/8/24/125
> Patchset v3 was posted here[3]
> [3]: https://lkml.org/lkml/2015/10/13/392
> Patchset v3 was posted here[4]
> [4]: https://lkml.org/lkml/2015/10/19/278
> 
> This patchset, I have tested on Peach-Pi (Exynos5880) based chromebook for 
> boot
> and S2R functionality.
> 

Entire patchset tested on Trats2 (Exynos4412) board. Unless Kukjin picks
it also, I plan to take it for v4.5.

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: what's in nvdimm.git for v4.4?

[Dan Williams]

On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner  wrote:
> On Tue, Oct 20, 2015 at 11:31:45PM +, Williams, Dan J wrote:
>> Here is a status summary of the topic-branches nvdimm.git is tracking
>> for v4.4.  Unless indicated these branches are not present in -next.
>> Please ACK, NAK, or ask for a re-post of any of the below to disposition
>> it for the merge window.
>>
>> ===
>> for-4.4/dax-fixes:
>> ===
> ...
>> Dave Chinner (5):
>>   xfs: fix inode size update overflow in xfs_map_direct()
>>   xfs: introduce BMAPI_ZERO for allocating zeroed extents
>>   xfs: Don't use unwritten extents for DAX
>>   xfs: DAX does not use IO completion callbacks
>>   xfs: add ->pfn_mkwrite support for DAX
>
> Please drop these. They have not been reviewed yet, and because
> the changes affect more than just DAX (core XFS allocator
> functionality was changed) these need to go through the XFS tree.
>

Ok, thanks for the heads up.  For the get_user_pages() patches that
build on these fixes I'm assuming your review bandwidth is in short
supply to also give an XFS sign-off on those changes for 4.4?

I'm wondering if we can take a conservative step forward with those
patches for 4.4.  if XFS and EXT4 interactions need more time to get
worked out, which I believe they do, I can conceive just turning on
get_user_pages() support for DAX-mappings of the raw block device.
This would be via the new facility I posted yesterday:
https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
While not very functional for applications it makes testing base DAX
mechanisms straightforward.
--
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 04/14] task_isolation: add initial support

[Steven Rostedt]

On Tue, 20 Oct 2015 14:26:34 -0700
Andy Lutomirski  wrote:

> I'm not a scheduler person, so I don't know.  But "don't run me unless
> I'm isolated" seems like a design that will, at best, only ever work
> by dumb luck.  You have to disable migration, avoid other runnable
> tasks, hope that the kernel keeps working the way it did when you
> wrote the patch, hope you continue to get lucky enough that you ever
> get to user mode in the first place, etc.


Since it only makes sense to run one isolated task per cpu (not more
than one on the same CPU), I wonder if we should add a new interface
for this, that would force everything else off the CPU that it
requests. That is, you bind a task to a CPU, and then change it to
SCHED_ISOLATED (or what not), and the kernel will force all other tasks
off that CPU. Well, we would still have kernel threads, but that's a
different matter.

Also, doesn't RCU need to have a few ticks go by before it can safely
disable itself from userspace? I recall something like that. Paul?

-- Steve
--
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 v7 02/60] sparc/PCI: Use correct bus address to resource offset

[Yinghai Lu]

On Tue, Oct 20, 2015 at 5:03 PM, Yinghai Lu  wrote:
>> The failing T4 booted up with updated patches.
>>
>
> Thanks, will post updated patch2 and patches3 and patch 4 with
> pcibios_bus_to_resource as Bjorn requested.

Please double test attached three patches that should replace patch 2, 3, 4.
esp on T4.

Thanks

Yinghai
Subject: [PATCH] PCI: Return host bridge window res for bus addr converting

We need to check if there is window or not, and also need to
use that window res as parent for resource requesting.

Signed-off-by: Yinghai Lu 

---
 drivers/pci/host-bridge.c |   10 +-
 include/linux/pci.h   |5 +++--
 2 files changed, 12 insertions(+), 3 deletions(-)

Index: linux-2.6/drivers/pci/host-bridge.c
===
--- linux-2.6.orig/drivers/pci/host-bridge.c
+++ linux-2.6/drivers/pci/host-bridge.c
@@ -70,12 +70,17 @@ static bool region_contains(struct pci_b
 	return region1->start <= region2->start && region1->end >= region2->end;
 }
 
-void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
+/*
+ * return host bridge window resource
+ */
+struct resource *pcibios_bus_to_resource(struct pci_bus *bus,
+			 struct resource *res,
 			 struct pci_bus_region *region)
 {
 	struct pci_host_bridge *bridge = pci_find_host_bridge(bus);
 	struct resource_entry *window;
 	resource_size_t offset = 0;
+	struct resource *res_ret = NULL;
 
 	resource_list_for_each_entry(window, >windows) {
 		struct pci_bus_region bus_region;
@@ -88,11 +93,14 @@ void pcibios_bus_to_resource(struct pci_
 
 		if (region_contains(_region, region)) {
 			offset = window->offset;
+			res_ret = window->res;
 			break;
 		}
 	}
 
 	res->start = region->start + offset;
 	res->end = region->end + offset;
+
+	return res_ret;
 }
 EXPORT_SYMBOL(pcibios_bus_to_resource);
Index: linux-2.6/include/linux/pci.h
===
--- linux-2.6.orig/include/linux/pci.h
+++ linux-2.6/include/linux/pci.h
@@ -781,8 +781,9 @@ void pci_fixup_cardbus(struct pci_bus *)
 
 void pcibios_resource_to_bus(struct pci_bus *bus, struct pci_bus_region *region,
 			 struct resource *res);
-void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
-			 struct pci_bus_region *region);
+struct resource *pcibios_bus_to_resource(struct pci_bus *bus,
+	 struct resource *res,
+	 struct pci_bus_region *region);
 void pcibios_scan_specific_bus(int busn);
 struct pci_bus *pci_find_bus(int domain, int busnr);
 void pci_bus_add_devices(const struct pci_bus *bus);
Subject: [PATCH] sparc/PCI: Use correct bus address to resource offset

After we add 64bit mmio parsing, we got some "no compatible bridge window"
warning on anther new model that support 64bit resource.

It turns out that we can not use mem_space.start as 64bit mem space
offset, aka mem_space.start != offset.

Use child_phys_addr to calculate exact offset and recorder offset in
pbm.

After patch we get correct offset.

/pci@305: PCI IO [io  0x2007e-0x2007e0fff] offset 2007e
/pci@305: PCI MEM [mem 0x20010-0x27eff] offset 2
/pci@305: PCI MEM64 [mem 0x20001-0x2000d] offset 2
...
pci_sun4v f02ae7f8: PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x2007e-0x2007e0fff] (bus address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x20010-0x27eff] (bus address [0x0010-0x7eff])
pci_bus :00: root bus resource [mem 0x20001-0x2000d] (bus address [0x1-0xd])


-v2: to make is simple, do not add mem64_offset, and assume
 mem64_offset == mem_offset, otherwise would make
 pci_mmap_resource() path too complicated.

-v3: put back mem64_offset, as we found T4 has mem_offset != mem64_offset
 check overlapping between mem64_space and mem_space.

-v4: use pcibios_bus_to_region() all the way.

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 

---
 arch/sparc/kernel/pci.c|   49 +
 arch/sparc/kernel/pci_common.c |   32 --
 arch/sparc/kernel/pci_impl.h   |4 +++
 3 files changed, 49 insertions(+), 36 deletions(-)

Index: linux-2.6/arch/sparc/kernel/pci.c
===
--- linux-2.6.orig/arch/sparc/kernel/pci.c
+++ linux-2.6/arch/sparc/kernel/pci.c
@@ -654,12 +654,12 @@ struct pci_bus *pci_scan_one_pbm(struct
 	printk("PCI: Scanning PBM %s\n", node->full_name);
 
 	pci_add_resource_offset(, >io_space,
-pbm->io_space.start);
+pbm->io_offset);
 	pci_add_resource_offset(, >mem_space,
-pbm->mem_space.start);
+pbm->mem_offset);
 	if (pbm->mem64_space.flags)
 		pci_add_resource_offset(, >mem64_space,
-	pbm->mem_space.start);
+	pbm->mem64_offset);
 	pbm->busn.start = pbm->pci_first_busno;
 	pbm->busn.end	= pbm->pci_last_busno;
 	

Re: Steal time accounting in KVM. Benchmark.

[Alexey Makhalov]

Yes, VM1 results are as before.

Alexey

On Tue, Oct 20, 2015 at 4:04 PM, Wanpeng Li  wrote:
> On 10/21/15 4:05 AM, Alexey Makhalov wrote:
>>
>> 'echo NO_NONTASK_CAPACITY > /sys/kernel/debug/sched_features'  in both
>> guests.
>> Results:
>> VM1: STA is disabled -- no changes, still little bit bellow expected 90%
>> VM2: STA is enabled -- result is changed, but still bad. Hard to say
>> better or worse. It prefers to stuck at quarters (100% 75% 50% 25%)
>> Output is attached.
>
>
> If the output in attachment is for VM2 only?
>
> Regards,
> Wanpeng Li
--
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/5] drivers/tty: make more bool drivers explicitly non-modular

[Paul Gortmaker]

[Re: [PATCH 0/5] drivers/tty: make more bool drivers explicitly non-modular] On 
20/10/2015 (Tue 17:10) Alexandre Belloni wrote:

> On 18/10/2015 at 18:21:13 -0400, Paul Gortmaker wrote :
> > The one common thread here for all the patches is that we also
> > scrap the .remove functions which would only be used for module
> > unload (impossible) and driver unbind.  For the drivers here, there
> > doesn't seem to be a sensible unbind use case (vs. e.g. a multiport
> > PCI ethernet driver where one port is unbound and passed through to
> > a kvm guest or similar).  Hence we just explicitly disallow any
> > driver unbind operations to help prevent root from doing something
> > illogical to the machine that they could have done previously.
> > 
> > We've already done this for drivers/tty/serial/mpsc.c previously.
> > 
> > Build tested for allmodconfig on ARM64 and powerpc for tty/tty-testing.
> > 
> 
> So, how does this actually build test atmel_serial?

Not sure why this should be a surprise;  I build test it exactly like this:

paul@builder-02:~/git/linux-head$ echo $ARCH
arm64
paul@builder-02:~/git/linux-head$ echo $CROSS_COMPILE 
aarch64-linux-gnu-
paul@builder-02:~/git/linux-head$ make O=../arm-build/  
drivers/tty/serial/atmel_serial.o
make[1]: Entering directory '/home/paul/git/arm-build'
arch/arm64/Makefile:25: LSE atomics not supported by binutils
  CHK include/config/kernel.release
  Using /home/paul/git/linux-head as source for kernel
  GEN ./Makefile
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h

[...]

  HOSTCC  scripts/sign-file
  HOSTCC  scripts/extract-cert
  CC  drivers/tty/serial/atmel_serial.o
make[1]: Leaving directory '/home/paul/git/arm-build'
paul@builder-02:~/git/linux-head$ 

It did build; no warning/error.  Would you call it an invalid build test?

> 
> A proper solution would be to actually make it a tristate and allow
> building as a module. I think it currently fails because of
> console_initcall() but that is certainly fixable.

Well, as per other threads on this topic, if people want to extend
the functionality to support tristate, then great.  But please do
not confuse that with existing functionality which is clearly non
modular in this case.

Thanks,
Paul.
--

> 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
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/