[PATCH 2/5] f2fs: avoid small data writes by skipping writepages

[Jaegeuk Kim]

This patch introduces nr_pages_to_skip(sbi, type) to determine writepages can
be skipped.
The dentry, node, and meta pages can be conrolled by F2FS without breaking the
FS consistency.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c |  4 ++--
 fs/f2fs/data.c   |  4 
 fs/f2fs/node.c   |  8 +---
 fs/f2fs/segment.h| 19 +++
 4 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 4c0e98d..1f52b70 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -187,7 +187,7 @@ static int f2fs_write_meta_pages(struct address_space 
*mapping,
struct writeback_control *wbc)
 {
struct f2fs_sb_info *sbi = F2FS_SB(mapping->host->i_sb);
-   int nrpages = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   int nrpages = nr_pages_to_skip(sbi, META);
long written;
 
if (wbc->for_kupdate)
@@ -682,7 +682,7 @@ retry:
inode = igrab(entry->inode);
spin_unlock(>dir_inode_lock);
if (inode) {
-   filemap_flush(inode->i_mapping);
+   filemap_fdatawrite(inode->i_mapping);
iput(inode);
} else {
/*
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 101b4cd..e3b7cfa 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -868,6 +868,10 @@ static int f2fs_write_data_pages(struct address_space 
*mapping,
if (!mapping->a_ops->writepage)
return 0;
 
+   if (S_ISDIR(inode->i_mode) && wbc->sync_mode == WB_SYNC_NONE &&
+   get_dirty_dents(inode) < nr_pages_to_skip(sbi, DATA))
+   return 0;
+
if (wbc->nr_to_write < MAX_DESIRED_PAGES_WP) {
desired_nrtw = MAX_DESIRED_PAGES_WP;
excess_nrtw = desired_nrtw - wbc->nr_to_write;
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 3e36240..cb514f1 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1198,12 +1198,6 @@ redirty_out:
return AOP_WRITEPAGE_ACTIVATE;
 }
 
-/*
- * It is very important to gather dirty pages and write at once, so that we can
- * submit a big bio without interfering other data writes.
- * Be default, 512 pages (2MB) * 3 node types, is more reasonable.
- */
-#define COLLECT_DIRTY_NODES1536
 static int f2fs_write_node_pages(struct address_space *mapping,
struct writeback_control *wbc)
 {
@@ -1214,7 +1208,7 @@ static int f2fs_write_node_pages(struct address_space 
*mapping,
f2fs_balance_fs_bg(sbi);
 
/* collect a number of dirty node pages and write together */
-   if (get_pages(sbi, F2FS_DIRTY_NODES) < COLLECT_DIRTY_NODES)
+   if (get_pages(sbi, F2FS_DIRTY_NODES) < nr_pages_to_skip(sbi, NODE))
return 0;
 
/* if mounting is failed, skip writing node pages */
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index c3d5e36..bbd9761 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -664,3 +664,22 @@ static inline unsigned int max_hw_blocks(struct 
f2fs_sb_info *sbi)
struct request_queue *q = bdev_get_queue(bdev);
return SECTOR_TO_BLOCK(sbi, queue_max_sectors(q));
 }
+
+/*
+ * It is very important to gather dirty pages and write at once, so that we can
+ * submit a big bio without interfering other data writes.
+ * By default, 512 pages for directory data,
+ * 512 pages (2MB) * 3 for three types of nodes, and
+ * max_bio_blocks for meta are set.
+ */
+static inline int nr_pages_to_skip(struct f2fs_sb_info *sbi, int type)
+{
+   if (type == DATA)
+   return sbi->blocks_per_seg;
+   else if (type == NODE)
+   return 3 * sbi->blocks_per_seg;
+   else if (type == META)
+   return MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   else
+   return 0;
+}
-- 
1.8.4.474.g128a96c

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

[PATCH V2] regulator: dbx500: use seq_puts() instead of seq_printf()

[Jingoo Han]

For a constant format without additional arguments, use seq_puts()
instead of seq_printf(). Also, it fixes the following checkpatch
warning.

  WARNING: Prefer seq_puts to seq_printf

Signed-off-by: Jingoo Han 
---
Changes since v1:
- Removed unnecessary seq_puts() in ux500_regulator_power_state_cnt_print()
  in order to prevent build error, per Fengguang Wu.

 drivers/regulator/dbx500-prcmu.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/dbx500-prcmu.c b/drivers/regulator/dbx500-prcmu.c
index ce89f78..ac2c1d6 100644
--- a/drivers/regulator/dbx500-prcmu.c
+++ b/drivers/regulator/dbx500-prcmu.c
@@ -127,9 +127,9 @@ static int ux500_regulator_status_print(struct seq_file *s, 
void *p)
int i;
 
/* print dump header */
-   err = seq_printf(s, "ux500-regulator status:\n");
+   err = seq_puts(s, "ux500-regulator status:\n");
if (err < 0)
-   dev_err(dev, "seq_printf overflow\n");
+   dev_err(dev, "seq_puts overflow\n");
 
err = seq_printf(s, "%31s : %8s : %8s\n", "current",
"before", "after");
-- 
1.7.10.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: [RFC 0/6] mm: support madvise(MADV_FREE)

[Andy Lutomirski]

On Tue, Mar 18, 2014 at 5:18 PM, Minchan Kim  wrote:
> Hello,
>
> On Tue, Mar 18, 2014 at 10:55:24AM -0700, Andy Lutomirski wrote:
>> On 03/13/2014 11:37 PM, Minchan Kim wrote:
>> > This patch is an attempt to support MADV_FREE for Linux.
>> >
>> > Rationale is following as.
>> >
>> > Allocators call munmap(2) when user call free(3) if ptr is
>> > in mmaped area. But munmap isn't cheap because it have to clean up
>> > all pte entries, unlinking a vma and returns free pages to buddy
>> > so overhead would be increased linearly by mmaped area's size.
>> > So they like madvise_dontneed rather than munmap.
>> >
>> > "dontneed" holds read-side lock of mmap_sem so other threads
>> > of the process could go with concurrent page faults so it is
>> > better than munmap if it's not lack of address space.
>> > But the problem is that most of allocator reuses that address
>> > space soonish so applications see page fault, page allocation,
>> > page zeroing if allocator already called madvise_dontneed
>> > on the address space.
>> >
>> > For avoidng that overheads, other OS have supported MADV_FREE.
>> > The idea is just mark pages as lazyfree when madvise called
>> > and purge them if memory pressure happens. Otherwise, VM doesn't
>> > detach pages on the address space so application could use
>> > that memory space without above overheads.
>>
>> I must be missing something.
>>
>> If the application issues MADV_FREE and then writes to the MADV_FREEd
>> range, the kernel needs to know that the pages are no longer safe to
>> lazily free.  This would presumably happen via a page fault on write.
>> For that to happen reliably, the kernel has to write protect the pages
>> when MADV_FREE is called, which in turn requires flushing the TLBs.
>
> It could be done by pte_dirty bit check. Of course, if some architectures
> don't support it by H/W, pte_mkdirty would make it CoW as you said.

If the page already has dirty PTEs, then you need to clear the dirty
bits and flush TLBs so that other CPUs notice that the PTEs are clean,
I think.

Also, this has very odd semantics wrt reading the page after MADV_FREE
-- is reading the page guaranteed to un-free it?

>>
>> How does this end up being faster than munmap?
>
> MADV_FREE doesn't need to return back the pages into page allocator
> compared to MADV_DONTNEED and the overhead is not small when I measured
> that on my machine.(Roughly, MADV_FREE's cost is half of DONTNEED through
> avoiding involving page allocator.)
>
> But I'd like to clarify that it's not MADV_FREE's goal that syscall
> itself should be faster than MADV_DONTNEED but major goal is to
> avoid unnecessary page fault + page allocation + page zeroing +
> garbage swapout.

This sounds like it might be better solved by trying to make munmap or
MADV_DONTNEED faster.  Maybe those functions should lazily give pages
back to the buddy allocator.

--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 03/11] Input: synaptics-rmi4 - do not update configuration in rmi_f01_probe()

[Christopher Heiny]

On 02/12/2014 09:27 PM, Dmitry Torokhov wrote:

Do not write configuration data in probe(), we have config() for that.


I've just submitted a patch to correctly call config() after probe(). 
So this becomes...


Signed-off-by: Christopher Heiny 



Signed-off-by: Dmitry Torokhov 
---
  drivers/input/rmi4/rmi_f01.c | 18 --
  1 file changed, 18 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
index 897d8ac..976aba3 100644
--- a/drivers/input/rmi4/rmi_f01.c
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -303,12 +303,6 @@ static int rmi_f01_initialize(struct rmi_function *fn)
if (pdata->power_management.doze_interval) {
data->device_control.doze_interval =
pdata->power_management.doze_interval;
-   error = rmi_write(rmi_dev, data->doze_interval_addr,
-   data->device_control.doze_interval);
-   if (error < 0) {
-   dev_err(>dev, "Failed to configure F01 doze 
interval register.\n");
-   return error;
-   }
} else {
error = rmi_read(rmi_dev, data->doze_interval_addr,
>device_control.doze_interval);
@@ -324,12 +318,6 @@ static int rmi_f01_initialize(struct rmi_function *fn)
if (pdata->power_management.wakeup_threshold) {
data->device_control.wakeup_threshold =
pdata->power_management.wakeup_threshold;
-   error = rmi_write(rmi_dev, data->wakeup_threshold_addr,
-   data->device_control.wakeup_threshold);
-   if (error < 0) {
-   dev_err(>dev, "Failed to configure F01 wakeup 
threshold register.\n");
-   return error;
-   }
} else {
error = rmi_read(rmi_dev, data->wakeup_threshold_addr,
>device_control.wakeup_threshold);
@@ -347,12 +335,6 @@ static int rmi_f01_initialize(struct rmi_function *fn)
if (pdata->power_management.doze_holdoff) {
data->device_control.doze_holdoff =
pdata->power_management.doze_holdoff;
-   error = rmi_write(rmi_dev, data->doze_holdoff_addr,
-   data->device_control.doze_holdoff);
-   if (error < 0) {
-   dev_err(>dev, "Failed to configure F01 doze 
holdoff register.\n");
-   return error;
-   }
} else {
error = rmi_read(rmi_dev, data->doze_holdoff_addr,
>device_control.doze_holdoff);




--

Christopher Heiny
Senior Staff Firmware Engineer
Synaptics Incorporated
--
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/3] regulator: dbx500: use seq_puts() instead of seq_printf()

[Jingoo Han]

On Wednesday, February 26, 2014 10:21 AM, Jingoo Han wrote:
> 
> For a constant format without additional arguments, use seq_puts()
> instead of seq_printf(). Also, it fixes the following checkpatch
> warning.
> 
>   WARNING: Prefer seq_puts to seq_printf
> 
> Signed-off-by: Jingoo Han 
> ---
>  drivers/regulator/dbx500-prcmu.c |   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/regulator/dbx500-prcmu.c 
> b/drivers/regulator/dbx500-prcmu.c
> index f111dfb..3dd1096 100644
> --- a/drivers/regulator/dbx500-prcmu.c
> +++ b/drivers/regulator/dbx500-prcmu.c
> @@ -97,10 +97,10 @@ static int ux500_regulator_power_state_cnt_print(struct 
> seq_file *s, void *p)
>   int err;
> 
>   /* print power state count */
> - err = seq_printf(s, "ux500-regulator power state count: %i\n",
> - power_state_active_get());
> + err = seq_puts(s, "ux500-regulator power state count: %i\n",
> + power_state_active_get());

It makes build error with 'make ARCH=arm allmodconfig', as 
Fengguang Wu reported.

  drivers/regulator/dbx500-prcmu.c: In function 
'ux500_regulator_power_state_cnt_print':
  drivers/regulator/dbx500-prcmu.c:103:4: error: too many arguments to function 
'seq_puts'

So, I will send v2 patch. Sorry for annoying you.
Thank you.

Best regards,
Jingoo Han

>   if (err < 0)
> - dev_err(dev, "seq_printf overflow\n");
> + dev_err(dev, "seq_puts overflow\n");
> 
>   return 0;
>  }
> @@ -127,9 +127,9 @@ static int ux500_regulator_status_print(struct seq_file 
> *s, void *p)
>   int i;
> 
>   /* print dump header */
> - err = seq_printf(s, "ux500-regulator status:\n");
> + err = seq_puts(s, "ux500-regulator status:\n");
>   if (err < 0)
> - dev_err(dev, "seq_printf overflow\n");
> + dev_err(dev, "seq_puts overflow\n");
> 
>   err = seq_printf(s, "%31s : %8s : %8s\n", "current",
>   "before", "after");
> --
> 1.7.10.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 3/9] perf hists: Add support for showing relative percentage

[Namhyung Kim]

Hi Arnaldo,

On Tue, Mar 18, 2014 at 8:08 PM, Arnaldo Carvalho de Melo
 wrote:
> Em Mon, Mar 10, 2014 at 04:43:54PM +0900, Namhyung Kim escreveu:
>> @@ -695,12 +695,17 @@ static void hists__remove_entry_filter(struct hists 
>> *hists, struct hist_entry *h
>>   if (h->filtered)
>>   return;
>>
>> - ++hists->nr_entries;
>> - if (h->ms.unfolded)
>> + hists->nr_entries++;
>> + hists->nr_non_filtered_entries++;
>
> Why not keep existing practice? prefix or suffix generates the same
> code, changing it from prefix to suffix increment just adds noise to the
> patch :-\

Argh, sorry - I couldn't resist changing it.  Won't do that in the future. :-/

>
> Also, this is why I was asking about nr_entries and total_period being
> invariant, looking at this function we can see it is _not_ invariant, as
> when we apply/remove filters we touch them.
>
> This is why I made the comment (in a private conversation) about having
> a invariant_total_period invariant_nr_entries pair (I think I used some
> other naming) while knowing that the existing variables nr_entries and
> total_period are actually subjected to the filters being used.
>
> I.e. to avoid confusion we need to make total_entries and nr_entries
> never change when a filter is applied, touching only two new variables
> for non_filtered total_period and nr_entries.
>
> I'll try doing it if you don't do it first, but will first process some
> more patches and submit what I already processed.

Please see the next patch 4/9 ("perf report: Add --percentage option")
doing that.  What I did in this patch is just adding new
non_filtered_* fields and not changing existing behavior.  And in the
next patch, the total_period and nr_entries will become invariant.

Do you want to split the patch 4/9 or merge a part of it into this?

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 v3 1/3] clk: s2mps11: Add support for S2MPS14 clocks

[Mike Turquette]

Quoting Krzysztof Kozlowski (2014-03-17 02:19:16)
> This patch adds support for S2MPS14 PMIC clocks (BT and AP) to the
> s2mps11 clock driver.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Reviewed-by: Yadwinder Singh Brar 
> Reviewed-by: Tomasz Figa 

This does not apply cleanly to to clk tree trip, nor does it compile
after manually merging due to changes introducing
linux/mfd/samsung/s2mps14.h.

The changes look OK to me so maybe Lee can take it with my Ack?

Acked-by: Mike Turquette 

Regards,
Mike

> ---
>  drivers/clk/Kconfig   |8 +++---
>  drivers/clk/clk-s2mps11.c |   61 
> ++---
>  2 files changed, 50 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 6f56d3a4f010..8f9ce8ba036d 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -65,12 +65,12 @@ config COMMON_CLK_SI570
>   clock generators.
>  
>  config COMMON_CLK_S2MPS11
> -   tristate "Clock driver for S2MPS11/S5M8767 MFD"
> +   tristate "Clock driver for S2MPS1X/S5M8767 MFD"
> depends on MFD_SEC_CORE
> ---help---
> - This driver supports S2MPS11/S5M8767 crystal oscillator clock. These
> - multi-function devices have 3 fixed-rate oscillators, clocked at
> - 32KHz each.
> + This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
> + clock. These multi-function devices have two (S2MPS14) or three
> + (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
>  
>  config CLK_TWL6040
> tristate "External McPDM functional clock from twl6040"
> diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
> index 508875535e1e..8dafb552274f 100644
> --- a/drivers/clk/clk-s2mps11.c
> +++ b/drivers/clk/clk-s2mps11.c
> @@ -1,7 +1,7 @@
>  /*
>   * clk-s2mps11.c - Clock driver for S2MPS11.
>   *
> - * Copyright (C) 2013 Samsung Electornics
> + * Copyright (C) 2013,2014 Samsung Electornics
>   *
>   * This program is free software; you can redistribute  it and/or modify it
>   * under  the terms of  the GNU General  Public License as published by the
> @@ -13,10 +13,6 @@
>   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>   * GNU General Public License for more details.
>   *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> - *
>   */
>  
>  #include 
> @@ -27,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -125,7 +122,21 @@ static struct clk_init_data 
> s2mps11_clks_init[S2MPS11_CLKS_NUM] = {
> },
>  };
>  
> -static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev)
> +static struct clk_init_data s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
> +   [S2MPS11_CLK_AP] = {
> +   .name = "s2mps14_ap",
> +   .ops = _clk_ops,
> +   .flags = CLK_IS_ROOT,
> +   },
> +   [S2MPS11_CLK_BT] = {
> +   .name = "s2mps14_bt",
> +   .ops = _clk_ops,
> +   .flags = CLK_IS_ROOT,
> +   },
> +};
> +
> +static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
> +   struct clk_init_data *clks_init)
>  {
> struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
> struct device_node *clk_np;
> @@ -145,9 +156,12 @@ static struct device_node *s2mps11_clk_parse_dt(struct 
> platform_device *pdev)
> if (!clk_table)
> return ERR_PTR(-ENOMEM);
>  
> -   for (i = 0; i < S2MPS11_CLKS_NUM; i++)
> +   for (i = 0; i < S2MPS11_CLKS_NUM; i++) {
> +   if (!clks_init[i].name)
> +   continue; /* Skip clocks not present in some devices 
> */
> of_property_read_string_index(clk_np, "clock-output-names", i,
> -   _clks_init[i].name);
> +   _init[i].name);
> +   }
>  
> return clk_np;
>  }
> @@ -158,6 +172,7 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
> struct s2mps11_clk *s2mps11_clks, *s2mps11_clk;
> struct device_node *clk_np = NULL;
> unsigned int s2mps11_reg;
> +   struct clk_init_data *clks_init;
> int i, ret = 0;
> u32 val;
>  
> @@ -168,25 +183,33 @@ static int s2mps11_clk_probe(struct platform_device 
> *pdev)
>  
> s2mps11_clk = s2mps11_clks;
>  
> -   clk_np = s2mps11_clk_parse_dt(pdev);
> -   if (IS_ERR(clk_np))
> -   return PTR_ERR(clk_np);
> -
> switch (platform_get_device_id(pdev)->driver_data) {
> case S2MPS11X:
> s2mps11_reg = S2MPS11_REG_RTC_CTRL;
> +   clks_init = s2mps11_clks_init;
> +   break;
> +   case S2MPS14X:
> +   s2mps11_reg = S2MPS14_REG_RTCCTRL;
> + 

Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0

[DaeSeok Youn]

Hi, Ken
Thanks for review.

But I have a question,  I wan to know why tracing buffer
status(Malloc_FailuresAlloc, Malloc_BytesInUse...) for
info_proc_read_helper() are needed.
If it doesn't need, whole tracing stuff for memory can be removed.

After getting a reply from you and greg, I will make a patch.
Regards,
Daeseok Youn.

2014-03-18 22:00 GMT+09:00 Ken Cox :
>
> On 03/17/2014 07:26 PM, DaeSeok Youn wrote:
>>
>> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use
>> vmalloc/kmalloc directly.
>> (UISMALLOC() macro is also removed.)
>> And uislib_malloc() is renamed to "uislib_trace_buffer_status()" which
>> is just tracing buffer status(Malloc_FailuresAlloc, Malloc_BytesInUse
>> ...) for info_proc_read_helper().
>>
>> If this change is accepted, it also need to change uislib_free().
>>
>> Is it fine to change like this?
>
> This change is fine with me.  It makes the logic easier to follow.
>
>>
>> Thanks.
>> Daeseok Youn.
>>
>> 2014-03-18 6:41 GMT+09:00 Greg KH :
>>>
>>> On Wed, Mar 12, 2014 at 07:37:50PM +0900, Daeseok Youn wrote:

 Signed-off-by: Daeseok Youn 
 ---
   drivers/staging/unisys/uislib/uislib.c   |5 +
   drivers/staging/unisys/uislib/uisutils.c |2 +-
   2 files changed, 2 insertions(+), 5 deletions(-)

 diff --git a/drivers/staging/unisys/uislib/uislib.c
 b/drivers/staging/unisys/uislib/uislib.c
 index d77df9a..9748fcb 100644
 --- a/drivers/staging/unisys/uislib/uislib.c
 +++ b/drivers/staging/unisys/uislib/uislib.c
 @@ -339,8 +339,6 @@ create_bus(CONTROLVM_MESSAGE *msg, char *buf)
return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
}

 - memset(bus, 0, size);
 -
/* Currently by default, the bus Number is the GuestHandle.
 * Configure Bus message can override this.
 */
 @@ -530,7 +528,6 @@ create_device(CONTROLVM_MESSAGE *msg, char *buf)
return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
}

 - memset(dev, 0, sizeof(struct device_info));
dev->channelTypeGuid = msg->cmd.createDevice.dataTypeGuid;
dev->intr = msg->cmd.createDevice.intr;
dev->channelAddr = msg->cmd.createDevice.channelAddr;
 @@ -1437,7 +1434,7 @@ uislib_malloc(size_t siz, gfp_t gfp, U8
 contiguous, char *fn, int ln)
* get memory for you (like, invoke oom killer), which
* will probably cripple the system.
*/
 - p = kmalloc(siz, gfp | __GFP_NORETRY);
 + p = kzalloc(siz, gfp | __GFP_NORETRY);
}
if (p == NULL) {
LOGERR("uislib_malloc failed to alloc %d bytes @%s:%d",
 diff --git a/drivers/staging/unisys/uislib/uisutils.c
 b/drivers/staging/unisys/uislib/uisutils.c
 index 208b7ea..2f05be1 100644
 --- a/drivers/staging/unisys/uislib/uisutils.c
 +++ b/drivers/staging/unisys/uislib/uisutils.c
 @@ -294,7 +294,7 @@ ReqHandlerAdd(GUID switchTypeGuid,
rc = UISMALLOC(sizeof(*rc), GFP_ATOMIC);
if (!rc)
return NULL;
 - memset(rc, 0, sizeof(*rc));
 +
rc->switchTypeGuid = switchTypeGuid;
rc->controlfunc = controlfunc;
rc->min_channel_bytes = min_channel_bytes;
>>>
>>> Can you just remove the UISMALLOC() macro completly, so that it's easier
>>> to verify that changes like this are actually correct?
>>>
>>> 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 trivial 1/2] ARM: shmobile: armadillo800eva: Spelling and grammar

[Simon Horman]

On Tue, Mar 18, 2014 at 10:39:23AM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> Signed-off-by: Geert Uytterhoeven 
> Cc: Simon Horman 
> Cc: linux...@vger.kernel.org

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

[PATCH V2] checkpatch: Reduce false positives for "Missing blank line after declarations" test

[Joe Perches]

Reduce the false positives of this test by checking
previous lines for known macros that declare variables.

Add c90 keywords and test those too.

Comment the specific tests done a bit better.

Signed-off-by: Joe Perches 
---

V2: I believe this one works better.
Don't allow "else if" to be an $Ident $Ident match
Skip bitfield continuations too

 scripts/checkpatch.pl | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d44e440..93beee8 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -303,6 +303,7 @@ our $Operators  = qr{
=>|->|<<|>>|<|>|!|~|
&&|\|\||,|\^|\+\+|--|&|\||$Arithmetic
  }x;
+our $c90_Keywords = 
qr{do|for|while|if|else|return|goto|continue|switch|default|case|break}x;
 
 our $NonptrType;
 our $NonptrTypeWithAttr;
@@ -388,6 +389,11 @@ our @mode_permission_funcs = (
["(?:CLASS|DEVICE|SENSOR)_ATTR", 2],
 );
 
+our $declaration_macros = qr{(?x:
+   (?:$Storage\s+)?(?:DECLARE|DEFINE)_[A-Z]+\s*\(|
+   (?:$Storage\s+)?LIST_HEAD\s*\(
+)};
+
 our $allowed_asm_includes = qr{(?x:
irq|
memory
@@ -2251,14 +2257,32 @@ sub process {
}
 
 # check for missing blank lines after declarations
-   if ($prevline =~ /^\+\s+$Declare\s+$Ident/ &&
-   !($prevline =~ /(?:$Compare|$Assignment|$Operators)\s*$/ ||
- $prevline =~ /(?:\{\s*|\\)$/) &&  #extended lines
-   $sline =~ /^\+\s+/ &&   #Not at char 1
+   if ($sline =~ /^\+\s+\S/ && #Not at char 1
+   # actual declarations
+   ($prevline =~ /^\+\s+$Declare\s+$Ident\s*[=,;\[]/ ||
+   # foo bar; where foo is some local typedef or #define
+$prevline =~ 
/^\+\s+$Ident(?:\s+|\s*\*\s*)$Ident\s*[=,;\[]/ ||
+   # known declaration macros
+$prevline =~ /^\+\s+$declaration_macros/) &&
+   # for "else if" which can look like "$Ident $Ident"
+   !($prevline =~ /^\+\s+$c90_Keywords\b/ ||
+   # other possible extensions of declaration lines
+ $prevline =~ /(?:$Compare|$Assignment|$Operators)\s*$/ ||
+   # not starting a section or a macro "\" extended line
+ $prevline =~ /(?:\{\s*|\\)$/) &&
+   # looks like a declaration
!($sline =~ /^\+\s+$Declare/ ||
- $sline =~ /^\+\s+$Ident\s+$Ident/ ||  #eg: typedef foo
+   # foo bar; where foo is some local typedef or #define
+ $sline =~ /^\+\s+$Ident(?:\s+|\s*\*\s*)$Ident\s*[=,;\[]/ 
||
+   # known declaration macros
+ $sline =~ /^\+\s+$declaration_macros/ ||
+   # start of struct or union or enum
  $sline =~ /^\+\s+(?:union|struct|enum|typedef)\b/ ||
- $sline =~ /^\+\s+(?:$|[\{\}\.\#\"\?\:\(])/ ||
+   # start or end of block or continuation of declaration
+ $sline =~ /^\+\s+(?:$|[\{\}\.\#\"\?\:\(\[])/ ||
+   # bitfield continuation
+ $sline =~ /^\+\s+$Ident\s*:\s*\d+\s*[,;]/ ||
+   # other possible extensions of declaration lines
  $sline =~ 
/^\+\s+\(?\s*(?:$Compare|$Assignment|$Operators)/)) {
WARN("SPACING",
 "Missing a blank line after declarations\n" . 
$hereprev);
-- 
1.8.1.2.459.gbcd45b4.dirty



--
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 7/9] fsl: add EPU FSM configuration for deep sleep

[Chenhui Zhao]

On Tue, Mar 18, 2014 at 06:21:22PM -0500, Scott Wood wrote:
> On Mon, 2014-03-17 at 18:27 +0800, Chenhui Zhao wrote:
> > On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote:
> > > On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote:
> > > > On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote:
> > > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > > +   /* Configure the EPU Counters */
> > > > > > +   epu_write(EPCCR15, 0x9284);
> > > > > > +   epu_write(EPCCR14, 0x9284);
> > > > > > +   epu_write(EPCCR12, 0x9284);
> > > > > > +   epu_write(EPCCR11, 0x9284);
> > > > > > +   epu_write(EPCCR10, 0x9284);
> > > > > > +   epu_write(EPCCR9, 0x9284);
> > > > > > +   epu_write(EPCCR8, 0x9284);
> > > > > > +   epu_write(EPCCR5, 0x9284);
> > > > > > +   epu_write(EPCCR4, 0x9284);
> > > > > > +   epu_write(EPCCR2, 0x9284);
> > > > > > +
> > > > > > +   /* Configure the SCUs Inputs */
> > > > > > +   epu_write(EPSMCR15, 0x7600);
> > > > > > +   epu_write(EPSMCR14, 0x0031);
> > > > > > +   epu_write(EPSMCR13, 0x3100);
> > > > > > +   epu_write(EPSMCR12, 0x7F00);
> > > > > > +   epu_write(EPSMCR11, 0x3174);
> > > > > > +   epu_write(EPSMCR10, 0x6530);
> > > > > > +   epu_write(EPSMCR9, 0x3000);
> > > > > > +   epu_write(EPSMCR8, 0x6430);
> > > > > > +   epu_write(EPSMCR7, 0x3000);
> > > > > > +   epu_write(EPSMCR6, 0x7C00);
> > > > > > +   epu_write(EPSMCR5, 0x2E00);
> > > > > > +   epu_write(EPSMCR4, 0x002F);
> > > > > > +   epu_write(EPSMCR3, 0x2F00);
> > > > > > +   epu_write(EPSMCR2, 0x6C70);
> > > > > 
> > > > > Where do these magic numbers come from?  Which chips are they valid 
> > > > > for?
> > > > 
> > > > They are for T1040. Can be found in the RCPM chapter of T1040RM.
> > > 
> > > Then put in a comment to that effect, including what part of the RCPM
> > > chapter.
> > > 
> > > How do you plan to handle the addition of another SoC with different
> > > values?
> > > 
> > > -Scott
> > 
> > Had thought that using an array to put these values (pairs of offset and 
> > value)
> > and passing the array to the function.
> 
> Arrays are better than a long sequence of function calls in any case.
> 
> > However, luckily T104x and LS1 have same values for these registers
> > according to the current Reference Manuals.
> 
> If it's likely that the values will remain the same on all chips for the
> near future, then a fancy mechanism to select the array to use can wait
> -- but you should still use an array, and have a comment acknowledging
> the possibility of needing to accommodate different values in the
> future.
> 
> -Scott

OK. Will use an array to pass the values.

-Chenhui

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

Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0

[DaeSeok Youn]

Hi, greg.

Review my comment below.

Thanks.
Daeseok Youn.

2014-03-18 17:11 GMT+09:00 DaeSeok Youn :
> 2014-03-18 9:37 GMT+09:00 Greg KH :
>> On Tue, Mar 18, 2014 at 09:26:07AM +0900, DaeSeok Youn wrote:
>>> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use
>>> vmalloc/kmalloc directly.
>>
>> Yes.  Actually, just use kmalloc, I don't knwo why vmalloc is being
>> used, but cc: the driver maintainers just to be sure.
>
> It try to allocate 128KiB(131072byte) with vmalloc(). I think if it
> trying to allocate with kmalloc()
> it has a possibility to fail because of memory fragmentation even if
> system has enough memory to use.
> Just my opinion. If I'm wrong, let me know.
>
>>
>>> (UISMALLOC() macro is also removed.)
>>
>> Yes.
>>
>>> And uislib_malloc() is renamed to "uislib_trace_buffer_status()" which
>>> is just tracing buffer status(Malloc_FailuresAlloc, Malloc_BytesInUse
>>> ...) for info_proc_read_helper().
>>
>> The whole tracing stuff needs to be ripped out, so no problem deleting
>> it here as well.
>
> OK. I will remove that information in info_proc_read_helper().
>
>>
>>> If this change is accepted, it also need to change uislib_free().
>>
>> Drop it and just use kfree().
> OK. replace kfree() with uislib_free().
>
>>
>> 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] ASoC: Add support for multi register mux

[Mark Brown]

On Tue, Mar 18, 2014 at 04:51:32PM -0700, Arun Shamanna Lakshmi wrote:

> Currently soc_enum structure supports only 2 registers (reg, reg2)
> for kcontrol. However, it is possible to have multiple registers
> per mux. This change allows us to control these multiple registers.

I'd want to see a user along with this and...

> @@ -1093,6 +1093,9 @@ struct soc_enum {
>   unsigned int mask;
>   const char * const *texts;
>   const unsigned int *values;
> + unsigned int *regs;
> + unsigned int *masks;
> + unsigned int num_regs;

...it duplicates and generally isn't joined up with the existing members
of the structure, and has no support in the helpers (for example,
converting the existing stereo controls to be two element arrays which
I'd expect to see).  Helpers would count as users here.

Note that we don't support double register enums or muxes - only
numerical controls are supported.  It's not clear what a multi-register
enum would mean.


signature.asc
Description: Digital signature

Re: [PATCH V5 0/5] Add X-Gene platform reboot mechanism

[Feng Kan]

Just want to ping this again, since no activity for a while. I have
added endian and
access size related information in the documentation.  Please let me
know if more is
needed.

On Wed, Jan 29, 2014 at 4:03 PM, Feng Kan  wrote:
> Enable reboot driver for the X-Gene platform. Add generic syscon reboot
> driver.
>
> V5 Change:
> - Documentation update, endian and access size.
>
> V4 Change:
> - Remove old X-Gene reboot driver
> - Add generic syscon reboot driver
> - Add DTS and Kconfig for X-Gene reboot using syscon method
>
> V3 Change:
> - Remove the reboot driver's use of acpi resource patch.
> - Change the reboot driver to use syscon to parse out
>   system clock register. Remove the old method of getting
>   register from the reboot driver directly.
> - Remove documentation since its now simple.
>
> V2 Change:
> - Add support for using ACPI resource.
>
> Feng Kan (5):
>   power: reset: Add generic SYSCON register mapped reset
>   power: reset: Remove X-Gene reboot driver
>   arm64: dts: Add X-Gene reboot driver dts node
>   arm64: Select reboot driver for X-Gene platform
>   Documentation: power: reset: Add documentation for generic SYSCON
> reboot driver
>
>  .../bindings/power/reset/syscon-reboot.txt |   23 +
>  arch/arm64/Kconfig |2 +
>  arch/arm64/boot/dts/apm-storm.dtsi |   13 +++
>  drivers/power/reset/Kconfig|8 +-
>  drivers/power/reset/Makefile   |2 +-
>  drivers/power/reset/syscon-reboot.c|  100 +++
>  drivers/power/reset/xgene-reboot.c |  103 
> 
>  7 files changed, 143 insertions(+), 108 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
>  create mode 100644 drivers/power/reset/syscon-reboot.c
>  delete mode 100644 drivers/power/reset/xgene-reboot.c
>
> --
> 1.7.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 v11 10/27] iommu/exynos: use managed device helper functions

[Jingoo Han]

On Wednesday, March 19, 2014 12:12 AM, Tomasz Figa wrote:
> On 18.03.2014 11:38, Cho KyongHo wrote:
> > On Fri, 14 Mar 2014 14:28:36 +0100, Tomasz Figa wrote:
> >> On 14.03.2014 06:05, Cho KyongHo wrote:
> >>> This patch uses managed device helper functions in the probe().
> >>>
> >>> Signed-off-by: Cho KyongHo 
> >>> ---
> >>>drivers/iommu/exynos-iommu.c |   64 
> >>> +-
> >>>1 file changed, 26 insertions(+), 38 deletions(-)
> >>>
> >>> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> >>> index 36e6b73..33b424d 100644
> >>> --- a/drivers/iommu/exynos-iommu.c
> >>> +++ b/drivers/iommu/exynos-iommu.c

[.]

> >>>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >>>   if (!res) {
> >>> - dev_dbg(dev, "Unable to find IOMEM region\n");
> >>> - ret = -ENOENT;
> >>> - goto err_init;
> >>> + dev_err(dev, "Unable to find IOMEM region\n");
> >>> + return -ENOENT;
> >>>   }
> >>
> >> No need to check for error and print message, because
> >> devm_ioremap_resource() already checks the passed resource and handles
> >> error cases.
> >>
> >
> > Yes but devm_ioremap_resource() just tells that the given 'res' is not
> > correct. I think the message in the driver is more informative.
> 
> The common practice used in Linux kernel is to not duplicate such
> messages. It is obvious that devm_ioremap_resource() printing such
> message is related to an IOMEM resource anyway, as you can't used it
> with other types of resources.

+1

I agree with Tomasz Figa's opinion.
These messages have been being removed from Linux kernel.
Thank you.

Best regards,
Jingoo Han

--
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] ASoC: Add support for multi register mux

[Arun Shamanna Lakshmi]

Currently soc_enum structure supports only 2 registers (reg, reg2)
for kcontrol. However, it is possible to have multiple registers
per mux. This change allows us to control these multiple registers.

Signed-off-by: Arun Shamanna Lakshmi 
Signed-off-by: Songhee Baek 
---
 include/sound/soc.h |3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index 9a00147..ddedfb4 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1093,6 +1093,9 @@ struct soc_enum {
unsigned int mask;
const char * const *texts;
const unsigned int *values;
+   unsigned int *regs;
+   unsigned int *masks;
+   unsigned int num_regs;
 };
 
 /* codec IO */
-- 
1.7.9.5

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

Re: [PATCH v3 2/5] pwm: kona: Introduce Kona PWM controller support

[Tim Kryger]

On Tue, Mar 18, 2014 at 2:52 PM, Thierry Reding
 wrote:
> On Wed, Mar 12, 2014 at 01:15:43PM -0700, Tim Kryger wrote:
> [...]
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index 22f2f28..1fd42af 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -62,6 +62,16 @@ config PWM_ATMEL_TCB
>> To compile this driver as a module, choose M here: the module
>> will be called pwm-atmel-tcb.
>>
>> +config PWM_BCM_KONA
>> + tristate "Kona PWM support"
>> + depends on ARCH_BCM_MOBILE
>> + default y
>
> No "default y", please.

Even though it depends on ARCH_BCM_MOBILE?  It seems like a reasonable default.

These SoCs target mobile phones which almost always have a backlight
controlled by the PWM.

>
>> diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
> [...]
>> +static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int 
>> chan)
>> +{
>> + unsigned long value = readl(kp->base + PWM_CONTROL_OFFSET);
>> +
>> + /*
>> +  * New duty and period settings are only reflected in the PWM output
>> +  * after a rising edge of the enable bit.  When smooth bit is set, the
>> +  * new settings are delayed until the prior PWM period has completed.
>> +  * Furthermore, if the smooth bit is set, the PWM continues to output a
>> +  * waveform based on the old settings during the time that the enable
>> +  * bit is low.  Otherwise the output is a constant high signal while
>> +  * the enable bit is low.
>> +  */
>> +
>> + /* clear enable bit but set smooth bit to maintain old output */
>> + value |= (1 << PWM_CONTROL_SMOOTH_SHIFT(chan));
>
> There's no need for the parentheses here.

Ok

>
>> + value &= ~(1 << PWM_CONTROL_ENABLE_SHIFT(chan));
>> + writel(value, kp->base + PWM_CONTROL_OFFSET);
>> +
>> + /* set enable bit and clear smooth bit to apply new settings */
>> + value &= ~(1 << PWM_CONTROL_SMOOTH_SHIFT(chan));
>> + value |= (1 << PWM_CONTROL_ENABLE_SHIFT(chan));
>
> Nor here.

Ok

>
>> + writel(value, kp->base + PWM_CONTROL_OFFSET);
>
> I'm curious about how this work. The above writes the control register
> once with smooth set and enable cleared, then immediately rewrites it
> again with smooth cleared and enable set. Are these writes somehow
> queued in hardware, so that the subsequent write becomes active only
> after the current period?

It isn't exactly queuing up the writes but if smooth mode is set, it
will wait to apply the new settings.

>
>> +static int kona_pwmc_config(struct pwm_chip *chip, struct pwm_device *pwm,
>> + int duty_ns, int period_ns)
>
> Please align arguments on subsequent lines with those on the first line.

Sure

>
>> +{
>> + struct kona_pwmc *kp = dev_get_drvdata(chip->dev);
>
> The proper way to do this would be upcasting using container_of().
> Better yet, define a static inline function that wraps container_of(),
> just like very other driver does.
>

I will convert to use this approach (except in kona_pwmc_remove)

>> + u64 val, div, clk_rate;
>> + unsigned long prescale = PRESCALE_MIN, pc, dc;
>> + unsigned int value, chan = pwm->hwpwm;
>> +
>> + /*
>> +  * Find period count, duty count and prescale to suit duty_ns and
>> +  * period_ns. This is done according to formulas described below:
>> +  *
>> +  * period_ns = 10^9 * (PRESCALE + 1) * PC / PWM_CLK_RATE
>> +  * duty_ns = 10^9 * (PRESCALE + 1) * DC / PWM_CLK_RATE
>> +  *
>> +  * PC = (PWM_CLK_RATE * period_ns) / (10^9 * (PRESCALE + 1))
>> +  * DC = (PWM_CLK_RATE * duty_ns) / (10^9 * (PRESCALE + 1))
>> +  */
>> +
>> + clk_rate = clk_get_rate(kp->clk);
>
> "rate" is 50% shorter and would do equally well.

That works for me.

>
>> +
>> + /* There is polarity support in HW but it is easier to manage in SW */
>> + if (pwm->polarity == PWM_POLARITY_INVERSED)
>> + duty_ns = period_ns - duty_ns;
>
> No, this is wrong. You're not actually changing the *polarity* here.

Please elaborate.  I don't understand what is wrong here.

Does polarity influence the output while a PWM is disabled?

>
> Also I think this is missing a pair of clk_prepare_enable() and
> clk_disable_unprepare().

There is no issue here since the hardware registers are only touched
in kona_pwmc_config if the channel was already enabled.

>
>> +static int kona_pwmc_set_polarity(struct pwm_chip *chip, struct pwm_device 
>> *pwm,
>> +   enum pwm_polarity polarity)
>> +{
>> + /*
>> +  * The framework only allows the polarity to be changed when a PWM is
>> +  * disabled so no immediate action is required here.  When a channel is
>> +  * enabled, the polarity gets handled as part of the re-config step.
>> +  */
>> +
>> + return 0;
>> +}
>
> See above. If you don't want to implement the hardware support for
> inversed polarity, then simply don't implement this.

I had 

mmotm 2014-03-18-16-37 uploaded

[akpm]

The mm-of-the-moment snapshot 2014-03-18-16-37 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (3.x
or 3.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/?p=linux-mmots.git;a=summary

and use of this tree is similar to
http://git.cmpxchg.org/?p=linux-mmotm.git, described above.


This mmotm tree contains the following patches against 3.14-rc7:
(patches marked "*" will be included in linux-next)

  origin.patch
  arch-alpha-kernel-systblss-remove-debug-check.patch
  i-need-old-gcc.patch
  maintainers-akpm-maintenance.patch
* sh-fix-format-string-bug-in-stack-tracer.patch
* backing_dev-fix-hung-task-on-sync.patch
* backing_dev-fix-hung-task-on-sync-fix.patch
* slub-fix-high-order-page-allocation-problem-with-__gfp_nofail.patch
* bdi-avoid-oops-on-device-removal.patch
* kthread-ensure-locality-of-task_struct-allocations.patch
* arch-x86-mm-kmemcheck-kmemcheckc-use-kstrtoint-instead-of-sscanf.patch
* arm-use-generic-fixmaph.patch
* fs-cifs-cifsfsc-add-__init-to-cifs_init_inodecache.patch
* fs-freevxfs-vxfs_lookupc-update-function-comment.patch
* fanotify-remove-useless-bypass_perm-check.patch
* fanotify-use-fanotify-event-structure-for-permission-response-processing.patch
* fanotify-convert-access_mutex-to-spinlock.patch
* fanotify-reorganize-loop-in-fanotify_read.patch
* fanotify-move-unrelated-handling-from-copy_event_to_user.patch
* sched_clock-document-4mhz-vs-1mhz-decision.patch
* input-route-kbd-leds-through-the-generic-leds-layer.patch
* genksyms-fix-typeof-handling.patch
* score-remove-unused-cpu_score7-kconfig-parameter.patch
* sh-push-extra-copy-of-r0-r2-for-syscall-parameters.patch
* sh-remove-unused-do_fpu_error.patch
* sh-dont-pass-saved-userspace-state-to-exception-handlers.patch
* arch-sh-boards-board-sh7757lcrc-fixup-sdhi-register-size.patch
* sh-sh7757-switch-rspi-clock-to-dev-id-match.patch
* drivers-net-irda-donauboe-convert-to-module_pci_driver.patch
* net-core-rtnetlinkc-copy-paste-error-in-rtnl_bridge_notify.patch
* 
ocfs2-fix-null-pointer-dereference-when-access-dlm_state-before-launching-dlm-thread.patch
* ocfs2-change-ip_unaligned_aio-to-of-type-mutex-from-atomit_t.patch
* ocfs2-remove-unused-variable-uuid_net_key-in-ocfs2_initialize_super.patch
* 
ocfs2-improve-fsync-efficiency-and-fix-deadlock-between-aio_write-and-sync_file.patch
* 
ocfs2-o2net-incorrect-to-terminate-accepting-connections-loop-upon-rejecting-an-invalid-one.patch
* ocfs2-dlm-fix-lock-migration-crash.patch
* ocfs2-dlm-fix-recovery-hung.patch
* ocfs2-add-dlm_recover_callback_support-in-sysfs.patch
* ocfs2-add-dlm_recover_callback_support-in-sysfs-fix.patch
* ocfs2-fix-a-tiny-race-when-running-dirop_fileop_racer.patch
* 
ocfs2-o2net-o2net_listen_data_ready-should-do-nothing-if-socket-state-is-not-tcp_listen.patch
* ocfs2-remove-ocfs2_inode_skip_delete-flag.patch
* ocfs2-move-dquot_initialize-in-ocfs2_delete_inode-somewhat-later.patch
* quota-provide-function-to-grab-quota-structure-reference.patch
* 

Re: [PATCH 4/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)

[Paul E. McKenney]

On Wed, Mar 19, 2014 at 04:15:44AM +0530, Monam Agarwal wrote:
> Signed-off-by: Monam Agarwal 

Reviewed-by: Paul E. McKenney 

> ---
>  drivers/net/ppp/pptp.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
> index 89f829f..ede899c 100644
> --- a/drivers/net/ppp/pptp.c
> +++ b/drivers/net/ppp/pptp.c
> @@ -162,7 +162,7 @@ static void del_chan(struct pppox_sock *sock)
>  {
>   spin_lock(_lock);
>   clear_bit(sock->proto.pptp.src_addr.call_id, callid_bitmap);
> - rcu_assign_pointer(callid_sock[sock->proto.pptp.src_addr.call_id], 
> NULL);
> + RCU_INIT_POINTER(callid_sock[sock->proto.pptp.src_addr.call_id], NULL);
>   spin_unlock(_lock);
>   synchronize_rcu();
>  }
> -- 
> 1.7.9.5
> 

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

Re: [PATCH 5/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)

[Paul E. McKenney]

On Wed, Mar 19, 2014 at 04:16:42AM +0530, Monam Agarwal wrote:
> Signed-off-by: Monam Agarwal 

Reviewed-by: Paul E. McKenney 

> ---
>  drivers/net/wireless/ath/carl9170/main.c |   12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/carl9170/main.c 
> b/drivers/net/wireless/ath/carl9170/main.c
> index f06e069..5518592 100644
> --- a/drivers/net/wireless/ath/carl9170/main.c
> +++ b/drivers/net/wireless/ath/carl9170/main.c
> @@ -446,7 +446,7 @@ static void carl9170_op_stop(struct ieee80211_hw *hw)
> 
>   mutex_lock(>mutex);
>   if (IS_ACCEPTING_CMD(ar)) {
> - rcu_assign_pointer(ar->beacon_iter, NULL);
> + RCU_INIT_POINTER(ar->beacon_iter, NULL);
> 
>   carl9170_led_set_state(ar, 0);
> 
> @@ -678,7 +678,7 @@ unlock:
>   vif_priv->active = false;
>   bitmap_release_region(>vif_bitmap, vif_id, 0);
>   ar->vifs--;
> - rcu_assign_pointer(ar->vif_priv[vif_id].vif, NULL);
> + RCU_INIT_POINTER(ar->vif_priv[vif_id].vif, NULL);
>   list_del_rcu(_priv->list);
>   mutex_unlock(>mutex);
>   synchronize_rcu();
> @@ -716,7 +716,7 @@ static void carl9170_op_remove_interface(struct 
> ieee80211_hw *hw,
>   WARN_ON(vif_priv->enable_beacon);
>   vif_priv->enable_beacon = false;
>   list_del_rcu(_priv->list);
> - rcu_assign_pointer(ar->vif_priv[id].vif, NULL);
> + RCU_INIT_POINTER(ar->vif_priv[id].vif, NULL);
> 
>   if (vif == main_vif) {
>   rcu_read_unlock();
> @@ -1258,7 +1258,7 @@ static int carl9170_op_sta_add(struct ieee80211_hw *hw,
>   }
> 
>   for (i = 0; i < CARL9170_NUM_TID; i++)
> - rcu_assign_pointer(sta_info->agg[i], NULL);
> + RCU_INIT_POINTER(sta_info->agg[i], NULL);
> 
>   sta_info->ampdu_max_len = 1 << (3 + sta->ht_cap.ampdu_factor);
>   sta_info->ht_sta = true;
> @@ -1285,7 +1285,7 @@ static int carl9170_op_sta_remove(struct ieee80211_hw 
> *hw,
>   struct carl9170_sta_tid *tid_info;
> 
>   tid_info = rcu_dereference(sta_info->agg[i]);
> - rcu_assign_pointer(sta_info->agg[i], NULL);
> + RCU_INIT_POINTER(sta_info->agg[i], NULL);
> 
>   if (!tid_info)
>   continue;
> @@ -1398,7 +1398,7 @@ static int carl9170_op_ampdu_action(struct ieee80211_hw 
> *hw,
>   spin_unlock_bh(>tx_ampdu_list_lock);
>   }
> 
> - rcu_assign_pointer(sta_info->agg[tid], NULL);
> + RCU_INIT_POINTER(sta_info->agg[tid], NULL);
>   rcu_read_unlock();
> 
>   ieee80211_stop_tx_ba_cb_irqsafe(vif, sta->addr, tid);
> -- 
> 1.7.9.5
> 

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

Re: [PATCH 2/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) in drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c

[Paul E. McKenney]

On Wed, Mar 19, 2014 at 04:12:16AM +0530, Monam Agarwal wrote:
> Signed-off-by: Monam Agarwal 

Reviewed-by: Paul E. McKenney 

> ---
>  drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c 
> b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
> index da5a5d9..a7ec886 100644
> --- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
> +++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
> @@ -1300,7 +1300,7 @@ int cxgb3_offload_activate(struct adapter *adapter)
> 
>  out_free_l2t:
>   t3_free_l2t(L2DATA(dev));
> - rcu_assign_pointer(dev->l2opt, NULL);
> + RCU_INIT_POINTER(dev->l2opt, NULL);
>  out_free:
>   kfree(t);
>   return err;
> @@ -1328,7 +1328,7 @@ void cxgb3_offload_deactivate(struct adapter *adapter)
>   rcu_read_lock();
>   d = L2DATA(tdev);
>   rcu_read_unlock();
> - rcu_assign_pointer(tdev->l2opt, NULL);
> + RCU_INIT_POINTER(tdev->l2opt, NULL);
>   call_rcu(>rcu_head, clean_l2_data);
>   if (t->nofail_skb)
>   kfree_skb(t->nofail_skb);
> -- 
> 1.7.9.5
> 

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

Re: [PATCH 3/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) in drivers/net/macvtap.c

[Paul E. McKenney]

On Wed, Mar 19, 2014 at 04:14:31AM +0530, Monam Agarwal wrote:
> Signed-off-by: Monam Agarwal 

Reviewed-by: Paul E. McKenney 

> ---
>  drivers/net/macvtap.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 1b7082d..7c88d13 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -145,8 +145,8 @@ static void macvtap_put_queue(struct macvtap_queue *q)
>   if (vlan) {
>   int index = get_slot(vlan, q);
> 
> - rcu_assign_pointer(vlan->taps[index], NULL);
> - rcu_assign_pointer(q->vlan, NULL);
> + RCU_INIT_POINTER(vlan->taps[index], NULL);
> + RCU_INIT_POINTER(q->vlan, NULL);
>   sock_put(>sk);
>   --vlan->numvtaps;
>   }
> @@ -223,8 +223,8 @@ static void macvtap_del_queues(struct net_device *dev)
> lockdep_is_held(_lock));
>   if (q) {
>   qlist[j++] = q;
> - rcu_assign_pointer(vlan->taps[i], NULL);
> - rcu_assign_pointer(q->vlan, NULL);
> + RCU_INIT_POINTER(vlan->taps[i], NULL);
> + RCU_INIT_POINTER(q->vlan, NULL);
>   vlan->numvtaps--;
>   }
>   }
> -- 
> 1.7.9.5
> 

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

Re: [PATCH 1/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) in drivers/net/ethernet/broadcom/bnx2.c

[Paul E. McKenney]

On Wed, Mar 19, 2014 at 04:10:42AM +0530, Monam Agarwal wrote:
> Signed-off-by: Monam Agarwal 

Reviewed-by: Paul E. McKenney 

> ---
>  drivers/net/ethernet/broadcom/bnx2.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/bnx2.c 
> b/drivers/net/ethernet/broadcom/bnx2.c
> index 965c723..5eab730 100644
> --- a/drivers/net/ethernet/broadcom/bnx2.c
> +++ b/drivers/net/ethernet/broadcom/bnx2.c
> @@ -409,7 +409,7 @@ static int bnx2_unregister_cnic(struct net_device *dev)
>   mutex_lock(>cnic_lock);
>   cp->drv_state = 0;
>   bnapi->cnic_present = 0;
> - rcu_assign_pointer(bp->cnic_ops, NULL);
> + RCU_INIT_POINTER(bp->cnic_ops, NULL);
>   mutex_unlock(>cnic_lock);
>   synchronize_rcu();
>   return 0;
> -- 
> 1.7.9.5
> 

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

Re: [BUG -next] "mm: per-thread vma caching fix 5" breaks s390

[Stephen Rothwell]

Hi Andrew,

On Tue, 18 Mar 2014 16:10:50 -0700 Andrew Morton  
wrote:
>
> On Tue, 18 Mar 2014 16:06:59 -0700 Tony Luck  wrote:
> 
> > On Tue, Mar 18, 2014 at 5:41 AM, Heiko Carstens
> >  wrote:
> > > Given that this is just an addon patch to Davidlohr's "mm: per-thread
> > > vma caching" patch I was wondering if something in there is architecture
> > > specific.
> > > But it doesn't look like that. So I'm wondering if this only breaks on
> > > s390?
> > 
> > I'm seeing this same BUG_ON() on ia64 (when trying out next-20140318)
> 
> -next is missing
> http://ozlabs.org/~akpm/mmots/broken-out/mm-per-thread-vma-caching-fix-6.patch.
> Am presently trying to cook up an mmotm for tomorrow's -next.  

I could apply just that patch to today's linux-next if you like.
Otherwise if you get a new mmotm out in the next ~6-8 hours, I will use
that.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpJgI012a2WD.pgp
Description: PGP signature

Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep

[Scott Wood]

On Mon, 2014-03-17 at 18:27 +0800, Chenhui Zhao wrote:
> On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote:
> > On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote:
> > > On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote:
> > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > + /* Configure the EPU Counters */
> > > > > + epu_write(EPCCR15, 0x9284);
> > > > > + epu_write(EPCCR14, 0x9284);
> > > > > + epu_write(EPCCR12, 0x9284);
> > > > > + epu_write(EPCCR11, 0x9284);
> > > > > + epu_write(EPCCR10, 0x9284);
> > > > > + epu_write(EPCCR9, 0x9284);
> > > > > + epu_write(EPCCR8, 0x9284);
> > > > > + epu_write(EPCCR5, 0x9284);
> > > > > + epu_write(EPCCR4, 0x9284);
> > > > > + epu_write(EPCCR2, 0x9284);
> > > > > +
> > > > > + /* Configure the SCUs Inputs */
> > > > > + epu_write(EPSMCR15, 0x7600);
> > > > > + epu_write(EPSMCR14, 0x0031);
> > > > > + epu_write(EPSMCR13, 0x3100);
> > > > > + epu_write(EPSMCR12, 0x7F00);
> > > > > + epu_write(EPSMCR11, 0x3174);
> > > > > + epu_write(EPSMCR10, 0x6530);
> > > > > + epu_write(EPSMCR9, 0x3000);
> > > > > + epu_write(EPSMCR8, 0x6430);
> > > > > + epu_write(EPSMCR7, 0x3000);
> > > > > + epu_write(EPSMCR6, 0x7C00);
> > > > > + epu_write(EPSMCR5, 0x2E00);
> > > > > + epu_write(EPSMCR4, 0x002F);
> > > > > + epu_write(EPSMCR3, 0x2F00);
> > > > > + epu_write(EPSMCR2, 0x6C70);
> > > > 
> > > > Where do these magic numbers come from?  Which chips are they valid for?
> > > 
> > > They are for T1040. Can be found in the RCPM chapter of T1040RM.
> > 
> > Then put in a comment to that effect, including what part of the RCPM
> > chapter.
> > 
> > How do you plan to handle the addition of another SoC with different
> > values?
> > 
> > -Scott
> 
> Had thought that using an array to put these values (pairs of offset and 
> value)
> and passing the array to the function.

Arrays are better than a long sequence of function calls in any case.

> However, luckily T104x and LS1 have same values for these registers
> according to the current Reference Manuals.

If it's likely that the values will remain the same on all chips for the
near future, then a fancy mechanism to select the array to use can wait
-- but you should still use an array, and have a comment acknowledging
the possibility of needing to accommodate different values in the
future.

-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: [PATCH] staging/xillybus: Handle OOM in xillybus_init()

[Eli Billauer]

Hi,

I stand (shamefully) corrected. Thanks.

  Eli

On 19/03/14 01:07, Richard Weinberger wrote:

alloc_workqueue() can fail and returns NULL in case of
OOM.
Handle this case and undo class_create().

Signed-off-by: Richard Weinberger
---
  drivers/staging/xillybus/xillybus_core.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/xillybus/xillybus_core.c 
b/drivers/staging/xillybus/xillybus_core.c
index 2ebaf16..b0a6696 100644
--- a/drivers/staging/xillybus/xillybus_core.c
+++ b/drivers/staging/xillybus/xillybus_core.c
@@ -2318,8 +2318,12 @@ static int __init xillybus_init(void)
}

xillybus_wq = alloc_workqueue(xillyname, 0, 0);
+   if (!xillybus_wq) {
+   class_destroy(xillybus_class);
+   rc = -ENOMEM;
+   }

-   return 0; /* Success */
+   return rc;
  }

  static void __exit xillybus_exit(void)
   



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

Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

[Scott Wood]

On Sun, 2014-03-16 at 12:58 +0800, Kevin Hao wrote:
> On Fri, Mar 14, 2014 at 05:26:27PM -0500, Scott Wood wrote:
> > On Thu, 2014-03-13 at 15:46 +0800, Kevin Hao wrote:
> > > On Wed, Mar 12, 2014 at 12:43:05PM -0500, Scott Wood wrote:
> > > > > Shouldn't we use "readback, sync" here? The following is quoted form 
> > > > > t4240RM:
> > > > >   To guarantee that the results of any sequence of writes to 
> > > > > configuration
> > > > >   registers are in effect, the final configuration register write 
> > > > > should be
> > > > >   immediately followed by a read of the same register, and that 
> > > > > should be
> > > > >   followed by a SYNC instruction. Then accesses can safely be made to 
> > > > > memory
> > > > >   regions affected by the configuration register write.
> > > > 
> > > > I agree that the sync before the readback is probably not necessary,
> > > > since transactions to the same address should already be ordered.
> > > > 
> > > > A sync after the readback helps if you're trying to order the readback
> > > > with subsequent memory accesses, though in that case wouldn't a sync
> > > > alone (no readback) be adequate?
> > > 
> > > No, we don't just want to order the subsequent memory access here.
> > > The 'write, readback, sync' is the required sequence if we want to make
> > > sure that the writing to CCSR register does really take effect.
> > > 
> > > >  Though maybe not always -- see the
> > > > comment near the end of fsl_elbc_write_buf() in
> > > > drivers/mtd/nand_fsl_elbc.c.  I guess the readback does more than just
> > > > make sure the device has seen the write, ensuring that the device has
> > > > finished the transaction to the point of acting on another one.
> > > 
> > > Agree.
> > > 
> > > > 
> > > > The data dependency plus isync sequence, which is done by the normal I/O
> > > > accessors used from C code, orders the readback versus all future
> > > > instructions (not just I/O).  The delay loop is not I/O.
> > > 
> > > According to the PowerISA, the sequence 'load, date dependency, isync' 
> > > only
> > > order the load accesses. 
> > 
> > The point is to order the delay loop after the load, not to order
> > storage versus storage.
> 
> I think the point is to make sure that the writing of the CCSR_DDR_SDRAM_CFG_2
> does really take effect before we begin to delay loop.

Yes.

>  The sequence "write, readback, sync" will guarantee this according to the 
> manual. 

If you're referring to the section you quoted above, the manual does not
say that.  It only talks about when accesses "to memory regions affected
by the configuration register write" can be safely made.

> If we just want to
> order the delay loop after the load, the following sequence should be enough:
>   store to CCSR_DDR_SDRAM_CFG_2
>   load from CCSR_DDR_SDRAM_CFG_2
>   isync or sync
>   delay loop
> 
> Why do we need the 'date dependency' here? According to the e6500 manual, the
> instructions can execute out of order, but complete in order. So I am really
> wondering why we need to order the load and the following delay loop if there
> is no intention to order the storage access? 

The data (not date) dependency means that the twi will not execute until
after the load instruction returns data (thus, after the device has
responded to the load).  The twi, being a flow control instruction
rather than a storage instruction, should be fully ordered by isync.

>From the isync description in the ISA: "Except as described in the
preceding sentence, the isync instruction may complete before storage
accesses associated with instructions preceding the
isync instruction have been performed."

I don't know if that really applies to loads (as opposed to stores), and
it probably doesn't apply to guarded loads, but I feel safer leaving the
twi in.

As for sync instead of isync, I see nothing to indicate that it would be
adequate (though it may be that the only reason there needed to be a
delay loop in the first place was the lack of a readback/sync before
doing other I/O, in which case this is moot).

> > This is a sequence we're already using on all of our I/O loads
> > (excluding accesses like in this patch that don't use the standard
> > accessors).  I'm confident that it works even if it's not
> > architecturally guaranteed.
> 
> This sequence is used to order the load and the followed storage access.

It's also used to order loads versus other things, such as enabling
MSR[EE].

> And this is guaranteed by the architecture. But I don't think it is suitable
> for a case like this. The following is quoted from PowerISA:
>   Because stores cannot be performed “out-of-order”
>   (see Book III), if a Store instruction depends on the
>   value returned by a preceding Load instruction
>   (because the value returned by the Load is used to
>   compute either the effective address specified by the
>   Store or the value to be stored), the corresponding stor-
>   age accesses are performed in program order. 

[PATCH 2/3] ARM: at91/dt: at91sam9m10g45ek: add ADC and touchscreen support

[Alexandre Belloni]

Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/at91sam9m10g45ek.dts | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts 
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 7ff665a8c708..7800931a4b16 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -130,6 +130,21 @@
status = "okay";
};
 
+   adc0: adc@fffb {
+   pinctrl-names = "default";
+   pinctrl-0 = <
+   _adc0_ad0
+   _adc0_ad1
+   _adc0_ad2
+   _adc0_ad3
+   _adc0_ad4
+   _adc0_ad5
+   _adc0_ad6
+   _adc0_ad7>;
+   atmel,adc-ts-wires = <4>;
+   status = "okay";
+   };
+
pwm0: pwm@fffb8000 {
status = "okay";
 
-- 
1.8.3.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/3] ARM: at91/dt: at91sam9m10g45ek PWM leds polarity is inversed

[Alexandre Belloni]

The real polarity of the LEDs is inversed. The led is between 3.3v and the PWM.
It was working before because the driver was getting the duty cycle calculation
wrong.

Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/at91sam9m10g45ek.dts | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts 
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 7800931a4b16..9f5b0a674995 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -8,6 +8,7 @@
  */
 /dts-v1/;
 #include "at91sam9g45.dtsi"
+#include 
 
 / {
model = "Atmel AT91SAM9M10G45-EK";
@@ -231,14 +232,14 @@
 
d6 {
label = "d6";
-   pwms = < 3 5000 0>;
+   pwms = < 3 5000 PWM_POLARITY_INVERTED>;
max-brightness = <255>;
linux,default-trigger = "nand-disk";
};
 
d7 {
label = "d7";
-   pwms = < 1 5000 0>;
+   pwms = < 1 5000 PWM_POLARITY_INVERTED>;
max-brightness = <255>;
linux,default-trigger = "mmc0";
};
-- 
1.8.3.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 0/3] ARM: at91: improve at91sam9m10g45ek support

[Alexandre Belloni]

Here are a few DT improvements for the at91sam9m10g45ek.

The first patch corrects the ADC support for the at91sam9g45.

The second patch adds ADC and touchscreen support to the at91sam9m10g45ek.

The last one corrects the PWM polarity after the polarity got right in the
driver, following patch "PWM: atmel-pwm: Fix polarity handling"


Alexandre Belloni (3):
  ARM: at91/dt: sam9g45: improve ADC/touchscreen support
  ARM: at91/dt: at91sam9m10g45ek: add ADC and touchscreen support
  ARM: at91/dt: at91sam9m10g45ek PWM leds polarity is inversed

 arch/arm/boot/dts/at91sam9g45.dtsi | 33 +++--
 arch/arm/boot/dts/at91sam9m10g45ek.dts | 20 ++--
 2 files changed, 49 insertions(+), 4 deletions(-)

-- 
1.8.3.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/3] ARM: at91/dt: sam9g45: improve ADC/touchscreen support

[Alexandre Belloni]

Fixes the compatible string, adds the pinmuxing for the ADC pins.

Also, removes atmel,adc-use-external-triggers as it is not possible to remove it
unless redefining the whole adc node

Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/at91sam9g45.dtsi | 33 +++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi 
b/arch/arm/boot/dts/at91sam9g45.dtsi
index dc4fb7d99902..b1d67282b0b6 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -136,6 +136,36 @@
  >;
 
/* shared pinctrl settings */
+   adc0 {
+   pinctrl_adc0_adtrg: adc0_adtrg {
+   atmel,pins = ;
+   };
+   pinctrl_adc0_ad0: adc0_ad0 {
+   atmel,pins = ;
+   };
+   pinctrl_adc0_ad1: adc0_ad1 {
+   atmel,pins = ;
+   };
+   pinctrl_adc0_ad2: adc0_ad2 {
+   atmel,pins = ;
+   };
+   pinctrl_adc0_ad3: adc0_ad3 {
+   atmel,pins = ;
+   };
+   pinctrl_adc0_ad4: adc0_ad4 {
+   atmel,pins = ;
+   };
+   pinctrl_adc0_ad5: adc0_ad5 {
+   atmel,pins = ;
+   };
+   pinctrl_adc0_ad6: adc0_ad6 {
+   atmel,pins = ;
+   };
+   pinctrl_adc0_ad7: adc0_ad7 {
+   atmel,pins = ;
+   };
+   };
+
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
@@ -634,10 +664,9 @@
adc0: adc@fffb {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "atmel,at91sam9260-adc";
+   compatible = "atmel,at91sam9g45-adc";
reg = <0xfffb 0x100>;
interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
-   atmel,adc-use-external-triggers;
atmel,adc-channels-used = <0xff>;
atmel,adc-vref = <3300>;
atmel,adc-startup-time = <40>;
-- 
1.8.3.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 00/12] scsi/NCR5380: fix debugging macros and #include structure

[Finn Thain]

On Tue, 18 Mar 2014, Joe Perches wrote:

> On Tue, 2014-03-18 at 13:55 +0100, Geert Uytterhoeven wrote:

> > 
> > #define dprintk(flg, fmt, ...) no_printk(fmt, ##__VA_ARGS__)
> 
> Fine, but with a correction.
> 
> no_printk keeps all side effects like performing any function calls made 
> by the statement or accessing any volatiles.
> 
> Using
> 
> do { if (0) no_printk(fmt, ##__VA_ARGS__); } while (0)
> 
> does not have any side-effects.

I take your point about having the compiler check arguments when
NDEBUG & flg == 0.

As for side-effects, chip register accesses would be affected if dprintk() 
expanded to no_printk() when NDEBUG & flg == 0.

E.g. NCR5380.c line 1213:
dprintk(NDEBUG_INTR, "scsi : unknown interrupt, BASR 0x%X, MR 0x%X, SR 0x%x\n",
 basr, NCR5380_read(MODE_REG), NCR5380_read(STATUS_REG));

I don't want to re-introduce side-effects into a dozen different NCR5380 
drivers on three different architectures when I can test only one of those 
drivers. It's difficult to get good code coverage even for one driver.

-- 
--
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: cxt1e1: hwprobe: Fix sparse warning

[Greg KH]

On Wed, Mar 19, 2014 at 12:33:19AM +0200, Matei Oprea wrote:
> This fixes the following sparse warning:
> * drivers/staging/cxt1e1/hwprobe.c:43:19: 
> warning: symbol 'hdw_info' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:47:1: 
> warning: symbol 'show_two' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:99:1: 
> warning: symbol 'hdw_sn_get' was not declared. Should it be static?
> *drivers/staging/cxt1e1/hwprobe.c:149:1: 
> warning: symbol 'prep_hdw_info' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:169:1: 
> warning: symbol 'cleanup_ioremap' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:195:1: 
> warning: symbol 'cleanup_devs' was not declared. Should it be static?
> drivers/staging/cxt1e1/hwprobe.c:293:1: 
> * warning: symbol 'c4hw_attach_all' was not declared. Should it be static?
> 
> Signed-off-by: Matei Oprea 
> Cc: ROSEdu Kernel Community 
> ---
>  drivers/staging/cxt1e1/hwprobe.c |   14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/cxt1e1/hwprobe.c 
> b/drivers/staging/cxt1e1/hwprobe.c
> index 02b4f8f..694047a 100644
> --- a/drivers/staging/cxt1e1/hwprobe.c
> +++ b/drivers/staging/cxt1e1/hwprobe.c
> @@ -40,10 +40,10 @@ voidc4_stopwd (ci_t *);
>  struct net_device * __init c4_add_dev (hdw_info_t *, int, unsigned long, 
> unsigned long, int, int);
>  
>  
> -struct s_hdw_info hdw_info[MAX_BOARDS];
> +static struct s_hdw_info hdw_info[MAX_BOARDS];
>  
>  
> -void__init
> +static void__init
>  show_two (hdw_info_t *hi, int brdno)
>  {
>  ci_t   *ci;
> @@ -95,7 +95,7 @@ show_two (hdw_info_t *hi, int brdno)


This patch doesn't apply at all, did you do it against my staging-next
branch of staging.git or linux-next?  Or did you do it against Linus's
tree?  If Linus's tree, that's quite "old" for development stuff, always
work against linux-next to avoid making the same changes others already
have in the past.

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: cxt1e1: hwprobe: Fix sparse warning

[Greg KH]

On Wed, Mar 19, 2014 at 12:33:19AM +0200, Matei Oprea wrote:
> This fixes the following sparse warning:
> * drivers/staging/cxt1e1/hwprobe.c:43:19: 
> warning: symbol 'hdw_info' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:47:1: 
> warning: symbol 'show_two' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:99:1: 
> warning: symbol 'hdw_sn_get' was not declared. Should it be static?
> *drivers/staging/cxt1e1/hwprobe.c:149:1: 
> warning: symbol 'prep_hdw_info' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:169:1: 
> warning: symbol 'cleanup_ioremap' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:195:1: 
> warning: symbol 'cleanup_devs' was not declared. Should it be static?
> drivers/staging/cxt1e1/hwprobe.c:293:1: 
> * warning: symbol 'c4hw_attach_all' was not declared. Should it be static?

Please don't line-wrap sparse or compiler warnings, it just looks messy.
--
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: [BUG -next] "mm: per-thread vma caching fix 5" breaks s390

[Andrew Morton]

On Tue, 18 Mar 2014 16:06:59 -0700 Tony Luck  wrote:

> On Tue, Mar 18, 2014 at 5:41 AM, Heiko Carstens
>  wrote:
> > Given that this is just an addon patch to Davidlohr's "mm: per-thread
> > vma caching" patch I was wondering if something in there is architecture
> > specific.
> > But it doesn't look like that. So I'm wondering if this only breaks on
> > s390?
> 
> I'm seeing this same BUG_ON() on ia64 (when trying out next-20140318)

-next is missing
http://ozlabs.org/~akpm/mmots/broken-out/mm-per-thread-vma-caching-fix-6.patch.
Am presently trying to cook up an mmotm for tomorrow's -next.  
--
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: cxt1e1: hwprobe: Fix sparse warning

[Greg KH]

On Wed, Mar 19, 2014 at 12:33:19AM +0200, Matei Oprea wrote:
> This fixes the following sparse warning:
> * drivers/staging/cxt1e1/hwprobe.c:43:19: 
> warning: symbol 'hdw_info' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:47:1: 
> warning: symbol 'show_two' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:99:1: 
> warning: symbol 'hdw_sn_get' was not declared. Should it be static?
> *drivers/staging/cxt1e1/hwprobe.c:149:1: 
> warning: symbol 'prep_hdw_info' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:169:1: 
> warning: symbol 'cleanup_ioremap' was not declared. Should it be static?
> * drivers/staging/cxt1e1/hwprobe.c:195:1: 
> warning: symbol 'cleanup_devs' was not declared. Should it be static?
> drivers/staging/cxt1e1/hwprobe.c:293:1: 
> * warning: symbol 'c4hw_attach_all' was not declared. Should it be static?
> 
> Signed-off-by: Matei Oprea 
> Cc: ROSEdu Kernel Community 

Why the cc: for a non-maintainer / person?

curious,

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] leds: pwm: set polarity on non DT platforms

[Alexandre Belloni]

On 18/03/2014 at 16:02:51 -0700, Bryan Wu wrote :
> On Mon, Mar 17, 2014 at 11:38 AM, Alexandre Belloni
>  wrote:
> > Set inversed polarity when .active_low is set in the platform_data. With 
> > device
> > tree, this is taken care of by of_pwm_xlate_with_flags(), called from
> > of_pwm_get().
> >
> > Signed-off-by: Alexandre Belloni 
> > ---
> >  drivers/leds/leds-pwm.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> > index 605047428b5a..09681556a6aa 100644
> > --- a/drivers/leds/leds-pwm.c
> > +++ b/drivers/leds/leds-pwm.c
> > @@ -180,6 +180,11 @@ static int led_pwm_probe(struct platform_device *pdev)
> > led_dat->cdev.max_brightness = 
> > cur_led->max_brightness;
> > led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
> >
> > +   if (led_dat->active_low)
> 
> Why .active_low needs to inverse PWM polarity? In
> of_pwm_xlate_with_flags(), it checked with PWM_POLARITY_INVERSED in
> args. Moreover in of_pwm_simple_xlate() and pxa_pwm_of_xlate(), we
> didn't inverse PWM polarity at all.
> 

Yeah, exactly, there is no issue when using device tree. What I'm trying
to fix here is th non-DT case where of_pwm_xlate_with_flags() is not
called.

> Add Thierry to review this.
> 

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

Re: [PATCH] staging: slicoss: Fix prefer ether_addr_copy over memcpy

[Joel Pelaez Jorge]

El 17/03/14 23:49, Jingoo Han escribió:

On Tuesday, March 18, 2014 2:04 PM, Joel Pelaez Jorge wrote:



@@ -810,8 +810,8 @@ static int slic_mac_set_address(struct net_device
*dev, void *ptr)
if (!is_valid_ether_addr(addr->sa_data))
return -EINVAL;

-   memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
-   memcpy(adapter->currmacaddr, addr->sa_data, dev->addr_len);
+   ether_addr_copy(dev->dev_addr, addr->sa_data);
+   ether_addr_copy(adapter->currmacaddr, addr->sa_data);


By the way, I am wondering if 'dev->addr_len' is 6 bytes.
Is there anyone who can confirm it?

If nobody can confirm 'dev->addr_len' is 6 bytes, it should
not be changed to 'ether_addr_copy()'.

Best regards,
Jingoo Han

In the first case, is necessary use memcpy for copy te ethernet address 
to dev->dev_addr because this is a pointer, uses dev->addr_len for 
define size.


But in the second, adapter->currmacaddr is fixed to 6 size, so that here 
one can use ether_addr_copy without issues.


--
Best regards,
Joel Pelaez Jorge
Joel Pelaez Jorge


--
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: [BUG -next] "mm: per-thread vma caching fix 5" breaks s390

[Tony Luck]

On Tue, Mar 18, 2014 at 5:41 AM, Heiko Carstens
 wrote:
> Given that this is just an addon patch to Davidlohr's "mm: per-thread
> vma caching" patch I was wondering if something in there is architecture
> specific.
> But it doesn't look like that. So I'm wondering if this only breaks on
> s390?

I'm seeing this same BUG_ON() on ia64 (when trying out next-20140318)

Starting HAkernel BUG at mm/vmacache.c:76!
L daemon7[?25lps[3259]: bugcheck! 0 [1]
Modules linked in: mptctl

CPU: 0 PID: 3259 Comm: ps Not tainted 3.14.0-rc7-zx1-smp-next-20140318 #1
Hardware name: hp server rx2620   , BIOS 03.17
   03/31/2005
task: e107 ti: e1070c80 task.ti: e1070c80
psr : 101008526038 ifs : 8309 ip  :
[]Not tainted (3.14.0-rc7-zx1-smp-next-20140318)
ip is at vmacache_find+0x1d0/0x1e0
unat:  pfs : 0309 rsc : 0003
rnat: 0009804c0270033f bsps: a0010153e470 pr  : 19a99565
ldrs:  ccv : 0010e0bb89b1 fpsr: 0009804c0270033f
csd :  ssd : 
b0  : a0010019a930 b6  : a001006cff20 b7  : a001006d1a40
f6  : 1003e00167080aa40 f7  : 1003e0514
f8  : 1003e00167080a52c f9  : 1003e0001
f10 : 1003e501ac672552bd930 f11 : 1003e0004
r1  : a0010176aa00 r2  : a0010153e468 r3  : a0010156b5e0
r8  : 001f r9  : 1b14 r10 : 
r11 :  r12 : e1077df0 r13 : e107
r14 : a0010153e470 r15 : a0010153e470 r16 : 1b140d8a
r17 :  r18 : 7fff r19 : 0182
r20 : 0003 r21 :  r22 : 0182
r23 : a0010130a9a8 r24 : a001006cff20 r25 : a0010130a9a8
r26 : a001006cff20 r27 : a00101544658 r28 : a001015e2508
r29 : a0010130a998 r30 : a001006cfec0 r31 : a001015e23e0

Call Trace:
 [] show_stack+0x80/0xa0
sp=e10779b0 bsp=e10712e0
 [] show_regs+0x640/0x920
sp=e1077b80 bsp=e1071288
 [] die+0x1a0/0x2e0
sp=e1077b90 bsp=e1071248
 [] die_if_kernel+0x50/0x80
sp=e1077b90 bsp=e1071218
 [] ia64_bad_break+0x3d0/0x6e0
sp=e1077b90 bsp=e10711e8
 [] ia64_native_leave_kernel+0x0/0x270
sp=e1077c20 bsp=e10711e8
 [] vmacache_find+0x1d0/0x1e0
sp=e1077df0 bsp=e10711a0
 [] find_vma+0x30/0x140
sp=e1077df0 bsp=e1071170
 [] find_extend_vma+0x30/0x140
sp=e1077df0 bsp=e1071138
 [] __get_user_pages+0x120/0xd60
sp=e1077df0 bsp=e1071010
 [] get_user_pages+0x70/0xa0
sp=e1077e10 bsp=e1070fb0
 [] __access_remote_vm+0xb0/0x360
sp=e1077e10 bsp=e1070f18
 [] access_process_vm+0x60/0xa0
sp=e1077e20 bsp=e1070ed0
 [] get_cmdline+0xb0/0x240
sp=e1077e20 bsp=e1070e88
 [] proc_pid_cmdline+0x30/0x60
sp=e1077e20 bsp=e1070e60
 [] proc_info_read+0x120/0x200
sp=e1077e20 bsp=e1070e10
 [] vfs_read+0x140/0x340
sp=e1077e20 bsp=e1070dc0
 [] SyS_read+0xa0/0x120
sp=e1077e20 bsp=e1070d40
 [] ia64_ret_from_syscall+0x0/0x20
sp=e1077e30 bsp=e1070d40
 [] ia64_ivt+0x00040720/0x400
sp=e1078000 bsp=e1070d40
Disabling lock debugging due to kernel taint
--
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] staging/xillybus: Handle OOM in xillybus_init()

[Richard Weinberger]

alloc_workqueue() can fail and returns NULL in case of
OOM.
Handle this case and undo class_create().

Signed-off-by: Richard Weinberger 
---
 drivers/staging/xillybus/xillybus_core.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/xillybus/xillybus_core.c 
b/drivers/staging/xillybus/xillybus_core.c
index 2ebaf16..b0a6696 100644
--- a/drivers/staging/xillybus/xillybus_core.c
+++ b/drivers/staging/xillybus/xillybus_core.c
@@ -2318,8 +2318,12 @@ static int __init xillybus_init(void)
}
 
xillybus_wq = alloc_workqueue(xillyname, 0, 0);
+   if (!xillybus_wq) {
+   class_destroy(xillybus_class);
+   rc = -ENOMEM;
+   }
 
-   return 0; /* Success */
+   return rc;
 }
 
 static void __exit xillybus_exit(void)
-- 
1.8.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] leds: pwm: set polarity on non DT platforms

[Bryan Wu]

On Mon, Mar 17, 2014 at 11:38 AM, Alexandre Belloni
 wrote:
> Set inversed polarity when .active_low is set in the platform_data. With 
> device
> tree, this is taken care of by of_pwm_xlate_with_flags(), called from
> of_pwm_get().
>
> Signed-off-by: Alexandre Belloni 
> ---
>  drivers/leds/leds-pwm.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index 605047428b5a..09681556a6aa 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -180,6 +180,11 @@ static int led_pwm_probe(struct platform_device *pdev)
> led_dat->cdev.max_brightness = 
> cur_led->max_brightness;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>
> +   if (led_dat->active_low)

Why .active_low needs to inverse PWM polarity? In
of_pwm_xlate_with_flags(), it checked with PWM_POLARITY_INVERSED in
args. Moreover in of_pwm_simple_xlate() and pxa_pwm_of_xlate(), we
didn't inverse PWM polarity at all.

Add Thierry to review this.

Thanks,
-Bryan

> +   if (pwm_set_polarity(led_dat->pwm,
> +PWM_POLARITY_INVERSED))
> +   dev_err(>dev, "impossible to 
> change polarity");
> +
> led_dat->can_sleep = pwm_can_sleep(led_dat->pwm);
> if (led_dat->can_sleep)
> INIT_WORK(_dat->work, led_pwm_work);
> --
> 1.8.3.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: [RFC PATCH 1/2] ACPICA: Dispatcher: Ignore SyncLevel for auto-serialization mechanism.

[Sabrina Dubroca]

Hi,

2014-03-18, 00:50:04 +, Zheng, Lv wrote:
> Hi, Sabrina and Valdis
> 
> Could you give this patch a try to see if this patch is working?
> 
> Thanks and best regards
> -Lv

I applied the two patches. The laptop boots and there is no ACPI
error in the logs, both with auto-serialization enabled and disabled.

Thanks,

-- 
Sabrina
--
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 9/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)

[Monam Agarwal]

Signed-off-by: Monam Agarwal 
---
 drivers/vhost/test.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index fc9a1d7..82b3744 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -128,7 +128,7 @@ static void *vhost_test_stop_vq(struct vhost_test *n,
mutex_lock(>mutex);
private = rcu_dereference_protected(vq->private_data,
 lockdep_is_held(>mutex));
-   rcu_assign_pointer(vq->private_data, NULL);
+   RCU_INIT_POINTER(vq->private_data, NULL);
mutex_unlock(>mutex);
return private;
 }
-- 
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 8/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)

[Monam Agarwal]

Signed-off-by: Monam Agarwal 
---
 drivers/vhost/net.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 882a51f..b243e06 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -556,7 +556,7 @@ static struct socket *vhost_net_stop_vq(struct vhost_net *n,
sock = rcu_dereference_protected(vq->private_data,
 lockdep_is_held(>mutex));
vhost_net_disable_vq(n, vq);
-   rcu_assign_pointer(vq->private_data, NULL);
+   RCU_INIT_POINTER(vq->private_data, NULL);
mutex_unlock(>mutex);
return sock;
 }
-- 
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 7/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)

[Monam Agarwal]

Signed-off-by: Monam Agarwal 
---
 drivers/target/tcm_fc/tfc_sess.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/target/tcm_fc/tfc_sess.c b/drivers/target/tcm_fc/tfc_sess.c
index 3269213..95fb826 100644
--- a/drivers/target/tcm_fc/tfc_sess.c
+++ b/drivers/target/tcm_fc/tfc_sess.c
@@ -110,7 +110,7 @@ static void ft_tport_delete(struct ft_tport *tport)
ft_sess_delete_all(tport);
lport = tport->lport;
BUG_ON(tport != lport->prov[FC_TYPE_FCP]);
-   rcu_assign_pointer(lport->prov[FC_TYPE_FCP], NULL);
+   RCU_INIT_POINTER(lport->prov[FC_TYPE_FCP], NULL);
 
tpg = tport->tpg;
if (tpg) {
-- 
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 6/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)

[Monam Agarwal]

Signed-off-by: Monam Agarwal 
---
 drivers/scsi/libfc/fc_libfc.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/libfc/fc_libfc.c b/drivers/scsi/libfc/fc_libfc.c
index b773512..ee74eec 100644
--- a/drivers/scsi/libfc/fc_libfc.c
+++ b/drivers/scsi/libfc/fc_libfc.c
@@ -297,9 +297,9 @@ void fc_fc4_deregister_provider(enum fc_fh_type type, 
struct fc4_prov *prov)
BUG_ON(type >= FC_FC4_PROV_SIZE);
mutex_lock(_prov_mutex);
if (prov->recv)
-   rcu_assign_pointer(fc_passive_prov[type], NULL);
+   RCU_INIT_POINTER(fc_passive_prov[type], NULL);
else
-   rcu_assign_pointer(fc_active_prov[type], NULL);
+   RCU_INIT_POINTER(fc_active_prov[type], NULL);
mutex_unlock(_prov_mutex);
synchronize_rcu();
 }
-- 
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 5/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)

[Monam Agarwal]

Signed-off-by: Monam Agarwal 
---
 drivers/net/wireless/ath/carl9170/main.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/carl9170/main.c 
b/drivers/net/wireless/ath/carl9170/main.c
index f06e069..5518592 100644
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -446,7 +446,7 @@ static void carl9170_op_stop(struct ieee80211_hw *hw)
 
mutex_lock(>mutex);
if (IS_ACCEPTING_CMD(ar)) {
-   rcu_assign_pointer(ar->beacon_iter, NULL);
+   RCU_INIT_POINTER(ar->beacon_iter, NULL);
 
carl9170_led_set_state(ar, 0);
 
@@ -678,7 +678,7 @@ unlock:
vif_priv->active = false;
bitmap_release_region(>vif_bitmap, vif_id, 0);
ar->vifs--;
-   rcu_assign_pointer(ar->vif_priv[vif_id].vif, NULL);
+   RCU_INIT_POINTER(ar->vif_priv[vif_id].vif, NULL);
list_del_rcu(_priv->list);
mutex_unlock(>mutex);
synchronize_rcu();
@@ -716,7 +716,7 @@ static void carl9170_op_remove_interface(struct 
ieee80211_hw *hw,
WARN_ON(vif_priv->enable_beacon);
vif_priv->enable_beacon = false;
list_del_rcu(_priv->list);
-   rcu_assign_pointer(ar->vif_priv[id].vif, NULL);
+   RCU_INIT_POINTER(ar->vif_priv[id].vif, NULL);
 
if (vif == main_vif) {
rcu_read_unlock();
@@ -1258,7 +1258,7 @@ static int carl9170_op_sta_add(struct ieee80211_hw *hw,
}
 
for (i = 0; i < CARL9170_NUM_TID; i++)
-   rcu_assign_pointer(sta_info->agg[i], NULL);
+   RCU_INIT_POINTER(sta_info->agg[i], NULL);
 
sta_info->ampdu_max_len = 1 << (3 + sta->ht_cap.ampdu_factor);
sta_info->ht_sta = true;
@@ -1285,7 +1285,7 @@ static int carl9170_op_sta_remove(struct ieee80211_hw *hw,
struct carl9170_sta_tid *tid_info;
 
tid_info = rcu_dereference(sta_info->agg[i]);
-   rcu_assign_pointer(sta_info->agg[i], NULL);
+   RCU_INIT_POINTER(sta_info->agg[i], NULL);
 
if (!tid_info)
continue;
@@ -1398,7 +1398,7 @@ static int carl9170_op_ampdu_action(struct ieee80211_hw 
*hw,
spin_unlock_bh(>tx_ampdu_list_lock);
}
 
-   rcu_assign_pointer(sta_info->agg[tid], NULL);
+   RCU_INIT_POINTER(sta_info->agg[tid], NULL);
rcu_read_unlock();
 
ieee80211_stop_tx_ba_cb_irqsafe(vif, sta->addr, tid);
-- 
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 4/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)

[Monam Agarwal]

Signed-off-by: Monam Agarwal 
---
 drivers/net/ppp/pptp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
index 89f829f..ede899c 100644
--- a/drivers/net/ppp/pptp.c
+++ b/drivers/net/ppp/pptp.c
@@ -162,7 +162,7 @@ static void del_chan(struct pppox_sock *sock)
 {
spin_lock(_lock);
clear_bit(sock->proto.pptp.src_addr.call_id, callid_bitmap);
-   rcu_assign_pointer(callid_sock[sock->proto.pptp.src_addr.call_id], 
NULL);
+   RCU_INIT_POINTER(callid_sock[sock->proto.pptp.src_addr.call_id], NULL);
spin_unlock(_lock);
synchronize_rcu();
 }
-- 
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 3/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) in drivers/net/macvtap.c

[Monam Agarwal]

Signed-off-by: Monam Agarwal 
---
 drivers/net/macvtap.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 1b7082d..7c88d13 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -145,8 +145,8 @@ static void macvtap_put_queue(struct macvtap_queue *q)
if (vlan) {
int index = get_slot(vlan, q);
 
-   rcu_assign_pointer(vlan->taps[index], NULL);
-   rcu_assign_pointer(q->vlan, NULL);
+   RCU_INIT_POINTER(vlan->taps[index], NULL);
+   RCU_INIT_POINTER(q->vlan, NULL);
sock_put(>sk);
--vlan->numvtaps;
}
@@ -223,8 +223,8 @@ static void macvtap_del_queues(struct net_device *dev)
  lockdep_is_held(_lock));
if (q) {
qlist[j++] = q;
-   rcu_assign_pointer(vlan->taps[i], NULL);
-   rcu_assign_pointer(q->vlan, NULL);
+   RCU_INIT_POINTER(vlan->taps[i], NULL);
+   RCU_INIT_POINTER(q->vlan, NULL);
vlan->numvtaps--;
}
}
-- 
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 2/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) in drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c

[Monam Agarwal]

Signed-off-by: Monam Agarwal 
---
 drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c 
b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
index da5a5d9..a7ec886 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
@@ -1300,7 +1300,7 @@ int cxgb3_offload_activate(struct adapter *adapter)
 
 out_free_l2t:
t3_free_l2t(L2DATA(dev));
-   rcu_assign_pointer(dev->l2opt, NULL);
+   RCU_INIT_POINTER(dev->l2opt, NULL);
 out_free:
kfree(t);
return err;
@@ -1328,7 +1328,7 @@ void cxgb3_offload_deactivate(struct adapter *adapter)
rcu_read_lock();
d = L2DATA(tdev);
rcu_read_unlock();
-   rcu_assign_pointer(tdev->l2opt, NULL);
+   RCU_INIT_POINTER(tdev->l2opt, NULL);
call_rcu(>rcu_head, clean_l2_data);
if (t->nofail_skb)
kfree_skb(t->nofail_skb);
-- 
1.7.9.5

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

Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

[Scott Wood]

On Mon, 2014-03-17 at 19:19 +0800, Chenhui Zhao wrote:
> On Fri, Mar 14, 2014 at 06:18:27PM -0500, Scott Wood wrote:
> > On Wed, 2014-03-12 at 18:40 +0800, Chenhui Zhao wrote:
> > > On Tue, Mar 11, 2014 at 08:10:24PM -0500, Scott Wood wrote:
> > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > From: Zhao Chenhui 
> > > > > 
> > > > > T1040 supports deep sleep feature, which can switch off most parts of
> > > > > the SoC when it is in deep sleep mode. This way, it becomes more
> > > > > energy-efficient.
> > > > > 
> > > > > The DDR controller will also be powered off in deep sleep. Therefore,
> > > > > the last stage (the latter part of fsl_dp_enter_low) will run without 
> > > > > DDR
> > > > > access. This piece of code and related TLBs will be prefetched.
> > > > > 
> > > > > Due to the different initialization code between 32-bit and 64-bit, 
> > > > > they
> > > > > have seperate resume entry and precedure.
> > > > > 
> > > > > The feature supports 32-bit and 64-bit kernel mode.
> > > > > 
> > > > > Signed-off-by: Zhao Chenhui 
> > > > > ---
> > > > >  arch/powerpc/include/asm/booke_save_regs.h |3 +
> > > > >  arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   17 ++
> > > > >  arch/powerpc/kernel/head_fsl_booke.S   |   30 +++
> > > > >  arch/powerpc/platforms/85xx/Makefile   |2 +-
> > > > >  arch/powerpc/platforms/85xx/deepsleep.c|  201 +++
> > > > >  arch/powerpc/platforms/85xx/qoriq_pm.c |   38 
> > > > >  arch/powerpc/platforms/85xx/sleep.S|  295 
> > > > > 
> > > > >  arch/powerpc/sysdev/fsl_soc.h  |7 +
> > > > >  8 files changed, 592 insertions(+), 1 deletions(-)
> > > > >  create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c
> > > > >  create mode 100644 arch/powerpc/platforms/85xx/sleep.S
> > > > > 
> > > > > diff --git a/arch/powerpc/include/asm/booke_save_regs.h 
> > > > > b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > index 87c357a..37c1f6c 100644
> > > > > --- a/arch/powerpc/include/asm/booke_save_regs.h
> > > > > +++ b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > @@ -88,6 +88,9 @@
> > > > >  #define HIBERNATION_FLAG 1
> > > > >  #define DEEPSLEEP_FLAG   2
> > > > >  
> > > > > +#define CPLD_FLAG1
> > > > > +#define FPGA_FLAG2
> > > > 
> > > > What is this?
> > > 
> > > We have two kind of boards, QDS and RDB.
> > > They have different register map. Use the flag to indicate the current 
> > > board is using which kind
> > > of register map.
> > 
> > CPLD versus FPGA is not a meaningful difference.  We don't care what
> > technology is used to implement programmable logic -- we care what
> > programming interface is exposed.  Customers will have their own boards
> > that will likely not imitate either of these programming interfaces, but
> > what they do have will still probably be implemented in a CPLD or FPGA.
> > Likewise, Freescale may have future reference boards whose CPLD/FPGA is
> > not compatible.
> 
> Will use a better name.
> 
> > 
> > So use better naming, and structure the code so it's easy to plug in
> > implementations for new or custom boards.
> >  
> > > > > diff --git a/arch/powerpc/kernel/head_fsl_booke.S 
> > > > > b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > index 20204fe..3285752 100644
> > > > > --- a/arch/powerpc/kernel/head_fsl_booke.S
> > > > > +++ b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > @@ -162,6 +162,19 @@ _ENTRY(__early_start)
> > > > >  #include "fsl_booke_entry_mapping.S"
> > > > >  #undef ENTRY_MAPPING_BOOT_SETUP
> > > > >  
> > > > > +#if defined(CONFIG_SUSPEND) && defined(CONFIG_FSL_CORENET_RCPM)
> > > > > + /* if deep_sleep_flag != 0, jump to the deep sleep resume entry 
> > > > > */
> > > > > + LOAD_REG_ADDR(r4, deep_sleep_flag)
> > > > > + lwz r3, 0(r4)
> > > > > + cmpwi   r3, 0
> > > > > + beq 11f
> > > > > + /* clear deep_sleep_flag */
> > > > > + li  r3, 0
> > > > > + stw r3, 0(r4)
> > > > > + b   fsl_deepsleep_resume
> > > > > +11:
> > > > > +#endif
> > > > 
> > > > Why do you come in via the normal kernel entry, versus specifying a
> > > > direct entry point for deep sleep resume?  How does U-Boot even know
> > > > what the normal entry is when resuming?
> > > 
> > > I wish to return to a specified point (like 64-bit mode), but the code in
> > > fsl_booke_entry_mapping.S only can run in the first page. Because it
> > > only setups a temp mapping of 4KB.
> > 
> > Why do you need the entry mapping on 32-bit but not 64-bit?
> 
> fsl_booke_entry_mapping.S is for 32-bit. 64-bit calls
> initial_tlb_book3e() in exceptions-64e.S.

The answer I was looking for is that __entry_deep_sleep calls
start_initialization_book3e which calls the code to handle it.

But why is it driven from sleep.S on 64-bit but not on 32-bit?  Why
can't you make it so that the 32-bit TLB setup can be called into in a
similar manner?

> > > > > +#define 

[PATCH 1/9] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) in drivers/net/ethernet/broadcom/bnx2.c

[Monam Agarwal]

Signed-off-by: Monam Agarwal 
---
 drivers/net/ethernet/broadcom/bnx2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2.c 
b/drivers/net/ethernet/broadcom/bnx2.c
index 965c723..5eab730 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -409,7 +409,7 @@ static int bnx2_unregister_cnic(struct net_device *dev)
mutex_lock(>cnic_lock);
cp->drv_state = 0;
bnapi->cnic_present = 0;
-   rcu_assign_pointer(bp->cnic_ops, NULL);
+   RCU_INIT_POINTER(bp->cnic_ops, NULL);
mutex_unlock(>cnic_lock);
synchronize_rcu();
return 0;
-- 
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 0/9] Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,NULL)

[Monam Agarwal]

This patchset uses following coccinelle script to replace 
rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,NULL)

@@
expression E;
@@
- rcu_assign_pointer(
+ RCU_INIT_POINTER(
E, NULL)

Monam Agarwal (9):
  rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
NULL) in drivers/net/ethernet/broadcom/bnx2.c
  rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
NULL) in drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
  rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
NULL) in drivers/net/macvtap.c
  rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
NULL)
  rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
NULL)
  rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
NULL)
  rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
NULL)
  rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
NULL)
  rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
NULL)

 drivers/net/ethernet/broadcom/bnx2.c   |2 +-
 drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c |4 ++--
 drivers/net/macvtap.c  |8 
 drivers/net/ppp/pptp.c |2 +-
 drivers/net/wireless/ath/carl9170/main.c   |   12 ++--
 drivers/scsi/libfc/fc_libfc.c  |4 ++--
 drivers/target/tcm_fc/tfc_sess.c   |2 +-
 drivers/vhost/net.c|2 +-
 drivers/vhost/test.c   |2 +-
 9 files changed, 19 insertions(+), 19 deletions(-)

-- 
1.7.9.5

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

Re: [PATCH v3 1/4] mfd: max8997: use regmap to access registers

[Bryan Wu]

On Thu, Mar 13, 2014 at 2:38 AM, Robert Baldyga  wrote:
> This patch modifies max8997 driver and each associated function driver,
> to use regmap instead of operating directly on i2c bus. It will allow to
> simplify IRQ handling using regmap-irq.
>
> Signed-off-by: Robert Baldyga 
> Reviewed-by: Krzysztof Kozlowski 
> ---
>  drivers/extcon/extcon-max8997.c |   31 
>  drivers/input/misc/max8997_haptic.c |   34 +
>  drivers/leds/leds-max8997.c |   13 ++--
>  drivers/mfd/Kconfig |1 +
>  drivers/mfd/max8997-irq.c   |   64 +++-
>  drivers/mfd/max8997.c   |  141 
> ---
>  drivers/power/max8997_charger.c |   33 
>  drivers/regulator/max8997.c |   87 +++--
>  drivers/rtc/rtc-max8997.c   |   56 +++---
>  include/linux/mfd/max8997-private.h |   17 ++---
>  10 files changed, 228 insertions(+), 249 deletions(-)
>
> diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
> index 6a00464..f258c08 100644
> --- a/drivers/extcon/extcon-max8997.c
> +++ b/drivers/extcon/extcon-max8997.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #defineDEV_NAME"max8997-muic"
>  #defineDELAY_MS_DEFAULT2   /* unit: 
> millisecond */
> @@ -116,7 +117,7 @@ enum max8997_muic_charger_type {
>
>  struct max8997_muic_info {
> struct device *dev;
> -   struct i2c_client *muic;
> +   struct max8997_dev *max8997;
> struct extcon_dev *edev;
> int prev_cable_type;
> int prev_chg_type;
> @@ -190,10 +191,10 @@ static int max8997_muic_set_debounce_time(struct 
> max8997_muic_info *info,
> case ADC_DEBOUNCE_TIME_10MS:
> case ADC_DEBOUNCE_TIME_25MS:
> case ADC_DEBOUNCE_TIME_38_62MS:
> -   ret = max8997_update_reg(info->muic,
> +   ret = regmap_update_bits(info->max8997->regmap_muic,
>   MAX8997_MUIC_REG_CONTROL3,
> - time << CONTROL3_ADCDBSET_SHIFT,
> - CONTROL3_ADCDBSET_MASK);
> + CONTROL3_ADCDBSET_MASK,
> + time << CONTROL3_ADCDBSET_SHIFT);
> if (ret) {
> dev_err(info->dev, "failed to set ADC debounce 
> time\n");
> return ret;
> @@ -228,8 +229,8 @@ static int max8997_muic_set_path(struct max8997_muic_info 
> *info,
> else
> ctrl1 = CONTROL1_SW_OPEN;
>
> -   ret = max8997_update_reg(info->muic,
> -   MAX8997_MUIC_REG_CONTROL1, ctrl1, COMP_SW_MASK);
> +   ret = regmap_update_bits(info->max8997->regmap_muic,
> +   MAX8997_MUIC_REG_CONTROL1, COMP_SW_MASK, ctrl1);
> if (ret < 0) {
> dev_err(info->dev, "failed to update MUIC register\n");
> return ret;
> @@ -240,9 +241,9 @@ static int max8997_muic_set_path(struct max8997_muic_info 
> *info,
> else
> ctrl2 |= CONTROL2_LOWPWR_MASK;  /* LowPwr=1, CPEn=0 */
>
> -   ret = max8997_update_reg(info->muic,
> -   MAX8997_MUIC_REG_CONTROL2, ctrl2,
> -   CONTROL2_LOWPWR_MASK | CONTROL2_CPEN_MASK);
> +   ret = regmap_update_bits(info->max8997->regmap_muic,
> +   MAX8997_MUIC_REG_CONTROL2,
> +   CONTROL2_LOWPWR_MASK | CONTROL2_CPEN_MASK, ctrl2);
> if (ret < 0) {
> dev_err(info->dev, "failed to update MUIC register\n");
> return ret;
> @@ -543,8 +544,8 @@ static void max8997_muic_irq_work(struct work_struct 
> *work)
> if (info->irq == muic_irqs[i].virq)
> irq_type = muic_irqs[i].irq;
>
> -   ret = max8997_bulk_read(info->muic, MAX8997_MUIC_REG_STATUS1,
> -   2, info->status);
> +   ret = regmap_bulk_read(info->max8997->regmap_muic,
> +   MAX8997_MUIC_REG_STATUS1, info->status, 2);
> if (ret) {
> dev_err(info->dev, "failed to read muic register\n");
> mutex_unlock(>mutex);
> @@ -605,8 +606,8 @@ static int max8997_muic_detect_dev(struct 
> max8997_muic_info *info)
> mutex_lock(>mutex);
>
> /* Read STATUSx register to detect accessory */
> -   ret = max8997_bulk_read(info->muic,
> -   MAX8997_MUIC_REG_STATUS1, 2, info->status);
> +   ret = regmap_bulk_read(info->max8997->regmap_muic,
> +   MAX8997_MUIC_REG_STATUS1, info->status, 2);
> if (ret) {
> dev_err(info->dev, "failed to read MUIC register\n");
> mutex_unlock(>mutex);
> @@ -667,7 +668,7 @@ static int max8997_muic_probe(struct platform_device 

[PATCH] staging: cxt1e1: hwprobe: Fix sparse warning

[Matei Oprea]

This fixes the following sparse warning:
* drivers/staging/cxt1e1/hwprobe.c:43:19: 
warning: symbol 'hdw_info' was not declared. Should it be static?
* drivers/staging/cxt1e1/hwprobe.c:47:1: 
warning: symbol 'show_two' was not declared. Should it be static?
* drivers/staging/cxt1e1/hwprobe.c:99:1: 
warning: symbol 'hdw_sn_get' was not declared. Should it be static?
*drivers/staging/cxt1e1/hwprobe.c:149:1: 
warning: symbol 'prep_hdw_info' was not declared. Should it be static?
* drivers/staging/cxt1e1/hwprobe.c:169:1: 
warning: symbol 'cleanup_ioremap' was not declared. Should it be static?
* drivers/staging/cxt1e1/hwprobe.c:195:1: 
warning: symbol 'cleanup_devs' was not declared. Should it be static?
drivers/staging/cxt1e1/hwprobe.c:293:1: 
* warning: symbol 'c4hw_attach_all' was not declared. Should it be static?

Signed-off-by: Matei Oprea 
Cc: ROSEdu Kernel Community 
---
 drivers/staging/cxt1e1/hwprobe.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/cxt1e1/hwprobe.c b/drivers/staging/cxt1e1/hwprobe.c
index 02b4f8f..694047a 100644
--- a/drivers/staging/cxt1e1/hwprobe.c
+++ b/drivers/staging/cxt1e1/hwprobe.c
@@ -40,10 +40,10 @@ voidc4_stopwd (ci_t *);
 struct net_device * __init c4_add_dev (hdw_info_t *, int, unsigned long, 
unsigned long, int, int);
 
 
-struct s_hdw_info hdw_info[MAX_BOARDS];
+static struct s_hdw_info hdw_info[MAX_BOARDS];
 
 
-void__init
+static void__init
 show_two (hdw_info_t *hi, int brdno)
 {
 ci_t   *ci;
@@ -95,7 +95,7 @@ show_two (hdw_info_t *hi, int brdno)
 }
 
 
-void__init
+static void__init
 hdw_sn_get (hdw_info_t *hi, int brdno)
 {
 /* obtain hardware EEPROM information */
@@ -145,7 +145,7 @@ hdw_sn_get (hdw_info_t *hi, int brdno)
 }
 
 
-void__init
+static void__init
 prep_hdw_info (void)
 {
 hdw_info_t *hi;
@@ -165,7 +165,7 @@ prep_hdw_info (void)
 }
 }
 
-void
+static void
 cleanup_ioremap (void)
 {
 hdw_info_t *hi;
@@ -191,7 +191,7 @@ cleanup_ioremap (void)
 }
 
 
-void
+static void
 cleanup_devs (void)
 {
 hdw_info_t *hi;
@@ -289,7 +289,7 @@ c4_hdw_init (struct pci_dev *pdev, int found)
 }
 
 
-status_t__init
+static status_t__init
 c4hw_attach_all (void)
 {
 hdw_info_t *hi;
-- 
1.7.9.5

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

Re: [PATCH] mfd: mc13xxx: Move definitions out of structures

[Bryan Wu]

On Tue, Mar 18, 2014 at 2:40 AM, Lee Jones  wrote:
>> > > > > Signed-off-by: Alexander Shiyan 
>> > > > > ---
>> > > > >  include/linux/mfd/mc13xxx.h | 22 --
>> > > > >  1 file changed, 12 insertions(+), 10 deletions(-)
>> > > > >
>> > > > > diff --git a/include/linux/mfd/mc13xxx.h 
>> > > > > b/include/linux/mfd/mc13xxx.h
>> > > > > index a326c85..d63b1d3 100644
>> > > > > --- a/include/linux/mfd/mc13xxx.h
>> > > > > +++ b/include/linux/mfd/mc13xxx.h
>> > > > > @@ -117,10 +117,6 @@ struct mc13xxx_led_platform_data {
>> > > > >
>> > > > >  #define MAX_LED_CONTROL_REGS 6
>> > > > >
>> > > > > -struct mc13xxx_leds_platform_data {
>> > > > > - struct mc13xxx_led_platform_data *led;
>> > > > > - int num_leds;
>> > > > > -
>> > > > >  /* MC13783 LED Control 0 */
>> > > > >  #define MC13783_LED_C0_ENABLE(1 << 0)
>> > > > >  #define MC13783_LED_C0_TRIODE_MD (1 << 7)
>> > > > > @@ -169,10 +165,13 @@ struct mc13xxx_leds_platform_data {
>> > > > >  /* MC34708 LED Control 0 */
>> > > >
>> > > > I don't see the line above in the MFD tree?
>> > > >
>> > > > Which commit/branch/repo is this patch based on?
>> > >
>> > > Dependency:
>> > > linux-next, a59ce6584d (leds: leds-mc13783: Add MC34708 LED support)
>> > >
>> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/include/linux/mfd/mc13xxx.h?id=a59ce6584d566847980f9dcad5343cd9856145c8
>> >
>> > Ah, you can't do that, as it will cause conflicts and Linus will
>> > likely get upset.
>>
>> So what do we do now? What is the solution?
>
> Don't worry about it. Bryan and I should be able to sort something out.

I lost the context here.

I merged Alexander's patch as a59ce6584d566847980f9dcad5343cd9856145c8
which modified the mc13xxx.h. But all things are related to LED driver
and only add several lines. Next time I will ask Lee to give an review
and ack.

So probably this patch has to wait for
a59ce6584d566847980f9dcad5343cd9856145c8 merged.

Thanks,
-Bryan
--
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: For review: open_by_name_at(2) man page

[NeilBrown]

On Tue, 18 Mar 2014 13:37:15 +0100 "Michael Kerrisk (man-pages)"
 wrote:

> On 03/18/2014 10:43 AM, Christoph Hellwig wrote:
> > On Tue, Mar 18, 2014 at 09:00:07AM +1100, NeilBrown wrote:
> >> ESTALE is also returned if the filesystem does not support file-handle ->
> >> file mappings.
> >> On filesystems which don't provide export_operations (/sys /proc ubifs
> >> romfs cramfs nfs coda ... several others) name_to_handle_at will produce a
> >> generic handle using the 32 bit inode and 32 bit i_generation.
> > 
> > Do we?  Seems like the code is erroring out early if there are no
> > export_ops?
> 
> It appears to me that Neil's statement isn't correct, at least for /proc
> and /sys (see my other mail, to Neil). I'm unsure about whether it is true
> for some of those other FSes thought.


Indeed, I was wrong.

I was looking at

int exportfs_encode_inode_fh(struct inode *inode, struct fid *fid,
 int *max_len, struct inode *parent)
{
const struct export_operations *nop = inode->i_sb->s_export_op;

if (nop && nop->encode_fh)
return nop->encode_fh(inode, fid->raw, max_len, parent);

return export_encode_fh(inode, fid, max_len, parent);
}


which uses a default if there is no 'nop'.

However do_sys_name_to_handle() contains

if (!path->dentry->d_sb->s_export_op ||
!path->dentry->d_sb->s_export_op->fh_to_dentry)
return -EOPNOTSUPP;

long before export_encode_inode_fh() gets called.  So the default isn't used.

I would have thought that exportfs_encode_inode_fh would never get called if
there were no s_export_op pointer - certainly name_to_handle_at and nfsd
would never call it in that case.
However it seems that

This routine will be used to generate a file handle in fdinfo output for
inotify subsystem, where if no s_export_op present the general
export_encode_fh should be used.  Thus add a test if s_export_op present
inside exportfs_encode_fh itself.

according to

commit ab49bdecc3ebb46ab661f5f05d5c5ea9606406c6
Author: Cyrill Gorcunov 
Date:   Mon Dec 17 16:05:06 2012 -0800


I guess that means that you can extract filehandles from /proc/self/fdinfo/$FD
when $FD is an inotify fd which is watching the particular file.  I
wouldn't have expected that, but maybe it is a good idea.

So yes: if the filesystem doesn't support filehandles you get EOPNOTSUPP.
So if you get ESTALE from open_by_handle_at(), then it really is a stale
handle.  Sorry for the confusion.

NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH v2 11/15] arm64: add EFI stub

[Jason Gunthorpe]

On Tue, Mar 18, 2014 at 02:48:30PM -0700, Roy Franz wrote:

> > It isn't clear to me if UEFI does cache flushing at ExitBootServices
> > time, but even so, at least stack use will get cached between then and
> > the kernel entry point. The stub could conceivably get its hands on the
> > EFI memmap and invalidate dcache using address ranges from UEFI memory
> > descriptors so maybe that is the way we should do it.

> I looked at the UEFI spec and there is no mention of cache flushing
> in ExitBootServices(), so it seems it is up to the OS to do any
> cache management.

Something to think about: On mvebu we recently confirmed a situation
where turning off the L1 cache is not sufficient for booting. The L2
cache must also be completely off and disabled prior to jumping in to
the kernel.

The issue is the decompressor turns the L1 cache back on, and if the
L2 is also enabled at this point then it gets filled with
decompression data. Things go wrong from here because after
decompression the L1 dcache is switched off, but the L2 isn't
flush-invalidated.

So now the L2 holds writeback data and uncached reads return garbage,
and/or the L2 misses the uncached writes (eg relocation fixup) and
becomes inconsistent with memory. Either case gives a black screen
crash at boot.

Fundementally if the L2 doesn't monitor uncached read/writes then it
will cause a big problem.

Thus, if the UEFI calls the sub with the caches on, and the stub
doesn't know enough to turn off the L2 then you might not be able to
turn the dcache off at all. :(

On ARM64 at least the L1 cache ops are standardized so maybe ARM64
could keep the mmu+caches enabled during boot and do the L1
d-flush/i-inval required for instruction coherency?

Jason
--
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] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)

[Paul E. McKenney]

On Wed, Mar 19, 2014 at 03:32:30AM +0530, Monam Agarwal wrote:
> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, 
> NULL) in drivers/infiniband/hw/qib/qib_qp.c
> 
> Signed-off-by: Monam Agarwal 

Reviewed-by: Paul E. McKenney 

> ---
>  drivers/infiniband/hw/qib/qib_qp.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/qib/qib_qp.c 
> b/drivers/infiniband/hw/qib/qib_qp.c
> index 7e7e16f..1f5f04c 100644
> --- a/drivers/infiniband/hw/qib/qib_qp.c
> +++ b/drivers/infiniband/hw/qib/qib_qp.c
> @@ -252,10 +252,10 @@ static void remove_qp(struct qib_ibdev *dev, struct 
> qib_qp *qp)
> 
>   if (ibp->qp0 == qp) {
>   atomic_dec(>refcount);
> - rcu_assign_pointer(ibp->qp0, NULL);
> + RCU_INIT_POINTER(ibp->qp0, NULL);
>   } else if (ibp->qp1 == qp) {
>   atomic_dec(>refcount);
> - rcu_assign_pointer(ibp->qp1, NULL);
> + RCU_INIT_POINTER(ibp->qp1, NULL);
>   } else {
>   struct qib_qp *q, **qpp;
> 
> @@ -303,7 +303,7 @@ unsigned qib_free_all_qps(struct qib_devdata *dd)
>   spin_lock_irqsave(>qpt_lock, flags);
>   for (n = 0; n < dev->qp_table_size; n++) {
>   qp = dev->qp_table[n];
> - rcu_assign_pointer(dev->qp_table[n], NULL);
> + RCU_INIT_POINTER(dev->qp_table[n], NULL);
> 
>   for (; qp; qp = qp->next)
>   qp_inuse++;
> -- 
> 1.7.9.5
> 

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

Re: [PATCH] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) in drivers/input/input.c

[Paul E. McKenney]

On Wed, Mar 19, 2014 at 03:30:29AM +0530, Monam Agarwal wrote:
> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, 
> NULL) in drivers/input/input.c
> 
> Signed-off-by: Monam Agarwal 

Reviewed-by: Paul E. McKenney 

> ---
>  drivers/input/input.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index da38d97..41b5c82 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -463,7 +463,7 @@ static void __input_release_device(struct input_handle 
> *handle)
>   struct input_dev *dev = handle->dev;
> 
>   if (dev->grab == handle) {
> - rcu_assign_pointer(dev->grab, NULL);
> + RCU_INIT_POINTER(dev->grab, NULL);
>   /* Make sure input_pass_event() notices that grab is gone */
>   synchronize_rcu();
> 
> -- 
> 1.7.9.5
> 

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

Re: [patch 02/12] can: c_can: Fix hardware raminit function

[Thomas Gleixner]

On Tue, 18 Mar 2014, Marc Kleine-Budde wrote:
> On 03/18/2014 06:19 PM, Thomas Gleixner wrote:
> > +static void c_can_hw_raminit_wait(const struct c_can_priv *priv, u32 mask,
> > + u32 val)
> > +{
> > +   /* We look only at the bits of our instance. */
> > +   val &= mask;
> > +   while ((readl(priv->raminit_ctrlreg) & mask) != val)
> > +   udelay(1);
> 
> Do we have to add a timeout here, or is it "safe" to have a potential
> endless loop here? As you have probably tortured the hardware and driver
> a lot (or have been tortured by them), I assume you would have added a
> timeout check if you had seen a lockup here.

I haven't seen any failure on that. We could add a timeout for
paranoia reasons. I'm quite sure that the raminit works as advertised
when we do it the right way. The only way to wreckage it so far is by
not waiting for it to complete.

Thanks,

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

Re: [GIT PULL] uprobes: Add uprobes support for ARM

[David Long]

On 03/17/14 19:52, Russell King - ARM Linux wrote:

On Tue, Mar 11, 2014 at 02:36:09PM -0400, David Long wrote:

   git://git.linaro.org/people/dave.long/linux.git uprobes-v7

for you to fetch changes up to e55c35236b8adf79453a998506ec6081833b9484:

   ARM: add uprobes support (2014-03-11 11:40:29 -0400)


I pulled this a week ago into my devel-testing (which is unpublished),
and while it hasn't shown any signs of functional problems, I was just
about to merge it into devel-stable when I noticed the history.

This is based upon:

Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6
+ Linux 3.11
+ Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
+ Linux 3.12-rc5
+ Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
+ Linux 3.13-rc3
+ Linux 3.13-rc4
+ Linux 3.13-rc8
+ Linux 3.14-rc2
+ Linux 3.14-rc4
+ Linux 3.14-rc5
|
[your uprobes patches]

where each + is a merge of the named commit into the previous.  This is
the kind of thing which will make Linus quite unhappy: please base
patches off a plain -rc release, not off a merge commit.

I'm sure there's others on the mailing list who can guide you on this
point, but I do need to ask you to re-spin without those merges.  I'm
happy to take a respin of it provided it's based on 3.14-rc5 (so I can
more easily confirm that there aren't any changes which I haven't
already tested.)


OK, I consulted with a couple coworkers and the fix for this was 
particularly easy.  The respun branch is in place now.  Same repo, same 
branch name, based on v3.14-rc5.  Sorry for the newbie mistake.


I'm assuming a new git-pull request is not required (until I hear 
otherwise).



Thanks, and sorry about the lateness of this email.



I'm just back Monday night from a few days vacation, so your timing was 
perfect for me.


-dl

--
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] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) in drivers/input/endev.c

[Paul E. McKenney]

On Wed, Mar 19, 2014 at 03:28:39AM +0530, Monam Agarwal wrote:
> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, 
> NULL) in drivers/input/endev.c
> 
> Signed-off-by: Monam Agarwal 

Reviewed-by: Paul E. McKenney 

> ---
>  drivers/input/evdev.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index 4cf2534..92e7a3c 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -174,7 +174,7 @@ static int evdev_ungrab(struct evdev *evdev, struct 
> evdev_client *client)
>   if (evdev->grab != client)
>   return  -EINVAL;
> 
> - rcu_assign_pointer(evdev->grab, NULL);
> + RCU_INIT_POINTER(evdev->grab, NULL);
>   synchronize_rcu();
>   input_release_device(>handle);
> 
> -- 
> 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/

[ANNOUNCE] Git v1.9.1

[Junio C Hamano]

The latest maintenance release Git v1.9.1 is now available at
the usual places.

The release tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the v1.9.1
tag and the maint branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git


Git v1.9.1 Release Notes


Fixes since v1.9.0
--

 * "git clean -d pathspec" did not use the given pathspec correctly
   and ended up cleaning too much.

 * "git difftool" misbehaved when the repository is bound to the
   working tree with the ".git file" mechanism, where a textual file
   ".git" tells us where it is.

 * "git push" did not pay attention to branch.*.pushremote if it is
   defined earlier than remote.pushdefault; the order of these two
   variables in the configuration file should not matter, but it did
   by mistake.

 * Codepaths that parse timestamps in commit objects have been
   tightened.

 * "git diff --external-diff" incorrectly fed the submodule directory
   in the working tree to the external diff driver when it knew it is
   the same as one of the versions being compared.

 * "git reset" needs to refresh the index when working in a working
   tree (it can also be used to match the index to the HEAD in an
   otherwise bare repository), but it failed to set up the working
   tree properly, causing GIT_WORK_TREE to be ignored.

 * "git check-attr" when working on a repository with a working tree
   did not work well when the working tree was specified via the
   --work-tree (and obviously with --git-dir) option.

 * "merge-recursive" was broken in 1.7.7 era and stopped working in
   an empty (temporary) working tree, when there are renames
   involved.  This has been corrected.

 * "git rev-parse" was loose in rejecting command line arguments
   that do not make sense, e.g. "--default" without the required
   value for that option.

 * include.path variable (or any variable that expects a path that
   can use ~username expansion) in the configuration file is not a
   boolean, but the code failed to check it.

 * "git diff --quiet -- pathspec1 pathspec2" sometimes did not return
   correct status value.

 * Attempting to deepen a shallow repository by fetching over smart
   HTTP transport failed in the protocol exchange, when no-done
   extension was used.  The fetching side waited for the list of
   shallow boundary commits after the sending end stopped talking to
   it.

 * Allow "git cmd path/", when the 'path' is where a submodule is
   bound to the top-level working tree, to match 'path', despite the
   extra and unnecessary trailing slash (such a slash is often
   given by command line completion).



Changes since v1.9.0 are as follows:

Brad King (4):
  t3030-merge-recursive: test known breakage with empty work tree
  read-cache.c: refactor --ignore-missing implementation
  read-cache.c: extend make_cache_entry refresh flag with options
  merge-recursive.c: tolerate missing files while refreshing index

David Aguilar (1):
  difftool: support repositories with .git-files

David Sharp (1):
  rev-parse: check i before using argv[i] against argc

Jeff King (12):
  expand_user_path: do not look at NULL path
  handle_path_include: don't look at NULL value
  tests: auto-set LIB_HTTPD_PORT from test name
  t4212: test bogus timestamps with git-log
  fsck: report integer overflow in author timestamps
  date: check date overflow against time_t
  log: handle integer overflow in timestamps
  log: do not segfault on gmtime errors
  remote: handle pushremote config in any order
  show_ident_date: fix tz range check
  clean: respect pathspecs with "-d"
  clean: simplify dir/not-dir logic

Junio C Hamano (4):
  t0003: do not chdir the whole test process
  check-attr: move to the top of working tree when in non-bare repository
  t7800: add a difftool test for .git-files
  Git 1.9.1

Nguyễn Thái Ngọc Duy (17):
  test: rename http fetch and push test files
  pack-protocol.txt: clarify 'obj-id' in the last ACK after 'done'
  protocol-capabilities.txt: refer multi_ack_detailed back to 
pack-protocol.txt
  protocol-capabilities.txt: document no-done
  fetch-pack: fix deepen shallow over smart http with no-done cap
  t5537: move http tests out to t5539
  reset: optionally setup worktree and refresh index on --mixed
  pathspec: convert some match_pathspec_depth() to ce_path_match()
  pathspec: convert some match_pathspec_depth() to dir_path_match()
  pathspec: rename match_pathspec_depth() to 

Re: [UPDATED PATCH v3 10/52] arm, kvm: Fix CPU hotplug callback registration

[Christoffer Dall]

On 18 March 2014 03:23, Srivatsa S. Bhat
 wrote:
> On 03/15/2014 12:40 AM, Christoffer Dall wrote:
>> On Fri, Mar 14, 2014 at 11:13:29AM +0530, Srivatsa S. Bhat wrote:
>>> On 03/13/2014 04:51 AM, Christoffer Dall wrote:
 On Tue, Mar 11, 2014 at 02:05:38AM +0530, Srivatsa S. Bhat wrote:
> Subsystems that want to register CPU hotplug callbacks, as well as perform
> initialization for the CPUs that are already online, often do it as shown
> below:
>
> [...]
 Just so we're clear, the existing code was simply racy as not prone to
 deadlocks, right?

 This makes it clear that the test above for compatible CPUs can be quite
 easily evaded by using CPU hotplug, but we don't really have a good
 solution for handling that yet...  Hmmm, grumble grumble, I guess if you
 hotplug unsupported CPUs on a KVM/ARM system for now, stuff will break.

>>>
>>> In this particular case, there was no deadlock possibility, rather the
>>> existing code had insufficient synchronization against CPU hotplug.
>>>
>>> init_hyp_mode() would invoke cpu_init_hyp_mode() on currently online CPUs
>>> using on_each_cpu(). If a CPU came online after this point and before 
>>> calling
>>> register_cpu_notifier(), that CPU would remain uninitialized because this
>>> subsystem would miss the hot-online event. This patch fixes this bug and
>>> also uses the new synchronization method (instead of get/put_online_cpus())
>>> to ensure that we don't deadlock with CPU hotplug.
>>>
>>
>> Yes, that was my conclusion as well.  Thanks for clarifying.  (It could
>> be noted in the commit message as well if you should feel so inclined).
>>
>
> Please find the patch with updated changelog (and your Ack) below.
> (No changes in code).
>

perfect, thanks!

> From: Srivatsa S. Bhat 
> Subject: [PATCH] arm, kvm: Fix CPU hotplug callback registration
>
> Subsystems that want to register CPU hotplug callbacks, as well as perform
> initialization for the CPUs that are already online, often do it as shown
> below:
>
> get_online_cpus();
>
> for_each_online_cpu(cpu)
> init_cpu(cpu);
>
> register_cpu_notifier(_cpu_notifier);
>
> put_online_cpus();
>
> This is wrong, since it is prone to ABBA deadlocks involving the
> cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
> with CPU hotplug operations).
>
> Instead, the correct and race-free way of performing the callback
> registration is:
>
> cpu_notifier_register_begin();
>
> for_each_online_cpu(cpu)
> init_cpu(cpu);
>
> /* Note the use of the double underscored version of the API */
> __register_cpu_notifier(_cpu_notifier);
>
> cpu_notifier_register_done();
>
>
> In the existing arm kvm code, there is no synchronization with CPU hotplug
> to avoid missing the hotplug events that might occur after invoking
> init_hyp_mode() and before calling register_cpu_notifier(). Fix this bug
> and also use the new synchronization method (instead of get/put_online_cpus())
> to ensure that we don't deadlock with CPU hotplug.
>
> Cc: Gleb Natapov 
> Cc: Russell King 
> Cc: Ingo Molnar 
> Cc: kvm...@lists.cs.columbia.edu
> Cc: k...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Acked-by: Paolo Bonzini 
> Acked-by: Christoffer Dall 
> Signed-off-by: Srivatsa S. Bhat 
> ---
>
>  arch/arm/kvm/arm.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index bd18bb8..f0e50a0 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -1051,21 +1051,26 @@ int kvm_arch_init(void *opaque)
> }
> }
>
> +   cpu_notifier_register_begin();
> +
> err = init_hyp_mode();
> if (err)
> goto out_err;
>
> -   err = register_cpu_notifier(_init_cpu_nb);
> +   err = __register_cpu_notifier(_init_cpu_nb);
> if (err) {
> kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
> goto out_err;
> }
>
> +   cpu_notifier_register_done();
> +
> hyp_cpu_pm_init();
>
> kvm_coproc_table_init();
> return 0;
>  out_err:
> +   cpu_notifier_register_done();
> return err;
>  }
>
>
>
--
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] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) in drivers/input/input.c

[Monam Agarwal]

This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) 
in drivers/input/input.c

Signed-off-by: Monam Agarwal 
---
 drivers/input/input.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index da38d97..41b5c82 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -463,7 +463,7 @@ static void __input_release_device(struct input_handle 
*handle)
struct input_dev *dev = handle->dev;
 
if (dev->grab == handle) {
-   rcu_assign_pointer(dev->grab, NULL);
+   RCU_INIT_POINTER(dev->grab, NULL);
/* Make sure input_pass_event() notices that grab is gone */
synchronize_rcu();
 
-- 
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] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)

[Monam Agarwal]

This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) 
in drivers/infiniband/hw/qib/qib_qp.c

Signed-off-by: Monam Agarwal 
---
 drivers/infiniband/hw/qib/qib_qp.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/hw/qib/qib_qp.c 
b/drivers/infiniband/hw/qib/qib_qp.c
index 7e7e16f..1f5f04c 100644
--- a/drivers/infiniband/hw/qib/qib_qp.c
+++ b/drivers/infiniband/hw/qib/qib_qp.c
@@ -252,10 +252,10 @@ static void remove_qp(struct qib_ibdev *dev, struct 
qib_qp *qp)
 
if (ibp->qp0 == qp) {
atomic_dec(>refcount);
-   rcu_assign_pointer(ibp->qp0, NULL);
+   RCU_INIT_POINTER(ibp->qp0, NULL);
} else if (ibp->qp1 == qp) {
atomic_dec(>refcount);
-   rcu_assign_pointer(ibp->qp1, NULL);
+   RCU_INIT_POINTER(ibp->qp1, NULL);
} else {
struct qib_qp *q, **qpp;
 
@@ -303,7 +303,7 @@ unsigned qib_free_all_qps(struct qib_devdata *dd)
spin_lock_irqsave(>qpt_lock, flags);
for (n = 0; n < dev->qp_table_size; n++) {
qp = dev->qp_table[n];
-   rcu_assign_pointer(dev->qp_table[n], NULL);
+   RCU_INIT_POINTER(dev->qp_table[n], NULL);
 
for (; qp; qp = qp->next)
qp_inuse++;
-- 
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 v3 5/7] OF: i2c: Add overlay bus handler

[Pantelis Antoniou]

Add the bus handler registration needed for performing overlays
containing i2c devices.

Signed-off-by: Pantelis Antoniou 
---
 drivers/i2c/i2c-core.c | 87 +-
 1 file changed, 86 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 5fb80b8..5120d28 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1073,10 +1073,89 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
device_node *node)
return i2c_verify_adapter(dev);
 }
 EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
+
+#ifdef CONFIG_OF_OVERLAY
+static int i2c_handler_create(struct of_overlay_device_entry *de,
+   int revert)
+{
+   struct device_node *dn;
+   struct i2c_adapter *adap;
+   struct i2c_client *client;
+
+   if (!de || !de->np)
+   return -ENOTSUPP;
+
+   dn = de->np;
+
+   adap = of_find_i2c_adapter_by_node(dn->parent);
+   if (adap == NULL)
+   return -ENOTSUPP;
+
+   client = of_i2c_register_device(adap, dn);
+   put_device(>dev);
+
+   if (client == NULL) {
+   pr_err("%s: failed to create i2c client device "
+   "for '%s'\n",
+   __func__, dn->full_name);
+   /* of_i2c_device_create tosses the real error code */
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int i2c_handler_remove(struct of_overlay_device_entry *de,
+   int revert)
+{
+   struct device_node *dn;
+   struct i2c_client *client;
+
+   if (!de || !de->np)
+   return -ENOTSUPP;
+
+   dn = de->np;
+
+   client = of_find_i2c_device_by_node(dn);
+   if (client == NULL)
+   return -ENOTSUPP;
+
+   /* unregister takes one ref away */
+   i2c_unregister_device(client);
+
+   /* and put the reference of the find */
+   put_device(>dev);
+
+   return 0;
+}
+
+static const struct of_overlay_handler_ops i2c_handler_ops = {
+   .create = i2c_handler_create,
+   .remove = i2c_handler_remove,
+};
+
+static struct of_overlay_handler i2c_handler = {
+   .name = "i2c",
+   .ops = _handler_ops,
+};
+
+static int __init i2c_bus_handler_register(void)
+{
+   return of_overlay_handler_register(_handler);
+}
+#endif
+
 #else
 static void of_i2c_register_devices(struct i2c_adapter *adap) { }
 #endif /* CONFIG_OF */
 
+#if !defined(CONFIG_OF) || !defined(CONFIG_OF_OVERLAY)
+static inline int i2c_bus_handler_register(void)
+{
+   return 0;
+}
+#endif
+
 /* ACPI support code */
 
 #if IS_ENABLED(CONFIG_ACPI)
@@ -1668,8 +1747,14 @@ static int __init i2c_init(void)
retval = i2c_add_driver(_driver);
if (retval)
goto class_err;
-   return 0;
 
+   retval = i2c_bus_handler_register();
+   if (retval)
+   goto bus_handler_err;
+
+   return 0;
+bus_handler_err:
+   i2c_del_driver(_driver);
 class_err:
 #ifdef CONFIG_I2C_COMPAT
class_compat_unregister(i2c_adapter_compat_class);
-- 
1.7.12

--
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] rcu: Replace rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) in drivers/input/endev.c

[Monam Agarwal]

This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) 
in drivers/input/endev.c

Signed-off-by: Monam Agarwal 
---
 drivers/input/evdev.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 4cf2534..92e7a3c 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -174,7 +174,7 @@ static int evdev_ungrab(struct evdev *evdev, struct 
evdev_client *client)
if (evdev->grab != client)
return  -EINVAL;
 
-   rcu_assign_pointer(evdev->grab, NULL);
+   RCU_INIT_POINTER(evdev->grab, NULL);
synchronize_rcu();
input_release_device(>handle);
 
-- 
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 v3 2/7] OF: Introduce DT overlay support.

[Pantelis Antoniou]

Introduce DT overlay support.
Using this functionality it is possible to dynamically overlay a part of
the kernel's tree with another tree that's been dynamically loaded.
It is also possible to remove node and properties.

The creation/destruction of the devices is handled by calling in to
bus specific handlers which can deal with the peculiarities of each
device.

Signed-off-by: Pantelis Antoniou 
---
 Documentation/devicetree/overlay-notes.txt | 187 ++
 drivers/of/Kconfig |  10 +
 drivers/of/Makefile|   1 +
 drivers/of/overlay.c   | 895 +
 include/linux/of.h | 153 +
 5 files changed, 1246 insertions(+)
 create mode 100644 Documentation/devicetree/overlay-notes.txt
 create mode 100644 drivers/of/overlay.c

diff --git a/Documentation/devicetree/overlay-notes.txt 
b/Documentation/devicetree/overlay-notes.txt
new file mode 100644
index 000..882d512
--- /dev/null
+++ b/Documentation/devicetree/overlay-notes.txt
@@ -0,0 +1,187 @@
+Device Tree Overlay Notes
+-
+
+This document describes the implementation of the in-kernel
+device tree overlay functionality residing in drivers/of/overlay.c and is a
+companion document to Documentation/devicetree/dt-object-internal.txt[1] &
+Documentation/devicetree/dynamic-resolution-notes.txt[2]
+
+How overlays work
+-
+
+A Device Tree's overlay purpose is to modify the kernel's live tree, and
+have the modification affecting the state of the the kernel in a way that
+is reflecting the changes.
+Since the kernel mainly deals with devices, any new device node that result
+in an active device should have it created while if the device node is either
+disabled or removed all together, the affected device should be deregistered.
+
+Lets take an example where we have a foo board with the following base tree
+which is taken from [1].
+
+ foo.dts -
+   /* FOO platform */
+   / {
+   compatible = "corp,foo";
+
+   /* shared resources */
+   res: res {
+   };
+
+   /* On chip peripherals */
+   ocp: ocp {
+   /* peripherals that are always instantiated */
+   peripheral1 { ... };
+   }
+   };
+ foo.dts -
+
+The overlay bar.dts, when loaded (and resolved as described in [2]) should
+
+ bar.dts -
+/plugin/;  /* allow undefined label references and record them */
+/ {
+   /* various properties for loader use; i.e. part id etc. */
+   fragment@0 {
+   target = <>;
+   __overlay__ {
+   /* bar peripheral */
+   bar {
+   compatible = "corp,bar";
+   ... /* various properties and child nodes */
+   }
+   };
+   };
+};
+ bar.dts -
+
+result in foo+bar.dts
+
+ foo+bar.dts -
+   /* FOO platform + bar peripheral */
+   / {
+   compatible = "corp,foo";
+
+   /* shared resources */
+   res: res {
+   };
+
+   /* On chip peripherals */
+   ocp: ocp {
+   /* peripherals that are always instantiated */
+   peripheral1 { ... };
+
+   /* bar peripheral */
+   bar {
+   compatible = "corp,bar";
+   ... /* various properties and child nodes */
+   }
+   }
+   };
+ foo+bar.dts -
+
+As a result of the the overlay, a new device node (bar) has been created
+so a bar platform device will be registered and if a matching device driver
+is loaded the device will be created as expected.
+
+Overlay in-kernel API
+-
+
+The steps typically required to get an overlay to work are as follows:
+
+1. Use of_build_overlay_info() to create an array of initialized and
+ready to use of_overlay_info structures.
+2. Call of_overlay() to apply the overlays declared in the array.
+3. If the overlay needs to be removed, call of_overlay_revert().
+4. Finally release the memory taken by the overlay info array by
+of_free_overlay_info().
+
+/**
+ * of_build_overlay_info   - Build an overlay info array
+ * @tree:  Device node containing all the overlays
+ * @cntp:  Pointer to where the overlay info count will be help
+ * @ovinfop:   Pointer to the pointer of an overlay info structure.
+ *

[PATCH v3 7/7] of: i2c: Export single device registration method

[Pantelis Antoniou]

From: Pantelis Antoniou 

Dynamically inserting i2c client device nodes requires the use
of a single device registration method. Rework and export it.

Signed-off-by: Pantelis Antoniou 
---
 drivers/i2c/i2c-core.c | 99 +++---
 include/linux/i2c.h| 10 +
 2 files changed, 64 insertions(+), 45 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 5120d28..017fb03 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i2c-core.h"
 
@@ -982,63 +983,71 @@ static void i2c_scan_static_board_info(struct i2c_adapter 
*adapter)
 /* OF support code */
 
 #if IS_ENABLED(CONFIG_OF)
-static void of_i2c_register_devices(struct i2c_adapter *adap)
+struct i2c_client *
+of_i2c_register_device(struct i2c_adapter *adap,
+   struct device_node *node)
 {
-   void *result;
-   struct device_node *node;
+   struct i2c_client *result;
+   struct i2c_board_info info = {};
+   struct dev_archdata dev_ad = {};
+   const __be32 *addr;
+   int len;
 
-   /* Only register child devices if the adapter has a node pointer set */
-   if (!adap->dev.of_node)
-   return;
+   dev_dbg(>dev, "of_i2c: register %s\n", node->full_name);
 
-   dev_dbg(>dev, "of_i2c: walking child nodes\n");
+   if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
+   dev_err(>dev, "of_i2c: modalias failure on %s\n",
+   node->full_name);
+   return ERR_PTR(-EINVAL);
+   }
 
-   for_each_available_child_of_node(adap->dev.of_node, node) {
-   struct i2c_board_info info = {};
-   struct dev_archdata dev_ad = {};
-   const __be32 *addr;
-   int len;
+   addr = of_get_property(node, "reg", );
+   if (!addr || (len < sizeof(int))) {
+   dev_err(>dev, "of_i2c: invalid reg on %s\n",
+   node->full_name);
+   return ERR_PTR(-EINVAL);
+   }
 
-   dev_dbg(>dev, "of_i2c: register %s\n", node->full_name);
+   info.addr = be32_to_cpup(addr);
+   if (info.addr > (1 << 10) - 1) {
+   dev_err(>dev, "of_i2c: invalid addr=%x on %s\n",
+   info.addr, node->full_name);
+   return ERR_PTR(-EINVAL);
+   }
 
-   if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
-   dev_err(>dev, "of_i2c: modalias failure on %s\n",
-   node->full_name);
-   continue;
-   }
+   info.irq = irq_of_parse_and_map(node, 0);
+   info.of_node = of_node_get(node);
+   info.archdata = _ad;
 
-   addr = of_get_property(node, "reg", );
-   if (!addr || (len < sizeof(int))) {
-   dev_err(>dev, "of_i2c: invalid reg on %s\n",
-   node->full_name);
-   continue;
-   }
+   if (of_get_property(node, "wakeup-source", NULL))
+   info.flags |= I2C_CLIENT_WAKE;
 
-   info.addr = be32_to_cpup(addr);
-   if (info.addr > (1 << 10) - 1) {
-   dev_err(>dev, "of_i2c: invalid addr=%x on %s\n",
-   info.addr, node->full_name);
-   continue;
-   }
+   request_module("%s%s", I2C_MODULE_PREFIX, info.type);
 
-   info.irq = irq_of_parse_and_map(node, 0);
-   info.of_node = of_node_get(node);
-   info.archdata = _ad;
+   result = i2c_new_device(adap, );
+   if (result == NULL) {
+   dev_err(>dev, "of_i2c: Failure registering %s\n",
+   node->full_name);
+   of_node_put(node);
+   irq_dispose_mapping(info.irq);
+   return ERR_PTR(-EINVAL);
+   }
+   return result;
+}
+EXPORT_SYMBOL(of_i2c_register_device);
 
-   if (of_get_property(node, "wakeup-source", NULL))
-   info.flags |= I2C_CLIENT_WAKE;
+static void of_i2c_register_devices(struct i2c_adapter *adap)
+{
+   struct device_node *node;
 
-   request_module("%s%s", I2C_MODULE_PREFIX, info.type);
+   /* Only register child devices if the adapter has a node pointer set */
+   if (!adap->dev.of_node)
+   return;
 
-   result = i2c_new_device(adap, );
-   if (result == NULL) {
-   dev_err(>dev, "of_i2c: Failure registering %s\n",
-   node->full_name);
-   of_node_put(node);
-   irq_dispose_mapping(info.irq);
-   continue;
-   }
-   }
+   dev_dbg(>dev, "of_i2c: walking child nodes\n");
+
+   for_each_available_child_of_node(adap->dev.of_node, node)
+   

[PATCH v3 4/7] OF: platform: Add overlay bus handler

[Pantelis Antoniou]

Add the bus handler registration needed for performing overlays
containing platform devices.

Signed-off-by: Pantelis Antoniou 
---
 drivers/base/platform.c | 99 +++--
 1 file changed, 96 insertions(+), 3 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index bc78848..e113733 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -925,6 +925,87 @@ struct bus_type platform_bus_type = {
 };
 EXPORT_SYMBOL_GPL(platform_bus_type);
 
+#ifdef CONFIG_OF_OVERLAY
+
+static int platform_handler_create(struct of_overlay_device_entry *de,
+   int revert)
+{
+   struct device_node *dn;
+   struct platform_device *pdev_parent, *pdev;
+
+   if (!de || !de->np)
+   return -ENOTSUPP;
+
+   dn = de->np;
+
+   /* verify that the parent is a bus */
+   if (!of_match_node(of_default_bus_match_table, dn->parent))
+   return -ENOTSUPP;
+
+   pdev_parent = of_find_device_by_node(dn->parent);
+   if (pdev_parent == NULL)
+   return -ENOTSUPP;
+
+   pdev = of_platform_device_create(dn, NULL, _parent->dev);
+   of_dev_put(pdev_parent);
+
+   if (pdev == NULL) {
+   pr_err("%s: failed to create platform device "
+   "for '%s'\n",
+   __func__, dn->full_name);
+   /* of_platform_device_create tosses the real error code */
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int platform_handler_remove(struct of_overlay_device_entry *de,
+   int revert)
+{
+   struct device_node *dn;
+   struct platform_device *pdev;
+
+   if (!de || !de->np)
+   return -ENOTSUPP;
+
+   dn = de->np;
+
+   pdev = of_find_device_by_node(dn);
+   if (pdev == NULL)
+   return -ENOTSUPP;
+
+   /* unregister takes one ref away */
+   platform_device_unregister(pdev);
+
+   /* and put the reference of the find */
+   of_dev_put(pdev);
+
+   return 0;
+}
+
+static const struct of_overlay_handler_ops platform_handler_ops = {
+   .create = platform_handler_create,
+   .remove = platform_handler_remove,
+};
+
+static struct of_overlay_handler platform_handler = {
+   .name = "platform",
+   .ops = _handler_ops,
+};
+
+static int __init platform_bus_handler_register(void)
+{
+   return of_overlay_handler_register(_handler);
+}
+
+#else
+static inline int platform_bus_handler_register(void)
+{
+   return 0;
+}
+#endif
+
 int __init platform_bus_init(void)
 {
int error;
@@ -933,10 +1014,22 @@ int __init platform_bus_init(void)
 
error = device_register(_bus);
if (error)
-   return error;
-   error =  bus_register(_bus_type);
+   goto err_out;
+
+   error = bus_register(_bus_type);
if (error)
-   device_unregister(_bus);
+   goto err_unreg_dev;
+
+   error = platform_bus_handler_register();
+   if (error)
+   goto err_unreg_bus;
+
+   return 0;
+err_unreg_bus:
+   bus_unregister(_bus_type);
+err_unreg_dev:
+   device_unregister(_bus);
+err_out:
return error;
 }
 
-- 
1.7.12

--
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 6/7] OF: spi: Add overlay bus handler

[Pantelis Antoniou]

Add the bus handler registration needed for performing overlays
containing spi devices.

Signed-off-by: Pantelis Antoniou 
---
 drivers/spi/spi.c | 345 ++
 1 file changed, 242 insertions(+), 103 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index d0b28bb..2d7037b 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -993,6 +993,123 @@ err_init_queue:
 /*-*/
 
 #if defined(CONFIG_OF)
+
+static struct spi_device *
+of_register_spi_device(struct spi_master *master, struct device_node *node)
+{
+   struct spi_device *spi;
+   struct device_node *nc;
+   int err;
+   u32 value;
+
+   /* Alloc an spi_device */
+   spi = spi_alloc_device(master);
+   if (!spi) {
+   dev_err(>dev, "spi_device alloc error for %s\n",
+   nc->full_name);
+   err = -ENOMEM;
+   goto err_out;
+   }
+
+   /* Select device driver */
+   err = of_modalias_node(nc, spi->modalias,
+   sizeof(spi->modalias));
+   if (err) {
+   dev_err(>dev, "cannot find modalias for %s\n",
+   nc->full_name);
+   goto err_out;
+   }
+
+   /* Device address */
+   err = of_property_read_u32(nc, "reg", );
+   if (err) {
+   dev_err(>dev, "%s has no valid 'reg' property (%d)\n",
+   nc->full_name, err);
+   goto err_out;
+   }
+   spi->chip_select = value;
+
+   /* Mode (clock phase/polarity/etc.) */
+   if (of_find_property(nc, "spi-cpha", NULL))
+   spi->mode |= SPI_CPHA;
+   if (of_find_property(nc, "spi-cpol", NULL))
+   spi->mode |= SPI_CPOL;
+   if (of_find_property(nc, "spi-cs-high", NULL))
+   spi->mode |= SPI_CS_HIGH;
+   if (of_find_property(nc, "spi-3wire", NULL))
+   spi->mode |= SPI_3WIRE;
+
+   /* Device DUAL/QUAD mode */
+   if (!of_property_read_u32(nc, "spi-tx-bus-width", )) {
+   switch (value) {
+   case 1:
+   break;
+   case 2:
+   spi->mode |= SPI_TX_DUAL;
+   break;
+   case 4:
+   spi->mode |= SPI_TX_QUAD;
+   break;
+   default:
+   dev_err(>dev,
+   "spi-tx-bus-width %d not supported\n",
+   value);
+   err = -EINVAL;
+   goto err_out;
+   }
+   }
+
+   if (!of_property_read_u32(nc, "spi-rx-bus-width", )) {
+   switch (value) {
+   case 1:
+   break;
+   case 2:
+   spi->mode |= SPI_RX_DUAL;
+   break;
+   case 4:
+   spi->mode |= SPI_RX_QUAD;
+   break;
+   default:
+   dev_err(>dev,
+   "spi-rx-bus-width %d not supported\n",
+   value);
+   err = -EINVAL;
+   goto err_out;
+   }
+   }
+
+   /* Device speed */
+   err = of_property_read_u32(nc, "spi-max-frequency", );
+   if (err) {
+   dev_err(>dev, "%s has no valid 'spi-max-frequency' 
property (%d)\n",
+   nc->full_name, err);
+   goto err_out;
+   }
+   spi->max_speed_hz = value;
+
+   /* IRQ */
+   spi->irq = irq_of_parse_and_map(nc, 0);
+
+   /* Store a pointer to the node in the device structure */
+   of_node_get(nc);
+   spi->dev.of_node = nc;
+
+   /* Register the new device */
+   request_module("%s%s", SPI_MODULE_PREFIX, spi->modalias);
+   err = spi_add_device(spi);
+   if (err) {
+   dev_err(>dev, "spi_device register error %s\n",
+   nc->full_name);
+   goto err_out;
+   }
+
+   return spi;
+
+err_out:
+   spi_dev_put(spi);
+   return ERR_PTR(err);
+}
+
 /**
  * of_register_spi_devices() - Register child devices onto the SPI bus
  * @master:Pointer to spi_master device
@@ -1002,124 +1119,140 @@ err_init_queue:
  */
 static void of_register_spi_devices(struct spi_master *master)
 {
-   struct spi_device *spi;
struct device_node *nc;
-   int rc;
-   u32 value;
 
if (!master->dev.of_node)
return;
 
-   for_each_available_child_of_node(master->dev.of_node, nc) {
-   /* Alloc an spi_device */
-   spi = spi_alloc_device(master);
-   if (!spi) {
-   dev_err(>dev, "spi_device alloc error for %s\n",
-   nc->full_name);
-   

[PATCH v3 0/7] Introducing (yet again) Device Tree Overlays

[Pantelis Antoniou]

The following patchset introduces Device Tree overlays, a method
of dynamically altering the kernel's live Device Tree, along with
a generic interface to use it in a board agnostic manner.

It is dependent on Grant Likely's DT kobjectification patches located
in his tree as queued for -next.

It relies on the following previously submitted patches/patchsets:

* OF: Add [__]of_find_node_by_full_name
* OF: Utility helper functions for dynamic nodes
* of: Make of_find_node_by_path() handle /aliases

To compile overlays you need the DTC compiler patch

* "dtc: Dynamic symbols & fixup support (v2)"

Changes since V2:
* Use of a configfs board agnostic overlay method
* Use of per bus handlers instead of hardcoded behaviour
* Optional target-path overlay target, which allows one to use standard
DTBs without resolution options.

Changes since V1:

* Removal of any bits related to a specific board (beaglebone).
* Introduced a platform agnostic interface using /proc/device-tree-overlay
* Various bug fixes related to i2c device handling have been squashed in.


Pantelis Antoniou (7):
  OF: Introduce Device Tree resolve support.
  OF: Introduce DT overlay support.
  OF: DT-Overlay configfs interface
  OF: platform: Add overlay bus handler
  OF: i2c: Add overlay bus handler
  OF: spi: Add overlay bus handler
  of: i2c: Export single device registration method

 .../devicetree/dynamic-resolution-notes.txt|  25 +
 Documentation/devicetree/overlay-notes.txt | 187 +
 drivers/base/platform.c|  99 ++-
 drivers/i2c/i2c-core.c | 186 +++--
 drivers/of/Kconfig |  24 +
 drivers/of/Makefile|   3 +
 drivers/of/configfs.c  | 272 +++
 drivers/of/overlay.c   | 895 +
 drivers/of/resolver.c  | 376 +
 drivers/spi/spi.c  | 345 +---
 include/linux/i2c.h|  10 +
 include/linux/of.h | 170 
 12 files changed, 2440 insertions(+), 152 deletions(-)
 create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt
 create mode 100644 Documentation/devicetree/overlay-notes.txt
 create mode 100644 drivers/of/configfs.c
 create mode 100644 drivers/of/overlay.c
 create mode 100644 drivers/of/resolver.c

-- 
1.7.12

--
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 3/7] OF: DT-Overlay configfs interface

[Pantelis Antoniou]

Add a runtime interface to using configfs for generic device tree overlay
usage.

A device-tree configfs entry is created in /config/device-tree/overlays

To create an overlay you mkdir the directory and then echo the overlay
firmware file to the path property file.

# mkdir /config/device-tree/overlays/foo
# echo foo.dtbo >/config/device-tree/overlays/foo/path

The overlay file will be loaded using the standard firmware loader
and will be applied.

To remove it simply rmdir the directory.

# rmdir /config/device-tree/overlays/foo

Signed-off-by: Pantelis Antoniou 
---
 drivers/of/Kconfig|   5 +
 drivers/of/Makefile   |   1 +
 drivers/of/configfs.c | 272 ++
 3 files changed, 278 insertions(+)
 create mode 100644 drivers/of/configfs.c

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 7517be2..fc0e3ec 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -77,6 +77,10 @@ config OF_RESERVED_MEM
help
  Helpers to allow for reservation of memory regions
 
+config OF_CONFIGFS
+   select CONFIGFS_FS
+   def_bool n
+
 config OF_RESOLVE
bool "OF Dynamic resolution support"
depends on OF
@@ -92,6 +96,7 @@ config OF_OVERLAY
select OF_DYNAMIC
select OF_DEVICE
select OF_RESOLVE
+   select OF_CONFIGFS
help
  OpenFirmware overlay support. Allows you to modify on runtime the
  live tree using overlays.
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index d2a6e0d..4efa17b 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_MTD)  += of_mtd.o
 obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
 obj-$(CONFIG_OF_RESOLVE)  += resolver.o
 obj-$(CONFIG_OF_OVERLAY) += overlay.o
+obj-$(CONFIG_OF_CONFIGFS) += configfs.o
diff --git a/drivers/of/configfs.c b/drivers/of/configfs.c
new file mode 100644
index 000..a494643
--- /dev/null
+++ b/drivers/of/configfs.c
@@ -0,0 +1,272 @@
+/*
+ * Configfs entries for device-tree
+ *
+ * Copyright (C) 2013 - Pantelis Antoniou 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "of_private.h"
+
+#ifdef CONFIG_OF_OVERLAY
+
+struct cfs_overlay_item {
+   struct config_item  item;
+
+   charpath[PATH_MAX];
+
+   const struct firmware   *fw;
+   struct device_node  *overlay;
+   int ovinfo_cnt;
+   struct of_overlay_info  *ovinfo;
+   unsigned intapplied : 1;
+};
+
+static inline struct cfs_overlay_item *to_cfs_overlay_item(struct config_item 
*item)
+{
+   return item ? container_of(item, struct cfs_overlay_item, item) : NULL;
+}
+
+CONFIGFS_ATTR_STRUCT(cfs_overlay_item);
+#define CFS_OVERLAY_ITEM_ATTR(_name, _mode, _show, _store) \
+struct cfs_overlay_item_attribute cfs_overlay_item_attr_##_name = \
+   __CONFIGFS_ATTR(_name, _mode, _show, _store)
+#define CFS_OVERLAY_ITEM_ATTR_RO(_name, _show) \
+struct cfs_overlay_item_attribute cfs_overlay_item_attr_##_name = \
+   __CONFIGFS_ATTR_RO(_name, _show)
+
+static ssize_t cfs_overlay_item_path_show(struct cfs_overlay_item *overlay,
+   char *page)
+{
+   return sprintf(page, "%s\n", overlay->path);
+}
+
+static ssize_t cfs_overlay_item_path_store(struct cfs_overlay_item *overlay,
+   const char *page, size_t count)
+{
+   const char *p = page;
+   char *s;
+   int err;
+
+   /* if it's set do not allow changes */
+   if (overlay->path[0] != '\0')
+   return -EPERM;
+
+   /* copy to path buffer (and make sure it's always zero terminated */
+   count = snprintf(overlay->path, sizeof(overlay->path) - 1, "%s", p);
+   overlay->path[sizeof(overlay->path) - 1] = '\0';
+
+   /* strip trailing newlines */
+   s = overlay->path + strlen(overlay->path);
+   while (s > overlay->path && *--s == '\n')
+   *s = '\0';
+
+   pr_debug("%s: path is '%s'\n", __func__, overlay->path);
+
+   err = request_firmware(>fw, overlay->path, NULL);
+   if (err != 0)
+   goto out_err;
+
+   /* unflatten the tree */
+   of_fdt_unflatten_tree((void *)overlay->fw->data, >overlay);
+   if (overlay->overlay == NULL) {
+   pr_err("%s: failed to unflatten tree\n", __func__);
+   err = -EINVAL;
+   goto out_err;
+   }
+   pr_debug("%s: unflattened OK\n", __func__);
+
+   /* mark it as detached */
+   of_node_set_flag(overlay->overlay, OF_DETACHED);
+
+   /* perform resolution */
+   

[PATCH v3 1/7] OF: Introduce Device Tree resolve support.

[Pantelis Antoniou]

Introduce support for dynamic device tree resolution.
Using it, it is possible to prepare a device tree that's
been loaded on runtime to be modified and inserted at the kernel
live tree.

Export of of_resolve by Guenter Roeck 

Signed-off-by: Pantelis Antoniou 
---
 .../devicetree/dynamic-resolution-notes.txt|  25 ++
 drivers/of/Kconfig |   9 +
 drivers/of/Makefile|   1 +
 drivers/of/resolver.c  | 376 +
 include/linux/of.h |  17 +
 5 files changed, 428 insertions(+)
 create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt
 create mode 100644 drivers/of/resolver.c

diff --git a/Documentation/devicetree/dynamic-resolution-notes.txt 
b/Documentation/devicetree/dynamic-resolution-notes.txt
new file mode 100644
index 000..0b396c4
--- /dev/null
+++ b/Documentation/devicetree/dynamic-resolution-notes.txt
@@ -0,0 +1,25 @@
+Device Tree Dynamic Resolver Notes
+--
+
+This document describes the implementation of the in-kernel
+Device Tree resolver, residing in drivers/of/resolver.c and is a
+companion document to Documentation/devicetree/dt-object-internal.txt[1]
+
+How the resolver works
+--
+
+The resolver is given as an input an arbitrary tree compiled with the
+proper dtc option and having a /plugin/ tag. This generates the
+appropriate __fixups__ & __local_fixups__ nodes as described in [1].
+
+In sequence the resolver works by the following steps:
+
+1. Get the maximum device tree phandle value from the live tree + 1.
+2. Adjust all the local phandles of the tree to resolve by that amount.
+3. Using the __local__fixups__ node information adjust all local references
+   by the same amount.
+4. For each property in the __fixups__ node locate the node it references
+   in the live tree. This is the label used to tag the node.
+5. Retrieve the phandle of the target of the fixup.
+5. For each fixup in the property locate the node:property:offset location
+   and replace it with the phandle value.
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 889005f..33a8fef 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -77,4 +77,13 @@ config OF_RESERVED_MEM
help
  Helpers to allow for reservation of memory regions
 
+config OF_RESOLVE
+   bool "OF Dynamic resolution support"
+   depends on OF
+   select OF_DYNAMIC
+   select OF_DEVICE
+   help
+ Enable OF dynamic resolution support. This allows you to
+ load Device Tree object fragments are run time.
+
 endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 26de2ed..c241e79 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_OF_PCI)  += of_pci.o
 obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
 obj-$(CONFIG_OF_MTD)   += of_mtd.o
 obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
+obj-$(CONFIG_OF_RESOLVE)  += resolver.o
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
new file mode 100644
index 000..14fbbd3
--- /dev/null
+++ b/drivers/of/resolver.c
@@ -0,0 +1,376 @@
+/*
+ * Functions for dealing with DT resolution
+ *
+ * Copyright (C) 2012 Pantelis Antoniou 
+ * Copyright (C) 2012 Texas Instruments Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * Find live tree's maximum phandle value.
+ */
+static phandle of_get_tree_max_phandle(void)
+{
+   struct device_node *node;
+   phandle phandle;
+   unsigned long flags;
+
+   /* now search recursively */
+   raw_spin_lock_irqsave(_lock, flags);
+   phandle = 0;
+   for_each_of_allnodes(node) {
+   if (node->phandle != OF_PHANDLE_ILLEGAL &&
+   node->phandle > phandle)
+   phandle = node->phandle;
+   }
+   raw_spin_unlock_irqrestore(_lock, flags);
+
+   return phandle;
+}
+
+/**
+ * Adjust a subtree's phandle values by a given delta.
+ * Makes sure not to just adjust the device node's phandle value,
+ * but modify the phandle properties values as well.
+ */
+static void __of_adjust_tree_phandles(struct device_node *node,
+   int phandle_delta)
+{
+   struct device_node *child;
+   struct property *prop;
+   phandle phandle;
+
+   /* first adjust the node's phandle direct value */
+   if (node->phandle != 0 && node->phandle != OF_PHANDLE_ILLEGAL)
+   node->phandle += phandle_delta;
+
+   /* now adjust phandle & linux,phandle values */
+   for_each_property_of_node(node, prop) {
+
+   /* only look for these two */
+   if 

[PATCH] OF: Add [__]of_find_node_by_full_name

[Pantelis Antoniou]

__of_find_node_by_full_name recursively searches for a matching node
with the given full name without taking any locks.

of_find_node_by_full_name takes locks and takes a reference on the
matching node.

Signed-off-by: Pantelis Antoniou 
---
 drivers/of/base.c  | 58 ++
 include/linux/of.h |  4 
 2 files changed, 62 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 19bcdb4..08156e6 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1142,6 +1142,64 @@ static void *of_find_property_value_of_size(const struct 
device_node *np,
 }
 
 /**
+ * __of_find_node_by_full_name - Find a node with the full name recursively
+ * @node:  Root of the tree to perform the search
+ * @full_name: Full name of the node to find.
+ *
+ * Find a node with the give full name by recursively following any of
+ * the child node links.
+ * Returns the matching node, or NULL if not found.
+ * Note that the devtree lock is not taken, so this function is only
+ * safe to call on either detached trees, or when devtree lock is already
+ * taken.
+ */
+struct device_node *__of_find_node_by_full_name(struct device_node *node,
+   const char *full_name)
+{
+   struct device_node *child, *found;
+
+   if (node == NULL)
+   return NULL;
+
+   /* check */
+   if (of_node_cmp(node->full_name, full_name) == 0)
+   return node;
+
+   __for_each_child_of_node(node, child) {
+   found = __of_find_node_by_full_name(child, full_name);
+   if (found != NULL)
+   return found;
+   }
+
+   return NULL;
+}
+EXPORT_SYMBOL(__of_find_node_by_full_name);
+
+/**
+ * of_find_node_by_full_name - Find a node with the full name recursively
+ * @node:  Root of the tree to perform the search
+ * @full_name: Full name of the node to find.
+ *
+ * Find a node with the give full name by recursively following any of
+ * the child node links.
+ * Returns the matching node (with a ref taken), or NULL if not found.
+ */
+struct device_node *of_find_node_by_full_name(struct device_node *node,
+   const char *full_name)
+{
+   unsigned long flags;
+   struct device_node *np;
+
+   raw_spin_lock_irqsave(_lock, flags);
+   np = of_find_node_by_full_name(node, full_name);
+   of_node_get(np);
+   raw_spin_unlock_irqrestore(_lock, flags);
+
+   return np;
+}
+EXPORT_SYMBOL(of_find_node_by_full_name);
+
+/**
  * of_property_read_u32_index - Find and read a u32 from a multi-value 
property.
  *
  * @np:device node from which the property value is to be read.
diff --git a/include/linux/of.h b/include/linux/of.h
index a8b9dad..bef3d5b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -223,6 +223,10 @@ extern struct device_node *of_find_matching_node_and_match(
 
 extern struct device_node *of_find_node_by_path(const char *path);
 extern struct device_node *of_find_node_by_phandle(phandle handle);
+struct device_node *__of_find_node_by_full_name(struct device_node *node,
+   const char *full_name);
+struct device_node *of_find_node_by_full_name(struct device_node *node,
+   const char *full_name);
 extern struct device_node *of_get_parent(const struct device_node *node);
 extern struct device_node *of_get_next_parent(struct device_node *node);
 extern struct device_node *of_get_next_child(const struct device_node *node,
-- 
1.7.12

--
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 0/4] RDSEED support for the Linux kernel

[tytso]

On Mon, Mar 17, 2014 at 04:36:26PM -0700, H. Peter Anvin wrote:
> Changes since version 1:
> 
> a. Rebased on top of random.git:dev.
> b. Unbreak the PowerPC build (I had managed to miss that PowerPC had
>grown archrandom.h support.)
> c. Remove duplicate dummy function definitions in .
> d. Add a fourth patch containing a microoptimization: avoid the loop
>in arch_random_refill() if arch_get_random_seed*() is unavailable.
> 
> Comments are, of course, appreciated.
> 
> Ted, if you are OK with this could you add this to random.git:dev so
> linux-next can pick it up?

Thanks, applied to the random.git tree.

- Ted
--
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/5] Add Broadcom Kona PWM Support

[Thierry Reding]

On Fri, Mar 14, 2014 at 09:43:24AM -0400, Matt Porter wrote:
> On Wed, Mar 12, 2014 at 01:15:41PM -0700, Tim Kryger wrote:
> > This series introduces the driver for the Kona PWM controller found in
> > Broadcom mobile SoCs like bcm281xx and updates the device tree and the
> > defconfig to enable use of this hardware on the bcm28155 AP board.
> > 
> > Changes since v2:
> >   - SoC DTS file updated to use real clock's phandle + specifier
> >   - Toggle smooth mode off during apply so new settings take immediately
> > 
> > Changes since v1:
> >   - Fixed up macros to be clearer and more complete
> >   - Corrected spelling and punctuation mistakes
> >   - Added support for polarity
> >   - Made peripheral clock use more efficient
> >   - Made prescale and duty computation clearer
> >   - Moved Makefile addition to keep alphabetical
> >   - Split complex lines into multiple steps
> > 
> > Dependencies:
> > The "ARM: dts: Declare the PWM for bcm11351 (bcm281xx)" patch depends
> > upon "ARM: dts: bcm281xx: define real clocks" which is queued up in
> > for-next of arm-soc. See https://lkml.org/lkml/2014/2/14/451
> > 
> > Tim Kryger (5):
> >   Documentation: dt: Add Kona PWM binding
> >   pwm: kona: Introduce Kona PWM controller support
> 
> Thierry, are you planning to merge these first two for 3.15? If so, I
> will apply dts patches for my last mach-bcm 3.15 pull. I don't want to
> do so until the binding is accepted.

I've reviewed this and it doesn't look like 3.15 material.

Thierry


pgpaz7SbZ_cDC.pgp
Description: PGP signature

Re: [PATCH v3 2/5] pwm: kona: Introduce Kona PWM controller support

[Thierry Reding]

On Wed, Mar 12, 2014 at 01:15:43PM -0700, Tim Kryger wrote:
[...]
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 22f2f28..1fd42af 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -62,6 +62,16 @@ config PWM_ATMEL_TCB
> To compile this driver as a module, choose M here: the module
> will be called pwm-atmel-tcb.
>  
> +config PWM_BCM_KONA
> + tristate "Kona PWM support"
> + depends on ARCH_BCM_MOBILE
> + default y

No "default y", please.

> diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
[...]
> +static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan)
> +{
> + unsigned long value = readl(kp->base + PWM_CONTROL_OFFSET);
> +
> + /*
> +  * New duty and period settings are only reflected in the PWM output
> +  * after a rising edge of the enable bit.  When smooth bit is set, the
> +  * new settings are delayed until the prior PWM period has completed.
> +  * Furthermore, if the smooth bit is set, the PWM continues to output a
> +  * waveform based on the old settings during the time that the enable
> +  * bit is low.  Otherwise the output is a constant high signal while
> +  * the enable bit is low.
> +  */
> +
> + /* clear enable bit but set smooth bit to maintain old output */
> + value |= (1 << PWM_CONTROL_SMOOTH_SHIFT(chan));

There's no need for the parentheses here.

> + value &= ~(1 << PWM_CONTROL_ENABLE_SHIFT(chan));
> + writel(value, kp->base + PWM_CONTROL_OFFSET);
> +
> + /* set enable bit and clear smooth bit to apply new settings */
> + value &= ~(1 << PWM_CONTROL_SMOOTH_SHIFT(chan));
> + value |= (1 << PWM_CONTROL_ENABLE_SHIFT(chan));

Nor here.

> + writel(value, kp->base + PWM_CONTROL_OFFSET);

I'm curious about how this work. The above writes the control register
once with smooth set and enable cleared, then immediately rewrites it
again with smooth cleared and enable set. Are these writes somehow
queued in hardware, so that the subsequent write becomes active only
after the current period?

> +static int kona_pwmc_config(struct pwm_chip *chip, struct pwm_device *pwm,
> + int duty_ns, int period_ns)

Please align arguments on subsequent lines with those on the first line.

> +{
> + struct kona_pwmc *kp = dev_get_drvdata(chip->dev);

The proper way to do this would be upcasting using container_of().
Better yet, define a static inline function that wraps container_of(),
just like very other driver does.

> + u64 val, div, clk_rate;
> + unsigned long prescale = PRESCALE_MIN, pc, dc;
> + unsigned int value, chan = pwm->hwpwm;
> +
> + /*
> +  * Find period count, duty count and prescale to suit duty_ns and
> +  * period_ns. This is done according to formulas described below:
> +  *
> +  * period_ns = 10^9 * (PRESCALE + 1) * PC / PWM_CLK_RATE
> +  * duty_ns = 10^9 * (PRESCALE + 1) * DC / PWM_CLK_RATE
> +  *
> +  * PC = (PWM_CLK_RATE * period_ns) / (10^9 * (PRESCALE + 1))
> +  * DC = (PWM_CLK_RATE * duty_ns) / (10^9 * (PRESCALE + 1))
> +  */
> +
> + clk_rate = clk_get_rate(kp->clk);

"rate" is 50% shorter and would do equally well.

> +
> + /* There is polarity support in HW but it is easier to manage in SW */
> + if (pwm->polarity == PWM_POLARITY_INVERSED)
> + duty_ns = period_ns - duty_ns;

No, this is wrong. You're not actually changing the *polarity* here.

Also I think this is missing a pair of clk_prepare_enable() and
clk_disable_unprepare().

> +static int kona_pwmc_set_polarity(struct pwm_chip *chip, struct pwm_device 
> *pwm,
> +   enum pwm_polarity polarity)
> +{
> + /*
> +  * The framework only allows the polarity to be changed when a PWM is
> +  * disabled so no immediate action is required here.  When a channel is
> +  * enabled, the polarity gets handled as part of the re-config step.
> +  */
> +
> + return 0;
> +}

See above. If you don't want to implement the hardware support for
inversed polarity, then simply don't implement this.

> +static int kona_pwmc_enable(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct kona_pwmc *kp = dev_get_drvdata(chip->dev);
> + int ret;
> +
> + /*
> +  * The PWM framework does not clear the enable bit in the flags if an
> +  * error is returned from a PWM driver's enable function so it must be
> +  * cleared here if any trouble is encountered.
> +  */
> +
> + ret = clk_prepare_enable(kp->clk);
> + if (ret < 0) {
> + dev_err(chip->dev, "failed to enable clock: %d\n", ret);
> + clear_bit(PWMF_ENABLED, >flags);

You're not supposed to touch these. This is a bug in the core, and it
should be fixed in the core.

> + return ret;
> + }
> +
> + ret = kona_pwmc_config(chip, pwm, pwm->duty_cycle, pwm->period);
> + if (ret < 0) {
> +

[PATCH] of: Make of_find_node_by_path() handle /aliases

[Pantelis Antoniou]

Make of_find_node_by_path() handle aliases as prefixes.

Originally by David Daney , but
reworked according to remark by Grant Likely.

Handles all cases without allocating memory as requested by
Grant Likely 

Signed-off-by: Pantelis Antoniou 
---
 drivers/of/base.c | 69 +++
 1 file changed, 65 insertions(+), 4 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 7083fad..19bcdb4 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -773,22 +773,83 @@ EXPORT_SYMBOL(of_get_child_by_name);
 /**
  * of_find_node_by_path - Find a node matching a full OF path
  * @path:  The full path to match
+ * @path: Either the full path to match, or if the path does not
+ *start with '/', the name of a property of the /aliases
+ *node (an alias).  In the case of an alias, the node
+ *matching the alias' value will be returned.
+ *
+ * Valid paths:
+ * /foo/barFull path
+ * foo Valid alias
+ * foo/bar Valid alias + relative path
  *
  * Returns a node pointer with refcount incremented, use
  * of_node_put() on it when done.
  */
 struct device_node *of_find_node_by_path(const char *path)
 {
-   struct device_node *np = of_allnodes;
+   struct device_node *np = NULL;
+   int len;
+   const char *p = NULL;
+   struct property *prop;
unsigned long flags;
 
+   /* under lock (not very nice) */
raw_spin_lock_irqsave(_lock, flags);
-   for (; np; np = np->allnext) {
-   if (np->full_name && (of_node_cmp(np->full_name, path) == 0)
-   && of_node_get(np))
+
+   len = strlen(path);
+
+   /* path begins with an alias */
+   if (path[0] != '/') {
+
+   /* now find the relative path (if any)*/
+   p = strchr(path, '/');
+   if (p != NULL)
+   len = p - path;
+
+   /* of_aliases must not be NULL */
+   if (!of_aliases)
+   goto out;
+
+   /* find matching alias */
+   for_each_property_of_node(of_aliases, prop)
+   if (strlen(prop->name) == len &&
+   strncmp(prop->name, path, len) == 0)
+   break;
+
+   /* not found; bail */
+   if (prop == NULL)
+   goto out;
+
+   path = prop->value;
+   }
+
+   /* path lookup */
+   for_each_of_allnodes(np) {
+
+   if (!np->full_name)
+   continue;
+
+   if (p == NULL) {
+   /* full component */
+   if (strcasecmp(np->full_name, path) != 0)
+   continue;
+   } else {
+   /* last component (including '/') */
+   if (strncasecmp(np->full_name, path, len) != 0)
+   continue;
+
+   if (strcasecmp(np->full_name + len, p) != 0)
+   continue;
+   }
+
+   if (of_node_get(np))
break;
}
+
+out:
raw_spin_unlock_irqrestore(_lock, flags);
+
return np;
 }
 EXPORT_SYMBOL(of_find_node_by_path);
-- 
1.7.12

--
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] OF: Utility helper functions for dynamic nodes

[Pantelis Antoniou]

Introduce helper functions for working with the live DT tree,
all of them related to dynamically adding/removing nodes and
properties.

__of_free_property() frees a dynamically created property
__of_free_tree() recursively frees a device node tree
__of_copy_property() copies a property dynamically
__of_create_empty_node() creates an empty node

Bug fix about prop->len == 0 by Ionut Nicu 

Signed-off-by: Pantelis Antoniou 
---
 drivers/of/Makefile |   2 +-
 drivers/of/util.c   | 210 
 include/linux/of.h  |  55 ++
 3 files changed, 266 insertions(+), 1 deletion(-)
 create mode 100644 drivers/of/util.c

diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index ed9660a..26de2ed 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,4 +1,4 @@
-obj-y = base.o device.o platform.o
+obj-y = base.o device.o platform.o util.o
 obj-$(CONFIG_OF_FLATTREE) += fdt.o
 obj-$(CONFIG_OF_PROMTREE) += pdt.o
 obj-$(CONFIG_OF_ADDRESS)  += address.o
diff --git a/drivers/of/util.c b/drivers/of/util.c
new file mode 100644
index 000..df747af
--- /dev/null
+++ b/drivers/of/util.c
@@ -0,0 +1,210 @@
+/*
+ * Utility functions for working with device tree(s)
+ *
+ * Copyright (C) 2012 Pantelis Antoniou 
+ * Copyright (C) 2012 Texas Instruments Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * __of_free_property - release the memory of an allocated property
+ * @prop:  Property to release
+ *
+ * Release the memory of an allocated property only after checking
+ * that the property has been marked as OF_DYNAMIC.
+ * Only call on known allocated properties.
+ */
+void __of_free_property(struct property *prop)
+{
+   if (prop == NULL)
+   return;
+
+   if (of_property_check_flag(prop, OF_DYNAMIC)) {
+   if (of_property_check_flag(prop, OF_ALLOCVALUE))
+   kfree(prop->value);
+   if (of_property_check_flag(prop, OF_ALLOCNAME))
+   kfree(prop->name);
+   kfree(prop);
+   }
+}
+
+/**
+ * __of_free_tree - release the memory of a device tree node and
+ * of all it's children + properties.
+ * @node:  Device Tree node to release
+ *
+ * Release the memory of a device tree node and of all it's children.
+ * Also release the properties and the dead properties.
+ * Only call on detached node trees, and you better be sure that
+ * no pointer exist for any properties. Only safe to do if you
+ * absolutely control the life cycle of the node.
+ * Also note that the node is not removed from the all_nodes list,
+ * neither from the parent's child list; this should be handled before
+ * calling this function.
+ */
+void __of_free_tree(struct device_node *node)
+{
+   struct property *prop;
+   struct device_node *noden;
+
+   /* sanity check */
+   if (!node)
+   return;
+
+   /* free recursively any children */
+   while ((noden = node->child) != NULL) {
+   node->child = noden->sibling;
+   __of_free_tree(noden);
+   }
+
+   /* free every property already allocated */
+   while ((prop = node->properties) != NULL) {
+   node->properties = prop->next;
+   __of_free_property(prop);
+   }
+
+   /* free dead properties already allocated */
+   while ((prop = node->deadprops) != NULL) {
+   node->deadprops = prop->next;
+   __of_free_property(prop);
+   }
+
+   if (of_node_check_flag(node, OF_DYNAMIC)) {
+   if (of_node_check_flag(node, OF_ALLOCFULL))
+   kfree(node->full_name);
+   if (of_node_check_flag(node, OF_ALLOCTYPE))
+   kfree(node->type);
+   if (of_node_check_flag(node, OF_ALLOCNAME))
+   kfree(node->name);
+   kfree(node);
+   }
+}
+
+/**
+ * __of_copy_property - Copy a property dynamically.
+ * @prop:  Property to copy
+ * @allocflags:Allocation flags (typically pass GFP_KERNEL)
+ * @propflags: Property flags
+ *
+ * Copy a property by dynamically allocating the memory of both the
+ * property stucture and the property name & contents. The property's
+ * flags have the OF_DYNAMIC bit set so that we can differentiate between
+ * dynamically allocated properties and not.
+ * Returns the newly allocated property or NULL on out of memory error.
+ */
+struct property *__of_copy_property(const struct property *prop,
+   gfp_t allocflags, unsigned long propflags)
+{
+   struct property *propn;
+
+   propn = kzalloc(sizeof(*prop), allocflags);
+   if (propn == NULL)
+   return NULL;
+
+

[PATCH] rcu: Convert rcu_dereference to rcu_access_pointer in drivers/net/ethernet/broadcom/cnic.c

[Monam Agarwal]

This patch converts rcu_dereference to rcu_access_pointer if its returned value 
is not used

Signed-off-by: Monam Agarwal 

Reviewed-by: Paul E. McKenney 

---
 drivers/net/ethernet/broadcom/cnic.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/cnic.c 
b/drivers/net/ethernet/broadcom/cnic.c
index 6f10c69..42fb026 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -355,7 +355,7 @@ static int cnic_iscsi_nl_msg_recv(struct cnic_dev *dev, u32 
msg_type,
break;
 
rcu_read_lock();
-   if (!rcu_dereference(cp->ulp_ops[CNIC_ULP_L4])) {
+   if (!rcu_access_pointer(cp->ulp_ops[CNIC_ULP_L4])) {
rc = -ENODEV;
rcu_read_unlock();
break;
-- 
1.7.9.5

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

Re: [RFC] QR encoding for Oops messages

[Matthew Garrett]

On Mon, Mar 17, 2014 at 02:59:47PM -0700, Teodora Baluta wrote:

> As far as decoding is concerned, there are a lot of apps on mobile devices
> that decode QR codes (just text mostly). In order to make this work, an
> app which also decodes the QR code is needed. I will be working the next
> couple of weeks on an Android app which scans the Oops encoding QR and
> sends it to a server which keeps track of these Oopses that are sent to
> it making a sort of stream of the latest Oopses. Any thoughts on what the best
> workflow would be are more than welcomed.

When I was thinking about doing this a while ago, my plan was to simply 
encode the oops as a URL - that way existing QR reader software would 
work and there's no need to write a specialised application. I also 
registered the domain kbu.gs to provide the service. Obviously I never 
got around to actually writing the code, so this is great!

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

Re: [PATCH v2 11/15] arm64: add EFI stub

[Roy Franz]

On Tue, Mar 18, 2014 at 2:40 PM, Mark Salter  wrote:
> On Tue, 2014-03-18 at 18:28 +, Catalin Marinas wrote:
>> On Tue, Mar 18, 2014 at 02:40:29PM +, Mark Salter wrote:
>> > On Tue, 2014-03-18 at 12:09 +, Catalin Marinas wrote:
>> > > On Thu, Mar 13, 2014 at 10:47:04PM +, Leif Lindholm wrote:
>> > > > --- /dev/null
>> > > > +++ b/arch/arm64/kernel/efi-entry.S
>> > > > @@ -0,0 +1,93 @@
>> > > > +/*
>> > > > + * EFI entry point.
>> > > > + *
>> > > > + * Copyright (C) 2013 Red Hat, Inc.
>> > > > + * Author: Mark Salter 
>> > > > + *
>> > > > + * This program is free software; you can redistribute it and/or 
>> > > > modify
>> > > > + * it under the terms of the GNU General Public License version 2 as
>> > > > + * published by the Free Software Foundation.
>> > > > + *
>> > > > + */
>> > > > +#include 
>> > > > +#include 
>> > > > +
>> > > > +#include 
>> > > > +
>> > > > +#define EFI_LOAD_ERROR 0x8001
>> > > > +
>> > > > +   __INIT
>> > > > +
>> > > > +   /*
>> > > > +* We arrive here from the EFI boot manager with:
>> > > > +*
>> > > > +** MMU on with identity-mapped RAM.
>> > > > +** Icache and Dcache on
>> > > > +*
>> > > > +* We will most likely be running from some place other than 
>> > > > where
>> > > > +* we want to be. The kernel image wants to be placed at 
>> > > > TEXT_OFFSET
>> > > > +* from start of RAM.
>> > > > +*/
>> > > > +ENTRY(efi_stub_entry)
>> > > > +   stp x29, x30, [sp, #-32]!
>> > > > +
>> > > > +   /*
>> > > > +* Call efi_entry to do the real work.
>> > > > +* x0 and x1 are already set up by firmware. Current runtime
>> > > > +* address of image is calculated and passed via *image_addr.
>> > > > +*
>> > > > +* unsigned long efi_entry(void *handle,
>> > > > +* efi_system_table_t *sys_table,
>> > > > +* unsigned long *image_addr) ;
>> > > > +*/
>> > > > +   adrpx8, _text
>> > > > +   add x8, x8, #:lo12:_text
>> > > > +   add x2, sp, 16
>> > > > +   str x8, [x2]
>> > > > +   bl  efi_entry
>> > > > +   cmn x0, #1
>> > > > +   b.eqefi_load_fail
>> > > > +
>> > > > +   /*
>> > > > +* efi_entry() will have relocated the kernel image if 
>> > > > necessary
>> > > > +* and we return here with device tree address in x0 and the 
>> > > > kernel
>> > > > +* entry point stored at *image_addr. Save those values in 
>> > > > registers
>> > > > +* which are preserved by __flush_dcache_all.
>> > > > +*/
>> > > > +   ldr x1, [sp, #16]
>> > > > +   mov x20, x0
>> > > > +   mov x21, x1
>> > > > +
>> > > > +   /* Turn off Dcache and MMU */
>> > > > +   mrs x0, CurrentEL
>> > > > +   cmp x0, #PSR_MODE_EL2t
>> > > > +   ccmpx0, #PSR_MODE_EL2h, #0x4, ne
>> > > > +   b.ne1f
>> > > > +   mrs x0, sctlr_el2
>> > > > +   bic x0, x0, #1 << 0 // clear SCTLR.M
>> > > > +   bic x0, x0, #1 << 2 // clear SCTLR.C
>> > > > +   msr sctlr_el2, x0
>> > > > +   isb
>> > > > +   b   2f
>> > > > +1:
>> > > > +   mrs x0, sctlr_el1
>> > > > +   bic x0, x0, #1 << 0 // clear SCTLR.M
>> > > > +   bic x0, x0, #1 << 2 // clear SCTLR.C
>> > > > +   msr sctlr_el1, x0
>> > > > +   isb
>> > > > +2:
>> > > > +   bl  __flush_dcache_all
>> > >
>> > > In linux-next I'm pushing a patch which no longer exports the
>> > > __flush_dcache_all function. The reason is that it doesn't really work
>> > > if you have a (not fully transparent) external cache like on the Applied
>> > > Micro boards. There other issues when running as a guest as well.
>> > >
>> > > If you know exactly what needs to be flushed here, can you use a range
>> > > (MVA) operation?
>> >
>> > This is just before the EFI stub jumps to kernel proper. The only things
>> > in the dcache would be from identity mapped references to RAM used by
>> > UEFI. The booting.txt doc says dcache should be off and invalidated. I
>> > am just wanting to comply with that. The code here doesn't really know
>> > the extent of DRAM to flush by address.
>>
>> Does UEFI do anything with the caches before invoking the EFI_STUB code?
>> I guess it doesn't since that's just another application for it. Can
>> UEFI flush the caches via exit boot? When is this called?
>>
>> As I said, we have a real problem here since the EFI_STUB call does not
>> have information about the SoC to be able to flush all the caches. But
>> UEFI should know more about the hardware.
>>
>> If UEFI doesn't handle the caches, the only thing left to EFI_STUB is to
>> flush by MVA. We don't need to flush the whole DRAM (and I would even
>> recommend it) but at least the relevant kernel code/data touched with
>> the MMU disabled.
>>
>
> So, it goes like 

Re: [PATCH v3 1/5] Documentation: dt: Add Kona PWM binding

[Tim Kryger]

On Tue, Mar 18, 2014 at 2:18 PM, Thierry Reding
 wrote:
> On Wed, Mar 12, 2014 at 01:15:42PM -0700, Tim Kryger wrote:

>> @@ -0,0 +1,24 @@
>> +Broadcom Kona PWM controller device tree bindings
>> +
>> +This controller has 6 channels.
>> +
>> +Required Properties :
>> +- compatible: should be "brcm,kona-pwm"
>
> This is somewhat inconsistent because the example below clearly doesn't
> set the compatible property to "brcm,kona-pwm". Perhaps better wording
> would be:
>
> - compatible: should contain "brcm,kona-pwm"

Agreed, what you wrote is more accurate.  I will update it.

>> +- reg: physical base address and length of the controller's registers
>> +- clocks: phandle + clock specifier pair for the external clock
>> +- #pwm-cells: should be 3.  The first cell specifies the per-chip index
>> +  of the PWM to use, the second cell is the period in nanoseconds, and
>> +  the third cell is the flags.
>
> Please use the canonical description for this:
>
> - #pwm-cells: Should be 3. See pwm.txt in this directory for a
>   description of the cells format.
>
>> +Refer to pwm/pwm.txt for generic pwm controller node properties.
>
> With the above, this line should go away. But still: "pwm controller" ->
> "PWM controller".

Okay.  I will use the text you provided and drop the other line.

Sorry for missing the capitalization.  I thought I had fixed them all.

Thanks,
Tim
--
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: rb tree hrtimer lockup bug (found by perf_fuzzer)

[Thomas Gleixner]

On Tue, 18 Mar 2014, Vince Weaver wrote:

> On Tue, 18 Mar 2014, Thomas Gleixner wrote:
> > 
> > > [3.678040] BUG: unable to handle kernel NULL pointer dereference at 
> > > 0018  
> > >   
> > > [3.686776] IP: [] 
> > > get_next_timer_interrupt+0x168/0x250
> > 
> > The back trace is not really helpful. Is there anything before that
> > BUG in dmesg?
> 
> no, just normal boot messages.
> 
> I re-compiled with the frame pointer enabled and here's an updated 
> version:
> 
> [3.722836] sd 1:0:0:0: [sda] 4096-byte physical blocks
>   
> [3.728682] sd 1:0:0:0: [sda] Write Protect is off 
>   
> [3.728826] sr 0:0:0:0: Attached scsi generic sg0 type 5   
>   
> [3.728992] sd 1:0:0:0: Attached scsi generic sg1 type 0   
>   
> [3.745700] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
> doesn't support DPO or FUA
>   
> [3.787096]  sda: sda1 sda2 sda3 sda4  
>   
> [3.792169] sd 1:0:0:0: [sda] Attached SCSI disk   
>   
> [4.312111] [ cut here ]   
>   
> [4.317176] kernel BUG at kernel/timer.c:1084! 
>   

Wow. That's in the cascade code. So it looks like the timer got
corrupted without using the timer api wrong. That might be a memset or
a stray pointer. Can you apply the following patch?

That really should give us a hint.

If that fails, enable the tracer in your config and add the following
to your commandline

   trace_event=timer_* ftrace_dump_on_oops

That will spill out a lot of crap over serial, but it should tell us
which timer is corrupted.

Thanks,

tglx

Index: linux-2.6/include/linux/debugobjects.h
===
--- linux-2.6.orig/include/linux/debugobjects.h
+++ linux-2.6/include/linux/debugobjects.h
@@ -68,6 +68,7 @@ extern void debug_object_deactivate(void
 extern void debug_object_destroy   (void *addr, struct debug_obj_descr *descr);
 extern void debug_object_free  (void *addr, struct debug_obj_descr *descr);
 extern void debug_object_assert_init(void *addr, struct debug_obj_descr 
*descr);
+extern void debug_object_info(void *addr, struct debug_obj_descr *descr);
 
 /*
  * Active state:
@@ -95,6 +96,8 @@ static inline void
 debug_object_free  (void *addr, struct debug_obj_descr *descr) { }
 static inline void
 debug_object_assert_init(void *addr, struct debug_obj_descr *descr) { }
+static inline void
+debug_object_info(void *addr, struct debug_obj_descr *descr) { }
 
 static inline void debug_objects_early_init(void) { }
 static inline void debug_objects_mem_init(void) { }
Index: linux-2.6/kernel/timer.c
===
--- linux-2.6.orig/kernel/timer.c
+++ linux-2.6/kernel/timer.c
@@ -1081,7 +1081,12 @@ static int cascade(struct tvec_base *bas
 * don't have to detach them individually.
 */
list_for_each_entry_safe(timer, tmp, _list, entry) {
-   BUG_ON(tbase_get_base(timer->base) != base);
+   if (tbase_get_base(timer->base) != base) {
+   pr_err("Invalid timer base: tmr %p tmr->base %p base 
%p\n",
+  timer, timer->base, base);
+   debug_object_info(timer, _debug_descr);
+   BUG();
+   }
/* No accounting, while moving them */
__internal_add_timer(base, timer);
}
Index: linux-2.6/lib/debugobjects.c
===
--- linux-2.6.orig/lib/debugobjects.c
+++ linux-2.6/lib/debugobjects.c
@@ -377,6 +377,28 @@ void debug_object_init_on_stack(void *ad
__debug_object_init(addr, descr, 1);
 }
 
+void debug_object_info(void *addr, struct debug_obj_descr *descr)
+{
+   struct debug_bucket *db;
+   struct debug_obj *obj;
+   unsigned long flags;
+
+   if (!debug_objects_enabled)
+   return;
+
+   db = get_bucket((unsigned long) addr);
+
+   raw_spin_lock_irqsave(>lock, flags);
+
+   obj = lookup_object(addr, db);
+   if (!obj)
+   pr_err("Object unknown %p\n", addr);
+   else
+   debug_print_object(obj, "Info");
+
+   raw_spin_unlock_irqrestore(>lock, flags);
+}
+
 /**
  * debug_object_activate - debug checks when an object is activated
  * @addr:  address of the object
--
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 v9 2/2] ARM hibernation / suspend-to-disk

[Sebastian Capella]

From: Russ Dill 

Enable hibernation for ARM architectures and provide ARM
architecture specific calls used during hibernation.

The swsusp hibernation framework depends on the
platform first having functional suspend/resume.

Then, in order to enable hibernation on a given platform, a
platform_hibernation_ops structure may need to be registered with
the system in order to save/restore any SoC-specific / cpu specific
state needing (re)init over a suspend-to-disk/resume-from-disk cycle.

For example:

 - "secure" SoCs that have different sets of control registers
   and/or different CR reg access patterns.

 - SoCs with L2 caches as the activation sequence there is
   SoC-dependent; a full off-on cycle for L2 is not done
   by the hibernation support code.

 - SoCs requiring steps on wakeup _before_ the "generic" parts
   done by cpu_suspend / cpu_resume can work correctly.

 - SoCs having persistent state which is maintained during suspend
   and resume, but will be lost during the power off cycle after
   suspend-to-disk.

This is a rebase/rework of Frank Hofmann's v5 hibernation patchset.

Acked-by: Russ Dill 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Sebastian Capella 
Acked-by: Pavel Machek 
Reviewed-by: Lorenzo Pieralisi 
Cc: Russell King 
Cc: Len Brown 
Cc: Nicolas Pitre 
Cc: Santosh Shilimkar 
Cc: Will Deacon 
Cc: Jonathan Austin 
Cc: Catalin Marinas 
Cc: "Uwe Kleine-König" 
Cc: Stephen Boyd 
Cc: Stefano Stabellini 
Cc: Sricharan R 
Cc: Jiang Liu 
Cc: Laura Abbott 
---
 arch/arm/Kconfig  |5 ++
 arch/arm/include/asm/memory.h |1 +
 arch/arm/kernel/Makefile  |1 +
 arch/arm/kernel/hibernate.c   |  107 +
 include/linux/suspend.h   |2 +
 5 files changed, 116 insertions(+)
 create mode 100644 arch/arm/kernel/hibernate.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1594945..d204231 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2279,6 +2279,11 @@ config ARCH_SUSPEND_POSSIBLE
 config ARM_CPU_SUSPEND
def_bool PM_SLEEP
 
+config ARCH_HIBERNATION_POSSIBLE
+   bool
+   depends on MMU
+   default y if ARCH_SUSPEND_POSSIBLE
+
 endmenu
 
 source "net/Kconfig"
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 4afb376..47347dd 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -289,6 +289,7 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define __pa(x)__virt_to_phys((unsigned long)(x))
 #define __va(x)((void 
*)__phys_to_virt((phys_addr_t)(x)))
 #define pfn_to_kaddr(pfn)  __va((pfn) << PAGE_SHIFT)
+#define virt_to_pfn(kaddr)  (__pa(kaddr) >> PAGE_SHIFT)
 
 extern phys_addr_t (*arch_virt_to_idmap)(unsigned long x);
 
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index a30fc9b..8afa848 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_ARTHUR)  += arthur.o
 obj-$(CONFIG_ISA_DMA)  += dma-isa.o
 obj-$(CONFIG_PCI)  += bios32.o isa.o
 obj-$(CONFIG_ARM_CPU_SUSPEND)  += sleep.o suspend.o
+obj-$(CONFIG_HIBERNATION)  += hibernate.o
 obj-$(CONFIG_SMP)  += smp.o
 ifdef CONFIG_MMU
 obj-$(CONFIG_SMP)  += smp_tlb.o
diff --git a/arch/arm/kernel/hibernate.c b/arch/arm/kernel/hibernate.c
new file mode 100644
index 000..bb8b796
--- /dev/null
+++ b/arch/arm/kernel/hibernate.c
@@ -0,0 +1,107 @@
+/*
+ * Hibernation support specific for ARM
+ *
+ * Derived from work on ARM hibernation support by:
+ *
+ * Ubuntu project, hibernation support for mach-dove
+ * Copyright (C) 2010 Nokia Corporation (Hiroshi Doyu)
+ * Copyright (C) 2010 Texas Instruments, Inc. (Teerth Reddy et al.)
+ *  https://lkml.org/lkml/2010/6/18/4
+ *  https://lists.linux-foundation.org/pipermail/linux-pm/2010-June/027422.html
+ *  https://patchwork.kernel.org/patch/96442/
+ *
+ * Copyright (C) 2006 Rafael J. Wysocki 
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+extern const void __nosave_begin, __nosave_end;
+
+int pfn_is_nosave(unsigned long pfn)
+{
+   unsigned long nosave_begin_pfn = virt_to_pfn(&__nosave_begin);
+   unsigned long nosave_end_pfn = virt_to_pfn(&__nosave_end - 1);
+
+   return (pfn >= nosave_begin_pfn) && (pfn <= nosave_end_pfn);
+}
+
+void notrace save_processor_state(void)
+{
+   WARN_ON(num_online_cpus() != 1);
+   local_fiq_disable();
+}
+
+void notrace restore_processor_state(void)
+{
+   local_fiq_enable();
+}
+
+/*
+ * Snapshot kernel memory and reset the system.
+ *
+ * swsusp_save() is executed in the suspend finisher so that the CPU
+ * context pointer and memory are part of the saved image, which is
+ * required by the resume kernel image to restart execution from
+ * swsusp_arch_suspend().
+ *
+ * soft_restart is not 

Re: [PATCH v2 11/15] arm64: add EFI stub

[Mark Salter]

On Tue, 2014-03-18 at 18:28 +, Catalin Marinas wrote:
> On Tue, Mar 18, 2014 at 02:40:29PM +, Mark Salter wrote:
> > On Tue, 2014-03-18 at 12:09 +, Catalin Marinas wrote:
> > > On Thu, Mar 13, 2014 at 10:47:04PM +, Leif Lindholm wrote:
> > > > --- /dev/null
> > > > +++ b/arch/arm64/kernel/efi-entry.S
> > > > @@ -0,0 +1,93 @@
> > > > +/*
> > > > + * EFI entry point.
> > > > + *
> > > > + * Copyright (C) 2013 Red Hat, Inc.
> > > > + * Author: Mark Salter 
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or modify
> > > > + * it under the terms of the GNU General Public License version 2 as
> > > > + * published by the Free Software Foundation.
> > > > + *
> > > > + */
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#include 
> > > > +
> > > > +#define EFI_LOAD_ERROR 0x8001
> > > > +
> > > > +   __INIT
> > > > +
> > > > +   /*
> > > > +* We arrive here from the EFI boot manager with:
> > > > +*
> > > > +** MMU on with identity-mapped RAM.
> > > > +** Icache and Dcache on
> > > > +*
> > > > +* We will most likely be running from some place other than 
> > > > where
> > > > +* we want to be. The kernel image wants to be placed at 
> > > > TEXT_OFFSET
> > > > +* from start of RAM.
> > > > +*/
> > > > +ENTRY(efi_stub_entry)
> > > > +   stp x29, x30, [sp, #-32]!
> > > > +
> > > > +   /*
> > > > +* Call efi_entry to do the real work.
> > > > +* x0 and x1 are already set up by firmware. Current runtime
> > > > +* address of image is calculated and passed via *image_addr.
> > > > +*
> > > > +* unsigned long efi_entry(void *handle,
> > > > +* efi_system_table_t *sys_table,
> > > > +* unsigned long *image_addr) ;
> > > > +*/
> > > > +   adrpx8, _text
> > > > +   add x8, x8, #:lo12:_text
> > > > +   add x2, sp, 16
> > > > +   str x8, [x2]
> > > > +   bl  efi_entry
> > > > +   cmn x0, #1
> > > > +   b.eqefi_load_fail
> > > > +
> > > > +   /*
> > > > +* efi_entry() will have relocated the kernel image if necessary
> > > > +* and we return here with device tree address in x0 and the 
> > > > kernel
> > > > +* entry point stored at *image_addr. Save those values in 
> > > > registers
> > > > +* which are preserved by __flush_dcache_all.
> > > > +*/
> > > > +   ldr x1, [sp, #16]
> > > > +   mov x20, x0
> > > > +   mov x21, x1
> > > > +
> > > > +   /* Turn off Dcache and MMU */
> > > > +   mrs x0, CurrentEL
> > > > +   cmp x0, #PSR_MODE_EL2t
> > > > +   ccmpx0, #PSR_MODE_EL2h, #0x4, ne
> > > > +   b.ne1f
> > > > +   mrs x0, sctlr_el2
> > > > +   bic x0, x0, #1 << 0 // clear SCTLR.M
> > > > +   bic x0, x0, #1 << 2 // clear SCTLR.C
> > > > +   msr sctlr_el2, x0
> > > > +   isb
> > > > +   b   2f
> > > > +1:
> > > > +   mrs x0, sctlr_el1
> > > > +   bic x0, x0, #1 << 0 // clear SCTLR.M
> > > > +   bic x0, x0, #1 << 2 // clear SCTLR.C
> > > > +   msr sctlr_el1, x0
> > > > +   isb
> > > > +2:
> > > > +   bl  __flush_dcache_all
> > > 
> > > In linux-next I'm pushing a patch which no longer exports the
> > > __flush_dcache_all function. The reason is that it doesn't really work
> > > if you have a (not fully transparent) external cache like on the Applied
> > > Micro boards. There other issues when running as a guest as well.
> > > 
> > > If you know exactly what needs to be flushed here, can you use a range
> > > (MVA) operation?
> > 
> > This is just before the EFI stub jumps to kernel proper. The only things
> > in the dcache would be from identity mapped references to RAM used by
> > UEFI. The booting.txt doc says dcache should be off and invalidated. I
> > am just wanting to comply with that. The code here doesn't really know
> > the extent of DRAM to flush by address.
> 
> Does UEFI do anything with the caches before invoking the EFI_STUB code?
> I guess it doesn't since that's just another application for it. Can
> UEFI flush the caches via exit boot? When is this called?
> 
> As I said, we have a real problem here since the EFI_STUB call does not
> have information about the SoC to be able to flush all the caches. But
> UEFI should know more about the hardware.
> 
> If UEFI doesn't handle the caches, the only thing left to EFI_STUB is to
> flush by MVA. We don't need to flush the whole DRAM (and I would even
> recommend it) but at least the relevant kernel code/data touched with
> the MMU disabled.
> 

So, it goes like this:

  1) UEFI calls stub with MMU/Caches on. Stub/kernel can be anywhere.
  2) Stub runs and relocates kernel to the desired runtime location
 but continues to execute from 

[PATCH v9 1/2] ARM: avoid tracers in soft_restart

[Sebastian Capella]

Use of tracers in local_irq_disable is causes abort loops when called
with irqs disabled using a temporary stack.  Replace local_irq_disable
with raw_local_irq_disable instead to avoid tracers.

Signed-off-by: Sebastian Capella 
Cc: Russell King 
Cc: Andrew Morton 
Cc: Will Deacon 
Cc: Robin Holt 
Cc: Thomas Gleixner 
Cc: Konstantin Khlebnikov 
Cc: Steven Capper 
Cc: Stephen Warren 
Cc: Tejun Heo 
---
 arch/arm/kernel/process.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 92f7b15..f58b723 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -100,7 +100,7 @@ void soft_restart(unsigned long addr)
u64 *stack = soft_restart_stack + ARRAY_SIZE(soft_restart_stack);
 
/* Disable interrupts first */
-   local_irq_disable();
+   raw_local_irq_disable();
local_fiq_disable();
 
/* Disable the L2 if we're the last man standing. */
-- 
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/

[ANNOUNCE] 3.2.55-rt81

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.2.55-rt81 stable release.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.2-rt
  Head SHA1: 3c8ce5f0a334826f3341a8233503d4748df11a3b


Or to build 3.2.55-rt81 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.55.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.55-rt81.patch.xz



You can also build from 3.2.55-rt80 by applying the incremental patch:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/incr/patch-3.2.55-rt80-rt81.patch.xz



Enjoy,

-- Steve


Changes from v3.2.55-rt80:

---

Marc Kleine-Budde (1):
  net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to 
wait for outstanding qdisc_run calls

Sebastian Andrzej Siewior (1):
  fs: jbd2: pull your plug when waiting for space

Steven Rostedt (1):
  cpu_chill: Add a UNINTERRUPTIBLE hrtimer_nanosleep

Steven Rostedt (Red Hat) (1):
  Linux 3.2.55-rt81


 fs/jbd2/checkpoint.c|  2 ++
 kernel/hrtimer.c| 25 ++---
 localversion-rt |  2 +-
 net/sched/sch_generic.c |  2 +-
 4 files changed, 22 insertions(+), 9 deletions(-)
---
diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
index 16a698b..c6443c3 100644
--- a/fs/jbd2/checkpoint.c
+++ b/fs/jbd2/checkpoint.c
@@ -129,6 +129,8 @@ void __jbd2_log_wait_for_space(journal_t *journal)
if (journal->j_flags & JBD2_ABORT)
return;
write_unlock(>j_state_lock);
+   if (current->plug)
+   io_schedule();
mutex_lock(>j_checkpoint_mutex);
 
/*
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 71acc21..0316f75 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1726,12 +1726,13 @@ void hrtimer_init_sleeper(struct hrtimer_sleeper *sl, 
struct task_struct *task)
 }
 EXPORT_SYMBOL_GPL(hrtimer_init_sleeper);
 
-static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode 
mode)
+static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode 
mode,
+   unsigned long state)
 {
hrtimer_init_sleeper(t, current);
 
do {
-   set_current_state(TASK_INTERRUPTIBLE);
+   set_current_state(state);
hrtimer_start_expires(>timer, mode);
if (!hrtimer_active(>timer))
t->task = NULL;
@@ -1775,7 +1776,8 @@ long __sched hrtimer_nanosleep_restart(struct 
restart_block *restart)
HRTIMER_MODE_ABS);
hrtimer_set_expires_tv64(, restart->nanosleep.expires);
 
-   if (do_nanosleep(, HRTIMER_MODE_ABS))
+   /* cpu_chill() does not care about restart state. */
+   if (do_nanosleep(, HRTIMER_MODE_ABS, TASK_INTERRUPTIBLE))
goto out;
 
rmtp = restart->nanosleep.rmtp;
@@ -1792,8 +1794,10 @@ out:
return ret;
 }
 
-long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,
-  const enum hrtimer_mode mode, const clockid_t clockid)
+static long
+__hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,
+   const enum hrtimer_mode mode, const clockid_t clockid,
+   unsigned long state)
 {
struct restart_block *restart;
struct hrtimer_sleeper t;
@@ -1806,7 +1810,7 @@ long hrtimer_nanosleep(struct timespec *rqtp, struct 
timespec __user *rmtp,
 
hrtimer_init_on_stack(, clockid, mode);
hrtimer_set_expires_range_ns(, timespec_to_ktime(*rqtp), slack);
-   if (do_nanosleep(, mode))
+   if (do_nanosleep(, mode, state))
goto out;
 
/* Absolute timers do not update the rmtp value and restart: */
@@ -1833,6 +1837,12 @@ out:
return ret;
 }
 
+long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,
+  const enum hrtimer_mode mode, const clockid_t clockid)
+{
+   return __hrtimer_nanosleep(rqtp, rmtp, mode, clockid, 
TASK_INTERRUPTIBLE);
+}
+
 SYSCALL_DEFINE2(nanosleep, struct timespec __user *, rqtp,
struct timespec __user *, rmtp)
 {
@@ -1859,7 +1869,8 @@ void cpu_chill(void)
unsigned int freeze_flag = current->flags & PF_NOFREEZE;
 
current->flags |= PF_NOFREEZE;
-   hrtimer_nanosleep(, NULL, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
+   __hrtimer_nanosleep(, NULL, HRTIMER_MODE_REL, CLOCK_MONOTONIC,
+   TASK_UNINTERRUPTIBLE);
if (!freeze_flag)
current->flags &= ~PF_NOFREEZE;
 }
diff --git a/localversion-rt b/localversion-rt
index 5ba2c20..8269ec1 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt80
+-rt81
diff --git 

[ANNOUNCE] 3.8.13.14-rt30

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.8.13.14-rt30 stable release.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.8-rt
  Head SHA1: eb8a811479ff408b938dc4eec456da574bd70270


Or to build 3.8.13.14-rt30 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.8.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.8.13.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/stable/patch-3.8.13.14.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.13.14-rt30.patch.xz



You can also build from 3.8.13.14-rt29 by applying the incremental patch:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/incr/patch-3.8.13.14-rt29-rt30.patch.xz



Enjoy,

-- Steve


Changes from v3.8.13.14-rt29:

---

Marc Kleine-Budde (1):
  net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to 
wait for outstanding qdisc_run calls

Sebastian Andrzej Siewior (2):
  fs: jbd2: pull your plug when waiting for space
  crypto: Reduce preempt disabled regions, more algos

Steven Rostedt (1):
  cpu_chill: Add a UNINTERRUPTIBLE hrtimer_nanosleep

Steven Rostedt (Red Hat) (1):
  Linux 3.8.13.14-rt30


 arch/x86/crypto/cast5_avx_glue.c | 21 +
 arch/x86/crypto/glue_helper.c| 19 +--
 fs/jbd2/checkpoint.c |  2 ++
 kernel/hrtimer.c | 25 ++---
 localversion-rt  |  2 +-
 net/sched/sch_generic.c  |  2 +-
 6 files changed, 40 insertions(+), 31 deletions(-)
---
diff --git a/arch/x86/crypto/cast5_avx_glue.c b/arch/x86/crypto/cast5_avx_glue.c
index c663181..2d48e83 100644
--- a/arch/x86/crypto/cast5_avx_glue.c
+++ b/arch/x86/crypto/cast5_avx_glue.c
@@ -60,7 +60,7 @@ static inline void cast5_fpu_end(bool fpu_enabled)
 static int ecb_crypt(struct blkcipher_desc *desc, struct blkcipher_walk *walk,
 bool enc)
 {
-   bool fpu_enabled = false;
+   bool fpu_enabled;
struct cast5_ctx *ctx = crypto_blkcipher_ctx(desc->tfm);
const unsigned int bsize = CAST5_BLOCK_SIZE;
unsigned int nbytes;
@@ -76,7 +76,7 @@ static int ecb_crypt(struct blkcipher_desc *desc, struct 
blkcipher_walk *walk,
u8 *wsrc = walk->src.virt.addr;
u8 *wdst = walk->dst.virt.addr;
 
-   fpu_enabled = cast5_fpu_begin(fpu_enabled, nbytes);
+   fpu_enabled = cast5_fpu_begin(false, nbytes);
 
/* Process multi-block batch */
if (nbytes >= bsize * CAST5_PARALLEL_BLOCKS) {
@@ -104,10 +104,9 @@ static int ecb_crypt(struct blkcipher_desc *desc, struct 
blkcipher_walk *walk,
} while (nbytes >= bsize);
 
 done:
+   cast5_fpu_end(fpu_enabled);
err = blkcipher_walk_done(desc, walk, nbytes);
}
-
-   cast5_fpu_end(fpu_enabled);
return err;
 }
 
@@ -231,7 +230,7 @@ done:
 static int cbc_decrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
   struct scatterlist *src, unsigned int nbytes)
 {
-   bool fpu_enabled = false;
+   bool fpu_enabled;
struct blkcipher_walk walk;
int err;
 
@@ -240,12 +239,11 @@ static int cbc_decrypt(struct blkcipher_desc *desc, 
struct scatterlist *dst,
desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
 
while ((nbytes = walk.nbytes)) {
-   fpu_enabled = cast5_fpu_begin(fpu_enabled, nbytes);
+   fpu_enabled = cast5_fpu_begin(false, nbytes);
nbytes = __cbc_decrypt(desc, );
+   cast5_fpu_end(fpu_enabled);
err = blkcipher_walk_done(desc, , nbytes);
}
-
-   cast5_fpu_end(fpu_enabled);
return err;
 }
 
@@ -315,7 +313,7 @@ done:
 static int ctr_crypt(struct blkcipher_desc *desc, struct scatterlist *dst,
 struct scatterlist *src, unsigned int nbytes)
 {
-   bool fpu_enabled = false;
+   bool fpu_enabled;
struct blkcipher_walk walk;
int err;
 
@@ -324,13 +322,12 @@ static int ctr_crypt(struct blkcipher_desc *desc, struct 
scatterlist *dst,
desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
 
while ((nbytes = walk.nbytes) >= CAST5_BLOCK_SIZE) {
-   fpu_enabled = cast5_fpu_begin(fpu_enabled, nbytes);
+   fpu_enabled = cast5_fpu_begin(false, nbytes);
nbytes = __ctr_crypt(desc, );
+   cast5_fpu_end(fpu_enabled);
err = blkcipher_walk_done(desc, , nbytes);
}
 
-   cast5_fpu_end(fpu_enabled);
-
if (walk.nbytes) {
ctr_crypt_final(desc, );
err = blkcipher_walk_done(desc, , 0);
diff --git a/arch/x86/crypto/glue_helper.c b/arch/x86/crypto/glue_helper.c
index 22ce4f6..40bcaca 100644
--- a/arch/x86/crypto/glue_helper.c
+++ 

[ANNOUNCE] 3.4.82-rt103

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.4.82-rt103 stable release.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.4-rt
  Head SHA1: b837f3a52f4aa74f8af135b5a5fbb7dd20fa1181


Or to build 3.4.82-rt103 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.82.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.82-rt103.patch.xz



You can also build from 3.4.82-rt102 by applying the incremental patch:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/incr/patch-3.4.82-rt102-rt103.patch.xz



Enjoy,

-- Steve


Changes from v3.4.82-rt102:

---

Marc Kleine-Budde (1):
  net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to 
wait for outstanding qdisc_run calls

Sebastian Andrzej Siewior (1):
  fs: jbd2: pull your plug when waiting for space

Steven Rostedt (1):
  cpu_chill: Add a UNINTERRUPTIBLE hrtimer_nanosleep

Steven Rostedt (Red Hat) (1):
  Linux 3.4.82-rt103


 fs/jbd2/checkpoint.c|  2 ++
 kernel/hrtimer.c| 25 ++---
 localversion-rt |  2 +-
 net/sched/sch_generic.c |  2 +-
 4 files changed, 22 insertions(+), 9 deletions(-)
---
diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
index c78841e..a4d273b 100644
--- a/fs/jbd2/checkpoint.c
+++ b/fs/jbd2/checkpoint.c
@@ -125,6 +125,8 @@ void __jbd2_log_wait_for_space(journal_t *journal)
if (journal->j_flags & JBD2_ABORT)
return;
write_unlock(>j_state_lock);
+   if (current->plug)
+   io_schedule();
mutex_lock(>j_checkpoint_mutex);
 
/*
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index a87d70d..5342f82 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1724,12 +1724,13 @@ void hrtimer_init_sleeper(struct hrtimer_sleeper *sl, 
struct task_struct *task)
 }
 EXPORT_SYMBOL_GPL(hrtimer_init_sleeper);
 
-static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode 
mode)
+static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode 
mode,
+   unsigned long state)
 {
hrtimer_init_sleeper(t, current);
 
do {
-   set_current_state(TASK_INTERRUPTIBLE);
+   set_current_state(state);
hrtimer_start_expires(>timer, mode);
if (!hrtimer_active(>timer))
t->task = NULL;
@@ -1773,7 +1774,8 @@ long __sched hrtimer_nanosleep_restart(struct 
restart_block *restart)
HRTIMER_MODE_ABS);
hrtimer_set_expires_tv64(, restart->nanosleep.expires);
 
-   if (do_nanosleep(, HRTIMER_MODE_ABS))
+   /* cpu_chill() does not care about restart state. */
+   if (do_nanosleep(, HRTIMER_MODE_ABS, TASK_INTERRUPTIBLE))
goto out;
 
rmtp = restart->nanosleep.rmtp;
@@ -1790,8 +1792,10 @@ out:
return ret;
 }
 
-long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,
-  const enum hrtimer_mode mode, const clockid_t clockid)
+static long
+__hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,
+   const enum hrtimer_mode mode, const clockid_t clockid,
+   unsigned long state)
 {
struct restart_block *restart;
struct hrtimer_sleeper t;
@@ -1804,7 +1808,7 @@ long hrtimer_nanosleep(struct timespec *rqtp, struct 
timespec __user *rmtp,
 
hrtimer_init_on_stack(, clockid, mode);
hrtimer_set_expires_range_ns(, timespec_to_ktime(*rqtp), slack);
-   if (do_nanosleep(, mode))
+   if (do_nanosleep(, mode, state))
goto out;
 
/* Absolute timers do not update the rmtp value and restart: */
@@ -1831,6 +1835,12 @@ out:
return ret;
 }
 
+long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,
+  const enum hrtimer_mode mode, const clockid_t clockid)
+{
+   return __hrtimer_nanosleep(rqtp, rmtp, mode, clockid, 
TASK_INTERRUPTIBLE);
+}
+
 SYSCALL_DEFINE2(nanosleep, struct timespec __user *, rqtp,
struct timespec __user *, rmtp)
 {
@@ -1857,7 +1867,8 @@ void cpu_chill(void)
unsigned int freeze_flag = current->flags & PF_NOFREEZE;
 
current->flags |= PF_NOFREEZE;
-   hrtimer_nanosleep(, NULL, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
+   __hrtimer_nanosleep(, NULL, HRTIMER_MODE_REL, CLOCK_MONOTONIC,
+   TASK_UNINTERRUPTIBLE);
if (!freeze_flag)
current->flags &= ~PF_NOFREEZE;
 }
diff --git a/localversion-rt b/localversion-rt
index 33017cd..e0a0b11 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt102
+-rt103
diff --git 

Re: [linux-next][regression] [PATCH] percpu: add preemption checks to __this_cpu ops

[Andrew Morton]

On Tue, 18 Mar 2014 10:54:06 -0500 (CDT) Christoph Lameter  
wrote:

> On Tue, 18 Mar 2014, Grygorii Strashko wrote:
> 
> > Any way, I can boot and console works fine with your change :)
> > Thanks.
> 
> Ok here is the properly formatted patch:
> 
> 
> Subject: preemption_checks: Avoid snprintf before checking error conditions
> 
> snprintf can cause hangs.

This is weird.  How the heck can snprintf() fail if called too early? 
All it does is shuffle chars around in memory.  The only external
dependency I'm seeing is a WARN_ON() which presumably didn't trigger
anyway.

I'm suspecting a misdiagnosis here.  Otherwise, we seriously need to
fix snprintf(), not work around it!

Also, what does "before checking error conditions" refer to?  Does this
mean you know why snprintf() failed??

> Move the string processing into the function
> so that the string operations only occur when necessary after the
> conditions have been checked.
> 
> Tested-by: Grygorii Strashko 

Grygorii, thanks for testing linux-next on unusual machines - it's most
helpful.

> Signed-off-by: Christoph Lameter 

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

[ANNOUNCE] 3.10.33-rt33

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.10.33-rt33 stable release.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.10-rt
  Head SHA1: bd9f4cee1cdf95e7c0c969fefc7b0e4e5381f28b


Or to build 3.10.33-rt33 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.33.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.33-rt33.patch.xz



You can also build from 3.10.33-rt32 by applying the incremental patch:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/incr/patch-3.10.33-rt32-rt33.patch.xz



Enjoy,

-- Steve


Changes from v3.10.33-rt32:

---

Marc Kleine-Budde (1):
  net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to 
wait for outstanding qdisc_run calls

Sebastian Andrzej Siewior (2):
  fs: jbd2: pull your plug when waiting for space
  crypto: Reduce preempt disabled regions, more algos

Steven Rostedt (1):
  cpu_chill: Add a UNINTERRUPTIBLE hrtimer_nanosleep

Steven Rostedt (Red Hat) (1):
  Linux 3.10.33-rt33


 arch/x86/crypto/cast5_avx_glue.c | 21 +
 arch/x86/crypto/glue_helper.c| 31 +++
 fs/jbd2/checkpoint.c |  2 ++
 kernel/hrtimer.c | 25 ++---
 localversion-rt  |  2 +-
 net/sched/sch_generic.c  |  2 +-
 6 files changed, 46 insertions(+), 37 deletions(-)
---
diff --git a/arch/x86/crypto/cast5_avx_glue.c b/arch/x86/crypto/cast5_avx_glue.c
index c663181..2d48e83 100644
--- a/arch/x86/crypto/cast5_avx_glue.c
+++ b/arch/x86/crypto/cast5_avx_glue.c
@@ -60,7 +60,7 @@ static inline void cast5_fpu_end(bool fpu_enabled)
 static int ecb_crypt(struct blkcipher_desc *desc, struct blkcipher_walk *walk,
 bool enc)
 {
-   bool fpu_enabled = false;
+   bool fpu_enabled;
struct cast5_ctx *ctx = crypto_blkcipher_ctx(desc->tfm);
const unsigned int bsize = CAST5_BLOCK_SIZE;
unsigned int nbytes;
@@ -76,7 +76,7 @@ static int ecb_crypt(struct blkcipher_desc *desc, struct 
blkcipher_walk *walk,
u8 *wsrc = walk->src.virt.addr;
u8 *wdst = walk->dst.virt.addr;
 
-   fpu_enabled = cast5_fpu_begin(fpu_enabled, nbytes);
+   fpu_enabled = cast5_fpu_begin(false, nbytes);
 
/* Process multi-block batch */
if (nbytes >= bsize * CAST5_PARALLEL_BLOCKS) {
@@ -104,10 +104,9 @@ static int ecb_crypt(struct blkcipher_desc *desc, struct 
blkcipher_walk *walk,
} while (nbytes >= bsize);
 
 done:
+   cast5_fpu_end(fpu_enabled);
err = blkcipher_walk_done(desc, walk, nbytes);
}
-
-   cast5_fpu_end(fpu_enabled);
return err;
 }
 
@@ -231,7 +230,7 @@ done:
 static int cbc_decrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
   struct scatterlist *src, unsigned int nbytes)
 {
-   bool fpu_enabled = false;
+   bool fpu_enabled;
struct blkcipher_walk walk;
int err;
 
@@ -240,12 +239,11 @@ static int cbc_decrypt(struct blkcipher_desc *desc, 
struct scatterlist *dst,
desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
 
while ((nbytes = walk.nbytes)) {
-   fpu_enabled = cast5_fpu_begin(fpu_enabled, nbytes);
+   fpu_enabled = cast5_fpu_begin(false, nbytes);
nbytes = __cbc_decrypt(desc, );
+   cast5_fpu_end(fpu_enabled);
err = blkcipher_walk_done(desc, , nbytes);
}
-
-   cast5_fpu_end(fpu_enabled);
return err;
 }
 
@@ -315,7 +313,7 @@ done:
 static int ctr_crypt(struct blkcipher_desc *desc, struct scatterlist *dst,
 struct scatterlist *src, unsigned int nbytes)
 {
-   bool fpu_enabled = false;
+   bool fpu_enabled;
struct blkcipher_walk walk;
int err;
 
@@ -324,13 +322,12 @@ static int ctr_crypt(struct blkcipher_desc *desc, struct 
scatterlist *dst,
desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
 
while ((nbytes = walk.nbytes) >= CAST5_BLOCK_SIZE) {
-   fpu_enabled = cast5_fpu_begin(fpu_enabled, nbytes);
+   fpu_enabled = cast5_fpu_begin(false, nbytes);
nbytes = __ctr_crypt(desc, );
+   cast5_fpu_end(fpu_enabled);
err = blkcipher_walk_done(desc, , nbytes);
}
 
-   cast5_fpu_end(fpu_enabled);
-
if (walk.nbytes) {
ctr_crypt_final(desc, );
err = blkcipher_walk_done(desc, , 0);
diff --git a/arch/x86/crypto/glue_helper.c b/arch/x86/crypto/glue_helper.c
index 432f1d76..4a2bd21 100644
--- a/arch/x86/crypto/glue_helper.c
+++ b/arch/x86/crypto/glue_helper.c
@@ -39,7 +39,7 @@ static int __glue_ecb_crypt_128bit(const struct 

[PATCH 01/13] perf timechart: Fix off-by-one error in 'record' argv handling

[Arnaldo Carvalho de Melo]

From: Ramkumar Ramachandra 

Since 367b315 (perf timechart: Add support for -P and -T in timechart
recording, 2013-11-01), the 'perf timechart record' command stopped
working:

  $ perf timechart record -- git status
  Workload failed: No such file or directory

This happens because of an off-by-one error while preparing the argv for
cmd_record(): it attempts to execute the command 'status' and complains
that it doesn't exist. Fix this error.

Signed-off-by: Ramkumar Ramachandra 
Acked-by: Stanislav Fomichev 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Stanislav Fomichev 
Link: 
http://lkml.kernel.org/r/1394985965-2332-1-git-send-email-artag...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-timechart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 25526d6eae59..d4991a235155 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -1238,7 +1238,7 @@ static int timechart__record(struct timechart *tchart, 
int argc, const char **ar
for (i = 0; i < old_power_args_nr; i++)
*p++ = strdup(old_power_args[i]);
 
-   for (j = 1; j < (unsigned int)argc; j++)
+   for (j = 0; j < (unsigned int)argc; j++)
*p++ = argv[j];
 
return cmd_record(rec_argc, rec_argv, NULL);
-- 
1.8.1.4

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

[PATCH 07/13] perf tools: Fix memory leak when synthesizing thread records

[Arnaldo Carvalho de Melo]

From: Namhyung Kim 

Checking default guest machine should be done before allocating event
structures otherwise it'll leak memory.

Signed-off-by: Namhyung Kim 
Cc: Don Zickus 
Cc: Jiri Olsa 
Cc: Joe Mario 
Link: http://lkml.kernel.org/r/87ob15tx6a@sejong.aot.lge.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/event.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index ebb48a623407..9d12aa6dd485 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -446,6 +446,9 @@ int perf_event__synthesize_threads(struct perf_tool *tool,
union perf_event *comm_event, *mmap_event, *fork_event;
int err = -1;
 
+   if (machine__is_default_guest(machine))
+   return 0;
+
comm_event = malloc(sizeof(comm_event->comm) + machine->id_hdr_size);
if (comm_event == NULL)
goto out;
@@ -458,9 +461,6 @@ int perf_event__synthesize_threads(struct perf_tool *tool,
if (fork_event == NULL)
goto out_free_mmap;
 
-   if (machine__is_default_guest(machine))
-   return 0;
-
snprintf(proc_path, sizeof(proc_path), "%s/proc", machine->root_dir);
proc = opendir(proc_path);
 
-- 
1.8.1.4

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

[PATCH 02/13] perf sched: Fixup header alignment in 'latency' output

[Arnaldo Carvalho de Melo]

From: Ramkumar Ramachandra 

Before:

 
---
  Task  |   Runtime ms  | Switches | Average delay ms | Maximum 
delay ms | Maximum delay at |
 
---
  ...   |   |  |  | 
 |
  git:24540 |336.622 ms |   10 | avg:0.032 ms | max:
0.062 ms | max at: 115610.111046 s
  git:24541 |  0.457 ms |1 | avg:0.000 ms | max:
0.000 ms | max at:  0.00 s
 
-
  TOTAL:|396.542 ms |  353 |
 ---

After:

 
-
  Task  |   Runtime ms  | Switches | Average delay ms | Maximum 
delay ms | Maximum delay at   |
 
-
  ...   |   |  |  | 
 |
  git:24540 |336.622 ms |   10 | avg:0.032 ms | max:
0.062 ms | max at: 115610.111046 s
  git:24541 |  0.457 ms |1 | avg:0.000 ms | max:
0.000 ms | max at:  0.00 s
 
-
  TOTAL:|396.542 ms |  353 |
 ---

Signed-off-by: Ramkumar Ramachandra 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Link: 
http://lkml.kernel.org/r/1395065901-25740-1-git-send-email-artag...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-sched.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 6a76a07b6789..9ac0a495c954 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1124,7 +1124,7 @@ static void output_lat_thread(struct perf_sched *sched, 
struct work_atoms *work_
 
avg = work_list->total_lat / work_list->nb_atoms;
 
-   printf("|%11.3f ms |%9" PRIu64 " | avg:%9.3f ms | max:%9.3f ms | max 
at: %9.6f s\n",
+   printf("|%11.3f ms |%9" PRIu64 " | avg:%9.3f ms | max:%9.3f ms | max 
at: %13.6f s\n",
  (double)work_list->total_runtime / 1e6,
 work_list->nb_atoms, (double)avg / 1e6,
 (double)work_list->max_lat / 1e6,
@@ -1527,9 +1527,9 @@ static int perf_sched__lat(struct perf_sched *sched)
 
perf_sched__sort_lat(sched);
 
-   printf("\n 
---\n");
-   printf("  Task  |   Runtime ms  | Switches | Average 
delay ms | Maximum delay ms | Maximum delay at |\n");
-   printf(" 
---\n");
+   printf("\n 
-\n");
+   printf("  Task  |   Runtime ms  | Switches | Average 
delay ms | Maximum delay ms | Maximum delay at   |\n");
+   printf(" 
-\n");
 
next = rb_first(>sorted_atom_root);
 
@@ -1541,7 +1541,7 @@ static int perf_sched__lat(struct perf_sched *sched)
next = rb_next(next);
}
 
-   printf(" 
-\n");
+   printf(" 
-\n");
printf("  TOTAL:|%11.3f ms |%9" PRIu64 " |\n",
(double)sched->all_runtime / 1e6, sched->all_count);
 
-- 
1.8.1.4

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

[PATCH 11/13] perf evsel: Update function names in debug messages

[Arnaldo Carvalho de Melo]

From: Ramkumar Ramachandra 

perf_event_open() was renamed to sys_perf_event_open(); update the debug
messages to reflect this.

Signed-off-by: Ramkumar Ramachandra 
Cc: David Ahern 
Cc: Jiri Olsa 
Link: 
http://lkml.kernel.org/r/1395169842-1399-1-git-send-email-artag...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evsel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 26b67b11c65b..5c28d82b76c4 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1023,7 +1023,7 @@ retry_sample_id:
 
group_fd = get_group_fd(evsel, cpu, thread);
 retry_open:
-   pr_debug2("perf_event_open: pid %d  cpu %d  group_fd %d 
 flags %#lx\n",
+   pr_debug2("sys_perf_event_open: pid %d  cpu %d  
group_fd %d  flags %#lx\n",
  pid, cpus->map[cpu], group_fd, flags);
 
FD(evsel, cpu, thread) = 
sys_perf_event_open(>attr,
@@ -1032,7 +1032,7 @@ retry_open:
 group_fd, 
flags);
if (FD(evsel, cpu, thread) < 0) {
err = -errno;
-   pr_debug2("perf_event_open failed, error %d\n",
+   pr_debug2("sys_perf_event_open failed, error 
%d\n",
  err);
goto try_fallback;
}
-- 
1.8.1.4

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

[PATCH 13/13] perf tools: Remove unused simple_strtoul() function

[Arnaldo Carvalho de Melo]

From: Ramkumar Ramachandra 

Moreover, the corresponding function in include/linux/kernel.h is marked
obsolete.

Signed-off-by: Ramkumar Ramachandra 
Cc: David Ahern 
Cc: Jiri Olsa 
Link: 
http://lkml.kernel.org/r/1395176715-4465-1-git-send-email-artag...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/include/linux/kernel.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/tools/perf/util/include/linux/kernel.h 
b/tools/perf/util/include/linux/kernel.h
index d8c927c868ee..9844c31b7c2b 100644
--- a/tools/perf/util/include/linux/kernel.h
+++ b/tools/perf/util/include/linux/kernel.h
@@ -94,12 +94,6 @@ static inline int scnprintf(char * buf, size_t size, const 
char * fmt, ...)
return (i >= ssize) ? (ssize - 1) : i;
 }
 
-static inline unsigned long
-simple_strtoul(const char *nptr, char **endptr, int base)
-{
-   return strtoul(nptr, endptr, base);
-}
-
 int eprintf(int level,
const char *fmt, ...) __attribute__((format(printf, 2, 3)));
 
-- 
1.8.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/