Re: [PATCH] clk: fixed-factor: add optional dt-binding clock-flags

2016-06-23 Thread kbuild test robot
Hi,

[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.7-rc4 next-20160623]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jongsung-Kim/clk-fixed-factor-add-optional-dt-binding-clock-flags/20160624-115201
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: microblaze-mmu_defconfig (attached as .config)
compiler: microblaze-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=microblaze 

All warnings (new ones prefixed by >>):

   drivers/clk/clk-fixed-factor.c: In function 'of_fixed_factor_clk_setup':
>> drivers/clk/clk-fixed-factor.c:170:2: warning: passing argument 3 of 
>> 'of_property_read_u32' from incompatible pointer type
 of_property_read_u32(node, "clock-flags", );
 ^
   In file included from include/linux/clk-provider.h:15:0,
from drivers/clk/clk-fixed-factor.c:11:
   include/linux/of.h:916:19: note: expected 'u32 *' but argument is of type 
'long unsigned int *'
static inline int of_property_read_u32(const struct device_node *np,
  ^

vim +/of_property_read_u32 +170 drivers/clk/clk-fixed-factor.c

   154  u32 div, mult;
   155  
   156  if (of_property_read_u32(node, "clock-div", )) {
   157  pr_err("%s Fixed factor clock <%s> must have a 
clock-div property\n",
   158  __func__, node->name);
   159  return;
   160  }
   161  
   162  if (of_property_read_u32(node, "clock-mult", )) {
   163  pr_err("%s Fixed factor clock <%s> must have a 
clock-mult property\n",
   164  __func__, node->name);
   165  return;
   166  }
   167  
   168  of_property_read_string(node, "clock-output-names", _name);
   169  parent_name = of_clk_get_parent_name(node, 0);
 > 170  of_property_read_u32(node, "clock-flags", );
   171  
   172  clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 
flags,
   173  mult, div);
   174  if (!IS_ERR(clk))
   175  of_clk_add_provider(node, of_clk_src_simple_get, clk);
   176  }
   177  EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
   178  CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clock",

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


.config.gz
Description: Binary data


Re: [PATCH v5 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

2016-06-23 Thread Wu, Songjun

Hi Rob,

Thank you for your comments.

On 6/20/2016 21:25, Rob Herring wrote:

On Fri, Jun 17, 2016 at 04:57:14PM +0800, Songjun Wu wrote:

DT binding documentation for ISC driver.

Signed-off-by: Songjun Wu 
---

Changes in v5:
- Add clock names.

Changes in v4:
- Remove the isc clock nodes.

Changes in v3:
- Remove the 'atmel,sensor-preferred'.
- Modify the isc clock node according to the Rob's remarks.

Changes in v2:
- Remove the unit address of the endpoint.
- Add the unit address to the clock node.
- Avoid using underscores in node names.
- Drop the "0x" in the unit address of the i2c node.
- Modify the description of 'atmel,sensor-preferred'.
- Add the description for the ISC internal clock.

 .../devicetree/bindings/media/atmel-isc.txt| 64 ++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt

diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt 
b/Documentation/devicetree/bindings/media/atmel-isc.txt
new file mode 100644
index 000..9558a77
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isc.txt
@@ -0,0 +1,64 @@
+Atmel Image Sensor Controller (ISC)
+--
+
+Required properties for ISC:
+- compatible
+   Must be "atmel,sama5d2-isc".
+- reg
+   Physical base address and length of the registers set for the device.
+- interrupts
+   Should contain IRQ line for the ISC.
+- clocks
+   List of clock specifiers, corresponding to entries in
+   the clock-names property;
+   Please refer to clock-bindings.txt.
+- clock-names
+   Required elements: "hclock".


What about the 2 other clocks in the example?


The other clocks is optional, not required.
Do you have any suggestion?


+- #clock-cells
+   Should be 0.
+- clock-output-names
+   Should contain the name of the clock driving the sensor master clock.


State what the name is.


"isc-mck" will be added.


+- pinctrl-names, pinctrl-0
+   Please refer to pinctrl-bindings.txt.
+
+ISC supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+isc: isc@f0008000 {
+   compatible = "atmel,sama5d2-isc";
+   reg = <0xf0008000 0x4000>;
+   interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
+   clocks = <_clk>, <>, <_gclk>;
+   clock-names = "hclock", "iscck", "gck";
+   #clock-cells = <0>;
+   clock-output-names = "isc-mck";
+   pinctrl-names = "default";
+   pinctrl-0 = <_isc_base _isc_data_8bit _isc_data_9_10 
_isc_data_11_12>;
+
+   port {
+   isc_0: endpoint {
+   remote-endpoint = <_0>;
+   hsync-active = <1>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   };
+   };
+};
+
+i2c1: i2c@fc028000 {
+   ov7740: camera@21 {
+   compatible = "ovti,ov7740";


Indentation is still wrong here...


Sorry, my mistake.
It should be fixed.


+   reg = <0x21>;
+   clocks = <>;
+   clock-names = "xvclk";
+   assigned-clocks = <>;
+   assigned-clock-rates = <2400>;
+
+   port {
+   ov7740_0: endpoint {
+   remote-endpoint = <_0>;
+   };
+   };
+};
--
2.7.4



Re: [PATCH v3] Doc/memory-barriers: Add Korean translation

2016-06-23 Thread SeongJae Park
Hello, Byungchul,


I guess the review is ongoing yet and maybe it requires more days.  Can you let
me know your estimated time for the review if it doesn't bother you?


Thanks,
SeongJae Park

On Fri, Jun 17, 2016 at 3:24 PM, Minchan Kim  wrote:
> On Wed, Jun 15, 2016 at 03:47:34PM +0900, SeongJae Park wrote:
>> 2016-06-09 5:45 GMT+09:00 SeongJae Park :
>> > 2016-06-09 2:24 GMT+09:00 Paul E. McKenney :
>> >> On Wed, Jun 08, 2016 at 05:58:41PM +0900, SeongJae Park wrote:
>> >>> This commit adds Korean version of memory-barriers.txt document.  The
>> >>> header is refered to HOWTO Korean version.
>> >>>
>> >>> The translator, SeongJae Park, is interested in parallel programming and
>> >>> translating[1] a book[2] about the topic.
>> >>>
>> >>> The translation has started from Feb, 2016 and using a github public
>> >>> repository[3] to maintain the work.  The work is following[4] updates to
>> >>> the original document as well.
>> >>>
>> >>> Because the translator has knowledge about the topic and already
>> >>> following up the upstream changes, one would sure that this translation
>> >>> will keep reasonable quality and freshness.
>> >>>
>> >>> [1] 
>> >>> https://git.kernel.org/cgit/linux/kernel/git/paulmck/perfbook.git/commit/FAQ.txt?id=edbfcdee0460
>> >>> [2] 
>> >>> https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
>> >>> [3] https://github.com/sjp38/linux.doc_trans_membarrier
>> >>> [4] 
>> >>> https://github.com/sjp38/linux.doc_trans_membarrier/commit/06bd12d390f164fd253b861fc3aa8006d6d19ed9
>> >>>
>> >>> Signed-off-by: SeongJae Park 
>> >>> Acked-by: David Howells 
>> >>> Signed-off-by: Parl E. McKenney 
>> >>> Acked-by: Minchan Kim 
>> >>
>> >> I cannot judge this, so I must defer to Minchan.  That said, the diffstat
>> >> since your version of April 18 is as follows:
>> >>
>> >>  memory-barriers.txt |  303 
>> >> ++--
>> >>  1 file changed, 175 insertions(+), 128 deletions(-)
>> >>
>> >> I cannot tell which mainline version these patches correspond to, but the
>> >> English version has this diffstat since v4.5:
>> >>
>> >>  memory-barriers.txt |  293 
>> >> +---
>> >>  1 file changed, 234 insertions(+), 59 deletions(-)
>> >>
>> >> So your level of change thus far seems plausible.
>> >
>> > I agree that Minchan deserves to judge that since he is the Korean 
>> > translations
>> > maintainer.
>>
>> Minchan, may I ask your opinion about this patch?
>
> Sorry for late response.
>
> I think it's really worth. That's why I support it. However, until now,
> I didn't review it in detail. Sorry about that and stuck with urgent
> works so I asked colleague byungchul who scheduler guy, he has an
> interest so He will review this patch soon.
>
> Hope it helps you.
>
> Thanks.
>


Re: linux-next: manual merge of the audit tree with the security tree

2016-06-23 Thread Heiko Carstens
On Thu, Jun 23, 2016 at 12:14:11PM -0400, Paul Moore wrote:
> On Thu, Jun 23, 2016 at 2:01 AM, Heiko Carstens
>  wrote:
> > On Thu, Jun 23, 2016 at 02:18:14PM +1000, Stephen Rothwell wrote:
> >> Hi Paul,
> >>
> >> Today's linux-next merge of the audit tree got a conflict in:
> >>
> >>   arch/s390/kernel/ptrace.c
> >>
> >> between commit:
> >>
> >>   0208b9445bc0 ("s390/ptrace: run seccomp after ptrace")
> >>
> >> from the security tree and commit:
> >>
> >>   bba696c2c083 ("s390: ensure that syscall arguments are properly masked 
> >> on s390")
> >>
> >> from the audit tree.
> >
> > Hmm, I haven't seen that commit, therefore I'm just commenting on the
> > result ;)
> 
> It was sent to the linux-audit and linux-s390 mailing lists yesterday
> with a follow up comment that I was going to add it to the audit#next
> branch and if anyone had any objections to let me know.
> 
> * https://www.redhat.com/archives/linux-audit/2016-June/msg00051.html

Yes, I missed that, sorry!

> >> + audit_syscall_entry(regs->gprs[2], regs->orig_gpr2 & mask,
> >> + regs->gprs[3] & mask, regs->gprs[4] & mask,
> >> + regs->gprs[5] & mask);
> >
> > With these masks it is more correct, however these are still not the values
> > used by the system call itself. This would be still incorrect for
> > e.g. compat pointers (31 bit on s390).
> >
> > So it seems like audit_syscall_entry should be called after all sign, zero
> > and masking has been done?
> 
> For someone not familiar with s390, compat or not, where would you
> suggest we place the audit_syscall_entry() call?

I was thinking of a more generic solution for all architectures: for
example setting a new TIF flag within do_syscall_trace_enter which
indicates that audit_syscall_entry needs be called and then add a
conditional call to the SYSCALL_DEFINE and COMPAT_SYSCALL_DEFINE macros.

That way audit_syscall_entry would always receive already properly sign and
zero extended system call parameters. At the downside this would increase
the kernel text size by probably ~370 conditional branches and add two more
instructions on the system call hot path.

But that's something that could be done independently from your patch,
which already improves the current situation.



Re: [PATCH 2/6] virtio-balloon: speed up inflate/deflate process

2016-06-23 Thread Michael S. Tsirkin
On Mon, Jun 13, 2016 at 05:47:09PM +0800, Liang Li wrote:
> The implementation of the current virtio-balloon is not very efficient,
> Bellow is test result of time spends on inflating the balloon to 3GB of
> a 4GB idle guest:
> 
> a. allocating pages (6.5%, 103ms)
> b. sending PFNs to host (68.3%, 787ms)
> c. address translation (6.1%, 96ms)
> d. madvise (19%, 300ms)
> 
> It takes about 1577ms for the whole inflating process to complete. The
> test shows that the bottle neck is the stage b and stage d.
> 
> If using a bitmap to send the page info instead of the PFNs, we can
> reduce the overhead in stage b quite a lot. Furthermore, it's possible
> to do the address translation and the madvise with a bulk of pages,
> instead of the current page per page way, so the overhead of stage c
> and stage d can also be reduced a lot.
> 
> This patch is the kernel side implementation which is intended to speed
> up the inflating & deflating process by adding a new feature to the
> virtio-balloon device. And now, inflating the balloon to 3GB of a 4GB
> idle guest only takes 200ms, it's about 8 times as fast as before.
> 
> TODO: optimize stage a by allocating/freeing a chunk of pages instead
> of a single page at a time.
> 
> Signed-off-by: Liang Li 
> Suggested-by: Michael S. Tsirkin 
> Cc: Michael S. Tsirkin 
> Cc: Paolo Bonzini 
> Cc: Cornelia Huck 
> Cc: Amit Shah 

Causes kbuild warnings

> ---
>  drivers/virtio/virtio_balloon.c | 164 
> +++-
>  include/uapi/linux/virtio_balloon.h |   1 +
>  2 files changed, 144 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 8d649a2..1fa601b 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -40,11 +40,19 @@
>  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
>  #define OOM_VBALLOON_DEFAULT_PAGES 256
>  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> +#define VIRTIO_BALLOON_PFNS_LIMIT ((2 * (1ULL << 30)) >> PAGE_SHIFT) /* 2GB 
> */

2<< 30  is 2G but that is not a useful comment.
pls explain what is the reason for this selection.

>  
>  static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
>  module_param(oom_pages, int, S_IRUSR | S_IWUSR);
>  MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
>  
> +struct balloon_bmap_hdr {
> + __virtio32 id;
> + __virtio32 page_shift;
> + __virtio64 start_pfn;
> + __virtio64 bmap_len;
> +};
> +

Put this in an uapi header please.

>  struct virtio_balloon {
>   struct virtio_device *vdev;
>   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
> @@ -62,6 +70,11 @@ struct virtio_balloon {
>  
>   /* Number of balloon pages we've told the Host we're not using. */
>   unsigned int num_pages;
> + /* Bitmap and length used to tell the host the pages */
> + unsigned long *page_bitmap;
> + unsigned long bmap_len;
> + /* Used to record the processed pfn range */
> + unsigned long min_pfn, max_pfn, start_pfn, end_pfn;
>   /*
>* The pages we've told the Host we're not using are enqueued
>* at vb_dev_info->pages list.
> @@ -105,15 +118,51 @@ static void balloon_ack(struct virtqueue *vq)
>   wake_up(>acked);
>  }
>  
> +static inline void init_pfn_range(struct virtio_balloon *vb)
> +{
> + vb->min_pfn = (1UL << 48);

Where does this value come from? Do you want ULONG_MAX?
This does not fit in long on 32 bit systems.


> + vb->max_pfn = 0;
> +}
> +
> +static inline void update_pfn_range(struct virtio_balloon *vb,
> +  struct page *page)
> +{
> + unsigned long balloon_pfn = page_to_balloon_pfn(page);
> +
> + if (balloon_pfn < vb->min_pfn)
> + vb->min_pfn = balloon_pfn;
> + if (balloon_pfn > vb->max_pfn)
> + vb->max_pfn = balloon_pfn;
> +}
> +
>  static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
>  {
> - struct scatterlist sg;
>   unsigned int len;
>  
> - sg_init_one(, vb->pfns, sizeof(vb->pfns[0]) * vb->num_pfns);
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_PAGE_BITMAP)) {
> + struct balloon_bmap_hdr hdr;

why not init fields here?

> + unsigned long bmap_len;

and here

> + struct scatterlist sg[2];
> +
> + hdr.id = cpu_to_virtio32(vb->vdev, 0);
> + hdr.page_shift = cpu_to_virtio32(vb->vdev, PAGE_SHIFT);
> + hdr.start_pfn = cpu_to_virtio64(vb->vdev, vb->start_pfn);
> + bmap_len = min(vb->bmap_len,
> + (vb->end_pfn - vb->start_pfn) / BITS_PER_BYTE);
> + hdr.bmap_len = cpu_to_virtio64(vb->vdev, bmap_len);
> + sg_init_table(sg, 2);
> + sg_set_buf([0], , sizeof(hdr));
> + sg_set_buf([1], vb->page_bitmap, bmap_len);
> + 

RE: [PATCH] Maxim/driver: Add driver for maxim ds26522

2016-06-23 Thread Qiang Zhao
On Thu, 2016-06-23 at 10:59PM, David Miller wrote:
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, June 23, 2016 10:59 PM
> To: Qiang Zhao 
> Cc: o...@buserror.net; linux-kernel@vger.kernel.org; net...@vger.kernel.org;
> Xiaobo Xie 
> Subject: Re: [PATCH] Maxim/driver: Add driver for maxim ds26522
> 
> From: Zhao Qiang 
> Date: Thu, 23 Jun 2016 09:09:45 +0800
> 
> > +MODULE_DESCRIPTION(DRV_DESC);
> 
> There is no definition of DRV_DESC, so this makes it look like you didn't even
> compile this driver.

I really, really compiled this driver.
Thank you for your review and comments. I will modify it the next version.

[zhaoqiang@titan:~/upstream/linux]$ll drivers/net/wan/slic_ds26522.o
-rw-r--r-- 1 zhaoqiang klocwork 153288 Jun 22 15:48 
drivers/net/wan/slic_ds26522.o
[zhaoqiang@titan:~/upstream/linux]$date
Fri Jun 24 09:42:16 CST 2016

-Zhao Qiang
BR


[PATCH] libnvdimm, pfn, dax: fix initialization vs autodetect for mode + alignment

2016-06-23 Thread Dan Williams
The updated ndctl unit tests discovered that if a pfn configuration with
a 4K alignment is read from the namespace, that alignment will be
ignored in favor of the default 2M alignment.  The result is that the
configuration will fail initialization with a message like:

dax6.1: bad offset: 0x22000 dax disabled align: 0x20

Fix this by allowing the alignment read from the info block to override
the default which is 2M not 0 in the autodetect path.  This also fixes a
similar problem with the mode and alignment settings silently being
overwritten by the kernel when userspace has changed it.  We now will
either overwrite the info block if userspace changes the uuid or fail
and warn if a live setting disagrees with the info block.

Cc: 
Cc: Micah Parrish 
Cc: Toshi Kani 
Signed-off-by: Dan Williams 
---

There was a similar, but incomplete, patch like this for the BTT back in
December of last year: "BTT: Change nd_btt_arena_is_valid() to verify
UUID".  I did not apply it due to the fact that it didn't address
setting changes and I did not fully understand the scope of the problem.

Now with the realization that the kernel silently overriding settings is
problematic, we should consider taking this deterministic behavior over
to the btt.  However, it's not a bug there like it is in the pfn case
because the settings default to an invalid uninitialized value, whereas
pfn devices have a default valid alignment.

 drivers/nvdimm/pfn_devs.c |   51 +++--
 1 file changed, 40 insertions(+), 11 deletions(-)

diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index f7718ec685fa..cea8350fbc7e 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -344,6 +344,8 @@ struct device *nd_pfn_create(struct nd_region *nd_region)
 int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
 {
u64 checksum, offset;
+   unsigned long align;
+   enum nd_pfn_mode mode;
struct nd_namespace_io *nsio;
struct nd_pfn_sb *pfn_sb = nd_pfn->pfn_sb;
struct nd_namespace_common *ndns = nd_pfn->ndns;
@@ -386,22 +388,50 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char 
*sig)
return -ENXIO;
}
 
+   align = le32_to_cpu(pfn_sb->align);
+   offset = le64_to_cpu(pfn_sb->dataoff);
+   if (align == 0)
+   align = 1UL << ilog2(offset);
+   mode = le32_to_cpu(pfn_sb->mode);
+
if (!nd_pfn->uuid) {
-   /* from probe we allocate */
+   /*
+* When probing a namepace via nd_pfn_probe() the uuid
+* is NULL (see: nd_pfn_devinit()) we init settings from
+* pfn_sb
+*/
nd_pfn->uuid = kmemdup(pfn_sb->uuid, 16, GFP_KERNEL);
if (!nd_pfn->uuid)
return -ENOMEM;
+   nd_pfn->align = align;
+   nd_pfn->mode = mode;
} else {
-   /* from init we validate */
+   /*
+* When probing a pfn / dax instance we validate the
+* live settings against the pfn_sb
+*/
if (memcmp(nd_pfn->uuid, pfn_sb->uuid, 16) != 0)
return -ENODEV;
+
+   /*
+* If the uuid validates, but other settings mismatch
+* return EINVAL because userspace has managed to change
+* the configuration without specifying new
+* identification.
+*/
+   if (nd_pfn->align != align || nd_pfn->mode != mode) {
+   dev_err(_pfn->dev,
+   "init failed, settings mismatch\n");
+   dev_dbg(_pfn->dev, "align: %lx:%lx mode: %d:%d\n",
+   nd_pfn->align, align, nd_pfn->mode,
+   mode);
+   return -EINVAL;
+   }
}
 
-   if (nd_pfn->align == 0)
-   nd_pfn->align = le32_to_cpu(pfn_sb->align);
-   if (nd_pfn->align > nvdimm_namespace_capacity(ndns)) {
+   if (align > nvdimm_namespace_capacity(ndns)) {
dev_err(_pfn->dev, "alignment: %lx exceeds capacity %llx\n",
-   nd_pfn->align, nvdimm_namespace_capacity(ndns));
+   align, nvdimm_namespace_capacity(ndns));
return -EINVAL;
}
 
@@ -411,7 +441,6 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
 * namespace has changed since the pfn superblock was
 * established.
 */
-   offset = le64_to_cpu(pfn_sb->dataoff);
nsio = to_nd_namespace_io(>dev);
if (offset >= resource_size(>res)) {
dev_err(_pfn->dev, "pfn array size exceeds capacity of %s\n",
@@ -419,10 +448,11 

Re: [v2,1/2] refactor code parsing size based on memory range

2016-06-23 Thread Michael Ellerman
On Wed, 2016-22-06 at 19:25:26 UTC, Hari Bathini wrote:
> Currently, crashkernel parameter supports the below syntax to parse size
> based on memory range:
> 
>   crashkernel=:[,:,...]
> 
> While such parsing is implemented for crashkernel parameter, it applies to
> other parameters with similar syntax. So, move this code to a more generic
> place for code reuse.
> 
> Cc: Eric Biederman 
> Cc: Vivek Goyal 
> Cc: Rusty Russell 
> Cc: ke...@lists.infradead.org
> Signed-off-by: Hari Bathini 

Hari, it's not immediately clear that this makes no change to the logic in the
kexec code. Can you reply with a longer change log explaining why the old & new
logic is the same for kexec.

cheers


> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 94aa10f..72f55e5 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -436,6 +436,11 @@ extern char *get_options(const char *str, int nints, int 
> *ints);
>  extern unsigned long long memparse(const char *ptr, char **retptr);
>  extern bool parse_option_str(const char *str, const char *option);
>  
> +extern bool __init is_param_range_based(const char *cmdline);
> +extern unsigned long long __init parse_mem_range_size(const char *param,
> +   char **str,
> +   unsigned long long 
> system_ram);
> +
>  extern int core_kernel_text(unsigned long addr);
>  extern int core_kernel_data(unsigned long addr);
>  extern int __kernel_text_address(unsigned long addr);
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 56b3ed0..d43f5cc 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1083,59 +1083,9 @@ static int __init parse_crashkernel_mem(char *cmdline,
>   char *cur = cmdline, *tmp;
>  
>   /* for each entry of the comma-separated list */
> - do {
> - unsigned long long start, end = ULLONG_MAX, size;
> -
> - /* get the start of the range */
> - start = memparse(cur, );
> - if (cur == tmp) {
> - pr_warn("crashkernel: Memory value expected\n");
> - return -EINVAL;
> - }
> - cur = tmp;
> - if (*cur != '-') {
> - pr_warn("crashkernel: '-' expected\n");
> - return -EINVAL;
> - }
> - cur++;
> -
> - /* if no ':' is here, than we read the end */
> - if (*cur != ':') {
> - end = memparse(cur, );
> - if (cur == tmp) {
> - pr_warn("crashkernel: Memory value expected\n");
> - return -EINVAL;
> - }
> - cur = tmp;
> - if (end <= start) {
> - pr_warn("crashkernel: end <= start\n");
> - return -EINVAL;
> - }
> - }
> -
> - if (*cur != ':') {
> - pr_warn("crashkernel: ':' expected\n");
> - return -EINVAL;
> - }
> - cur++;
> -
> - size = memparse(cur, );
> - if (cur == tmp) {
> - pr_warn("Memory value expected\n");
> - return -EINVAL;
> - }
> - cur = tmp;
> - if (size >= system_ram) {
> - pr_warn("crashkernel: invalid size\n");
> - return -EINVAL;
> - }
> -
> - /* match ? */
> - if (system_ram >= start && system_ram < end) {
> - *crash_size = size;
> - break;
> - }
> - } while (*cur++ == ',');
> + *crash_size = parse_mem_range_size("crashkernel", , system_ram);
> + if (cur == cmdline)
> + return -EINVAL;
>  
>   if (*crash_size > 0) {
>   while (*cur && *cur != ' ' && *cur != '@')
> @@ -1272,7 +1222,6 @@ static int __init __parse_crashkernel(char *cmdline,
>const char *name,
>const char *suffix)
>  {
> - char*first_colon, *first_space;
>   char*ck_cmdline;
>  
>   BUG_ON(!crash_size || !crash_base);
> @@ -1290,12 +1239,10 @@ static int __init __parse_crashkernel(char *cmdline,
>   return parse_crashkernel_suffix(ck_cmdline, crash_size,
>   suffix);
>   /*
> -  * if the commandline contains a ':', then that's the extended
> +  * if the parameter is range based, then that's the extended
>* syntax -- if not, it must be the classic syntax
>*/
> - first_colon = strchr(ck_cmdline, ':');
> - first_space = strchr(ck_cmdline, ' ');
> - if (first_colon && (!first_space || first_colon < first_space))

[PATCH v2 5/5] dmaengine: dma: Use different channel names for each dma

2016-06-23 Thread Kedareswara rao Appana
Current driver assumes that child node channel name is either
"xlnx,axi-vdma-mm2s-channel" or "xlnx,axi-vdma-s2mm-channel"
which is confusing the users of AXI DMA and CDMA.
This patch fixes this issue by using different channel
names for the AXI DMA and AXI CDMA child nodes.

Signed-off-by: Kedareswara rao Appana 
---
Chanes for v2:
---> New patch.

 .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |6 +-
 drivers/dma/xilinx/xilinx_dma.c|8 ++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index 0faa189..a2b8bfa 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -50,8 +50,12 @@ Optional properties for VDMA:
{3}, flush s2mm channel
 
 Required child node properties:
-- compatible: It should be either "xlnx,axi-vdma-mm2s-channel" or
+- compatible:
+   For VDMA: It should be either "xlnx,axi-vdma-mm2s-channel" or
"xlnx,axi-vdma-s2mm-channel".
+   For CDMA: It should be "xlnx,axi-cdma-channel".
+   For AXIDMA: It should be either "xlnx,axi-dma-mm2s-channel" or
+   "xlnx,axi-dma-s2mm-channel".
 - interrupts: Should contain per channel VDMA interrupts.
 - xlnx,datawidth: Should contain the stream data width, take values
{32,64...1024}.
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 0768d9f..cf47347 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -2353,7 +2353,9 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device 
*xdev,
if (!has_dre)
xdev->common.copy_align = fls(width - 1);
 
-   if (of_device_is_compatible(node, "xlnx,axi-vdma-mm2s-channel")) {
+   if (of_device_is_compatible(node, "xlnx,axi-vdma-mm2s-channel") ||
+   of_device_is_compatible(node, "xlnx,axi-dma-mm2s-channel") ||
+   of_device_is_compatible(node, "xlnx,axi-cdma-channel")) {
chan->direction = DMA_MEM_TO_DEV;
chan->id = chan_id;
chan->tdest = chan_id;
@@ -2367,7 +2369,9 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device 
*xdev,
chan->flush_on_fsync = true;
}
} else if (of_device_is_compatible(node,
-   "xlnx,axi-vdma-s2mm-channel")) {
+  "xlnx,axi-vdma-s2mm-channel") ||
+  of_device_is_compatible(node,
+  "xlnx,axi-dma-s2mm-channel")) {
chan->direction = DMA_DEV_TO_MEM;
chan->id = chan_id;
chan->tdest = chan_id - xdev->nr_channels;
-- 
1.7.1



[PATCH v2 4/5] dmaengine: dma: Rename driver and config

2016-06-23 Thread Kedareswara rao Appana
In the existing vdma driver support for
AXI DMA and CDMA got added so the driver is no
longer VDMA specific.

This patch renames the driver and DT binding doc to xilinx_dma
and updates the Kconfig description for all the DMAS.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> None.

 .../dma/xilinx/{xilinx_vdma.txt => xilinx_dma.txt} |0
 drivers/dma/Kconfig|   11 ---
 drivers/dma/xilinx/Makefile|2 +-
 drivers/dma/xilinx/{xilinx_vdma.c => xilinx_dma.c} |0
 4 files changed, 9 insertions(+), 4 deletions(-)
 rename Documentation/devicetree/bindings/dma/xilinx/{xilinx_vdma.txt => 
xilinx_dma.txt} (100%)
 rename drivers/dma/xilinx/{xilinx_vdma.c => xilinx_dma.c} (100%)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
similarity index 100%
rename from Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
rename to Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 8c98779..1f39f3e 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -519,19 +519,24 @@ config XGENE_DMA
help
  Enable support for the APM X-Gene SoC DMA engine.
 
-config XILINX_VDMA
-   tristate "Xilinx AXI VDMA Engine"
+config XILINX_DMA
+   tristate "Xilinx AXI DMAS Engine"
depends on (ARCH_ZYNQ || MICROBLAZE || ARM64)
select DMA_ENGINE
help
  Enable support for Xilinx AXI VDMA Soft IP.
 
- This engine provides high-bandwidth direct memory access
+ AXI VDMA engine provides high-bandwidth direct memory access
  between memory and AXI4-Stream video type target
  peripherals including peripherals which support AXI4-
  Stream Video Protocol.  It has two stream interfaces/
  channels, Memory Mapped to Stream (MM2S) and Stream to
  Memory Mapped (S2MM) for the data transfers.
+ AXI CDMA engine provides high-bandwidth direct memory access
+ between a memory-mapped source address and a memory-mapped
+ destination address.
+ AXI DMA engine provides high-bandwidth one dimensional direct
+ memory access between memory and AXI4-Stream target peripherals.
 
 config ZX_DMA
tristate "ZTE ZX296702 DMA support"
diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile
index 3c4e9f2..af9e69a 100644
--- a/drivers/dma/xilinx/Makefile
+++ b/drivers/dma/xilinx/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o
+obj-$(CONFIG_XILINX_DMA) += xilinx_dma.o
diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_dma.c
similarity index 100%
rename from drivers/dma/xilinx/xilinx_vdma.c
rename to drivers/dma/xilinx/xilinx_dma.c
-- 
1.7.1



[PATCH v2 0/5] dmaengine: vdma: AXI DMAS Enhancments

2016-06-23 Thread Kedareswara rao Appana
This patch series does the following thing.
---> Add support for AXI DMA Multi-channel DMA mode.
---> Delete AXI DMA binding doc.
---> Rename the driver and update config options.

Kedareswara rao Appana (5):
  Documentation: DT: vdma: Update binding doc for multi-channel dma
mode
  dmaengine: vdma: Add support for mulit-channel dma mode
  Documentation: DT: dma: Delete binding doc for AXI DMA
  dmaengine: dma: Rename driver and config
  dmaengine: dma: Use different channel names for each dma

 .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |   94 +++--
 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |  107 --
 drivers/dma/Kconfig|   11 +-
 drivers/dma/xilinx/Makefile|2 +-
 drivers/dma/xilinx/{xilinx_vdma.c => xilinx_dma.c} |  221 +---
 5 files changed, 277 insertions(+), 158 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
 rename drivers/dma/xilinx/{xilinx_vdma.c => xilinx_dma.c} (92%)



[PATCH v2 1/5] Documentation: DT: vdma: Update binding doc for multi-channel dma mode

2016-06-23 Thread Kedareswara rao Appana
This patch updates the device-tree binding doc for
AXI DMA multi channel dma mode.

Acked-by: Rob Herring 
Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> Added Rob Acked-by.

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index a1f2683..0faa189 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -40,6 +40,8 @@ Required properties for VDMA:
 Optional properties:
 - xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
+Optional properties for AXI DMA:
+- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
 Optional properties for VDMA:
 - xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
@@ -60,6 +62,8 @@ Optional child node properties:
 Optional child node properties for VDMA:
 - xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
+Optional child node properties for AXI DMA:
+-dma-channels: Number of dma channels in child node.
 
 Example:
 
-- 
1.7.1



[PATCH v2 2/5] dmaengine: vdma: Add support for mulit-channel dma mode

2016-06-23 Thread Kedareswara rao Appana
This patch adds support for AXI DMA multi-channel dma mode
Multichannel mode enables DMA to connect to multiple masters
and slaves on the streaming side.

In Multichannel mode AXI DMA supports 2D transfers.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> Removed mcdma_config as suggested by vinod

 drivers/dma/xilinx/xilinx_vdma.c |  213 +
 1 files changed, 190 insertions(+), 23 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 40f754b..0768d9f 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -114,7 +114,7 @@
 #define XILINX_VDMA_REG_START_ADDRESS_64(n)(0x000c + 8 * (n))
 
 /* HW specific definitions */
-#define XILINX_DMA_MAX_CHANS_PER_DEVICE0x2
+#define XILINX_DMA_MAX_CHANS_PER_DEVICE0x20
 
 #define XILINX_DMA_DMAXR_ALL_IRQ_MASK  \
(XILINX_DMA_DMASR_FRM_CNT_IRQ | \
@@ -165,6 +165,18 @@
 #define XILINX_DMA_COALESCE_MAX255
 #define XILINX_DMA_NUM_APP_WORDS   5
 
+/* Multi-Channel DMA Descriptor offsets*/
+#define XILINX_DMA_MCRX_CDESC(x)   (0x40 + (x-1) * 0x20)
+#define XILINX_DMA_MCRX_TDESC(x)   (0x48 + (x-1) * 0x20)
+
+/* Multi-Channel DMA Masks/Shifts */
+#define XILINX_DMA_BD_HSIZE_MASK   GENMASK(15, 0)
+#define XILINX_DMA_BD_STRIDE_MASK  GENMASK(15, 0)
+#define XILINX_DMA_BD_VSIZE_MASK   GENMASK(31, 19)
+#define XILINX_DMA_BD_TDEST_MASK   GENMASK(4, 0)
+#define XILINX_DMA_BD_STRIDE_SHIFT 0
+#define XILINX_DMA_BD_VSIZE_SHIFT  19
+
 /* AXI CDMA Specific Registers/Offsets */
 #define XILINX_CDMA_REG_SRCADDR0x18
 #define XILINX_CDMA_REG_DSTADDR0x20
@@ -210,8 +222,8 @@ struct xilinx_axidma_desc_hw {
u32 next_desc_msb;
u32 buf_addr;
u32 buf_addr_msb;
-   u32 pad1;
-   u32 pad2;
+   u32 mcdma_control;
+   u32 vsize_stride;
u32 control;
u32 status;
u32 app[XILINX_DMA_NUM_APP_WORDS];
@@ -349,6 +361,7 @@ struct xilinx_dma_chan {
struct xilinx_axidma_tx_segment *seg_v;
struct xilinx_axidma_tx_segment *cyclic_seg_v;
void (*start_transfer)(struct xilinx_dma_chan *chan);
+   u16 tdest;
 };
 
 struct xilinx_dma_config {
@@ -365,6 +378,7 @@ struct xilinx_dma_config {
  * @common: DMA device structure
  * @chan: Driver specific DMA channel
  * @has_sg: Specifies whether Scatter-Gather is present or not
+ * @mcdma: Specifies whether Multi-Channel is present or not
  * @flush_on_fsync: Flush on frame sync
  * @ext_addr: Indicates 64 bit addressing is supported by dma device
  * @pdev: Platform device structure pointer
@@ -374,6 +388,8 @@ struct xilinx_dma_config {
  * @txs_clk: DMA mm2s stream clock
  * @rx_clk: DMA s2mm clock
  * @rxs_clk: DMA s2mm stream clock
+ * @nr_channels: Number of channels DMA device supports
+ * @chan_id: DMA channel identifier
  */
 struct xilinx_dma_device {
void __iomem *regs;
@@ -381,6 +397,7 @@ struct xilinx_dma_device {
struct dma_device common;
struct xilinx_dma_chan *chan[XILINX_DMA_MAX_CHANS_PER_DEVICE];
bool has_sg;
+   bool mcdma;
u32 flush_on_fsync;
bool ext_addr;
struct platform_device  *pdev;
@@ -390,6 +407,8 @@ struct xilinx_dma_device {
struct clk *txs_clk;
struct clk *rx_clk;
struct clk *rxs_clk;
+   u32 nr_channels;
+   u32 chan_id;
 };
 
 /* Macros */
@@ -1196,18 +1215,20 @@ static void xilinx_dma_start_transfer(struct 
xilinx_dma_chan *chan)
tail_segment = list_last_entry(_desc->segments,
   struct xilinx_axidma_tx_segment, node);
 
-   old_head = list_first_entry(_desc->segments,
-   struct xilinx_axidma_tx_segment, node);
-   new_head = chan->seg_v;
-   /* Copy Buffer Descriptor fields. */
-   new_head->hw = old_head->hw;
+   if (chan->has_sg && !chan->xdev->mcdma) {
+   old_head = list_first_entry(_desc->segments,
+   struct xilinx_axidma_tx_segment, node);
+   new_head = chan->seg_v;
+   /* Copy Buffer Descriptor fields. */
+   new_head->hw = old_head->hw;
 
-   /* Swap and save new reserve */
-   list_replace_init(_head->node, _head->node);
-   chan->seg_v = old_head;
+   /* Swap and save new reserve */
+   list_replace_init(_head->node, _head->node);
+   chan->seg_v = old_head;
 
-   tail_segment->hw.next_desc = chan->seg_v->phys;
-   head_desc->async_tx.phys = new_head->phys;
+   tail_segment->hw.next_desc = chan->seg_v->phys;
+   head_desc->async_tx.phys = new_head->phys;
+   }
 
reg = dma_ctrl_read(chan, XILINX_DMA_REG_DMACR);
 
@@ -1218,23 +1239,53 @@ static void xilinx_dma_start_transfer(struct 
xilinx_dma_chan *chan)

[PATCH v2 3/5] Documentation: DT: dma: Delete binding doc for AXI DMA

2016-06-23 Thread Kedareswara rao Appana
The AXI DMA support is added to the existing AXI VDMA
driver. Device tree binding information also updated
in the VDMA binding doc.

Acked-by: Rob Herring 
Signed-off-by: Kedareswara rao Appana 
---
--> Added Rob Acked-by.

 .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |   65 
 1 files changed, 0 insertions(+), 65 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
deleted file mode 100644
index 3cf0072..000
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
-target devices. It can be configured to have one channel or two channels.
-If configured as two channels, one is to transmit to the device and another
-is to receive from the device.
-
-Required properties:
-- compatible: Should be "xlnx,axi-dma-1.00.a"
-- #dma-cells: Should be <1>, see "dmas" property below
-- reg: Should contain DMA registers location and length.
-- dma-channel child node: Should have at least one channel and can have up to
-   two channels per device. This node specifies the properties of each
-   DMA channel (see child node properties below).
-
-Optional properties:
-- xlnx,include-sg: Tells whether configured for Scatter-mode in
-   the hardware.
-
-Required child node properties:
-- compatible: It should be either "xlnx,axi-dma-mm2s-channel" or
-   "xlnx,axi-dma-s2mm-channel".
-- interrupts: Should contain per channel DMA interrupts.
-- xlnx,datawidth: Should contain the stream data width, take values
-   {32,64...1024}.
-
-Option child node properties:
-- xlnx,include-dre: Tells whether hardware is configured for Data
-   Realignment Engine.
-
-Example:
-
-
-axi_dma_0: axidma@4040 {
-   compatible = "xlnx,axi-dma-1.00.a";
-   #dma_cells = <1>;
-   reg = < 0x4040 0x1 >;
-   dma-channel@4040 {
-   compatible = "xlnx,axi-dma-mm2s-channel";
-   interrupts = < 0 59 4 >;
-   xlnx,datawidth = <0x40>;
-   } ;
-   dma-channel@40400030 {
-   compatible = "xlnx,axi-dma-s2mm-channel";
-   interrupts = < 0 58 4 >;
-   xlnx,datawidth = <0x40>;
-   } ;
-} ;
-
-
-* DMA client
-
-Required properties:
-- dmas: a list of <[DMA device phandle] [Channel ID]> pairs,
-   where Channel ID is '0' for write/tx and '1' for read/rx
-   channel.
-- dma-names: a list of DMA channel names, one per "dmas" entry
-
-Example:
-
-
-dmatest_0: dmatest@0 {
-   compatible ="xlnx,axi-dma-test-1.00.a";
-   dmas = <_dma_0 0
-   _dma_0 1>;
-   dma-names = "dma0", "dma1";
-} ;
-- 
1.7.1



Re: [PATCH] clk: fixed-factor: add optional dt-binding clock-flags

2016-06-23 Thread kbuild test robot
Hi,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.7-rc4 next-20160623]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jongsung-Kim/clk-fixed-factor-add-optional-dt-binding-clock-flags/20160624-115201
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: x86_64-randconfig-s4-06241247 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/clk/clk-fixed-factor.c: In function 'of_fixed_factor_clk_setup':
>> drivers/clk/clk-fixed-factor.c:170:44: error: passing argument 3 of 
>> 'of_property_read_u32' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 of_property_read_u32(node, "clock-flags", );
   ^
   In file included from include/linux/clk-provider.h:15:0,
from drivers/clk/clk-fixed-factor.c:11:
   include/linux/of.h:916:19: note: expected 'u32 * {aka unsigned int *}' but 
argument is of type 'long unsigned int *'
static inline int of_property_read_u32(const struct device_node *np,
  ^~~~
   cc1: some warnings being treated as errors

vim +/of_property_read_u32 +170 drivers/clk/clk-fixed-factor.c

   164  __func__, node->name);
   165  return;
   166  }
   167  
   168  of_property_read_string(node, "clock-output-names", _name);
   169  parent_name = of_clk_get_parent_name(node, 0);
 > 170  of_property_read_u32(node, "clock-flags", );
   171  
   172  clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 
flags,
   173  mult, div);

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


.config.gz
Description: Binary data


RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

2016-06-23 Thread Yang, Wenyou
Hi Alan,

Sorry for late answer.

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 2016年5月13日 2:11
> To: Yang, Wenyou 
> Cc: Greg Kroah-Hartman ; Ferre, Nicolas
> ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending
> 
> On Thu, 12 May 2016, Wenyou Yang wrote:
> 
> > In order to get lower consumption, as a workaround, suspend the USB
> > PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt
> > Configuration Register while OHCI USB suspending.
> 
> What does this mean?  What does suspending a port do?  Is it the same as a
> normal USB port suspend?

The usb controller from Synopsis does not managed correctly the suspend mode 
for the EHCI. 
There is no way to have the VDDUTMII (USB device and host UTMI interface) 
suspend without any device connected to it. 

That's why we added this specific control to fix this issue. Namely, by setting 
some bits of one of the special function registers to fix this issue outside 
the usb controller. 

And the suspend mode works in OHCI mode.

It is not same as a normal USB port suspend.

> 
> If it is the same, why doesn't the USB_PORT_FEAT_SUSPEND subcase of the
> SetPortFeature case in ohci_hub_control() already take care of this?
> 
> > This suspend operation must be done before stopping the USB clock,
> > resume after the USB clock enabled.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> 
> > @@ -132,6 +135,17 @@ static void at91_stop_hc(struct platform_device
> > *pdev)
> >
> >
> > /*
> > -*/
> >
> > +struct regmap *at91_dt_syscon_sfr(void) {
> > +   struct regmap *regmap;
> > +
> > +   regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> > +   if (IS_ERR(regmap))
> > +   return NULL;
> 
> If you get an error, the regmap pointer is set to NULL...
> 
> > @@ -197,6 +211,8 @@ static int usb_hcd_at91_probe(const struct hc_driver
> *driver,
> > goto err;
> > }
> >
> > +   ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
> 
> With no other error checking...
> 
> > +
> > board = hcd->self.controller->platform_data;
> > ohci = hcd_to_ohci(hcd);
> > ohci->num_ports = board->ports;
> 
> > +static int ohci_at91_port_ctrl(struct regmap *regmap, bool enable) {
> > +   u32 regval;
> > +   int ret;
> > +
> > +   if (IS_ERR(regmap))
> > +   return PTR_ERR(regmap);
> > +
> > +   ret = regmap_read(regmap, SFR_OHCIICR, );
> 
> And now what happens if regmap is NULL?  Hint: It won't be pretty...
> 
> Alan Stern


Best Regards,
Wenyou Yang



linux-next: manual merge of the userns tree with Linus' tree

2016-06-23 Thread Stephen Rothwell
Hi Eric,

Today's linux-next merge of the userns tree got a conflict in:

  fs/proc/root.c

between commit:

  e54ad7f1ee26 ("proc: prevent stacking filesystems on top")

from Linus' tree and commit:

  e94591d0d90c ("proc: Convert proc_mount to use mount_ns")

from the userns tree.

I fixed it up (I used the userns version of this file and added the
following patch) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

From: Stephen Rothwell 
Date: Fri, 24 Jun 2016 14:27:47 +1000
Subject: [PATCH] proc: fixup for "prevent stacking filesystems on top"

Signed-off-by: Stephen Rothwell 
---
 fs/proc/inode.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index a5b2c33745b7..6b1843e78bd7 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -463,6 +463,13 @@ int proc_fill_super(struct super_block *s, void *data, int 
silent)
struct inode *root_inode;
int ret;
 
+   /*
+* procfs isn't actually a stacking filesystem; however, there is
+* too much magic going on inside it to permit stacking things on
+* top of it
+*/
+   s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH;
+
if (!proc_parse_options(data, ns))
return -EINVAL;
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell


Re: [PATCH 6/7] of_graph: add of_graph_get_top_port()

2016-06-23 Thread kbuild test robot
Hi,

[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.7-rc4 next-20160623]
[cannot apply to glikely/devicetree/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kuninori-Morimoto/of_graph-prepare-for-ALSA-graph-support/20160624-105421
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c:22:0:
>> include/linux/of_graph.h:54:50: warning: 'struct device' declared inside 
>> parameter list
struct device_node *of_graph_get_top_port(struct device *dev);
 ^
>> include/linux/of_graph.h:54:50: warning: its scope is only this definition 
>> or declaration, which is probably not what you want

vim +54 include/linux/of_graph.h

38   */
39  #define for_each_endpoint_of_node(parent, child) \
40  for (child = of_graph_get_next_endpoint(parent, NULL); child != 
NULL; \
41   child = of_graph_get_next_endpoint(parent, child))
42  
43  #define of_graph_port_type_is_sound(n)  
of_graph_port_type_is(n, "sound")
44  #define of_graph_endpoint_type_is_sound(n)  
of_graph_endpoint_type_is(n, "sound")
45  #define of_graph_get_sound_endpoint_count(n)
of_graph_get_endpoint_count(n, "sound")
46  
47  #ifdef CONFIG_OF
48  int of_graph_parse_endpoint(const struct device_node *node,
49  struct of_endpoint *endpoint);
50  bool of_graph_port_type_is(struct device_node *port, char *type);
51  bool of_graph_endpoint_type_is(struct device_node *ep, char *type);
52  int of_graph_get_endpoint_count(const struct device_node *np, char 
*type);
53  struct device_node *of_graph_get_port_by_id(struct device_node *node, 
u32 id);
  > 54  struct device_node *of_graph_get_top_port(struct device *dev);
55  struct device_node *of_graph_get_next_endpoint(const struct device_node 
*parent,
56  struct device_node *previous);
57  struct device_node *of_graph_get_endpoint_by_regs(
58  const struct device_node *parent, int port_reg, int 
reg);
59  struct device_node *of_graph_get_remote_endpoint(
60  const struct device_node *node);
61  struct device_node *of_graph_get_port_parent(struct device_node *node);
62  struct device_node *of_graph_get_remote_port_parent(

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


.config.gz
Description: Binary data


Re: [RESEND][PATCH 0/2] Add pl031 RTC support for Hi6220/HiKey

2016-06-23 Thread Rob Herring
On Thu, Jun 23, 2016 at 3:39 PM, John Stultz  wrote:
> This patchset enables the pl031 RTC on the Hi6220 SoC.
>
> I'd like to submit it for review and consideration to be merged.
> (But I've not gotten much feedback on it. Do I have the right
> people cc'ed?)

Yes. One issue is the DT header causes dependency problems as either
clk or arm-soc maintainers have to take everything. I think it is
desired that you don't use defines in the dts file, so arm-soc can
take it and Michael/Stephen can take the clock changes.

Send the dts file change to a...@kernel.org if you can't get any
response from the sub-arch maintainer.

Rob

>
> Michael/Wei: If you don't object to this, can I get an ack from
> one of you so the other can take the change through their tree?
>
> thanks
> -john
>
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Wei Xu 
> Cc: Guodong Xu 
> Cc: Zhangfei Gao 
>
> Zhangfei Gao (2):
>   clk: hi6220: Add RTC clock for pl031
>   arm64: dts: hi6220: Add pl031 RTC support
>
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 16 
>  drivers/clk/hisilicon/clk-hi6220.c|  2 ++
>  include/dt-bindings/clock/hi6220-clock.h  |  5 +++--
>  3 files changed, 21 insertions(+), 2 deletions(-)
>
> --
> 1.9.1
>


Re: mmc: dw_mmc: warning with CONFIG_DMA_API_DEBUG

2016-06-23 Thread Jaehoon Chung
On 06/24/2016 10:25 AM, Shawn Lin wrote:
> Hi Jaehoon,
> 
> On 2016/6/23 19:39, Jaehoon Chung wrote:
>> Hi Shawn,
>>
>> On 06/21/2016 04:39 PM, Shawn Lin wrote:
>>> 在 2016/6/21 13:32, Jaehoon Chung 写道:
 Hi guys,

 On 06/21/2016 11:31 AM, Shawn Lin wrote:
> On 2016/6/21 10:24, Seung-Woo Kim wrote:
>> Hello Shawn,
>>
>>> -Original Message-
>>> From: Shawn Lin [mailto:shawn@rock-chips.com]
>>> Sent: Tuesday, June 21, 2016 10:52 AM
>>> To: Seung-Woo Kim; jh80.ch...@samsung.com; ulf.hans...@linaro.org; 
>>> linux-...@vger.kernel.org; linux-
>>> ker...@vger.kernel.org
>>> Cc: shawn@rock-chips.com
>>> Subject: Re: mmc: dw_mmc: warning with CONFIG_DMA_API_DEBUG
>>>
>>> On 2016/6/20 16:34, Seung-Woo Kim wrote:
 Hi folks,

 During booting test on my Exynos5422 based Odroid-XU3, kernel compiled
 with CONFIG_DMA_API_DEBUG reported following warning:

 [ cut here ]
 WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1096 check_unmap+0x7bc/0xb38
 dwmmc_exynos 1220.mmc: DMA-API: device driver tries to free DMA 
 memory it has not allocated [device
>>> address=0x6d9d2200]
>>>
>>> Thanks for this report and fix.
>>>
>>> DTO(the same as IDMAC-RI/TI) interrupts may or may not come together
>>> with DATA_ERR. If DATA_ERR occur without geting DTO, we should issue
>>> CMD12 manually to generate DTO. It's a ugly deisgn for dwmmc but from
>>> the vendor's ask.
>>>
>>> So you should never think we complete the xfer without
>>> checking DATA_ERR. This way you got the warning.

 Well, EVENT_DATA_ERR is already checked in tasklet_func..and cleared that 
 flags.
>>>
>>> From my view, the reality is that when we got DATA_ERROR interrupts,
>>> we set EVENT_DATA_ERR to the pending_events and schedule the tasklet
>>> but we may still fallback to the IDMAC interrupt case as the tasklet
>>> may come up a little late, namely right after the IDMAC interrupt checking.
>>>
>>> I'm trying to add some log there, and it well proves my guess.
>>
>> You're right..This is appeared because of "Data Over".
>> If Data Over interrupt is occurred, SW needs to read the remaining Data in 
>> FIFO.
>> At that time, it was set to DATA_COMPLETE. Because SW might read the 
>> remaining data, but already set to ERROR_DATA.
>>
>> In this case, Your suggestion may prevent to free twice.
>>
>> There is other case..during tuning sequence.. :(
>> I found that it also appeared during the tuning sequence.
>> - Really..stupid design..
>>
>> My suggestions are
>> First, apply the below solution.
> 
> Which solution? This $SUBJECT or the one I sent?

Yours. :)

> 
> 
> 
>> And then consider the HS200 tuning block with the below patch.
>>
>> https://patchwork.kernel.org/patch/8935791/
> 
> I saw this patch long ago, but I still have not seen
> this issue or got reports for it. From the code itself, it should
> be ok to landed as I checked the databook. :)
> 
>>
>> How about?
>> Do you have any other opinion?
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>

>>>
>>> So could you try this one:
>>
>> With your patch, there is no more the DMA API waring in my environment.
>
> Nice to hear that.  Thanks for testing, Seung-Woo.

 Really? It's not solution..When send tuning command, it should be returned 
 CRC error.
 Then it called the dw_mci_stop_dma() and also dma_ops->complete().
>>>
>>> Hrmm.. I can't see the reason it will also call dma_ops->complete.
>>> Could you explain a bit more here? :)
>>>
>>> From V2.70a Table 3-2
>>> For MMC CMD19, there may be no CRC status returned by the
>>> card but EBE is generated. Hence, EBE is set for CMD19. The application
>>> should not treat this as an error.
>>>
>>>

 When i applied you suggestion, also produced.. :)

 [2.469916] [] (unwind_backtrace) from [] 
 (show_stack+0x10/0x14)
 [2.469934] [] (show_stack) from [] 
 (dump_stack+0x74/0x94)
 [2.469949] [] (dump_stack) from [] 
 (__warn+0xd4/0x100)
 [2.469961] [] (__warn) from [] 
 (warn_slowpath_fmt+0x38/0x48)
 [2.469975] [] (warn_slowpath_fmt) from [] 
 (check_unmap+0x828/0x8a8)
 [2.469991] [] (check_unmap) from [] 
 (debug_dma_unmap_sg+0x5c/0x13c)
 [2.470012] [] (debug_dma_unmap_sg) from [] 
 (dw_mci_dma_cleanup+0x68/0xa4)
 [2.470029] [] (dw_mci_dma_cleanup) from [] 
 (dw_mci_stop_dma+0x30/0x40)
 [2.470045] [] (dw_mci_stop_dma) from [] 
 (dw_mci_tasklet_func+0x340/0x3b4)
 [2.470063] [] (dw_mci_tasklet_func) from [] 
 (tasklet_action+0x84/0x12c)
 [2.470076] [] (tasklet_action) from [] 
 (__do_softirq+0xec/0x244)
 [2.470089] [] (__do_softirq) from [] 
 (irq_exit+0xb4/0xf8)
 [2.470109] [] (irq_exit) from [] 
 (__handle_domain_irq+0x70/0xe4)
 [

[PATCH v4 04/16] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

2016-06-23 Thread Andy Lutomirski
This avoids pointless races in which another CPU or task might see a
partially populated global pgd entry.  These races should normally
be harmless, but, if another CPU propagates the entry via
vmalloc_fault and then populate_pgd fails (due to memory allocation
failure, for example), this prevents a use-after-free of the pgd
entry.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/mm/pageattr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 7a1f7bbf4105..6a8026918bf6 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1113,7 +1113,9 @@ static int populate_pgd(struct cpa_data *cpa, unsigned 
long addr)
 
ret = populate_pud(cpa, addr, pgd_entry, pgprot);
if (ret < 0) {
-   unmap_pgd_range(cpa->pgd, addr,
+   if (pud)
+   free_page((unsigned long)pud);
+   unmap_pud_range(pgd_entry, addr,
addr + (cpa->numpages << PAGE_SHIFT));
return ret;
}
-- 
2.5.5



[PATCH v4 03/16] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

2016-06-23 Thread Andy Lutomirski
From: Ingo Molnar 

So when memory hotplug removes a piece of physical memory from pagetable
mappings, it also frees the underlying PGD entry.

This complicates PGD management, so don't do this. We can keep the
PGD mapped and the PUD table all clear - it's only a single 4K page
per 512 GB of memory hotplugged.

Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Waiman Long 
Cc: linux...@kvack.org
Signed-off-by: Ingo Molnar 
Message-Id: <1442903021-3893-4-git-send-email-mi...@kernel.org>
---
 arch/x86/mm/init_64.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index bce2e5d9edd4..c7465453d64e 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -702,27 +702,6 @@ static void __meminit free_pmd_table(pmd_t *pmd_start, 
pud_t *pud)
spin_unlock(_mm.page_table_lock);
 }
 
-/* Return true if pgd is changed, otherwise return false. */
-static bool __meminit free_pud_table(pud_t *pud_start, pgd_t *pgd)
-{
-   pud_t *pud;
-   int i;
-
-   for (i = 0; i < PTRS_PER_PUD; i++) {
-   pud = pud_start + i;
-   if (pud_val(*pud))
-   return false;
-   }
-
-   /* free a pud table */
-   free_pagetable(pgd_page(*pgd), 0);
-   spin_lock(_mm.page_table_lock);
-   pgd_clear(pgd);
-   spin_unlock(_mm.page_table_lock);
-
-   return true;
-}
-
 static void __meminit
 remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
 bool direct)
@@ -913,7 +892,6 @@ remove_pagetable(unsigned long start, unsigned long end, 
bool direct)
unsigned long addr;
pgd_t *pgd;
pud_t *pud;
-   bool pgd_changed = false;
 
for (addr = start; addr < end; addr = next) {
next = pgd_addr_end(addr, end);
@@ -924,13 +902,8 @@ remove_pagetable(unsigned long start, unsigned long end, 
bool direct)
 
pud = (pud_t *)pgd_page_vaddr(*pgd);
remove_pud_table(pud, addr, next, direct);
-   if (free_pud_table(pud, pgd))
-   pgd_changed = true;
}
 
-   if (pgd_changed)
-   sync_global_pgds(start, end - 1, 1);
-
flush_tlb_all();
 }
 
-- 
2.5.5



[PATCH v4 05/16] x86/mm: Remove kernel_unmap_pages_in_pgd() and efi_cleanup_page_tables()

2016-06-23 Thread Andy Lutomirski
kernel_unmap_pages_in_pgd() is dangerous: if a pgd entry in
init_mm.pgd were to be cleared, callers would need to ensure that
the pgd entry hadn't been propagated to any other pgd.

Its only caller was efi_cleanup_page_tables(), and that, in turn,
was unused, so just delete both functions.  This leaves a couple of
other helpers unused, so delete them, too.

Cc: Matt Fleming 
Cc: linux-...@vger.kernel.org
Reviewed-by: Matt Fleming 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/efi.h   |  1 -
 arch/x86/include/asm/pgtable_types.h |  2 --
 arch/x86/mm/pageattr.c   | 28 
 arch/x86/platform/efi/efi.c  |  2 --
 arch/x86/platform/efi/efi_32.c   |  3 ---
 arch/x86/platform/efi/efi_64.c   |  5 -
 6 files changed, 41 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 78d1e7467eae..45ea38df86d4 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -125,7 +125,6 @@ extern void __init efi_map_region_fixed(efi_memory_desc_t 
*md);
 extern void efi_sync_low_kernel_mappings(void);
 extern int __init efi_alloc_page_tables(void);
 extern int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned 
num_pages);
-extern void __init efi_cleanup_page_tables(unsigned long pa_memmap, unsigned 
num_pages);
 extern void __init old_map_region(efi_memory_desc_t *md);
 extern void __init runtime_code_page_mkexec(void);
 extern void __init efi_runtime_update_mappings(void);
diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index 7b5efe264eff..0b9f58ad10c8 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -475,8 +475,6 @@ extern pmd_t *lookup_pmd_address(unsigned long address);
 extern phys_addr_t slow_virt_to_phys(void *__address);
 extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
   unsigned numpages, unsigned long page_flags);
-void kernel_unmap_pages_in_pgd(pgd_t *root, unsigned long address,
-  unsigned numpages);
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_X86_PGTABLE_DEFS_H */
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 6a8026918bf6..762162af3662 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -746,18 +746,6 @@ static bool try_to_free_pmd_page(pmd_t *pmd)
return true;
 }
 
-static bool try_to_free_pud_page(pud_t *pud)
-{
-   int i;
-
-   for (i = 0; i < PTRS_PER_PUD; i++)
-   if (!pud_none(pud[i]))
-   return false;
-
-   free_page((unsigned long)pud);
-   return true;
-}
-
 static bool unmap_pte_range(pmd_t *pmd, unsigned long start, unsigned long end)
 {
pte_t *pte = pte_offset_kernel(pmd, start);
@@ -871,16 +859,6 @@ static void unmap_pud_range(pgd_t *pgd, unsigned long 
start, unsigned long end)
 */
 }
 
-static void unmap_pgd_range(pgd_t *root, unsigned long addr, unsigned long end)
-{
-   pgd_t *pgd_entry = root + pgd_index(addr);
-
-   unmap_pud_range(pgd_entry, addr, end);
-
-   if (try_to_free_pud_page((pud_t *)pgd_page_vaddr(*pgd_entry)))
-   pgd_clear(pgd_entry);
-}
-
 static int alloc_pte_page(pmd_t *pmd)
 {
pte_t *pte = (pte_t *)get_zeroed_page(GFP_KERNEL | __GFP_NOTRACK);
@@ -1993,12 +1971,6 @@ out:
return retval;
 }
 
-void kernel_unmap_pages_in_pgd(pgd_t *root, unsigned long address,
-  unsigned numpages)
-{
-   unmap_pgd_range(root, address, address + (numpages << PAGE_SHIFT));
-}
-
 /*
  * The testcases use internal knowledge of the implementation that shouldn't
  * be exposed to the rest of the kernel. Include these directly here.
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index f93545e7dc54..62986e5fbdba 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -978,8 +978,6 @@ static void __init __efi_enter_virtual_mode(void)
 * EFI mixed mode we need all of memory to be accessible when
 * we pass parameters to the EFI runtime services in the
 * thunking code.
-*
-* efi_cleanup_page_tables(__pa(new_memmap), 1 << pg_shift);
 */
free_pages((unsigned long)new_memmap, pg_shift);
 
diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
index 338402b91d2e..cef39b097649 100644
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -49,9 +49,6 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
 {
return 0;
 }
-void __init efi_cleanup_page_tables(unsigned long pa_memmap, unsigned 
num_pages)
-{
-}
 
 void __init efi_map_region(efi_memory_desc_t *md)
 {
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 6e7242be1c87..5ab219c2ba43 

[PATCH v4 02/16] rxrpc: Avoid using stack memory in SG lists in rxkad

2016-06-23 Thread Andy Lutomirski
From: Herbert Xu 

rxkad uses stack memory in SG lists which would not work if stacks
were allocated from vmalloc memory.  In fact, in most cases this
isn't even necessary as the stack memory ends up getting copied
over to kmalloc memory.

This patch eliminates all the unnecessary stack memory uses by
supplying the final destination directly to the crypto API.  In
two instances where a temporary buffer is actually needed we also
switch use the skb->cb area instead of the stack.

Finally there is no need to split a split-page buffer into two SG
entries so code dealing with that has been removed.

Message-Id: <20160623064137.ga8...@gondor.apana.org.au>
Signed-off-by: Herbert Xu 
Signed-off-by: Andy Lutomirski 
---
 net/rxrpc/ar-internal.h |   1 +
 net/rxrpc/rxkad.c   | 103 
 2 files changed, 44 insertions(+), 60 deletions(-)

diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index f0b807a163fa..8ee5933982f3 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -277,6 +277,7 @@ struct rxrpc_connection {
struct key  *key;   /* security for this connection 
(client) */
struct key  *server_key;/* security for this service */
struct crypto_skcipher  *cipher;/* encryption handle */
+   struct rxrpc_crypt  csum_iv_head;   /* leading block for csum_iv */
struct rxrpc_crypt  csum_iv;/* packet checksum base */
unsigned long   events;
 #define RXRPC_CONN_CHALLENGE   0   /* send challenge packet */
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index bab56ed649ba..a28a3c6fdf1d 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -105,11 +105,9 @@ static void rxkad_prime_packet_security(struct 
rxrpc_connection *conn)
 {
struct rxrpc_key_token *token;
SKCIPHER_REQUEST_ON_STACK(req, conn->cipher);
-   struct scatterlist sg[2];
+   struct rxrpc_crypt *csum_iv;
+   struct scatterlist sg;
struct rxrpc_crypt iv;
-   struct {
-   __be32 x[4];
-   } tmpbuf __attribute__((aligned(16))); /* must all be in same page */
 
_enter("");
 
@@ -119,24 +117,21 @@ static void rxkad_prime_packet_security(struct 
rxrpc_connection *conn)
token = conn->key->payload.data[0];
memcpy(, token->kad->session_key, sizeof(iv));
 
-   tmpbuf.x[0] = htonl(conn->epoch);
-   tmpbuf.x[1] = htonl(conn->cid);
-   tmpbuf.x[2] = 0;
-   tmpbuf.x[3] = htonl(conn->security_ix);
+   csum_iv = >csum_iv_head;
+   csum_iv[0].x[0] = htonl(conn->epoch);
+   csum_iv[0].x[1] = htonl(conn->cid);
+   csum_iv[1].x[0] = 0;
+   csum_iv[1].x[1] = htonl(conn->security_ix);
 
-   sg_init_one([0], , sizeof(tmpbuf));
-   sg_init_one([1], , sizeof(tmpbuf));
+   sg_init_one(, csum_iv, 16);
 
skcipher_request_set_tfm(req, conn->cipher);
skcipher_request_set_callback(req, 0, NULL, NULL);
-   skcipher_request_set_crypt(req, [1], [0], sizeof(tmpbuf), iv.x);
+   skcipher_request_set_crypt(req, , , 16, iv.x);
 
crypto_skcipher_encrypt(req);
skcipher_request_zero(req);
 
-   memcpy(>csum_iv, [2], sizeof(conn->csum_iv));
-   ASSERTCMP((u32 __force)conn->csum_iv.n[0], ==, (u32 
__force)tmpbuf.x[2]);
-
_leave("");
 }
 
@@ -150,12 +145,9 @@ static int rxkad_secure_packet_auth(const struct 
rxrpc_call *call,
 {
struct rxrpc_skb_priv *sp;
SKCIPHER_REQUEST_ON_STACK(req, call->conn->cipher);
+   struct rxkad_level1_hdr hdr;
struct rxrpc_crypt iv;
-   struct scatterlist sg[2];
-   struct {
-   struct rxkad_level1_hdr hdr;
-   __be32  first;  /* first four bytes of data and padding */
-   } tmpbuf __attribute__((aligned(8))); /* must all be in same page */
+   struct scatterlist sg;
u16 check;
 
sp = rxrpc_skb(skb);
@@ -165,24 +157,21 @@ static int rxkad_secure_packet_auth(const struct 
rxrpc_call *call,
check = sp->hdr.seq ^ sp->hdr.callNumber;
data_size |= (u32)check << 16;
 
-   tmpbuf.hdr.data_size = htonl(data_size);
-   memcpy(, sechdr + 4, sizeof(tmpbuf.first));
+   hdr.data_size = htonl(data_size);
+   memcpy(sechdr, , sizeof(hdr));
 
/* start the encryption afresh */
memset(, 0, sizeof(iv));
 
-   sg_init_one([0], , sizeof(tmpbuf));
-   sg_init_one([1], , sizeof(tmpbuf));
+   sg_init_one(, sechdr, 8);
 
skcipher_request_set_tfm(req, call->conn->cipher);
skcipher_request_set_callback(req, 0, NULL, NULL);
-   skcipher_request_set_crypt(req, [1], [0], sizeof(tmpbuf), iv.x);
+   skcipher_request_set_crypt(req, , , 8, iv.x);
 
crypto_skcipher_encrypt(req);
skcipher_request_zero(req);
 
-   memcpy(sechdr, , sizeof(tmpbuf));
-
_leave(" = 

[PATCH v4 00/16] Virtually mapped stacks with guard pages (x86, core)

2016-06-23 Thread Andy Lutomirski
Since the dawn of time, a kernel stack overflow has been a real PITA
to debug, has caused nondeterministic crashes some time after the
actual overflow, and has generally been easy to exploit for root.

With this series, arches can enable HAVE_ARCH_VMAP_STACK.  Arches
that enable it (just x86 for now) get virtually mapped stacks with
guard pages.  This causes reliable faults when the stack overflows.

If the arch implements it well, we get a nice OOPS on stack overflow
(as opposed to panicing directly or otherwise exploding badly).  On
x86, the OOPS is nice, has a usable call trace, and the overflowing
task is killed cleanly.

On my laptop, this adds about 1.5µs of overhead to task creation,
which seems to be mainly caused by vmalloc inefficiently allocating
individual pages even when a higher-order page is available on the
freelist.

This does not address interrupt stacks.  It also does not address
the possibility of privilege escalation by a controlled stack
overflow that overwrites thread_info without hitting the guard page.
I'll send patches to address the latter issue once this series
lands.

It's worth noting that s390 has an arch-specific gcc feature that
detects stack overflows by adjusting function prologues.  Arches
with features like that may wish to avoid using vmapped stacks to
minimize the performance hit.

Ingo, would it make sense to throw it into a seaparate branch in
-tip?  I wouldn't mind seeing some -next testing to give people a
chance to shake out problems.  I'm particularly interested in
whether there are any drivers that expect virt_to_phys to work on
stack addresses.  (I know that virtio-net used to, but I fixed that
a while back.)

Once this lands in -tip, I'm planning on attacking thread_info.
Once thread_info is under control, we can start caching a couple of
stacks per cpu, and that should get us most of the performance back.

Changes from v3:
 - Fix rxrpc and bluetooth, which used scatterlists pointed at the stack
 - Add some acks and cc's

Changes from v2:
 - Delete kernel_unmap_pages_in_pgd rather than hardening it (Borislav)
 - Fix sub-page stack accounting better (Josh)

Changes from v1:
 - Fix rewind_stack_and_do_exit (Josh)
 - Fix deadlock under load
 - Clean up generic stack vmalloc code
 - Many other minor fixes
 
Andy Lutomirski (14):
  bluetooth: Switch SMP to crypto_cipher_encrypt_one()
  x86/cpa: In populate_pgd, don't set the pgd entry until it's populated
  x86/mm: Remove kernel_unmap_pages_in_pgd() and
efi_cleanup_page_tables()
  mm: Track NR_KERNEL_STACK in KiB instead of number of stacks
  mm: Fix memcg stack accounting for sub-page stacks
  dma-api: Teach the "DMA-from-stack" check about vmapped stacks
  fork: Add generic vmalloced stack support
  x86/die: Don't try to recover from an OOPS on a non-default stack
  x86/dumpstack: When OOPSing, rewind the stack before do_exit
  x86/dumpstack: When dumping stack bytes due to OOPS, start with
regs->sp
  x86/dumpstack: Try harder to get a call trace on stack overflow
  x86/dumpstack/64: Handle faults when printing the "Stack:" part of an
OOPS
  x86/mm/64: Enable vmapped stacks
  x86/mm: Improve stack-overflow #PF handling

Herbert Xu (1):
  rxrpc: Avoid using stack memory in SG lists in rxkad

Ingo Molnar (1):
  x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

 arch/Kconfig |  29 ++
 arch/ia64/include/asm/thread_info.h  |   2 +-
 arch/x86/Kconfig |   1 +
 arch/x86/entry/entry_32.S|  11 
 arch/x86/entry/entry_64.S|  11 
 arch/x86/include/asm/efi.h   |   1 -
 arch/x86/include/asm/pgtable_types.h |   2 -
 arch/x86/include/asm/switch_to.h |  28 +-
 arch/x86/include/asm/traps.h |   6 ++
 arch/x86/kernel/dumpstack.c  |  19 ++-
 arch/x86/kernel/dumpstack_32.c   |   4 +-
 arch/x86/kernel/dumpstack_64.c   |  16 +-
 arch/x86/kernel/traps.c  |  32 +++
 arch/x86/mm/fault.c  |  39 +
 arch/x86/mm/init_64.c|  27 -
 arch/x86/mm/pageattr.c   |  32 +--
 arch/x86/mm/tlb.c|  15 +
 arch/x86/platform/efi/efi.c  |   2 -
 arch/x86/platform/efi/efi_32.c   |   3 -
 arch/x86/platform/efi/efi_64.c   |   5 --
 drivers/base/node.c  |   3 +-
 fs/proc/meminfo.c|   2 +-
 include/linux/memcontrol.h   |   2 +-
 include/linux/mmzone.h   |   2 +-
 include/linux/sched.h|  15 +
 kernel/fork.c|  86 ++---
 lib/dma-debug.c  |  39 +++--
 mm/memcontrol.c  |   2 +-
 mm/page_alloc.c  |   3 +-
 net/bluetooth/smp.c  |  67 ++-
 net/rxrpc/ar-internal.h  |   1 +
 net/rxrpc/rxkad.c| 103 

[PATCH v4 01/16] bluetooth: Switch SMP to crypto_cipher_encrypt_one()

2016-06-23 Thread Andy Lutomirski
SMP does ECB crypto on stack buffers.  This is complicated and
fragile, and it will not work if the stack is virtually allocated.

Switch to the crypto_cipher interface, which is simpler and safer.

Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Cc: "David S. Miller" 
Cc: linux-blueto...@vger.kernel.org
Cc: Herbert Xu 
Cc: net...@vger.kernel.org
Signed-off-by: Andy Lutomirski 
---
 net/bluetooth/smp.c | 67 ++---
 1 file changed, 28 insertions(+), 39 deletions(-)

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 50976a6481f3..4c1a16a96ae5 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -22,9 +22,9 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -88,7 +88,7 @@ struct smp_dev {
u8  min_key_size;
u8  max_key_size;
 
-   struct crypto_skcipher  *tfm_aes;
+   struct crypto_cipher*tfm_aes;
struct crypto_shash *tfm_cmac;
 };
 
@@ -127,7 +127,7 @@ struct smp_chan {
u8  dhkey[32];
u8  mackey[16];
 
-   struct crypto_skcipher  *tfm_aes;
+   struct crypto_cipher*tfm_aes;
struct crypto_shash *tfm_cmac;
 };
 
@@ -361,10 +361,8 @@ static int smp_h6(struct crypto_shash *tfm_cmac, const u8 
w[16],
  * s1 and ah.
  */
 
-static int smp_e(struct crypto_skcipher *tfm, const u8 *k, u8 *r)
+static int smp_e(struct crypto_cipher *tfm, const u8 *k, u8 *r)
 {
-   SKCIPHER_REQUEST_ON_STACK(req, tfm);
-   struct scatterlist sg;
uint8_t tmp[16], data[16];
int err;
 
@@ -378,7 +376,7 @@ static int smp_e(struct crypto_skcipher *tfm, const u8 *k, 
u8 *r)
/* The most significant octet of key corresponds to k[0] */
swap_buf(k, tmp, 16);
 
-   err = crypto_skcipher_setkey(tfm, tmp, 16);
+   err = crypto_cipher_setkey(tfm, tmp, 16);
if (err) {
BT_ERR("cipher setkey failed: %d", err);
return err;
@@ -387,16 +385,7 @@ static int smp_e(struct crypto_skcipher *tfm, const u8 *k, 
u8 *r)
/* Most significant octet of plaintextData corresponds to data[0] */
swap_buf(r, data, 16);
 
-   sg_init_one(, data, 16);
-
-   skcipher_request_set_tfm(req, tfm);
-   skcipher_request_set_callback(req, 0, NULL, NULL);
-   skcipher_request_set_crypt(req, , , 16, NULL);
-
-   err = crypto_skcipher_encrypt(req);
-   skcipher_request_zero(req);
-   if (err)
-   BT_ERR("Encrypt data error %d", err);
+   crypto_cipher_encrypt_one(tfm, data, data);
 
/* Most significant octet of encryptedData corresponds to data[0] */
swap_buf(data, r, 16);
@@ -406,7 +395,7 @@ static int smp_e(struct crypto_skcipher *tfm, const u8 *k, 
u8 *r)
return err;
 }
 
-static int smp_c1(struct crypto_skcipher *tfm_aes, const u8 k[16],
+static int smp_c1(struct crypto_cipher *tfm_aes, const u8 k[16],
  const u8 r[16], const u8 preq[7], const u8 pres[7], u8 _iat,
  const bdaddr_t *ia, u8 _rat, const bdaddr_t *ra, u8 res[16])
 {
@@ -455,7 +444,7 @@ static int smp_c1(struct crypto_skcipher *tfm_aes, const u8 
k[16],
return err;
 }
 
-static int smp_s1(struct crypto_skcipher *tfm_aes, const u8 k[16],
+static int smp_s1(struct crypto_cipher *tfm_aes, const u8 k[16],
  const u8 r1[16], const u8 r2[16], u8 _r[16])
 {
int err;
@@ -471,7 +460,7 @@ static int smp_s1(struct crypto_skcipher *tfm_aes, const u8 
k[16],
return err;
 }
 
-static int smp_ah(struct crypto_skcipher *tfm, const u8 irk[16],
+static int smp_ah(struct crypto_cipher *tfm, const u8 irk[16],
  const u8 r[3], u8 res[3])
 {
u8 _res[16];
@@ -759,7 +748,7 @@ static void smp_chan_destroy(struct l2cap_conn *conn)
kzfree(smp->slave_csrk);
kzfree(smp->link_key);
 
-   crypto_free_skcipher(smp->tfm_aes);
+   crypto_free_cipher(smp->tfm_aes);
crypto_free_shash(smp->tfm_cmac);
 
/* Ensure that we don't leave any debug key around if debug key
@@ -1359,9 +1348,9 @@ static struct smp_chan *smp_chan_create(struct l2cap_conn 
*conn)
if (!smp)
return NULL;
 
-   smp->tfm_aes = crypto_alloc_skcipher("ecb(aes)", 0, CRYPTO_ALG_ASYNC);
+   smp->tfm_aes = crypto_alloc_cipher("aes", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(smp->tfm_aes)) {
-   BT_ERR("Unable to create ECB crypto context");
+   BT_ERR("Unable to create AES crypto context");
kzfree(smp);
return NULL;
}
@@ -1369,7 +1358,7 @@ static struct smp_chan *smp_chan_create(struct l2cap_conn 
*conn)
smp->tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);
if 

[PATCH v4 07/16] mm: Fix memcg stack accounting for sub-page stacks

2016-06-23 Thread Andy Lutomirski
We should account for stacks regardless of stack size, and we need
to account in sub-page units if THREAD_SIZE < PAGE_SIZE.  Change the
units to kilobytes and Move it into account_kernel_stack().

Fixes: 12580e4b54ba8 ("mm: memcontrol: report kernel stack usage in cgroup2 
memory.stat")
Cc: Vladimir Davydov 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: linux...@kvack.org
Reviewed-by: Vladimir Davydov 
Acked-by: Michal Hocko 
Signed-off-by: Andy Lutomirski 
---
 include/linux/memcontrol.h |  2 +-
 kernel/fork.c  | 15 ++-
 mm/memcontrol.c|  2 +-
 3 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index a805474df4ab..3b653b86bb8f 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -52,7 +52,7 @@ enum mem_cgroup_stat_index {
MEM_CGROUP_STAT_SWAP,   /* # of pages, swapped out */
MEM_CGROUP_STAT_NSTATS,
/* default hierarchy stats */
-   MEMCG_KERNEL_STACK = MEM_CGROUP_STAT_NSTATS,
+   MEMCG_KERNEL_STACK_KB = MEM_CGROUP_STAT_NSTATS,
MEMCG_SLAB_RECLAIMABLE,
MEMCG_SLAB_UNRECLAIMABLE,
MEMCG_SOCK,
diff --git a/kernel/fork.c b/kernel/fork.c
index be7f006af727..ff3c41c2ba96 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -165,20 +165,12 @@ static struct thread_info *alloc_thread_info_node(struct 
task_struct *tsk,
struct page *page = alloc_kmem_pages_node(node, THREADINFO_GFP,
  THREAD_SIZE_ORDER);
 
-   if (page)
-   memcg_kmem_update_page_stat(page, MEMCG_KERNEL_STACK,
-   1 << THREAD_SIZE_ORDER);
-
return page ? page_address(page) : NULL;
 }
 
 static inline void free_thread_info(struct thread_info *ti)
 {
-   struct page *page = virt_to_page(ti);
-
-   memcg_kmem_update_page_stat(page, MEMCG_KERNEL_STACK,
-   -(1 << THREAD_SIZE_ORDER));
-   __free_kmem_pages(page, THREAD_SIZE_ORDER);
+   free_kmem_pages((unsigned long)ti, THREAD_SIZE_ORDER);
 }
 # else
 static struct kmem_cache *thread_info_cache;
@@ -227,6 +219,11 @@ static void account_kernel_stack(struct thread_info *ti, 
int account)
 
mod_zone_page_state(zone, NR_KERNEL_STACK_KB,
THREAD_SIZE / 1024 * account);
+
+   /* All stack pages belong to the same memcg. */
+   memcg_kmem_update_page_stat(
+   virt_to_page(ti), MEMCG_KERNEL_STACK_KB,
+   account * (THREAD_SIZE / 1024));
 }
 
 void free_task(struct task_struct *tsk)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 75e74408cc8f..8e13a2419dad 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5133,7 +5133,7 @@ static int memory_stat_show(struct seq_file *m, void *v)
seq_printf(m, "file %llu\n",
   (u64)stat[MEM_CGROUP_STAT_CACHE] * PAGE_SIZE);
seq_printf(m, "kernel_stack %llu\n",
-  (u64)stat[MEMCG_KERNEL_STACK] * PAGE_SIZE);
+  (u64)stat[MEMCG_KERNEL_STACK_KB] * 1024);
seq_printf(m, "slab %llu\n",
   (u64)(stat[MEMCG_SLAB_RECLAIMABLE] +
 stat[MEMCG_SLAB_UNRECLAIMABLE]) * PAGE_SIZE);
-- 
2.5.5



[PATCH v4 10/16] x86/die: Don't try to recover from an OOPS on a non-default stack

2016-06-23 Thread Andy Lutomirski
It's not going to work, because the scheduler will explode if we try
to schedule when running on an IST stack or similar.

This will matter when we let kernel stack overflows (which are #DF)
call die().

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/dumpstack.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index d6209f3a69cb..70d5aae8b8f7 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -245,6 +245,9 @@ void oops_end(unsigned long flags, struct pt_regs *regs, 
int signr)
return;
if (in_interrupt())
panic("Fatal exception in interrupt");
+   if (((current_stack_pointer() ^ (current_top_of_stack() - 1))
+& ~(THREAD_SIZE - 1)) != 0)
+   panic("Fatal exception on special stack");
if (panic_on_oops)
panic("Fatal exception");
do_exit(signr);
-- 
2.5.5



[PATCH v4 09/16] fork: Add generic vmalloced stack support

2016-06-23 Thread Andy Lutomirski
If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with
vmalloc_node.

Signed-off-by: Andy Lutomirski 
---
 arch/Kconfig| 29 +
 arch/ia64/include/asm/thread_info.h |  2 +-
 include/linux/sched.h   | 15 +++
 kernel/fork.c   | 82 +
 4 files changed, 110 insertions(+), 18 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index e9734796531f..835eeef0f14d 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -661,4 +661,33 @@ config ARCH_NO_COHERENT_DMA_MMAP
 config CPU_NO_EFFICIENT_FFS
def_bool n
 
+config HAVE_ARCH_VMAP_STACK
+   def_bool n
+   help
+ An arch should select this symbol if it can support kernel stacks
+ in vmalloc space.  This means:
+
+ - vmalloc space must be large enough to hold many kernel stacks.
+   This may rule out many 32-bit architectures.
+
+ - Stacks in vmalloc space need to work reliably.  For example, if
+   vmap page tables are created on demand, either this mechanism
+   needs to work while the stack points to a virtual address with
+   unpopulated page tables or arch code (switch_to and switch_mm,
+   most likely) needs to ensure that the stack's page table entries
+   are populated before running on a possibly unpopulated stack.
+
+ - If the stack overflows into a guard page, something reasonable
+   should happen.  The definition of "reasonable" is flexible, but
+   instantly rebooting without logging anything would be unfriendly.
+
+config VMAP_STACK
+   bool "Use a virtually-mapped stack"
+   depends on HAVE_ARCH_VMAP_STACK
+   ---help---
+ Enable this if you want the use virtually-mapped kernel stacks
+ with guard pages.  This causes kernel stack overflows to be
+ caught immediately rather than causing difficult-to-diagnose
+ corruption.
+
 source "kernel/gcov/Kconfig"
diff --git a/arch/ia64/include/asm/thread_info.h 
b/arch/ia64/include/asm/thread_info.h
index aa995b67c3f5..d13edda6e09c 100644
--- a/arch/ia64/include/asm/thread_info.h
+++ b/arch/ia64/include/asm/thread_info.h
@@ -56,7 +56,7 @@ struct thread_info {
 #define alloc_thread_info_node(tsk, node)  ((struct thread_info *) 0)
 #define task_thread_info(tsk)  ((struct thread_info *) 0)
 #endif
-#define free_thread_info(ti)   /* nothing */
+#define free_thread_info(tsk)  /* nothing */
 #define task_stack_page(tsk)   ((void *)(tsk))
 
 #define __HAVE_THREAD_FUNCTIONS
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6e42ada26345..a37c3b790309 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1918,6 +1918,9 @@ struct task_struct {
 #ifdef CONFIG_MMU
struct task_struct *oom_reaper_list;
 #endif
+#ifdef CONFIG_VMAP_STACK
+   struct vm_struct *stack_vm_area;
+#endif
 /* CPU-specific state of this task */
struct thread_struct thread;
 /*
@@ -1934,6 +1937,18 @@ extern int arch_task_struct_size __read_mostly;
 # define arch_task_struct_size (sizeof(struct task_struct))
 #endif
 
+#ifdef CONFIG_VMAP_STACK
+static inline struct vm_struct *task_stack_vm_area(const struct task_struct *t)
+{
+   return t->stack_vm_area;
+}
+#else
+static inline struct vm_struct *task_stack_vm_area(const struct task_struct *t)
+{
+   return NULL;
+}
+#endif
+
 /* Future-safe accessor for struct task_struct's cpus_allowed. */
 #define tsk_cpus_allowed(tsk) (&(tsk)->cpus_allowed)
 
diff --git a/kernel/fork.c b/kernel/fork.c
index ff3c41c2ba96..fe1c785e5f8c 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -158,19 +158,38 @@ void __weak arch_release_thread_info(struct thread_info 
*ti)
  * Allocate pages if THREAD_SIZE is >= PAGE_SIZE, otherwise use a
  * kmemcache based allocator.
  */
-# if THREAD_SIZE >= PAGE_SIZE
+# if THREAD_SIZE >= PAGE_SIZE || defined(CONFIG_VMAP_STACK)
 static struct thread_info *alloc_thread_info_node(struct task_struct *tsk,
  int node)
 {
+#ifdef CONFIG_VMAP_STACK
+   struct thread_info *ti = __vmalloc_node_range(
+   THREAD_SIZE, THREAD_SIZE, VMALLOC_START, VMALLOC_END,
+   THREADINFO_GFP | __GFP_HIGHMEM, PAGE_KERNEL,
+   0, node, __builtin_return_address(0));
+
+   /*
+* We can't call find_vm_area() in interrupt context, and
+* free_thread_info can be called in interrupt context, so cache
+* the vm_struct.
+*/
+   if (ti)
+   tsk->stack_vm_area = find_vm_area(ti);
+   return ti;
+#else
struct page *page = alloc_kmem_pages_node(node, THREADINFO_GFP,
  THREAD_SIZE_ORDER);
 
return page ? page_address(page) : NULL;
+#endif
 }
 
-static inline void free_thread_info(struct thread_info *ti)
+static inline void free_thread_info(struct task_struct *tsk)
 {
-   

[PATCH v4 14/16] x86/dumpstack/64: Handle faults when printing the "Stack:" part of an OOPS

2016-06-23 Thread Andy Lutomirski
If we overflow the stack into a guard page, we'll recursively fault
when trying to dump the contents of the guard page.  Use
probe_kernel_address so we can recover if this happens.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/dumpstack_64.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index a81e1ef73bf2..6dede08dd98b 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -274,6 +274,8 @@ show_stack_log_lvl(struct task_struct *task, struct pt_regs 
*regs,
 
stack = sp;
for (i = 0; i < kstack_depth_to_print; i++) {
+   unsigned long word;
+
if (stack >= irq_stack && stack <= irq_stack_end) {
if (stack == irq_stack_end) {
stack = (unsigned long *) (irq_stack_end[-1]);
@@ -283,12 +285,18 @@ show_stack_log_lvl(struct task_struct *task, struct 
pt_regs *regs,
if (kstack_end(stack))
break;
}
+
+   if (probe_kernel_address(stack, word))
+   break;
+
if ((i % STACKSLOTS_PER_LINE) == 0) {
if (i != 0)
pr_cont("\n");
-   printk("%s %016lx", log_lvl, *stack++);
+   printk("%s %016lx", log_lvl, word);
} else
-   pr_cont(" %016lx", *stack++);
+   pr_cont(" %016lx", word);
+
+   stack++;
touch_nmi_watchdog();
}
preempt_enable();
-- 
2.5.5



[PATCH v4 13/16] x86/dumpstack: Try harder to get a call trace on stack overflow

2016-06-23 Thread Andy Lutomirski
If we overflow the stack, print_context_stack will abort.  Detect
this case and rewind back into the valid part of the stack so that
we can trace it.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/dumpstack.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 4592bc4ed3e1..4538f7ca9072 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -87,7 +87,7 @@ static inline int valid_stack_ptr(struct task_struct *task,
else
return 0;
}
-   return p > t && p < t + THREAD_SIZE - size;
+   return p >= t && p < t + THREAD_SIZE - size;
 }
 
 unsigned long
@@ -98,6 +98,13 @@ print_context_stack(struct task_struct *task,
 {
struct stack_frame *frame = (struct stack_frame *)bp;
 
+   /*
+* If we overflowed the stack into a guard page, jump back to the
+* bottom of the usable stack.
+*/
+   if ((unsigned long)task->stack - (unsigned long)stack < PAGE_SIZE)
+   stack = (unsigned long *)task->stack;
+
while (valid_stack_ptr(task, stack, sizeof(*stack), end)) {
unsigned long addr;
 
-- 
2.5.5



[PATCH v4 15/16] x86/mm/64: Enable vmapped stacks

2016-06-23 Thread Andy Lutomirski
This allows x86_64 kernels to enable vmapped stacks.  There are a
couple of interesting bits.

First, x86 lazily faults in top-level paging entries for the vmalloc
area.  This won't work if we get a page fault while trying to access
the stack: the CPU will promote it to a double-fault and we'll die.
To avoid this problem, probe the new stack when switching stacks and
forcibly populate the pgd entry for the stack when switching mms.

Second, once we have guard pages around the stack, we'll want to
detect and handle stack overflow.

I didn't enable it on x86_32.  We'd need to rework the double-fault
code a bit and I'm concerned about running out of vmalloc virtual
addresses under some workloads.

This patch, by itself, will behave somewhat erratically when the
stack overflows while RSP is still more than a few tens of bytes
above the bottom of the stack.  Specifically, we'll get #PF and make
it to no_context and an oops without triggering a double-fault, and
no_context doesn't know about stack overflows.  The next patch will
improve that case.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/Kconfig |  1 +
 arch/x86/include/asm/switch_to.h | 28 +++-
 arch/x86/kernel/traps.c  | 32 
 arch/x86/mm/tlb.c| 15 +++
 4 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d9a94da0c29f..afdcf96ef109 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -92,6 +92,7 @@ config X86
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE
select HAVE_EBPF_JITif X86_64
+   select HAVE_ARCH_VMAP_STACK if X86_64
select HAVE_CC_STACKPROTECTOR
select HAVE_CMPXCHG_DOUBLE
select HAVE_CMPXCHG_LOCAL
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 8f321a1b03a1..14e4b20f0aaf 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -8,6 +8,28 @@ struct tss_struct;
 void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
  struct tss_struct *tss);
 
+/* This runs runs on the previous thread's stack. */
+static inline void prepare_switch_to(struct task_struct *prev,
+struct task_struct *next)
+{
+#ifdef CONFIG_VMAP_STACK
+   /*
+* If we switch to a stack that has a top-level paging entry
+* that is not present in the current mm, the resulting #PF will
+* will be promoted to a double-fault and we'll panic.  Probe
+* the new stack now so that vmalloc_fault can fix up the page
+* tables if needed.  This can only happen if we use a stack
+* in vmap space.
+*
+* We assume that the stack is aligned so that it never spans
+* more than one top-level paging entry.
+*
+* To minimize cache pollution, just follow the stack pointer.
+*/
+   READ_ONCE(*(unsigned char *)next->thread.sp);
+#endif
+}
+
 #ifdef CONFIG_X86_32
 
 #ifdef CONFIG_CC_STACKPROTECTOR
@@ -39,6 +61,8 @@ do {  
\
 */ \
unsigned long ebx, ecx, edx, esi, edi;  \
\
+   prepare_switch_to(prev, next);  \
+   \
asm volatile("pushl %%ebp\n\t"  /* saveEBP   */ \
 "movl %%esp,%[prev_sp]\n\t"/* saveESP   */ \
 "movl %[next_sp],%%esp\n\t"/* restore ESP   */ \
@@ -103,7 +127,9 @@ do {
\
  * clean in kernel mode, with the possible exception of IOPL.  Kernel IOPL
  * has no effect.
  */
-#define switch_to(prev, next, last) \
+#define switch_to(prev, next, last)  \
+   prepare_switch_to(prev, next);\
+ \
asm volatile(SAVE_CONTEXT \
 "movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP */   \
 "movq %P[threadrsp](%[next]),%%rsp\n\t" /* restore RSP */\
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 00f03d82e69a..9cb7ea781176 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -292,12 +292,30 @@ DO_ERROR(X86_TRAP_NP, SIGBUS,  "segment not present", 
segment_not_present)
 DO_ERROR(X86_TRAP_SS, SIGBUS,  "stack segment",stack_segment)
 DO_ERROR(X86_TRAP_AC, SIGBUS,  "alignment check",  alignment_check)
 
+#ifdef 

[PATCH v4 12/16] x86/dumpstack: When dumping stack bytes due to OOPS, start with regs->sp

2016-06-23 Thread Andy Lutomirski
The comment suggests that show_stack(NULL, NULL) should backtrace
the current context, but the code doesn't match the comment.  If
regs are given, start the "Stack:" hexdump at regs->sp.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/dumpstack_32.c | 4 +++-
 arch/x86/kernel/dumpstack_64.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
index fef917e79b9d..948d77da3881 100644
--- a/arch/x86/kernel/dumpstack_32.c
+++ b/arch/x86/kernel/dumpstack_32.c
@@ -96,7 +96,9 @@ show_stack_log_lvl(struct task_struct *task, struct pt_regs 
*regs,
int i;
 
if (sp == NULL) {
-   if (task)
+   if (regs)
+   sp = (unsigned long *)regs->sp;
+   else if (task)
sp = (unsigned long *)task->thread.sp;
else
sp = (unsigned long *)
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index d558a8a49016..a81e1ef73bf2 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -264,7 +264,9 @@ show_stack_log_lvl(struct task_struct *task, struct pt_regs 
*regs,
 * back trace for this cpu:
 */
if (sp == NULL) {
-   if (task)
+   if (regs)
+   sp = (unsigned long *)regs->sp;
+   else if (task)
sp = (unsigned long *)task->thread.sp;
else
sp = (unsigned long *)
-- 
2.5.5



[PATCH v4 16/16] x86/mm: Improve stack-overflow #PF handling

2016-06-23 Thread Andy Lutomirski
If we get a page fault indicating kernel stack overflow, invoke
handle_stack_overflow().  To prevent us from overflowing the stack
again while handling the overflow (because we are likely to have
very little stack space left), call handle_stack_overflow() on the
double-fault stack

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/traps.h |  6 ++
 arch/x86/kernel/traps.c  |  6 +++---
 arch/x86/mm/fault.c  | 39 +++
 3 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index c3496619740a..01fd0a7f48cd 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -117,6 +117,12 @@ extern void ist_exit(struct pt_regs *regs);
 extern void ist_begin_non_atomic(struct pt_regs *regs);
 extern void ist_end_non_atomic(void);
 
+#ifdef CONFIG_VMAP_STACK
+void __noreturn handle_stack_overflow(const char *message,
+ struct pt_regs *regs,
+ unsigned long fault_address);
+#endif
+
 /* Interrupts/Exceptions */
 enum {
X86_TRAP_DE = 0,/*  0, Divide-by-zero */
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 9cb7ea781176..b389c0539eb9 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -293,9 +293,9 @@ DO_ERROR(X86_TRAP_SS, SIGBUS,  "stack segment", 
stack_segment)
 DO_ERROR(X86_TRAP_AC, SIGBUS,  "alignment check",  alignment_check)
 
 #ifdef CONFIG_VMAP_STACK
-static void __noreturn handle_stack_overflow(const char *message,
-struct pt_regs *regs,
-unsigned long fault_address)
+__visible void __noreturn handle_stack_overflow(const char *message,
+   struct pt_regs *regs,
+   unsigned long fault_address)
 {
printk(KERN_EMERG "BUG: stack guard page was hit at %p (stack is 
%p..%p)\n",
 (void *)fault_address, current->stack,
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 7d1fa7cd2374..c68b81f5659f 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -753,6 +753,45 @@ no_context(struct pt_regs *regs, unsigned long error_code,
return;
}
 
+#ifdef CONFIG_VMAP_STACK
+   /*
+* Stack overflow?  During boot, we can fault near the initial
+* stack in the direct map, but that's not an overflow -- check
+* that we're in vmalloc space to avoid this.
+*
+* Check this after trying fixup_exception, since there are handful
+* of kernel code paths that wander off the top of the stack but
+* handle any faults that occur.  Once those are fixed, we can
+* move this above fixup_exception.
+*/
+   if (is_vmalloc_addr((void *)address) &&
+   (((unsigned long)tsk->stack - 1 - address < PAGE_SIZE) ||
+address - ((unsigned long)tsk->stack + THREAD_SIZE) < PAGE_SIZE)) {
+   register void *__sp asm("rsp");
+   unsigned long stack =
+   this_cpu_read(orig_ist.ist[DOUBLEFAULT_STACK]) -
+   sizeof(void *);
+   /*
+* We're likely to be running with very little stack space
+* left.  It's plausible that we'd hit this condition but
+* double-fault even before we get this far, in which case
+* we're fine: the double-fault handler will deal with it.
+*
+* We don't want to make it all the way into the oops code
+* and then double-fault, though, because we're likely to
+* break the console driver and lose most of the stack dump.
+*/
+   asm volatile ("movq %[stack], %%rsp\n\t"
+ "call handle_stack_overflow\n\t"
+ "1: jmp 1b"
+ : "+r" (__sp)
+ : "D" ("kernel stack overflow (page fault)"),
+   "S" (regs), "d" (address),
+   [stack] "rm" (stack));
+   unreachable();
+   }
+#endif
+
/*
 * 32-bit:
 *
-- 
2.5.5



[PATCH v4 11/16] x86/dumpstack: When OOPSing, rewind the stack before do_exit

2016-06-23 Thread Andy Lutomirski
If we call do_exit with a clean stack, we greatly reduce the risk of
recursive oopses due to stack overflow in do_exit, and we allow
do_exit to work even if we OOPS from an IST stack.  The latter gives
us a much better chance of surviving long enough after we detect a
stack overflow to write out our logs.

I intentionally separated this from the preceding patch that
disables do_exit-on-OOPS on IST stacks.  This way, if we need to
revert this patch, we still end up in an acceptable state wrt stack
overflow handling.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/entry_32.S   | 11 +++
 arch/x86/entry/entry_64.S   | 11 +++
 arch/x86/kernel/dumpstack.c | 13 +
 3 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 983e5d3a0d27..0b5e6039 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -1153,3 +1153,14 @@ ENTRY(async_page_fault)
jmp error_code
 END(async_page_fault)
 #endif
+
+ENTRY(rewind_stack_do_exit)
+   /* Prevent any naive code from trying to unwind to our caller. */
+   xorl%ebp, %ebp
+
+   movlPER_CPU_VAR(cpu_current_top_of_stack), %esi
+   leal-TOP_OF_KERNEL_STACK_PADDING-PTREGS_SIZE(%esi), %esp
+
+   calldo_exit
+1: jmp 1b
+END(rewind_stack_do_exit)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 9ee0da1807ed..b846875aeea6 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1423,3 +1423,14 @@ ENTRY(ignore_sysret)
mov $-ENOSYS, %eax
sysret
 END(ignore_sysret)
+
+ENTRY(rewind_stack_do_exit)
+   /* Prevent any naive code from trying to unwind to our caller. */
+   xorl%ebp, %ebp
+
+   movqPER_CPU_VAR(cpu_current_top_of_stack), %rax
+   leaq-TOP_OF_KERNEL_STACK_PADDING-PTREGS_SIZE(%rax), %rsp
+
+   calldo_exit
+1: jmp 1b
+END(rewind_stack_do_exit)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 70d5aae8b8f7..4592bc4ed3e1 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -226,6 +226,8 @@ unsigned long oops_begin(void)
 EXPORT_SYMBOL_GPL(oops_begin);
 NOKPROBE_SYMBOL(oops_begin);
 
+extern void __noreturn rewind_stack_do_exit(int signr);
+
 void oops_end(unsigned long flags, struct pt_regs *regs, int signr)
 {
if (regs && kexec_should_crash(current))
@@ -245,12 +247,15 @@ void oops_end(unsigned long flags, struct pt_regs *regs, 
int signr)
return;
if (in_interrupt())
panic("Fatal exception in interrupt");
-   if (((current_stack_pointer() ^ (current_top_of_stack() - 1))
-& ~(THREAD_SIZE - 1)) != 0)
-   panic("Fatal exception on special stack");
if (panic_on_oops)
panic("Fatal exception");
-   do_exit(signr);
+
+   /*
+* We're not going to return, but we might be on an IST stack or
+* have very little stack space left.  Rewind the stack and kill
+* the task.
+*/
+   rewind_stack_do_exit(signr);
 }
 NOKPROBE_SYMBOL(oops_end);
 
-- 
2.5.5



[PATCH v4 06/16] mm: Track NR_KERNEL_STACK in KiB instead of number of stacks

2016-06-23 Thread Andy Lutomirski
Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
zone.  This only makes sense if each kernel stack exists entirely in
one zone, and allowing vmapped stacks could break this assumption.

Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack
allocations in a unit that divides both THREAD_SIZE and PAGE_SIZE on
all architectures.  Keep it simple and use KiB.

Cc: Vladimir Davydov 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: linux...@kvack.org
Reviewed-by: Vladimir Davydov 
Acked-by: Michal Hocko 
Signed-off-by: Andy Lutomirski 
---
 drivers/base/node.c| 3 +--
 fs/proc/meminfo.c  | 2 +-
 include/linux/mmzone.h | 2 +-
 kernel/fork.c  | 3 ++-
 mm/page_alloc.c| 3 +--
 5 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/base/node.c b/drivers/base/node.c
index 560751bad294..27dc68a0ed2d 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -121,8 +121,7 @@ static ssize_t node_read_meminfo(struct device *dev,
   nid, K(node_page_state(nid, NR_FILE_MAPPED)),
   nid, K(node_page_state(nid, NR_ANON_PAGES)),
   nid, K(i.sharedram),
-  nid, node_page_state(nid, NR_KERNEL_STACK) *
-   THREAD_SIZE / 1024,
+  nid, node_page_state(nid, NR_KERNEL_STACK_KB),
   nid, K(node_page_state(nid, NR_PAGETABLE)),
   nid, K(node_page_state(nid, NR_UNSTABLE_NFS)),
   nid, K(node_page_state(nid, NR_BOUNCE)),
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 83720460c5bc..239b5a06cee0 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -145,7 +145,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
global_page_state(NR_SLAB_UNRECLAIMABLE)),
K(global_page_state(NR_SLAB_RECLAIMABLE)),
K(global_page_state(NR_SLAB_UNRECLAIMABLE)),
-   global_page_state(NR_KERNEL_STACK) * THREAD_SIZE / 1024,
+   global_page_state(NR_KERNEL_STACK_KB),
K(global_page_state(NR_PAGETABLE)),
 #ifdef CONFIG_QUICKLIST
K(quicklist_total_size()),
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 02069c23486d..63f05a7efb54 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -127,7 +127,7 @@ enum zone_stat_item {
NR_SLAB_RECLAIMABLE,
NR_SLAB_UNRECLAIMABLE,
NR_PAGETABLE,   /* used for pagetables */
-   NR_KERNEL_STACK,
+   NR_KERNEL_STACK_KB, /* measured in KiB */
/* Second 128 byte cacheline */
NR_UNSTABLE_NFS,/* NFS unstable pages */
NR_BOUNCE,
diff --git a/kernel/fork.c b/kernel/fork.c
index 5c2c355aa97f..be7f006af727 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -225,7 +225,8 @@ static void account_kernel_stack(struct thread_info *ti, 
int account)
 {
struct zone *zone = page_zone(virt_to_page(ti));
 
-   mod_zone_page_state(zone, NR_KERNEL_STACK, account);
+   mod_zone_page_state(zone, NR_KERNEL_STACK_KB,
+   THREAD_SIZE / 1024 * account);
 }
 
 void free_task(struct task_struct *tsk)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6903b695ebae..a277dea926c9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4457,8 +4457,7 @@ void show_free_areas(unsigned int filter)
K(zone_page_state(zone, NR_SHMEM)),
K(zone_page_state(zone, NR_SLAB_RECLAIMABLE)),
K(zone_page_state(zone, NR_SLAB_UNRECLAIMABLE)),
-   zone_page_state(zone, NR_KERNEL_STACK) *
-   THREAD_SIZE / 1024,
+   zone_page_state(zone, NR_KERNEL_STACK_KB),
K(zone_page_state(zone, NR_PAGETABLE)),
K(zone_page_state(zone, NR_UNSTABLE_NFS)),
K(zone_page_state(zone, NR_BOUNCE)),
-- 
2.5.5



[PATCH v4 08/16] dma-api: Teach the "DMA-from-stack" check about vmapped stacks

2016-06-23 Thread Andy Lutomirski
If we're using CONFIG_VMAP_STACK and we manage to point an sg entry
at the stack, then either the sg page will be in highmem or sg_virt
will return the direct-map alias.  In neither case will the existing
check_for_stack() implementation realize that it's a stack page.

Fix it by explicitly checking for stack pages.

This has no effect by itself.  It's broken out for ease of review.

Cc: Andrew Morton 
Cc: Arnd Bergmann 
Signed-off-by: Andy Lutomirski 
---
 lib/dma-debug.c | 39 +--
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 51a76af25c66..5b2e63cba90e 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1162,11 +1163,35 @@ static void check_unmap(struct dma_debug_entry *ref)
put_hash_bucket(bucket, );
 }
 
-static void check_for_stack(struct device *dev, void *addr)
+static void check_for_stack(struct device *dev,
+   struct page *page, size_t offset)
 {
-   if (object_is_on_stack(addr))
-   err_printk(dev, NULL, "DMA-API: device driver maps memory from "
-   "stack [addr=%p]\n", addr);
+   void *addr;
+   struct vm_struct *stack_vm_area = task_stack_vm_area(current);
+
+   if (!stack_vm_area) {
+   /* Stack is direct-mapped. */
+   if (PageHighMem(page))
+   return;
+   addr = page_address(page) + offset;
+   if (object_is_on_stack(addr))
+   err_printk(dev, NULL, "DMA-API: device driver maps 
memory from stack [addr=%p]\n",
+  addr);
+   } else {
+   /* Stack is vmalloced. */
+   int i;
+
+   for (i = 0; i < stack_vm_area->nr_pages; i++) {
+   if (page != stack_vm_area->pages[i])
+   continue;
+
+   addr = (u8 *)current->stack + i * PAGE_SIZE +
+   offset;
+   err_printk(dev, NULL, "DMA-API: device driver maps 
memory from stack [probable addr=%p]\n",
+  addr);
+   break;
+   }
+   }
 }
 
 static inline bool overlap(void *addr, unsigned long len, void *start, void 
*end)
@@ -1289,10 +1314,11 @@ void debug_dma_map_page(struct device *dev, struct page 
*page, size_t offset,
if (map_single)
entry->type = dma_debug_single;
 
+   check_for_stack(dev, page, offset);
+
if (!PageHighMem(page)) {
void *addr = page_address(page) + offset;
 
-   check_for_stack(dev, addr);
check_for_illegal_area(dev, addr, size);
}
 
@@ -1384,8 +1410,9 @@ void debug_dma_map_sg(struct device *dev, struct 
scatterlist *sg,
entry->sg_call_ents   = nents;
entry->sg_mapped_ents = mapped_ents;
 
+   check_for_stack(dev, sg_page(s), s->offset);
+
if (!PageHighMem(sg_page(s))) {
-   check_for_stack(dev, sg_virt(s));
check_for_illegal_area(dev, sg_virt(s), sg_dma_len(s));
}
 
-- 
2.5.5



Re: [PATCH v6 2/2] mtd: nand: sunxi: add reset line support

2016-06-23 Thread Boris Brezillon
On Fri, 24 Jun 2016 07:20:38 +0800
Icenowy Zheng  wrote:

> In my opinion, return directly PTR_ERR(nfc->reset) is OK here.
> If devm_reset_control_get_optional() return -EPROBE_DEFER, the code here will 
> also return it. However, if we get other error, why should it return 
> -EPROBE_DEFER again?

Sorry, I just had a brainfart :-). Your implementation is correct.
BTW, can you avoid top-posting and reply inline?

> 
> 24.06.2016, 00:01, "Boris Brezillon" :
> > On Mon, 20 Jun 2016 12:48:38 +0800
> > Icenowy Zheng  wrote:
> >  
> >>  The NAND controller on some sun8i chips needs its reset line to be
> >>  deasserted before they can enter working state.
> >>
> >>  Signed-off-by: Icenowy Zheng 
> >>  ---
> >>    Changes in v2:
> >>  - Corrected the error checking code of reset line.
> >>
> >>    Changes in v3:
> >>  - Corrected a more serious error brought in the "fix" of v2.
> >>
> >>    Changes in v4:
> >>  - Removed unneeded code block after "else".
> >>
> >>    Changes in v5:
> >>  - Added reassertion code in case of initialization error and device
> >>    remove.
> >>
> >>    Changes in v6:
> >>  - Fixed a resource leak by not using goto to exit in case of error.
> >>
> >>   drivers/mtd/nand/sunxi_nand.c | 28 +---
> >>   1 file changed, 25 insertions(+), 3 deletions(-)
> >>
> >>  diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> >>  index a83a690..08d5e88 100644
> >>  --- a/drivers/mtd/nand/sunxi_nand.c
> >>  +++ b/drivers/mtd/nand/sunxi_nand.c
> >>  @@ -39,6 +39,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >>  +#include 
> >>
> >>   #define NFC_REG_CTL 0x
> >>   #define NFC_REG_ST 0x0004
> >>  @@ -269,6 +270,7 @@ struct sunxi_nfc {
> >>   void __iomem *regs;
> >>   struct clk *ahb_clk;
> >>   struct clk *mod_clk;
> >>  + struct reset_control *reset;
> >>   unsigned long assigned_cs;
> >>   unsigned long clk_rate;
> >>   struct list_head chips;
> >>  @@ -1871,26 +1873,42 @@ static int sunxi_nfc_probe(struct platform_device 
> >> *pdev)
> >>   if (ret)
> >>   goto out_ahb_clk_unprepare;
> >>
> >>  + nfc->reset = devm_reset_control_get_optional(dev, "ahb");
> >>  +
> >>  + if (!IS_ERR(nfc->reset)) {
> >>  + ret = reset_control_deassert(nfc->reset);
> >>  + if (ret) {
> >>  + dev_err(dev, "reset err %d\n", ret);
> >>  + goto out_mod_clk_unprepare;
> >>  + }
> >>  + } else if (PTR_ERR(nfc->reset) != -ENOENT) {
> >>  + ret = PTR_ERR(nfc->reset);  
> >
> > You should return -EDEFER_PROBE here.
> >
> > And can you please rebase this series on top of nand/next [1]?
> >
> > [1]https://github.com/linux-nand/linux/tree/nand/next  



Re: [PATCH] capabilities: add capability cgroup controller

2016-06-23 Thread Andy Lutomirski
On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen  wrote:
> On 06/23/16 23:46, Andrew Morton wrote:
>> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen  wrote:
>>
>>> There are many basic ways to control processes, including capabilities,
>>> cgroups and resource limits. However, there are far fewer ways to find
>>> out useful values for the limits, except blind trial and error.
>>>
>>> Currently, there is no way to know which capabilities are actually used.
>>> Even the source code is only implicit, in-depth knowledge of each
>>> capability must be used when analyzing a program to judge which
>>> capabilities the program will exercise.
>>>
>>> Add a new cgroup controller for monitoring of capabilities
>>> in the cgroup.
>>
>> I'm having trouble understanding how valuable this feature is to our
>> users, and that's a rather important thing!
>>
>> Perhaps it would help if you were to explain your motivation:
>> particular use cases which benefited from this, for example.
>>
>
> It's easy to control with for example systemd or many other tools, which
> capabilities a service should have at the start. But how should a system
> administrator, application developer or distro maintaner ever determine
> a suitable value for this? Currently the only way seems to be to become
> an expert on capabilities, make an educated guess how the set of
> programs in question happen to work in this context and especially how
> they could exercise the capabilites in all possible use cases. Even
> then, the outcome is to just try something to see if that happens to
> work. Reading the source code (if available) does not help very much,
> because the use of capabilities is anything but explicit there.
>
> This is way too difficult, there must be some easier way. The
> information which capabilities actually were used in a trial run gives a
> much better starting point. The users can just use the list of used
> capabilities with configuring the service or when developing or
> maintaining the application. Of course, even that could still fail
> eventually, but then you simply copy the new value of used capabilities
> to the configuration, whereas currently you have to reconsider your
> understanding of the capabilities and the programs in light of the
> failure, which by itself might give no new useful information.
>
> One way to solve this for good would be to make the use of capabilities
> explicit in the ABI. For example, there could be a system call
> dac_override() which would be the only possible way ever to use the
> capability CAP_DAC_OVERRIDE and so forth. Then reading source code,
> tracing and many other approaches would be useful. But the OS with that
> kind of ABI (not Linux) would not be Unix-like at all for any
> (potentially) capability using programs, like find(1) or cat(1).

The problem is that most of the capabilities are so powerful on their
own that limiting services to just a few may be all but useless.

--Andy


[PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

2016-06-23 Thread Jongsung Kim
There is no way to set additional flags for a DT-initialized fixed-
factor-clock, and it can be problematic i.e., when the clock rate
needs to be changed. [1][2]

This patch introduces an optional dt-binding named "clock-flags" to
be used for passing any needed flags from dts.

[1] http://www.spinics.net/lists/linux-clk/msg09040.html
[2] https://lkml.org/lkml/2016/6/20/1025

Changes since v1:
 - fix possible build failure when using gcc-5 or gcc-6

Signed-off-by: Jongsung Kim 
Cc: Maxime Ripard 
Cc: Mike Turquette 
Cc: Stephen Boyd 
---
 .../bindings/clock/fixed-factor-clock.txt  |  4 
 drivers/clk/clk-fixed-factor.c |  4 +++-
 include/dt-bindings/clk/clk.h  | 22 ++
 3 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/clk/clk.h

diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt 
b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
index 1bae8527..3e1b79e 100644
--- a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
@@ -13,12 +13,16 @@ Required properties:
 
 Optional properties:
 - clock-output-names : From common clock binding.
+- clock-flags : Additional flags to be used.
 
 Example:
+   #include 
+
clock {
compatible = "fixed-factor-clock";
clocks = <>;
#clock-cells = <0>;
clock-div = <2>;
clock-mult = <1>;
+   clock-flags = ;
};
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 75cd6c7..e626cad 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -150,6 +150,7 @@ void __init of_fixed_factor_clk_setup(struct device_node 
*node)
struct clk *clk;
const char *clk_name = node->name;
const char *parent_name;
+   u32 flags = 0;
u32 div, mult;
 
if (of_property_read_u32(node, "clock-div", )) {
@@ -166,8 +167,9 @@ void __init of_fixed_factor_clk_setup(struct device_node 
*node)
 
of_property_read_string(node, "clock-output-names", _name);
parent_name = of_clk_get_parent_name(node, 0);
+   of_property_read_u32(node, "clock-flags", );
 
-   clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+   clk = clk_register_fixed_factor(NULL, clk_name, parent_name, flags,
mult, div);
if (!IS_ERR(clk))
of_clk_add_provider(node, of_clk_src_simple_get, clk);
diff --git a/include/dt-bindings/clk/clk.h b/include/dt-bindings/clk/clk.h
new file mode 100644
index 000..1834933
--- /dev/null
+++ b/include/dt-bindings/clk/clk.h
@@ -0,0 +1,22 @@
+/*
+ * See include/linux/clk-provider.h for more information.
+ */
+
+#ifndef __DT_BINDINGS_CLK_CLK_H
+#define __DT_BINDINGS_CLK_CLK_H
+
+#define BIT(nr)(1UL << (nr))
+
+#define CLK_SET_RATE_GATE  BIT(0)
+#define CLK_SET_PARENT_GATEBIT(1)
+#define CLK_SET_RATE_PARENTBIT(2)
+#define CLK_IGNORE_UNUSED  BIT(3)
+#define CLK_IS_BASIC   BIT(5)
+#define CLK_GET_RATE_NOCACHE   BIT(6)
+#define CLK_SET_RATE_NO_REPARENT   BIT(7)
+#define CLK_GET_ACCURACY_NOCACHE   BIT(8)
+#define CLK_RECALC_NEW_RATES   BIT(9)
+#define CLK_SET_RATE_UNGATEBIT(10)
+#define CLK_IS_CRITICALBIT(11)
+
+#endif
-- 
2.7.4



RE: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

2016-06-23 Thread Tian, Kevin
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, June 24, 2016 11:37 AM
> 
> On Fri, 24 Jun 2016 10:52:58 +0800
> Yongji Xie  wrote:
> > On 2016/6/24 0:12, Alex Williamson wrote:
> > > On Mon, 30 May 2016 21:06:37 +0800
> > > Yongji Xie  wrote:
> > >> +static void vfio_pci_probe_mmaps(struct vfio_pci_device *vdev)
> > >> +{
> > >> +struct resource *res;
> > >> +int bar;
> > >> +struct vfio_pci_dummy_resource *dummy_res;
> > >> +
> > >> +INIT_LIST_HEAD(>dummy_resources_list);
> > >> +
> > >> +for (bar = PCI_STD_RESOURCES; bar <= PCI_STD_RESOURCE_END; 
> > >> bar++) {
> > >> +res = vdev->pdev->resource + bar;
> > >> +
> > >> +if (!IS_ENABLED(CONFIG_VFIO_PCI_MMAP))
> > >> +goto no_mmap;
> > >> +
> > >> +if (!(res->flags & IORESOURCE_MEM))
> > >> +goto no_mmap;
> > >> +
> > >> +/*
> > >> + * The PCI core shouldn't set up a resource with a
> > >> + * type but zero size. But there may be bugs that
> > >> + * cause us to do that.
> > >> + */
> > >> +if (!resource_size(res))
> > >> +goto no_mmap;
> > >> +
> > >> +if (resource_size(res) >= PAGE_SIZE) {
> > >> +vdev->bar_mmap_supported[bar] = true;
> > >> +continue;
> > >> +}
> > >> +
> > >> +if (!(res->start & ~PAGE_MASK)) {
> > >> +/*
> > >> + * Add a dummy resource to reserve the remainder
> > >> + * of the exclusive page in case that hot-add
> > >> + * device's bar is assigned into it.
> > >> + */
> > >> +dummy_res = kzalloc(sizeof(*dummy_res), 
> > >> GFP_KERNEL);
> > >> +if (dummy_res == NULL)
> > >> +goto no_mmap;
> > >> +
> > >> +dummy_res->resource.start = res->end + 1;
> > >> +dummy_res->resource.end = res->start + 
> > >> PAGE_SIZE - 1;
> > >> +dummy_res->resource.flags = res->flags;
> > >> +if (request_resource(res->parent,
> > >> +_res->resource)) {
> > >> +kfree(dummy_res);
> > >> +goto no_mmap;
> > >> +}
> > > Isn't it true that request_resource() only tells us that at a given
> > > point in time, no other drivers have reserved that resource?  It seems
> > > like it does not guarantee that the resource isn't routed to another
> > > device or that another driver won't at some point attempt to request
> > > that same resource.  So for example if a user constructs their initrd
> > > to bind vfio-pci to devices before other modules load, this
> > > request_resource() may succeed, at the expense of drivers loaded later
> > > now failing.  The behavior will depend on driver load order and we're
> > > not actually insuring that the overflow resource is unused, just that
> > > we got it first.  Can we do better?  Am I missing something that
> > > prevents this?  Thanks,
> > >
> > > Alex
> >
> > Couldn't PCI resources allocator prevent this, which will find a
> > empty slot in the resource tree firstly, then try to request that
> > resource in allocate_resource() when a PCI device is probed.
> > And I'd like to know why a PCI device driver would attempt to
> > call request_resource()? Should this be done in PCI enumeration?
> 
> Hi Yongji,
> 
> Looks like most pci drivers call pci_request_regions().  From there the
> call path is:
> 
> pci_request_selected_regions
>   __pci_request_selected_regions
> __pci_request_region
>   __request_mem_region
> __request_region
>   __request_resource
> 
> We see this driver ordering issue sometimes with users attempting to
> blacklist native pci drivers, trying to leave a device free for use by
> vfio-pci.  If the device is a graphics card, the generic vesa or uefi
> driver can request device resources causing a failure when vfio-pci
> tries to request those same resources.  I expect that unless it's a
> boot device, like vga in my example, the resources are not enabled
> until the driver opens the device, therefore the request_resource() call
> doesn't occur until that point.
> 
> For another trivial example, look at /proc/iomem as you load and unload
> a driver, on my laptop with e1000e unloaded I see:
> 
>   e120-e121 : :00:19.0
>   e123e000-e123efff : :00:19.0
> 
> When e1000e is loaded, each of these becomes claimed by the e1000e
> driver:
> 
>   e120-e121 : :00:19.0
> e120-e121 : e1000e
>   

Re: [PATCH V3] clocksource/drivers/arc: Convert init function to return error

2016-06-23 Thread Vineet Gupta
On Friday 17 June 2016 03:39 PM, Daniel Lezcano wrote:
> The init functions do not return any error. They behave as the following:
> 
>   - panic, thus leading to a kernel crash while another timer may work and
>make the system boot up correctly
> 
>   or
> 
>   - print an error and let the caller unaware if the state of the system
> 
> Change that by converting the init functions to return an error conforming
> to the CLOCKSOURCE_OF_RET prototype.
> 
> Proper error handling (rollback, errno value) will be changed later case
> by case, thus this change just return back an error or success in the init
> function.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  arch/arc/kernel/time.c | 69 
> ++

[...]

>   evt->cpumask = cpumask_of(smp_processor_id());
> @@ -347,24 +355,31 @@ static void __init arc_clockevent_setup(struct 
> device_node *node)
>   /* Needs apriori irq_set_percpu_devid() done in intc map function */
>   ret = request_percpu_irq(arc_timer_irq, timer_irq_handler,
>"Timer0 (per-cpu-tick)", evt);
> - if (ret)
> - panic("clockevent: unable to request irq\n");
> + if (ret) {
> + pr_err("clockevent: unable to request irq\n");
> + returnr ret;

oops I missed the typo here !
Daniel can u squash this to ur patch !

-Vineet



[PATCH] clk: fixed-factor: add optional dt-binding clock-flags

2016-06-23 Thread Jongsung Kim
There is no way to set additional flags for a DT-initialized fixed-
factor-clock, and it can be problematic i.e., when the clock rate
needs to be changed. [1][2]

This patch introduces an optional dt-binding named "clock-flags" to
be used for passing any needed flags from dts.

[1] http://www.spinics.net/lists/linux-clk/msg09040.html
[2] https://lkml.org/lkml/2016/6/20/1025

Signed-off-by: Jongsung Kim 
Cc: Maxime Ripard 
Cc: Mike Turquette 
Cc: Stephen Boyd 
---
 .../bindings/clock/fixed-factor-clock.txt  |  4 
 drivers/clk/clk-fixed-factor.c |  4 +++-
 include/dt-bindings/clk/clk.h  | 22 ++
 3 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/clk/clk.h

diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt 
b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
index 1bae8527..3e1b79e 100644
--- a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
@@ -13,12 +13,16 @@ Required properties:
 
 Optional properties:
 - clock-output-names : From common clock binding.
+- clock-flags : Additional flags to be used.
 
 Example:
+   #include 
+
clock {
compatible = "fixed-factor-clock";
clocks = <>;
#clock-cells = <0>;
clock-div = <2>;
clock-mult = <1>;
+   clock-flags = ;
};
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 75cd6c7..da3cd9c 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -150,6 +150,7 @@ void __init of_fixed_factor_clk_setup(struct device_node 
*node)
struct clk *clk;
const char *clk_name = node->name;
const char *parent_name;
+   unsigned long flags = 0;
u32 div, mult;
 
if (of_property_read_u32(node, "clock-div", )) {
@@ -166,8 +167,9 @@ void __init of_fixed_factor_clk_setup(struct device_node 
*node)
 
of_property_read_string(node, "clock-output-names", _name);
parent_name = of_clk_get_parent_name(node, 0);
+   of_property_read_u32(node, "clock-flags", );
 
-   clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+   clk = clk_register_fixed_factor(NULL, clk_name, parent_name, flags,
mult, div);
if (!IS_ERR(clk))
of_clk_add_provider(node, of_clk_src_simple_get, clk);
diff --git a/include/dt-bindings/clk/clk.h b/include/dt-bindings/clk/clk.h
new file mode 100644
index 000..1834933
--- /dev/null
+++ b/include/dt-bindings/clk/clk.h
@@ -0,0 +1,22 @@
+/*
+ * See include/linux/clk-provider.h for more information.
+ */
+
+#ifndef __DT_BINDINGS_CLK_CLK_H
+#define __DT_BINDINGS_CLK_CLK_H
+
+#define BIT(nr)(1UL << (nr))
+
+#define CLK_SET_RATE_GATE  BIT(0)
+#define CLK_SET_PARENT_GATEBIT(1)
+#define CLK_SET_RATE_PARENTBIT(2)
+#define CLK_IGNORE_UNUSED  BIT(3)
+#define CLK_IS_BASIC   BIT(5)
+#define CLK_GET_RATE_NOCACHE   BIT(6)
+#define CLK_SET_RATE_NO_REPARENT   BIT(7)
+#define CLK_GET_ACCURACY_NOCACHE   BIT(8)
+#define CLK_RECALC_NEW_RATES   BIT(9)
+#define CLK_SET_RATE_UNGATEBIT(10)
+#define CLK_IS_CRITICALBIT(11)
+
+#endif
-- 
2.7.4



Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

2016-06-23 Thread Chen-Yu Tsai
On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> From: Ondrej Jirman 
>
> Add label to the first cpu so that it can be referenced
> from derived dts files.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 9938972..82faefc 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -52,7 +52,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> -   cpu@0 {
> +   cpu0: cpu@0 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <0>;

Can you also set the cpu clock here? It is part of the SoC
and does not belong in the board DTS files.

Otherwise this one looks good.

ChenYu

> --
> 2.9.0
>


[PATCH V3] printk: Create pr_ functions

2016-06-23 Thread Joe Perches
Using functions instead of macros can reduce overall code size
by eliminating unnecessary "KERN_SOH" prefixes from
format strings.

defconfig x86-64:

$ size vmlinux*
   textdata bss  dec hex  filename
10193570 4331464 1105920 15630954  ee826a vmlinux.new
10192623 4335560 1105920 15634103  ee8eb7 vmlinux.old

As the return value are unimportant and unused in the kernel tree,
these new functions return void.

Miscellanea:

o change pr_ macros to call new __pr_ functions
o change vprintk_nmi and vprintk_default to add LOGLEVEL_ argument

Signed-off-by: Joe Perches 
---
change in v3:

In case anyone didn't notice, Joe can't cut'n'paste.
Fix __pr_info function definition at LOGLEVEL_NOTICE level.

changes in V2:

Fix "CONFIG_PRINTK is not set" builds by adding CONFIG_PRINTK blocks
Fix x86-32 builds by setting __pr_ functions __asmlinkage and visible

Compile tested cross-compiled sparc, tinyconfig, x86-32 & -64 w//o printk

 include/linux/printk.h   | 48 +---
 kernel/printk/internal.h | 16 ++--
 kernel/printk/nmi.c  | 13 +++--
 kernel/printk/printk.c   | 27 ---
 4 files changed, 78 insertions(+), 26 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index f4da695..e6ff22e 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -254,21 +254,39 @@ extern asmlinkage void dump_stack(void) __cold;
  * and other debug macros are compiled out unless either DEBUG is defined
  * or CONFIG_DYNAMIC_DEBUG is set.
  */
-#define pr_emerg(fmt, ...) \
-   printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__)
-#define pr_alert(fmt, ...) \
-   printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
-#define pr_crit(fmt, ...) \
-   printk(KERN_CRIT pr_fmt(fmt), ##__VA_ARGS__)
-#define pr_err(fmt, ...) \
-   printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
-#define pr_warning(fmt, ...) \
-   printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
-#define pr_warn pr_warning
-#define pr_notice(fmt, ...) \
-   printk(KERN_NOTICE pr_fmt(fmt), ##__VA_ARGS__)
-#define pr_info(fmt, ...) \
-   printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
+
+#ifdef CONFIG_PRINTK
+
+asmlinkage __printf(1, 2) __cold void __pr_emerg(const char *fmt, ...);
+asmlinkage __printf(1, 2) __cold void __pr_alert(const char *fmt, ...);
+asmlinkage __printf(1, 2) __cold void __pr_crit(const char *fmt, ...);
+asmlinkage __printf(1, 2) __cold void __pr_err(const char *fmt, ...);
+asmlinkage __printf(1, 2) __cold void __pr_warn(const char *fmt, ...);
+asmlinkage __printf(1, 2) __cold void __pr_notice(const char *fmt, ...);
+asmlinkage __printf(1, 2) __cold void __pr_info(const char *fmt, ...);
+
+#define pr_emerg(fmt, ...) __pr_emerg(pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_alert(fmt, ...) __pr_alert(pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_crit(fmt, ...)  __pr_crit(pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_err(fmt, ...)   __pr_err(pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_warn(fmt, ...)  __pr_warn(pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_notice(fmt, ...)__pr_notice(pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_info(fmt, ...)  __pr_info(pr_fmt(fmt), ##__VA_ARGS__)
+
+#else
+
+#define pr_emerg(fmt, ...) printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_alert(fmt, ...) printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_crit(fmt, ...)  printk(KERN_CRIT pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_err(fmt, ...)   printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_warn(fmt, ...)  printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_notice(fmt, ...)printk(KERN_NOTICE pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_info(fmt, ...)  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
+
+#endif
+
+#define pr_warning pr_warn
+
 /*
  * Like KERN_CONT, pr_cont() should only be used when continuing
  * a line with no newline ('\n') enclosed. Otherwise it defaults
diff --git a/kernel/printk/internal.h b/kernel/printk/internal.h
index 7fd2838..5d4505f 100644
--- a/kernel/printk/internal.h
+++ b/kernel/printk/internal.h
@@ -16,9 +16,11 @@
  */
 #include 
 
-typedef __printf(1, 0) int (*printk_func_t)(const char *fmt, va_list args);
+typedef __printf(2, 0) int (*printk_func_t)(int level, const char *fmt,
+   va_list args);
 
-int __printf(1, 0) vprintk_default(const char *fmt, va_list args);
+__printf(2, 0)
+int vprintk_default(int level, const char *fmt, va_list args);
 
 #ifdef CONFIG_PRINTK_NMI
 
@@ -31,9 +33,10 @@ extern raw_spinlock_t logbuf_lock;
  * via per-CPU variable.
  */
 DECLARE_PER_CPU(printk_func_t, printk_func);
-static inline __printf(1, 0) int vprintk_func(const char *fmt, va_list args)
+__printf(2, 0)
+static inline int vprintk_func(int level, const char *fmt, va_list args)
 {
-   return this_cpu_read(printk_func)(fmt, args);
+   return this_cpu_read(printk_func)(level, fmt, args);
 }
 
 extern atomic_t 

Re: [PATCH 07/14] regulator: SY8106A regulator driver

2016-06-23 Thread Chen-Yu Tsai
On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> From: Ondrej Jirman 
>
> SY8106A is I2C attached single output voltage regulator
> made by Silergy.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  drivers/regulator/Kconfig |   8 +-
>  drivers/regulator/Makefile|   2 +-
>  drivers/regulator/sy8106a-regulator.c | 153 
> ++
>  3 files changed, 161 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/regulator/sy8106a-regulator.c
>
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index 144cbf5..fc3fae2 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -860,5 +860,11 @@ config REGULATOR_WM8994
>   This driver provides support for the voltage regulators on the
>   WM8994 CODEC.
>
> -endif
> +config REGULATOR_SY8106A
> +   tristate "Silergy SY8106A"
> +   depends on I2C

Maybe you should also depend on OF since the driver is going to crippled
without any constraints set, or (OF || COMPILE_TEST) if you want some
compile test coverage.

> +   select REGMAP_I2C
> +   help
> + This driver provides support for the voltage regulator SY8106A.
>
> +endif
> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> index 85a1d44..f382095 100644
> --- a/drivers/regulator/Makefile
> +++ b/drivers/regulator/Makefile
> @@ -110,6 +110,6 @@ obj-$(CONFIG_REGULATOR_WM831X) += wm831x-ldo.o
>  obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
>  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>  obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
> -
> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o

Follow the existing ordering in the Makefile.

>
>  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
> diff --git a/drivers/regulator/sy8106a-regulator.c 
> b/drivers/regulator/sy8106a-regulator.c
> new file mode 100644
> index 000..34bd69c
> --- /dev/null
> +++ b/drivers/regulator/sy8106a-regulator.c
> @@ -0,0 +1,153 @@
> +/*
> + * sy8106a-regulator.c - Regulator device driver for SY8106A
> + *
> + * Copyright (C) 2016  Ondřej Jirman 
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Library General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Library General Public License for more details.
> + *
> + * You should have received a copy of the GNU Library General Public
> + * License along with this library; if not, write to the
> + * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
> + * Boston, MA  02110-1301, USA.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 

Do you need this one?

> +#include 
> +#include 

And this one?

> +#include 
> +#include 

Sort alphabetically please.

> +
> +#define SY8106A_REG_VOUT1_SEL  0x01
> +#define SY8106A_REG_VOUT_COM   0x02
> +#define SY8106A_REG_VOUT1_SEL_MASK 0x7f
> +#define SY8106A_DISABLE_REG0x01

BIT(0) would be clearer.

> +
> +struct sy8106a {
> +   struct regulator_dev *rdev;
> +   struct regmap *regmap;
> +};
> +
> +static const struct regmap_config sy8106a_regmap_config = {
> +   .reg_bits = 8,
> +   .val_bits = 8,
> +};
> +
> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, unsigned sel)
> +{
> +   return regmap_update_bits(rdev->regmap, rdev->desc->vsel_reg,
> + 0xff, sel | 0x80);

Can you use .apply_bit / .apply_reg with regulator_set_voltage_sel_regmap?

> +}
> +
> +static const struct regulator_ops sy8106a_ops = {
> +   .is_enabled = regulator_is_enabled_regmap,
> +   .set_voltage_sel = sy8106a_set_voltage_sel,
> +   .set_voltage_time_sel = regulator_set_voltage_time_sel,
> +   .get_voltage_sel = regulator_get_voltage_sel_regmap,
> +   .list_voltage = regulator_list_voltage_linear,
> +};
> +
> +/* Default limits measured in millivolts and milliamps */
> +#define SY8106A_MIN_MV 680
> +#define SY8106A_MAX_MV 1950
> +#define SY8106A_STEP_MV10
> +
> +static const struct regulator_desc sy8106a_reg = {
> +   .name = "SY8106A",
> +   .id = 0,
> +   .ops = _ops,
> +   .type = REGULATOR_VOLTAGE,
> +   .n_voltages = ((SY8106A_MAX_MV - SY8106A_MIN_MV) / SY8106A_STEP_MV) + 
> 1,
> +   .min_uV = (SY8106A_MIN_MV * 1000),
> +   .uV_step = (SY8106A_STEP_MV * 1000),
> +   .vsel_reg = SY8106A_REG_VOUT1_SEL,
> +   .vsel_mask = SY8106A_REG_VOUT1_SEL_MASK,
> +   .enable_reg = SY8106A_REG_VOUT_COM,
> +   .enable_mask = SY8106A_DISABLE_REG,
> +   

[PATCH] powercap/intel_rapl: Add support for Ivy Bridge server

2016-06-23 Thread Xiaolong Wang
It's confirmed that RAPL works as expected on Ivy Bridge servers.
Tested against processor: Intel(R) Xeon(R) CPU E5-2697 v2 @2.70GHz

Signed-off-by: Xiaolong Wang 
---
 drivers/powercap/intel_rapl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index 06d21e6..fbab29d 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -1134,6 +1134,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X,  rapl_defaults_core),
 
RAPL_CPU(INTEL_FAM6_IVYBRIDGE,  rapl_defaults_core),
+   RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,rapl_defaults_core),
 
RAPL_CPU(INTEL_FAM6_HASWELL_CORE,   rapl_defaults_core),
RAPL_CPU(INTEL_FAM6_HASWELL_ULT,rapl_defaults_core),
-- 
1.8.3.1



Re: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

2016-06-23 Thread Alex Williamson
On Fri, 24 Jun 2016 10:52:58 +0800
Yongji Xie  wrote:
> On 2016/6/24 0:12, Alex Williamson wrote:
> > On Mon, 30 May 2016 21:06:37 +0800
> > Yongji Xie  wrote:
> >> +static void vfio_pci_probe_mmaps(struct vfio_pci_device *vdev)
> >> +{
> >> +  struct resource *res;
> >> +  int bar;
> >> +  struct vfio_pci_dummy_resource *dummy_res;
> >> +
> >> +  INIT_LIST_HEAD(>dummy_resources_list);
> >> +
> >> +  for (bar = PCI_STD_RESOURCES; bar <= PCI_STD_RESOURCE_END; bar++) {
> >> +  res = vdev->pdev->resource + bar;
> >> +
> >> +  if (!IS_ENABLED(CONFIG_VFIO_PCI_MMAP))
> >> +  goto no_mmap;
> >> +
> >> +  if (!(res->flags & IORESOURCE_MEM))
> >> +  goto no_mmap;
> >> +
> >> +  /*
> >> +   * The PCI core shouldn't set up a resource with a
> >> +   * type but zero size. But there may be bugs that
> >> +   * cause us to do that.
> >> +   */
> >> +  if (!resource_size(res))
> >> +  goto no_mmap;
> >> +
> >> +  if (resource_size(res) >= PAGE_SIZE) {
> >> +  vdev->bar_mmap_supported[bar] = true;
> >> +  continue;
> >> +  }
> >> +
> >> +  if (!(res->start & ~PAGE_MASK)) {
> >> +  /*
> >> +   * Add a dummy resource to reserve the remainder
> >> +   * of the exclusive page in case that hot-add
> >> +   * device's bar is assigned into it.
> >> +   */
> >> +  dummy_res = kzalloc(sizeof(*dummy_res), GFP_KERNEL);
> >> +  if (dummy_res == NULL)
> >> +  goto no_mmap;
> >> +
> >> +  dummy_res->resource.start = res->end + 1;
> >> +  dummy_res->resource.end = res->start + PAGE_SIZE - 1;
> >> +  dummy_res->resource.flags = res->flags;
> >> +  if (request_resource(res->parent,
> >> +  _res->resource)) {
> >> +  kfree(dummy_res);
> >> +  goto no_mmap;
> >> +  }  
> > Isn't it true that request_resource() only tells us that at a given
> > point in time, no other drivers have reserved that resource?  It seems
> > like it does not guarantee that the resource isn't routed to another
> > device or that another driver won't at some point attempt to request
> > that same resource.  So for example if a user constructs their initrd
> > to bind vfio-pci to devices before other modules load, this
> > request_resource() may succeed, at the expense of drivers loaded later
> > now failing.  The behavior will depend on driver load order and we're
> > not actually insuring that the overflow resource is unused, just that
> > we got it first.  Can we do better?  Am I missing something that
> > prevents this?  Thanks,
> >
> > Alex  
> 
> Couldn't PCI resources allocator prevent this, which will find a
> empty slot in the resource tree firstly, then try to request that
> resource in allocate_resource() when a PCI device is probed.
> And I'd like to know why a PCI device driver would attempt to
> call request_resource()? Should this be done in PCI enumeration?

Hi Yongji,

Looks like most pci drivers call pci_request_regions().  From there the
call path is:

pci_request_selected_regions
  __pci_request_selected_regions
__pci_request_region
  __request_mem_region
__request_region
  __request_resource

We see this driver ordering issue sometimes with users attempting to
blacklist native pci drivers, trying to leave a device free for use by
vfio-pci.  If the device is a graphics card, the generic vesa or uefi
driver can request device resources causing a failure when vfio-pci
tries to request those same resources.  I expect that unless it's a
boot device, like vga in my example, the resources are not enabled
until the driver opens the device, therefore the request_resource() call
doesn't occur until that point.

For another trivial example, look at /proc/iomem as you load and unload
a driver, on my laptop with e1000e unloaded I see:

  e120-e121 : :00:19.0
  e123e000-e123efff : :00:19.0

When e1000e is loaded, each of these becomes claimed by the e1000e
driver:

  e120-e121 : :00:19.0
e120-e121 : e1000e
  e123e000-e123efff : :00:19.0
e123e000-e123efff : e1000e

Clearly pci core knows the resource is associated with the device, but
I don't think we're tapping into that with request_resource(), we're
just potentially stealing resources that another driver might have
claimed otherwise as I described above.  That's my suspicion at
least, feel free to show otherwise if it's incorrect.  Thanks,

Alex


Re: [PATCH] powerpc/mm: update arch_{add,remove}_memory() for radix

2016-06-23 Thread Balbir Singh


On 24/06/16 03:17, Aneesh Kumar K.V wrote:
> Reza Arbab  writes:
> 
>> These functions are making direct calls to the hash table APIs,
>> leading to a BUG() on systems using radix.
>>
>> Switch them to the vmemmap_{create,remove}_mapping() wrappers, and
>> move to the __meminit section.
> 
> 
> They are really not the same. They can possibly end up using different
> base page size. Also vmemmap is available only with SPARSEMEM_VMEMMAP
> enabled. Does hotplug depend on sparsemem vmemmap ?

# eventually, we can have this option just 'select SPARSEMEM'
config MEMORY_HOTPLUG
bool "Allow for memory hot-add"
depends on SPARSEMEM || X86_64_ACPI_NUMA
depends on ARCH_ENABLE_MEMORY_HOTPLUG

We depend on sparsemem for sure. vmemmap is just a way of getting the memory
virtually mapped. From the patch perspective, I think we need the equivalent of
just mapping the pages in kernel. The address may differ based on whether 
vmemmap
is used or not and of-course page_size, 

Balbir Singh


Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3

2016-06-23 Thread Chen-Yu Tsai
Hi,

On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> From: Ondrej Jirman 
>

The subject could read:

  thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3

> This patch adds support for the sun8i thermal sensor on
> Allwinner H3 SoC.
>
> Signed-off-by: Ondřej Jirman 
> ---
>  drivers/thermal/Kconfig |   7 ++
>  drivers/thermal/Makefile|   1 +
>  drivers/thermal/sun8i_ths.c | 295 
> 
>  3 files changed, 303 insertions(+)
>  create mode 100644 drivers/thermal/sun8i_ths.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 2d702ca..3de0f8d 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -351,6 +351,13 @@ config MTK_THERMAL
>   Enable this option if you want to have support for thermal 
> management
>   controller present in Mediatek SoCs
>
> +config SUN8I_THS
> +   tristate "sun8i THS driver"

Explain THS.

> +   depends on MACH_SUN8I
> +   depends on OF
> +   help
> + Enable this to support thermal reporting on some newer Allwinner 
> SoCs.
> +
>  menu "Texas Instruments thermal drivers"
>  depends on ARCH_HAS_BANDGAP || COMPILE_TEST
>  depends on HAS_IOMEM
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 10b07c1..7261ee8 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM)  += tegra/
>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
>  obj-$(CONFIG_MTK_THERMAL)  += mtk_thermal.o
>  obj-$(CONFIG_GENERIC_ADC_THERMAL)  += thermal-generic-adc.o
> +obj-$(CONFIG_SUN8I_THS)+= sun8i_ths.o
> diff --git a/drivers/thermal/sun8i_ths.c b/drivers/thermal/sun8i_ths.c
> new file mode 100644
> index 000..618ccc3
> --- /dev/null
> +++ b/drivers/thermal/sun8i_ths.c
> @@ -0,0 +1,295 @@
> +/*
> + * sun8i THS driver

Explain THS.

> + *
> + * Copyright (C) 2016 Ondřej Jirman
> + * Based on the work of Josef Gajdusek 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define THS_H3_CTRL0   0x00
> +#define THS_H3_CTRL2   0x40
> +#define THS_H3_INT_CTRL0x44
> +#define THS_H3_STAT0x48
> +#define THS_H3_FILTER  0x70
> +#define THS_H3_CDATA   0x74
> +#define THS_H3_DATA0x80
> +
> +#define THS_H3_CTRL0_SENSOR_ACQ0_OFFS   0
> +#define THS_H3_CTRL0_SENSOR_ACQ0(x) \
> +((x) << THS_H3_CTRL0_SENSOR_ACQ0_OFFS)
> +#define THS_H3_CTRL2_SENSE_EN_OFFS  0
> +#define THS_H3_CTRL2_SENSE_EN \
> +BIT(THS_H3_CTRL2_SENSE_EN_OFFS)
> +#define THS_H3_CTRL2_SENSOR_ACQ1_OFFS   16
> +#define THS_H3_CTRL2_SENSOR_ACQ1(x) \
> +((x) << THS_H3_CTRL2_SENSOR_ACQ1_OFFS)
> +
> +#define THS_H3_INT_CTRL_DATA_IRQ_EN_OFFS8
> +#define THS_H3_INT_CTRL_DATA_IRQ_EN \
> +   BIT(THS_H3_INT_CTRL_DATA_IRQ_EN_OFFS)
> +#define THS_H3_INT_CTRL_THERMAL_PER_OFFS12
> +#define THS_H3_INT_CTRL_THERMAL_PER(x) \
> +   ((x) << THS_H3_INT_CTRL_THERMAL_PER_OFFS)
> +
> +#define THS_H3_STAT_DATA_IRQ_STS_OFFS   8
> +#define THS_H3_STAT_DATA_IRQ_STS \
> +BIT(THS_H3_STAT_DATA_IRQ_STS_OFFS)
> +
> +#define THS_H3_FILTER_TYPE_OFFS 0
> +#define THS_H3_FILTER_TYPE(x) \
> +((x) << THS_H3_FILTER_TYPE_OFFS)
> +#define THS_H3_FILTER_EN_OFFS   2
> +#define THS_H3_FILTER_EN \
> +BIT(THS_H3_FILTER_EN_OFFS)

Is it really necessary to split the lines of all the macros?
It makes it harder to find and read stuff.

You're also not using any of the *_OFFS macros in the actual code,
so just drop them.

> +
> +#define THS_H3_CLK_IN 4000  /* Hz */
> +#define THS_H3_DATA_PERIOD 330  /* ms */
> +
> +#define THS_H3_FILTER_TYPE_VALUE   2  /* average over 2^(n+1) 
> samples */
> +#define THS_H3_FILTER_DIV  (1 << 
> (THS_H3_FILTER_TYPE_VALUE + 1))
> +#define THS_H3_INT_CTRL_THERMAL_PER_VALUE \
> +   (THS_H3_DATA_PERIOD * (THS_H3_CLK_IN / 1000) / THS_H3_FILTER_DIV / 
> 4096 - 1)
> +#define THS_H3_CTRL0_SENSOR_ACQ0_VALUE 0x3f /* 16us */
> +#define THS_H3_CTRL2_SENSOR_ACQ1_VALUE 0x3f
> +
> +struct sun8i_ths_data {
> +   struct reset_control *reset;
> +   struct clk *clk;
> +   struct clk *busclk;
> +   void __iomem *regs;
> +   struct nvmem_cell 

RE: [PATCH] ACPI: Execute the _PTS method when system reboot

2016-06-23 Thread Ocean HY1 He


Regards,
Ocean He
SW Development Dept. 
Beijing Design Center
Enterprise Product Group
Mobile: 18911778926
E-mail: he...@lenovo.com
No.6 Chuang Ye Road, Haidian District, Beijing, China 100085


> -Original Message-
> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of
> Rafael J. Wysocki
> Sent: Thursday, June 23, 2016 9:13 PM
> To: Ocean HY1 He
> Cc: Rafael J. Wysocki; l...@kernel.org; linux-a...@vger.kernel.org;
> linux-kernel@vger.kernel.org; David Tanaka; Nagananda Chumbalkar
> Subject: Re: [PATCH] ACPI: Execute the _PTS method when system reboot
> 
> On Thu, Jun 23, 2016 at 2:55 PM, Ocean HY1 He 
> wrote:
> > Hi Rafael,
> > Please see my reply in below.
> >
> > Regards,
> > Ocean He
> > SW Development Dept.
> > Beijing Design Center
> > Enterprise Product Group
> > Mobile: 18911778926
> > E-mail: he...@lenovo.com
> > No.6 Chuang Ye Road, Haidian District, Beijing, China 100085
> >
> >> -Original Message-
> >> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> >> Sent: Wednesday, June 22, 2016 7:56 AM
> >> To: Ocean HY1 He
> >> Cc: l...@kernel.org; linux-a...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; David Tanaka; Nagananda Chumbalkar
> >> Subject: Re: [PATCH] ACPI: Execute the _PTS method when system
> reboot
> >>
> >> On Monday, May 09, 2016 05:50:11 AM Ocean HY1 He wrote:
> >> > The _PTS control method is defined in the section 7.4.1 of acpi 6.0
> >> > spec. The _PTS control method is executed by the OS during the sleep
> >> > transition process for S1, S2, S3, S4, and for orderly S5 shutdown.
> >> > The sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5
> >> > soft-off state) is passed to the _PTS control method. This method
> >> > is called after OSPM has notified native device drivers of the sleep
> >> > state transition and before the OSPM has had a chance to fully
> >> > prepare the system for a sleep state transition.
> >> >
> >> > The _PTS control method provides the BIOS a mechanism for
> performing
> >> > some housekeeping, such as writing the sleep type value to the
> >> embedded
> >> > controller, before entering the system sleeping state.
> >> >
> >> > According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS.
> >> >
> >> > Thus, a _PTS block notifier is added to the reboot notifier list so that
> >> > the _PTS object will also be evaluated when the system reboot.
> >>
> >> So I understand why it may be necessary to evaluate _PTS before
> entering
> >> S5,
> >> but I'm totally unsure about reboot.
> >>
> >> What does reboot have to do with S5?
> >>
> > In ACPI spec, there is no explicit words saying _PTS should be
> > executed when reboot. But reboot could be equal to the
> > process S0->S5->S0.
> 
> Not in general.
> 
> In particular, wakeup devices that would be set up for S5 need not be
> set up for that.  Also the mechanism by which transitions to S5 are
> entered is different from the reboot one, at least from the OS
> perspective.
> 
> > Thus _PTS should be executed when reboot.
> 
> No, it doesn't follow.
> 
> > I am thinking this is the same as _TTS. In ACPI spec, there is also
> > no explicit words saying _TTS should be executed when reboot.
> > But kernel executes _TTS when reboot indeed.
> 
> Yes, it does.  Maybe it shouldn't?
> 
> It may not hurt to call _PTS before reboot too, but is it guaranteed
> to work across the board on all systems everywhere?
> 
I try to clarify the key point of this case: does devices should go to 
S5(shutdown) when reboot?

I think the answer is yes. 
And It has no hurt to let devices go to S5 before reboot is invoked, here is 
the reasons:
#1 The new _PTS codes block nothing thus reboot can be guaranteed to be invoked 
eventually.
#2. Devices are mandatory to support S5 state, this means go to S5 could be a 
safe trip.
#3 Reboot would cause devices re-initialization from the scratch.

What's your decision then? ;-)

Regards,
Ocean.

> >> > Signed-off-by: Ocean He 
> >> > Signed-off-by: Nagananda Chumbalkar 
> >> > ---
> >> >  drivers/acpi/sleep.c | 27 +++
> >> >  1 file changed, 27 insertions(+)
> >> >
> >> > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> >> > index 2a8b596..8b290fb 100644
> >> > --- a/drivers/acpi/sleep.c
> >> > +++ b/drivers/acpi/sleep.c
> >> > @@ -55,6 +55,26 @@ static struct notifier_block tts_notifier = {
> >> > .priority   = 0,
> >> >  };
> >> >
> >> > +static int pts_notify_reboot(struct notifier_block *this,
> >> > +   unsigned long code, void *x)
> >> > +{
> >> > +   acpi_status status;
> >> > +
> >> > +   status = acpi_execute_simple_method(NULL, "\\_PTS",
> >> ACPI_STATE_S5);
> >> > +   if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> >> > +   /* It won't break anything. */
> >> > +   printk(KERN_NOTICE "Failure in evaluating _PTS
> object\n");
> >> > +   }
> >> > +
> >> > +   return NOTIFY_DONE;
> >> > +}
> 

[git pull] drm fixes

2016-06-23 Thread Dave Airlie

Hi Linus,

This is the drm fixes tree for 4.7-rc5. It's a bit larger than normal,
due to fixes for production AMD Polaris GPUs. We only merged support for
these in 4.7-rc1 so it would be good if we got all the fixes into final.
The changes don't hit any other hardware.

Other than the amdgpu Polaris changes:

A single fix for atomic modesetting WARN.
Nouveau fix for when fbdev is disabled.
i915 fixes for FBC on Haswell and displayport regression.
Exynos fix for a display panel regression and some other minor changes
Atmel fixes for scaling and OF graph interaction
Allwiinner build, warning and probing fixes
AMD GPU non-polaris fix for num_rbs and some minor fixes.

Also I've just moved house, and my new place is Internet challenged
due to incompetent incumbent ISPs, hopefully sorted out in a couple of
weeks, so I might not be too responsive over the next while. It also
helps Daniel is on holidays for those couple of weeks as well.

Dave.

The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e:

  Linux 4.7-rc4 (2016-06-19 21:30:02 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.7-rc5

for you to fetch changes up to 81e257e964268d050f8e9188becd44d50f241d72:

  drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx 
(2016-06-24 11:10:36 +1000)


Alex Deucher (1):
  drm/amdgpu: fix num_rbs exposed to userspace (v2)

Arnd Bergmann (3):
  drm/sun4i: add COMMON_CLK dependency
  drm: sun4i: print DMA address correctly
  drm: sun4i: fix probe error handling

Boris Brezillon (2):
  drm: atmel-hlcdc: actually disable scaling when no scaling is required
  drm: atmel-hlcdc: Fix OF graph parsing

Chen-Yu Tsai (1):
  drm: sun4i: do cleanup if RGB output init fails

Dan Carpenter (2):
  drm/amdgpu: missing bounds check in amdgpu_set_pp_force_state()
  drm/amdgpu: precedence bug in amdgpu_device_init()

Dave Airlie (6):
  Merge branch 'linux-4.7' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2016-06-22' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge tag 'sunxi-drm-fixes-for-4.7' of 
https://git.kernel.org/.../mripard/linux into drm-fixes
  Merge tag 'drm-atmel-hlcdc-fixes/for-4.7-rc5' of 
github.com:bbrezillon/linux-at91 into drm-fixes
  Merge branch 'exynos-drm-fixes' of 
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
  Merge branch 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Dmitrii Tcvetkov (1):
  drm/nouveau: fix for disabled fbdev emulation

Javier Martinez Canillas (2):
  drm/exynos: fimd: don't set .has_hw_trigger in s3c6400 driver data
  drm/exynos: don't use HW trigger for Exynos5420/5422/5800

Lyude (1):
  drm/i915/fbc: Disable on HSW by default for now

Maarten Lankhorst (1):
  drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx

Maxime Ripard (6):
  drm/sun4i: request exact rates to our parents
  drm/sun4i: rgb: Validate the clock rate
  drm/sun4i: defer only if we didn't find our panel
  drm/sun4i: rgb: panel is an error pointer
  drm/sun4i: remove simplefb at probe
  drm/sun4i: Convert to connector register helpers

Mika Kahola (1):
  drm/i915: Revert DisplayPort fast link training feature

Nicolas Iooss (1):
  drm/amdgpu: initialize amdgpu_cgs_acpi_eval_object result value

Rex Zhu (12):
  drm/amd/powerplay: fix logic error.
  drm/amd/powerplay: fix bug that function parameter was incorect.
  drm/amd/powerplay: need to notify system bios pcie device ready
  drm/amd/powerplay: enable PowerContainment feature for polaris10/11.
  drm/amd/powerplay: initialize variables which were missed.
  drm/amd/powerplay: disable UVD SMU handshake for MCLK.
  drm/amd/powrplay: enable stutter_mode for polaris.
  drm/amd/powerplay: add avfs related define for polaris
  drm/amdgpu/atombios: add avfs struct for Polaris10/11
  drm/amd/powerplay: enable avfs feature for polaris
  drm/amdgpu/gfx8: update golden setting for polaris10
  drm/amd/powerplay: enable clock stretch feature for polaris

Tobias Jakobi (3):
  drm/exynos: g2d: drop the _REG postfix from the stride defines
  drm/exynos: remove superfluous inclusions of fbdev header
  drm/exynos: use logical AND in exynos_drm_plane_check_size()

Yakir Yang (1):
  drm/exynos: dp: Fix NULL pointer dereference due uninitialized connector

 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |  28 ++-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   3 +-
 drivers/gpu/drm/amd/include/atombios.h |  72 +++
 

Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line

2016-06-23 Thread Jisheng Zhang
Dear Konrad,

On Thu, 23 Jun 2016 12:06:10 -0400 Konrad Rzeszutek Wilk wrote:

> On June 23, 2016 10:30:34 AM EDT, Catalin Marinas  
> wrote:
> >On Thu, Jun 23, 2016 at 05:43:40PM +0530, Manjeet Pawar wrote:  
> >> From: Rohit Thapliyal 
> >> 
> >> swiotlb default size of 64M is too big as
> >> default value therefore it is made configurable
> >> through command line through swiotlb_size parameter.
> >> swiotlb allocation shall be done only when the
> >> swiotlb size is given through command line.
> >> Otherwise no swiotlb is allocated.  
> >
> >I already queued this patch:
> >
> >http://lkml.kernel.org/g/1465372426-4077-1-git-send-email-jszh...@marvell.com
> >
> >If you have any objections to it, please reply there.  
> 
> 
> I do (sorry about duplicate email, the other got rejected by mailing lists).
> 
> Why not expand the swiotlb= parameter instead of introducing a new one?

Do you mean pass "swiotlb=" for those platforms(most probably, arm64 with less
than 4GB DDR) which don't need swiotlb? I'm afraid this is not convenient, and
users even don't notice swiotlb parameter. From another side, pass "swiotlb=0"
will make the swiotlb reserve 64MB instead, so how can we achieve zero reserved
memory for swiotlb through "swiotlb=" parameter?

PS: my patch didn't introduce new boot parameter.

I'm not sure I got your meaning, so could you please comment my patch
directly?

Thanks,
Jisheng

> 
> Also, why not use the swiotlb by itself? That does the job as well?
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



[PATCH 0/2] cgroup: pids: extend pids.events

2016-06-23 Thread Aleksa Sarai
While reading the patchset by Kenny Yu, I realised that not having a
field for the "recent" number of failed forks means that userspace would
have trouble accurately deciding whether or not it should increase the
limits.

In addition, by having hits_since, we get to maintain the
on-reset-we-log-failures-again semantics that Tejun said he liked.

Aleksa Sarai (2):
  cgroup: pids: show number of failed forks since limit reset
  docs: cgroup/pids: update documentation to include pids.events

 Documentation/cgroup-v1/pids.txt | 18 ++
 kernel/cgroup_pids.c | 31 ++-
 2 files changed, 40 insertions(+), 9 deletions(-)

-- 
2.8.4



[PATCH 1/2] cgroup: pids: show number of failed forks since limit reset

2016-06-23 Thread Aleksa Sarai
This allows users to dynamically adjust their limits based on how many
failed forks happened since they last reset their limits, otherwise they
would have to track (in a racy way) how many limit failures there were
since the last limit change manually. In addition, we log the first
failure since the limit was reset (which was the original semantics of
the patchset).

In addition, I clarified the licensing for this file.

Signed-off-by: Aleksa Sarai 
---
 kernel/cgroup_pids.c | 31 ++-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/kernel/cgroup_pids.c b/kernel/cgroup_pids.c
index 2bd673783f1a..54ec3e4f3b71 100644
--- a/kernel/cgroup_pids.c
+++ b/kernel/cgroup_pids.c
@@ -26,9 +26,10 @@
  *
  * Copyright (C) 2015 Aleksa Sarai 
  *
- * This file is subject to the terms and conditions of version 2 of the GNU
- * General Public License.  See the file COPYING in the main directory of the
- * Linux distribution for more details.
+ * 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 
@@ -53,8 +54,11 @@ struct pids_cgroup {
/* Handle for "pids.events" */
struct cgroup_file  events_file;
 
-   /* Number of times fork failed because limit was hit. */
-   atomic64_t  events_limit;
+   /* Total number of times fork failed because limit was hit. */
+   atomic64_t  hits_total;
+
+   /* Number of times fork failed since limit was last set. */
+   atomic64_t  hits_since;
 };
 
 static struct pids_cgroup *css_pids(struct cgroup_subsys_state *css)
@@ -78,7 +82,8 @@ pids_css_alloc(struct cgroup_subsys_state *parent)
 
pids->limit = PIDS_MAX;
atomic64_set(>counter, 0);
-   atomic64_set(>events_limit, 0);
+   atomic64_set(>hits_total, 0);
+   atomic64_set(>hits_since, 0);
return >css;
 }
 
@@ -226,8 +231,12 @@ static int pids_can_fork(struct task_struct *task)
pids = css_pids(css);
err = pids_try_charge(pids, 1);
if (err) {
-   /* Only log the first time events_limit is incremented. */
-   if (atomic64_inc_return(>events_limit) == 1) {
+   /*
+* We only log the first time a fork fails after a limit has
+* been set. Resetting the limit will cause us to log again.
+*/
+   atomic64_inc(>hits_total);
+   if (atomic64_inc_return(>hits_since) == 1) {
pr_info("cgroup: fork rejected by pids controller in ");
pr_cont_cgroup_path(task_cgroup(current, pids_cgrp_id));
pr_cont("\n");
@@ -281,6 +290,9 @@ set_limit:
 * critical that any racing fork()s follow the new limit.
 */
pids->limit = limit;
+   /* Reset the since counter and notify userspace. */
+   atomic64_set(>hits_since, 0);
+   cgroup_file_notify(>events_file);
return nbytes;
 }
 
@@ -310,7 +322,8 @@ static int pids_events_show(struct seq_file *sf, void *v)
 {
struct pids_cgroup *pids = css_pids(seq_css(sf));
 
-   seq_printf(sf, "max %lld\n", (s64)atomic64_read(>events_limit));
+   seq_printf(sf, "since\t%lld\n", (s64)atomic64_read(>hits_since));
+   seq_printf(sf, "total\t%lld\n", (s64)atomic64_read(>hits_total));
return 0;
 }
 
-- 
2.8.4



[PATCH 2/2] docs: cgroup/pids: update documentation to include pids.events

2016-06-23 Thread Aleksa Sarai
So that users know what the interface and meaning of the keyed values
are. In addition, mention that the only time that since=0 is when the
limit was changed.

Signed-off-by: Aleksa Sarai 
---
 Documentation/cgroup-v1/pids.txt | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/cgroup-v1/pids.txt b/Documentation/cgroup-v1/pids.txt
index 1a078b5d281a..a9bb7b964c6f 100644
--- a/Documentation/cgroup-v1/pids.txt
+++ b/Documentation/cgroup-v1/pids.txt
@@ -33,6 +33,11 @@ limit in the hierarchy is followed).
 pids.current tracks all child cgroup hierarchies, so parent/pids.current is a
 superset of parent/child/pids.current.
 
+pids.events shows information about the number of failed forks in a particular
+cgroup, both overall (since the cgroup was created) and recently (since the
+last limit reset). Userspace is notified of each time a process failed to fork
+in a cgroup.
+
 Example
 ---
 
@@ -83,3 +88,16 @@ sh: fork: Resource temporary unavailable
 # /bin/echo "We can't even spawn a single process now."
 sh: fork: Resource temporary unavailable
 #
+
+We can also see how many times a particular cgroup has failed to fork. For an
+example cgroup:
+
+# cat /sys/fs/cgroup/pids/some_cgroup/pids.events
+since  1
+total  12
+#
+
+This cgroup has had 12 associated process fail to fork throughout its lifetime,
+and has had 1 process fail to fork since the limit was last set. On setting the
+limit, the since counter becomes 0 and userspace is notified (this is the only
+case where since will be 0 and userspace will get a notification).
-- 
2.8.4



Re: [linux-sunxi] [PATCH 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One

2016-06-23 Thread Julian Calaby
Hi Ondrej,

On Fri, Jun 24, 2016 at 5:21 AM,   wrote:
> From: Ondrej Jirman 
>
> Xulong Orange Pi One uses GPIO based regulator that
> switches between two voltages: 1.1V and 1.3V. The
> regulator is controlled from the PL6 pin.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index 0adf932..ce4ba91 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -88,6 +88,25 @@
> gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
> };
> };
> +
> +   vdd_soc: gpio-regulator {
> +   compatible = "regulator-gpio";
> +
> +   regulator-name = "soc-vdd-supply";
> +   regulator-min-microvolt = <110>;
> +   regulator-max-microvolt = <130>;
> +   regulator-boot-on;
> +   regulator-type = "voltage";
> +
> +   gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
> +   states = <110 0x0
> + 130 0x1>;
> +
> +   startup-delay-us = <10>;
> +   enable-active-high;
> +   };
> +};
> +

Also, isn't adding another closing bracket here a syntax error?

>  };

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


Re: [linux-sunxi] [PATCH 11/14] ARM: sun8i: clk: Add clk-factor rate application method

2016-06-23 Thread Julian Calaby
Hi Ondrej,

On Fri, Jun 24, 2016 at 5:21 AM,   wrote:
> From: Ondrej Jirman 
>
> PLL1 on H3 requires special factors application algorithm,
> when the rate is changed. This algorithm was extracted
> from the arisc code that handles frequency scaling
> in the BSP kernel.
>
> This commit adds optional apply function to
> struct factors_data, that can implement non-trivial
> factors application method, when necessary.
>
> Also struct clk_factors_config is extended with position
> of the PLL lock flag.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi |  2 +-
>  drivers/clk/sunxi/clk-factors.c | 34 +--
>  drivers/clk/sunxi/clk-factors.h | 12 +++
>  drivers/clk/sunxi/clk-sunxi.c   | 72 
> +++--
>  4 files changed, 98 insertions(+), 22 deletions(-)

Shouldn't the .dtsi changes be in a separate patch?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


Re: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

2016-06-23 Thread Yongji Xie

Hi, Alex

On 2016/6/24 0:12, Alex Williamson wrote:


On Mon, 30 May 2016 21:06:37 +0800
Yongji Xie  wrote:


Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs. This will cause some
performance issues when we passthrough a PCI device with
this kind of BARs. Guest will be not able to handle the mmio
accesses to the BARs which leads to mmio emulations in host.

However, not all sub-page BARs will share page with other BARs.
We should allow to mmap the sub-page MMIO BARs which we can
make sure will not share page with other BARs.

This patch adds support for this case. And we try to add a
dummy resource to reserve the remainder of the page which
hot-add device's BAR might be assigned into. But it's not
necessary to handle the case when the BAR is not page aligned.
Because we can't expect the BAR will be assigned into the same
location in a page in guest when we passthrough the BAR. And
it's hard to access this BAR in userspace because we have
no way to get the BAR's location in a page.

Signed-off-by: Yongji Xie 
---
  drivers/vfio/pci/vfio_pci.c |   87 ---
  drivers/vfio/pci/vfio_pci_private.h |8 
  2 files changed, 89 insertions(+), 6 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 188b1ff..3cca2a7 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -110,6 +110,73 @@ static inline bool vfio_pci_is_vga(struct pci_dev *pdev)
return (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
  }
  
+static void vfio_pci_probe_mmaps(struct vfio_pci_device *vdev)

+{
+   struct resource *res;
+   int bar;
+   struct vfio_pci_dummy_resource *dummy_res;
+
+   INIT_LIST_HEAD(>dummy_resources_list);
+
+   for (bar = PCI_STD_RESOURCES; bar <= PCI_STD_RESOURCE_END; bar++) {
+   res = vdev->pdev->resource + bar;
+
+   if (!IS_ENABLED(CONFIG_VFIO_PCI_MMAP))
+   goto no_mmap;
+
+   if (!(res->flags & IORESOURCE_MEM))
+   goto no_mmap;
+
+   /*
+* The PCI core shouldn't set up a resource with a
+* type but zero size. But there may be bugs that
+* cause us to do that.
+*/
+   if (!resource_size(res))
+   goto no_mmap;
+
+   if (resource_size(res) >= PAGE_SIZE) {
+   vdev->bar_mmap_supported[bar] = true;
+   continue;
+   }
+
+   if (!(res->start & ~PAGE_MASK)) {
+   /*
+* Add a dummy resource to reserve the remainder
+* of the exclusive page in case that hot-add
+* device's bar is assigned into it.
+*/
+   dummy_res = kzalloc(sizeof(*dummy_res), GFP_KERNEL);
+   if (dummy_res == NULL)
+   goto no_mmap;
+
+   dummy_res->resource.start = res->end + 1;
+   dummy_res->resource.end = res->start + PAGE_SIZE - 1;
+   dummy_res->resource.flags = res->flags;
+   if (request_resource(res->parent,
+   _res->resource)) {
+   kfree(dummy_res);
+   goto no_mmap;
+   }

Isn't it true that request_resource() only tells us that at a given
point in time, no other drivers have reserved that resource?  It seems
like it does not guarantee that the resource isn't routed to another
device or that another driver won't at some point attempt to request
that same resource.  So for example if a user constructs their initrd
to bind vfio-pci to devices before other modules load, this
request_resource() may succeed, at the expense of drivers loaded later
now failing.  The behavior will depend on driver load order and we're
not actually insuring that the overflow resource is unused, just that
we got it first.  Can we do better?  Am I missing something that
prevents this?  Thanks,

Alex


Couldn't PCI resources allocator prevent this, which will find a
empty slot in the resource tree firstly, then try to request that
resource in allocate_resource() when a PCI device is probed.
And I'd like to know why a PCI device driver would attempt to
call request_resource()? Should this be done in PCI enumeration?

Thanks,
Yongji


+   dummy_res->index = bar;
+   list_add(_res->res_next,
+   >dummy_resources_list);
+   vdev->bar_mmap_supported[bar] = true;
+   continue;
+   }
+   /*
+* Here we don't handle 

Re: [linux-sunxi] [PATCH 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One

2016-06-23 Thread Julian Calaby
Hi Ondrej,

On Fri, Jun 24, 2016 at 5:21 AM,   wrote:
> From: Ondrej Jirman 
>
> Xulong Orange Pi One uses GPIO based regulator that
> switches between two voltages: 1.1V and 1.3V. The
> regulator is controlled from the PL6 pin.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index 0adf932..ce4ba91 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -88,6 +88,25 @@
> gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
> };
> };
> +
> +   vdd_soc: gpio-regulator {
> +   compatible = "regulator-gpio";
> +
> +   regulator-name = "soc-vdd-supply";
> +   regulator-min-microvolt = <110>;
> +   regulator-max-microvolt = <130>;
> +   regulator-boot-on;
> +   regulator-type = "voltage";
> +
> +   gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
> +   states = <110 0x0
> + 130 0x1>;
> +
> +   startup-delay-us = <10>;
> +   enable-active-high;

Don't you need to reference the new pinctl node in this one?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


Re: [PATCH 4.6 38/81] gpio: bail out silently on NULL descriptors

2016-06-23 Thread Greg Kroah-Hartman
On Thu, Jun 23, 2016 at 09:21:02AM +0200, Linus Walleij wrote:
> On Thu, Jun 23, 2016 at 12:46 AM, Greg Kroah-Hartman
>  wrote:
> 
> > 4.6-stable review patch.  If anyone has any objections, please let me know.
> 
> This should ideally be paired with
> commit 79bb71bd1d93197ce227fa167b450b633f30a52b
> "gpio: make sure gpiod_to_irq() returns negative on NULL desc"
> which went upstream yesterday.
> 
> Lest Hans de Goede will be unhappy.

Thanks, I've queued that up now.

greg k-h


Re: [v3 PATCH 3/5] phy: Add USB Type-C PHY driver for rk3399

2016-06-23 Thread Chris Zhong

Hi Guenter

On 06/24/2016 10:10 AM, Guenter Roeck wrote:

Hi Chris,

On Thu, Jun 23, 2016 at 5:34 PM, Chris Zhong  wrote:

Hi Guenter


On 06/24/2016 05:47 AM, Guenter Roeck wrote:

Hi Chris,

On Thu, Jun 23, 2016 at 5:51 AM, Chris Zhong  wrote:

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications. The
PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and
HBR2 data rates.

Signed-off-by: Chris Zhong 
Signed-off-by: Kever Yang 


[ ... ]


+
+static void tcphy_get_state(struct rockchip_typec_phy *tcphy,
+   struct extcon_dev *edev)
+{
+   int mode;
+   bool plugged, flip, pin_assign, dfp, ufp, dp;
+
+   ufp = extcon_get_cable_state_(edev, EXTCON_USB);
+   dfp = extcon_get_cable_state_(edev, EXTCON_USB_HOST);
+   dp = extcon_get_cable_state_(edev, EXTCON_DISP_DP);
+   flip = extcon_get_cable_state_(edev, EXTCON_TYPEC_POLARITY);
+   pin_assign = extcon_get_cable_state_(edev,
EXTCON_TYPEC_PIN_ASSIGN);
+
+   plugged = ufp | dfp | dp;
+   tcphy->flip = flip;
+
+   if (plugged) {
+   if (ufp) {
+   mode = MODE_UFP_USB;
+   } else if (dfp && !dp) {
+   mode = MODE_DFP_USB;
+   } else if (dfp && dp) {
+   mode = MODE_DFP_USB | MODE_DFP_DP;
+   tcphy->pin_assign = pin_assign ? PIN_MAP_D :
PIN_MAP_B;
+   } else {
+   mode = MODE_DFP_DP;
+   tcphy->pin_assign = pin_assign ? PIN_MAP_C :
PIN_MAP_A;

I am having trouble extracting pin_assign from our code. What
determines if map A or C should be selected ?

Thanks,
Guenter

Oh, forgot rename the macro:

PIN_MAP_ should be PIN_ASSIGN_


  IF EXTCON_TYPEC_PIN_ASSIGN is attached, Type-C get
  Pin_Assignment_C(for DP only mode) or Pin_Assignment_D(for DP alt mode),
   if detached, it get the default Assignment: A(for DP only mode) or B(for
DP alt mode),.


So we are really talking about DP only vs. DP Alt mode ? If so, do we
even need PIN_ASSIGN ? Why not just use EXTCON_DISP_DP_ALT directly ?

Also, I'll have to get a better understanding what "DP only mode" and
"DP Alt mode" actually means. DisplayPort is already a Type-C
alternate mode, so the terminology is a bit confusing. Do you happen
to have a description somewhere, by any chance ?

Thanks,
Guenter

The Pin Assignments is come from:
VESA DisplayPort Alt Mode on USB Type-C Standard

There are 2 mode for DP: DP only mode, and DP+USB3 mode(EXTCON_DISP_DP_ALT )
At DP only mode, DP has 4 lanes of Type-C;
At DP+USB3 mode, DP has 2 lanes, and USB3 has the other 2 lanes.

For DP only mode, there are 3 kind of pin assignments: A, C, E.
For DP + USB3 mode, there are 3 kind of pin assignments: B, D, F.

Pin Assignments C and D use the same assignments as Pin Assignments E and F.
Thence, we just need to distinguish A and C for DP only mode.
and distinguish B and D for DP + USB3 mode.
That why the phy need a PIN_ASSIGN cable.


The name of "DP Alt mode", it is DP+USB3 mode, actually.
I think if the name makes anyone confused, it can be changed to DP_USB3 mode:
The cable list could be:
EXTCON_DISP_DP
EXTCON_DISP_DP_USB3





I am going to add a comment for describe which PIN_ASSIGN_ should be
selected
in next version, if no one disagrees the usage of cable














[PATCH 3/3] ASoC: hdmi-codec: enable multi probe for same device

2016-06-23 Thread Kuninori Morimoto

From: Kuninori Morimoto 

hdmi-codec driver is common HDMI sound driver,
but it doesn't care about multi sound ports.
For example, hdmi-codec driver is supporting 1 I2S and 1 SPDIF ports,
so, we can't use this driver if HDMI has 2 or more I2S ports.

And we would like to use multi detection.
For example, DesignWare HDMI driver is providing dw_hdmi_bind() to
DRM/KMS driver, and it will setups HDMI video/sound.
Note is that it will be called under for_each loop of ports.

int dw_hdmi_bind(xxx)
{
/* register hdmi-codec driver here */
}

static int xxx_probe(struct platform_device *pdev)
{
for_each_xxx(xx) {
...
dw_hdmi_bind(xxx);
...
}
}

This case, dw_hdmi_bind() would like to use hdmi-codec,
and it will be called multiple times for each ports.

Here, ASoC's CPU/Codec/Card bind will checks each "of_node" on DT,
and hdmi-codec driver is assuming its parent device for it.
But it doesn't care about case.
Thus, ASoC never detect correct sound card in this case.

To solve this issue, this patch checks each parent device,
and names "hdmi-hifi.x" in order to each ports.
And uses struct snd_soc_component_driver :: of_xlate_dai_name
for snd_soc_get_dai_name().

Signed-off-by: Kuninori Morimoto 
---
 sound/soc/codecs/hdmi-codec.c | 66 +--
 1 file changed, 63 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index f27d115..fe155bc 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -24,6 +24,15 @@
 
 #include  /* This is only to get MAX_ELD_BYTES */
 
+struct hdmi_device {
+   struct device *dev;
+   struct list_head list;
+   int cnt;
+};
+#define pos_to_hdmi_device(pos)container_of((pos), struct hdmi_device, 
list)
+LIST_HEAD(hdmi_device_list);
+
+#define DAI_NAME_SIZE 16
 struct hdmi_codec_priv {
struct hdmi_codec_pdata hcd;
struct snd_soc_dai_driver *daidrv;
@@ -320,7 +329,6 @@ static const struct snd_soc_dai_ops hdmi_dai_ops = {
 SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE)
 
 static struct snd_soc_dai_driver hdmi_i2s_dai = {
-   .name = "i2s-hifi",
.id = DAI_ID_I2S,
.playback = {
.stream_name = "Playback",
@@ -334,7 +342,6 @@ static struct snd_soc_dai_driver hdmi_i2s_dai = {
 };
 
 static const struct snd_soc_dai_driver hdmi_spdif_dai = {
-   .name = "spdif-hifi",
.id = DAI_ID_SPDIF,
.playback = {
.stream_name = "Playback",
@@ -346,6 +353,27 @@ static const struct snd_soc_dai_driver hdmi_spdif_dai = {
.ops = _dai_ops,
 };
 
+static char hdmi_dai_name[][DAI_NAME_SIZE] = {
+   "hdmi-hifi.0",
+   "hdmi-hifi.1",
+   "hdmi-hifi.2",
+   "hdmi-hifi.3",
+};
+
+static int hdmi_of_xlate_dai_name(struct snd_soc_component *component,
+ struct of_phandle_args *args,
+ const char **dai_name)
+{
+   int id = args->args[0];
+
+   if (id < ARRAY_SIZE(hdmi_dai_name)) {
+   *dai_name = hdmi_dai_name[id];
+   return 0;
+   }
+
+   return -EAGAIN;
+}
+
 static struct snd_soc_codec_driver hdmi_codec = {
.controls = hdmi_controls,
.num_controls = ARRAY_SIZE(hdmi_controls),
@@ -353,6 +381,9 @@ static struct snd_soc_codec_driver hdmi_codec = {
.num_dapm_widgets = ARRAY_SIZE(hdmi_widgets),
.dapm_routes = hdmi_routes,
.num_dapm_routes = ARRAY_SIZE(hdmi_routes),
+   .component_driver = {
+   .of_xlate_dai_name  = hdmi_of_xlate_dai_name,
+   },
 };
 
 static int hdmi_codec_probe(struct platform_device *pdev)
@@ -360,6 +391,8 @@ static int hdmi_codec_probe(struct platform_device *pdev)
struct hdmi_codec_pdata *hcd = pdev->dev.platform_data;
struct device *dev = >dev;
struct hdmi_codec_priv *hcp;
+   struct hdmi_device *hd;
+   struct list_head *pos;
int dai_count, i = 0;
int ret;
 
@@ -381,6 +414,30 @@ static int hdmi_codec_probe(struct platform_device *pdev)
if (!hcp)
return -ENOMEM;
 
+   hd = NULL;
+   list_for_each(pos, _device_list) {
+   struct hdmi_device *tmp = pos_to_hdmi_device(pos);
+   if (tmp->dev == dev->parent) {
+   hd = tmp;
+   break;
+   }
+   }
+
+   if (!hd) {
+   hd = devm_kzalloc(dev, sizeof(*hd), GFP_KERNEL);
+   if (!hd)
+   return -ENOMEM;
+
+   hd->dev = dev->parent;
+
+   list_add_tail(>list, _device_list);
+   }
+
+   if (hd->cnt >= ARRAY_SIZE(hdmi_dai_name)) {
+   dev_err(dev, "too many hdmi codec are deteced\n");
+   return -EINVAL;
+   }
+
hcp->hcd = 

[PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support

2016-06-23 Thread Kuninori Morimoto

From: Kuninori Morimoto 

Current dw-hdmi is supporting sound via AHB bus, but it has
I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
This HDMI I2S is supported by using ALSA SoC common HDMI encoder
driver.

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/bridge/Kconfig |   8 ++
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/dw-hdmi-audio.h |   7 ++
 drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c | 123 +
 drivers/gpu/drm/bridge/dw-hdmi.c   |  22 +-
 drivers/gpu/drm/bridge/dw-hdmi.h   |  21 +
 6 files changed, 180 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8f7423f..8e2a22d 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -32,6 +32,14 @@ config DRM_DW_HDMI_AHB_AUDIO
  Designware HDMI block.  This is used in conjunction with
  the i.MX6 HDMI driver.
 
+config DRM_DW_HDMI_I2S_AUDIO
+   tristate "Synopsis Designware I2S Audio interface"
+   depends on DRM_DW_HDMI
+   select SND_SOC_HDMI_CODEC
+   help
+ Support the I2S Audio interface which is part of the Synopsis
+ Designware HDMI block.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 96b13b3..1af92ad 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-audio.h 
b/drivers/gpu/drm/bridge/dw-hdmi-audio.h
index 91f631b..fd1f745 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi-audio.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi-audio.h
@@ -11,4 +11,11 @@ struct dw_hdmi_audio_data {
u8 *eld;
 };
 
+struct dw_hdmi_i2s_audio_data {
+   struct dw_hdmi *hdmi;
+
+   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
+   u8 (*read)(struct dw_hdmi *hdmi, int offset);
+};
+
 #endif
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
new file mode 100644
index 000..df1519c
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
@@ -0,0 +1,123 @@
+/*
+ * dw-hdmi-i2s-audio.c
+ *
+ * Copyright (c) 2016 Kuninori Morimoto 
+ *
+ * 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 "dw-hdmi.h"
+#include "dw-hdmi-audio.h"
+
+#define DRIVER_NAME "dw-hdmi-i2s-audio"
+
+static inline void hdmi_write(struct dw_hdmi_i2s_audio_data *audio, u8 val, 
int offset)
+{
+   struct dw_hdmi *hdmi = audio->hdmi;
+
+   audio->write(hdmi, val, offset);
+}
+
+static inline u8 hdmi_read(struct dw_hdmi_i2s_audio_data *audio, int offset)
+{
+   struct dw_hdmi *hdmi = audio->hdmi;
+
+   return audio->read(hdmi, offset);
+}
+
+static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
+struct hdmi_codec_daifmt *fmt,
+struct hdmi_codec_params *hparms)
+{
+   struct dw_hdmi_i2s_audio_data *audio = data;
+   struct dw_hdmi *hdmi = audio->hdmi;
+   u8 conf0 = 0;
+   u8 conf1 = 0;
+   u8 inputclkfs = 0;
+
+   /* it cares I2S only */
+   if ((fmt->fmt != HDMI_I2S) ||
+   (fmt->bit_clk_master | fmt->frame_clk_master)) {
+   dev_err(dev, "unsupported format/settings\n");
+   return -EINVAL;
+   }
+
+   inputclkfs  = HDMI_AUD_INPUTCLKFS_64FS;
+   conf0   = HDMI_AUD_CONF0_I2S_ALL_ENABLE;
+
+   switch(hparms->sample_width) {
+   case 16:
+   conf1 = HDMI_AUD_CONF1_WIDTH_16;
+   break;
+   case 24:
+   case 32:
+   conf1 = HDMI_AUD_CONF1_WIDTH_24;
+   break;
+   }
+
+   dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
+
+   hdmi_write(audio, inputclkfs, HDMI_AUD_INPUTCLKFS);
+   hdmi_write(audio, conf0, HDMI_AUD_CONF0);
+   hdmi_write(audio, conf1, HDMI_AUD_CONF1);
+
+   dw_hdmi_audio_enable(hdmi);
+
+   return 0;
+}
+
+static void dw_hdmi_i2s_audio_shutdown(struct device *dev, void *data)
+{
+   struct dw_hdmi_i2s_audio_data *audio = data;
+   struct dw_hdmi *hdmi = 

[PATCH 2/3] ASoC: hdmi-codec: callback function will be called with private data

2016-06-23 Thread Kuninori Morimoto
From: Kuninori Morimoto 

Current hdmi-codec driver is assuming that it will be registered
from HDMI driver. Because of this assumption, each callback function
has struct device pointer which is parent device (= HDMI).
Then, it can use dev_get_drvdata() to get private data.

OTOH, on some SoC/HDMI case, SoC has VIDEO/SOUND and HDMI IPs.
This case, it needs SoC VIDEO, SoC SOUND and HDMI video, HDMI codec
driver. In DesignWare HDMI IP case, SoC VIDEO (= DRM/KMS) driver tries
to bind DesignWare HDMI video driver, and HDMI codec driver
(= hdmi-codec). This case, above "parent device" of HDMI codec driver
is DRM/KMS driver and its "device" already has private data.

And, from DT and ASoC CPU/Codec/Card binding point of view, HDMI codec
(= hdmi-codec) needs to have "parent device" (= DRM/KMS), otherwise,
it never detect sound card.

Because of these reasons, some driver can't use dev_get_drvdata() to
get private data on hdmi-codec driver. This patch add new void pointer
on hdmi_codec_pdata for private data, and callback function will be
called with it.

Signed-off-by: Kuninori Morimoto 
---
 include/sound/hdmi-codec.h| 13 -
 sound/soc/codecs/hdmi-codec.c | 15 ---
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index fc3a481..530c57b 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -53,18 +53,19 @@ struct hdmi_codec_params {
int channels;
 };
 
+struct hdmi_codec_pdata;
 struct hdmi_codec_ops {
/*
 * Called when ASoC starts an audio stream setup.
 * Optional
 */
-   int (*audio_startup)(struct device *dev);
+   int (*audio_startup)(struct device *dev, void *data);
 
/*
 * Configures HDMI-encoder for audio stream.
 * Mandatory
 */
-   int (*hw_params)(struct device *dev,
+   int (*hw_params)(struct device *dev, void *data,
 struct hdmi_codec_daifmt *fmt,
 struct hdmi_codec_params *hparms);
 
@@ -72,19 +73,20 @@ struct hdmi_codec_ops {
 * Shuts down the audio stream.
 * Mandatory
 */
-   void (*audio_shutdown)(struct device *dev);
+   void (*audio_shutdown)(struct device *dev, void *data);
 
/*
 * Mute/unmute HDMI audio stream.
 * Optional
 */
-   int (*digital_mute)(struct device *dev, bool enable);
+   int (*digital_mute)(struct device *dev, void *data, bool enable);
 
/*
 * Provides EDID-Like-Data from connected HDMI device.
 * Optional
 */
-   int (*get_eld)(struct device *dev, uint8_t *buf, size_t len);
+   int (*get_eld)(struct device *dev, void *data,
+  uint8_t *buf, size_t len);
 };
 
 /* HDMI codec initalization data */
@@ -93,6 +95,7 @@ struct hdmi_codec_pdata {
uint i2s:1;
uint spdif:1;
int max_i2s_channels;
+   void *data;
 };
 
 #define HDMI_CODEC_DRV_NAME "hdmi-audio-codec"
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 8e36e88..f27d115 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -112,7 +112,7 @@ static int hdmi_codec_startup(struct snd_pcm_substream 
*substream,
return ret;
 
if (hcp->hcd.ops->audio_startup) {
-   ret = hcp->hcd.ops->audio_startup(dai->dev->parent);
+   ret = hcp->hcd.ops->audio_startup(dai->dev->parent, 
hcp->hcd.data);
if (ret) {
mutex_lock(>current_stream_lock);
hcp->current_stream = NULL;
@@ -122,8 +122,8 @@ static int hdmi_codec_startup(struct snd_pcm_substream 
*substream,
}
 
if (hcp->hcd.ops->get_eld) {
-   ret = hcp->hcd.ops->get_eld(dai->dev->parent, hcp->eld,
-   sizeof(hcp->eld));
+   ret = hcp->hcd.ops->get_eld(dai->dev->parent, hcp->hcd.data,
+   hcp->eld, sizeof(hcp->eld));
 
if (!ret) {
ret = snd_pcm_hw_constraint_eld(substream->runtime,
@@ -144,7 +144,7 @@ static void hdmi_codec_shutdown(struct snd_pcm_substream 
*substream,
 
WARN_ON(hcp->current_stream != substream);
 
-   hcp->hcd.ops->audio_shutdown(dai->dev->parent);
+   hcp->hcd.ops->audio_shutdown(dai->dev->parent, hcp->hcd.data);
 
mutex_lock(>current_stream_lock);
hcp->current_stream = NULL;
@@ -195,8 +195,8 @@ static int hdmi_codec_hw_params(struct snd_pcm_substream 
*substream,
hp.sample_rate = params_rate(params);
hp.channels = params_channels(params);
 
-   return hcp->hcd.ops->hw_params(dai->dev->parent, >daifmt[dai->id],
-  );
+   return hcp->hcd.ops->hw_params(dai->dev->parent, 

Re: [PATCH 3.14 21/29] netfilter: x_tables: validate targets of jumps

2016-06-23 Thread Greg Kroah-Hartman
On Thu, Jun 23, 2016 at 11:13:47AM +0200, Florian Westphal wrote:
> Florian Westphal  wrote:
> > Greg Kroah-Hartman  wrote:
> > > 3.14-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > 
> > I have -- this doesn't work in 3.14 as t->entries (the ruleset blob)
> > is still kept percpu.
> > 
> > > +static bool find_jump_target(const struct xt_table_info *t,
> > > +  const struct arpt_entry *target)
> > > +{
> > > + struct arpt_entry *iter;
> > > +
> > > + xt_entry_foreach(iter, t->entries, t->size) {
> > 
> > 
> > .. so this causes in kernel soft lockup when I try to insert a rule.
> > 
> > I will go over the 3.14 stable queue and see if I can amend this to work
> > with 3.14.
> 
> This amended patch works for me (iptables-test.py passes except those
> tests that I expected to fail due to some missing features in 3.14).
> 
> I also briefly tried 32bit iptables/ip6tables and that seems happy
> as well.  The reproduces for the two bugs fail with -EINVAL.
> 
> ebtables doesn't work (even ebtables -A INPUT -j ACCEPT fails), but
> that should be solved by picking up
> d26e2c9ffa385dd1b646f43c1397ba12af9e, "Revert "netfilter: ensure number
> of counters is >0 in do_replace()" [ its a PARTIAL revert, so don't drop
> the original patch ... ]
> 
> Subject: netfilter: x_tables: validate targets of jumps
> 
> commit 36472341017529e2b12573093cc0f68719300997 upstream.
> 
> When we see a jump also check that the offset gets us to beginning of
> a rule (an ipt_entry).
> 
> The extra overhead is negible, even with absurd cases.
> 
> 300k custom rules, 300k jumps to 'next' user chain:
> [ plus one jump from INPUT to first userchain ]:
> 
> Before:
> real0m24.874s
> user0m7.532s
> sys 0m16.076s
> 
> After:
> real0m27.464s
> user0m7.436s
> sys 0m18.840s
> 
> Signed-off-by: Florian Westphal 
> Signed-off-by: Pablo Neira Ayuso 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  Need to pass the start of the ruleset as extra argument as
>  t->entries won't work in 3.14 (its percpu and not even set
>  up for all processors at this point).

Thank you for the update, now applied.

greg k-h


Re: [PATCH 04/14] dt-bindings: document sun8i_ths

2016-06-23 Thread Chen-Yu Tsai
On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> From: Ondrej Jirman 
>
> This patch adds the binding documentation for the sun8i_ths driver
>
> Signed-off-by: Ondřej Jirman 
> ---
>  .../devicetree/bindings/thermal/sun8i-ths.txt  | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-ths.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/sun8i-ths.txt 
> b/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
> new file mode 100644
> index 000..826cd57
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
> @@ -0,0 +1,31 @@
> +* sun8i THS

An explanation of the acronym would be nice, both in the docs,
and in the commit message.

> +
> +Required properties:
> +- compatible : "allwinner,sun8i-h3-ths"
> +- reg : Address range of the thermal registers and location of the 
> calibration

*sensor*

Also you only specify one address range in the example. The "location
of the calibration value" is handled by the nvram-* properties. Please
remove the description.

> +value
> +- resets : Must contain an entry for each entry in reset-names.

This, and clocks below, should probably read "must contain phandles
to reset/clock controls matching the entries of the names".

Regards
ChenYu

> +   see ../reset/reset.txt for details
> +- reset-names : Must include the name "ahb"
> +- clocks : Must contain an entry for each entry in clock-names.
> +- clock-names : Must contain "ahb" for the bus gate and "ths" for the THS
> +  clock
> +
> +Optional properties:
> +- nvmem-cells : Must contain an entry for each entry in nvmem-cell-names
> +- nvmem-cell-names : Must contain "calibration" for the cell containing the
> +  temperature calibration cell, if available
> +
> +Example:
> +ths: ths@01c25000 {
> +   #thermal-sensor-cells = <0>;
> +   compatible = "allwinner,sun8i-h3-ths";
> +   reg = <0x01c25000 0x400>;
> +   interrupts = ;
> +   resets = <_rst 136>;
> +   reset-names = "ahb";
> +   clocks = <_gates 72>, <_clk>;
> +   clock-names = "ahb", "ths";
> +   nvmem-cells = <_calibration>;
> +   nvmem-cell-names = "calibration";
> +};
> --
> 2.9.0
>


[PATCH 0/3] DesignWare HDMI I2S suport

2016-06-23 Thread Kuninori Morimoto

Hi Mark, Thierry, Russell

These are DesignWare HDMI I2S support patches.
It will use ALSA SoC hdmi-codec driver, but we can't use it as-is.
So, 2), 3) patches modify hdmi-codec style.

Kuninori Morimoto (3):
  1) drm: bridge: add DesignWare HDMI I2S audio support
  2) ASoC: hdmi-codec: callback function will be called with private data
  3) ASoC: hdmi-codec: enable multi probe for same device

 drivers/gpu/drm/bridge/Kconfig |   8 ++
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/dw-hdmi-audio.h |   7 ++
 drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c | 123 +
 drivers/gpu/drm/bridge/dw-hdmi.c   |  22 +-
 drivers/gpu/drm/bridge/dw-hdmi.h   |  21 +
 include/sound/hdmi-codec.h |  13 +--
 sound/soc/codecs/hdmi-codec.c  |  81 ---
 8 files changed, 259 insertions(+), 17 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c

-- 
1.9.1



Re: [PATCH 01/14] ARM: dts: sun8i: Add SID node

2016-06-23 Thread Chen-Yu Tsai
On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> From: Josef Gajdusek 
>
> Add a node describing the Security ID memory to the Allwinner H3 .dtsi file.
>
> Signed-off-by: Josef Gajdusek 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 4a4926b..172576d 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -389,6 +389,13 @@
> #size-cells = <0>;
> };
>
> +   sid: eeprom@01c14000 {
> +   compatible = "allwinner,sun4i-a10-sid";

This has been discussed before. The hardware is not compatible.
The write control registers are at different offsets.

ChenYu

> +   reg = <0x01c14000 0x400>;
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   };
> +
> usbphy: phy@01c19400 {
> compatible = "allwinner,sun8i-h3-usb-phy";
> reg = <0x01c19400 0x2c>,
> --
> 2.9.0
>


Re: [PATCH] usb: serial: update CH34x driver in drivers/usb/serial

2016-06-23 Thread Greg KH
On Thu, Jun 23, 2016 at 06:47:54PM -0700, t...@winchiphead.com wrote:
> The old driver for usb-serial chips ch34x which submitted by kernel volunteer
> Frank A Kingswood  is too old to use, and 
> the
> driver has bugs when receiving chracters, thus after communicating with the 
> author 
> we decide to revoke the old driver ch341.c and submit the new one ch34x.c.
> 
> Add the relevant details to Documentation/usb/usb-serial.txt.
> Change the relevant files Kconfig and Makefile in drivers/usb/serial.
> 
> Signed-off-by: WCH Tech Group 
> 
> ---
>  Documentation/usb/usb-serial.txt |  27 +-
>  drivers/usb/serial/Kconfig   |   8 +-
>  drivers/usb/serial/Makefile  |   2 +-
>  drivers/usb/serial/ch341.c   | 580 ---
>  drivers/usb/serial/ch34x.c   | 985 
> +++
>  5 files changed, 1008 insertions(+), 594 deletions(-)
>  delete mode 100644 drivers/usb/serial/ch341.c
>  create mode 100644 drivers/usb/serial/ch34x.c
> 
> diff --git a/Documentation/usb/usb-serial.txt 
> b/Documentation/usb/usb-serial.txt
> index 349f310..c21437b 100644
> --- a/Documentation/usb/usb-serial.txt
> +++ b/Documentation/usb/usb-serial.txt
> @@ -1,4 +1,4 @@
> -INTRODUCTION
> +INTRODUCTION

You also don't need to change this line :)



Re: [PATCH] usb: serial: update CH34x driver in drivers/usb/serial

2016-06-23 Thread Greg KH
On Thu, Jun 23, 2016 at 06:47:54PM -0700, t...@winchiphead.com wrote:
> The old driver for usb-serial chips ch34x which submitted by kernel volunteer
> Frank A Kingswood  is too old to use, and 
> the
> driver has bugs when receiving chracters, thus after communicating with the 
> author 
> we decide to revoke the old driver ch341.c and submit the new one ch34x.c.

"revoke"?  Why not just fix the bugs in the existing one instead?  That
would be a much smaller patch, and much easier to review.

> Add the relevant details to Documentation/usb/usb-serial.txt.
> Change the relevant files Kconfig and Makefile in drivers/usb/serial.
> 
> Signed-off-by: WCH Tech Group 

This has to be a person, it can not be a company, or any other anonymous
email address, sorry.  Same with your "From:" address.

thanks,

greg k-h


[GIT PULL] PCI fixes for v4.7

2016-06-23 Thread Bjorn Helgaas
Hi Linus,

Here's a small fix for v4.7.  This problem was actually introduced in v4.6
when we unified Kconfig, making PCIe support available everywhere including
sparc, where config reads into unaligned buffers cause warnings.  This fix
is from Dave Miller.

As a reminder, any future PCI fixes for v4.7 will probably come from Alex
Williamson, since I'll be on vacation for most of the rest of this cycle.
I should be back about the time the merge window opens.

Bjorn


The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:

  Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v4.7-fixes-1

for you to fetch changes up to ef0dab4aae14e25efddf1577736f8450132800c5:

  PCI: Fix unaligned accesses in VC code (2016-06-20 13:24:20 -0500)


PCI updates for v4.7:

  Miscellaneous
Fix unaligned accesses in VC code (David Miller)


David Miller (1):
  PCI: Fix unaligned accesses in VC code

 drivers/pci/vc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


[PATCH 5/7] of_graph: add of_graph_get_port_parent()

2016-06-23 Thread Kuninori Morimoto

From: Kuninori Morimoto 

Linux kernel already has of_graph_get_remote_port_parent(),
but, sometimes we want to get own port parent.
This patch adds of_graph_get_port_parent()

Signed-off-by: Kuninori Morimoto 
---
 drivers/of/base.c| 30 ++
 include/linux/of_graph.h |  7 +++
 2 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a39d470..283cfbb 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2341,6 +2341,27 @@ struct device_node *of_graph_get_remote_endpoint(const 
struct device_node *node)
 EXPORT_SYMBOL(of_graph_get_remote_endpoint);
 
 /**
+ * of_graph_get_port_parent() - get port's parent node
+ * @node: pointer to a local endpoint device_node
+ *
+ * Return: device node associated with endpoint node linked
+ *to @node. Use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_port_parent(struct device_node *node)
+{
+   unsigned int depth;
+
+   /* Walk 3 levels up only if there is 'ports' node. */
+   for (depth = 3; depth && node; depth--) {
+   node = of_get_next_parent(node);
+   if (depth == 2 && of_node_cmp(node->name, "ports"))
+   break;
+   }
+   return node;
+}
+EXPORT_SYMBOL(of_graph_get_port_parent);
+
+/**
  * of_graph_get_remote_port_parent() - get remote port's parent node
  * @node: pointer to a local endpoint device_node
  *
@@ -2351,18 +2372,11 @@ struct device_node *of_graph_get_remote_port_parent(
   const struct device_node *node)
 {
struct device_node *np;
-   unsigned int depth;
 
/* Get remote endpoint node. */
np = of_graph_get_remote_endpoint(node);
 
-   /* Walk 3 levels up only if there is 'ports' node. */
-   for (depth = 3; depth && np; depth--) {
-   np = of_get_next_parent(np);
-   if (depth == 2 && of_node_cmp(np->name, "ports"))
-   break;
-   }
-   return np;
+   return of_graph_get_port_parent(np);
 }
 EXPORT_SYMBOL(of_graph_get_remote_port_parent);
 
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 86baae5..d9868c2 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -57,6 +57,7 @@ struct device_node *of_graph_get_endpoint_by_regs(
const struct device_node *parent, int port_reg, int reg);
 struct device_node *of_graph_get_remote_endpoint(
const struct device_node *node);
+struct device_node *of_graph_get_port_parent(struct device_node *node);
 struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -109,6 +110,12 @@ static inline struct device_node 
*of_graph_get_remote_endpoint(
return NULL;
 }
 
+static inline struct device_node *of_graph_get_port_parent(
+   struct device_node *node)
+{
+   return NULL;
+}
+
 static inline struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node)
 {
-- 
1.9.1



linux-next: manual merge of the block tree with the btrfs-kdave tree

2016-06-23 Thread Stephen Rothwell
Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  fs/btrfs/compression.c

between commit:

  edf0e062aa6f ("Btrfs: fix BUG_ON in btrfs_submit_compressed_write")

from the btrfs-kdave tree and commit:

  81a75f6781de ("btrfs: use bio fields for op and flags")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/compression.c
index 7a4d9c81aa2a,cefedabf0a92..
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@@ -401,11 -402,8 +402,11 @@@ int btrfs_submit_compressed_write(struc
BUG_ON(ret); /* -ENOMEM */
}
  
-   ret = btrfs_map_bio(root, WRITE, bio, 0, 1);
+   ret = btrfs_map_bio(root, bio, 0, 1);
 -  BUG_ON(ret); /* -ENOMEM */
 +  if (ret) {
 +  bio->bi_error = ret;
 +  bio_endio(bio);
 +  }
  
bio_put(bio);
  
@@@ -434,11 -433,8 +436,11 @@@
BUG_ON(ret); /* -ENOMEM */
}
  
-   ret = btrfs_map_bio(root, WRITE, bio, 0, 1);
+   ret = btrfs_map_bio(root, bio, 0, 1);
 -  BUG_ON(ret); /* -ENOMEM */
 +  if (ret) {
 +  bio->bi_error = ret;
 +  bio_endio(bio);
 +  }
  
bio_put(bio);
return 0;


[PATCH 4/7] of_graph: add of_graph_get_endpoint_count()

2016-06-23 Thread Kuninori Morimoto

From: Kuninori Morimoto 

OF graph want to count its endpoint number, same as
of_get_child_count(). This patch adds of_graph_get_endpoint_count()
which can check specific type. It will count all endpoint if type was NULL.

Signed-off-by: Kuninori Morimoto 
---
 drivers/of/base.c| 16 
 include/linux/of_graph.h |  8 
 2 files changed, 24 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a0fc63c..a39d470 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2430,3 +2430,19 @@ bool of_graph_endpoint_type_is(struct device_node *ep, 
char *type)
return of_graph_port_type_is(of_get_parent(ep), type);
 }
 EXPORT_SYMBOL(of_graph_endpoint_type_is);
+
+int of_graph_get_endpoint_count(const struct device_node *np, char *type)
+{
+   struct device_node *child;
+   int num = 0;
+
+   for_each_endpoint_of_node(np, child) {
+   if (!type)
+   num++;
+   else
+   num += of_graph_endpoint_type_is(child, type);
+   }
+
+   return num;
+}
+EXPORT_SYMBOL(of_graph_get_endpoint_count);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 1750d5c..86baae5 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -42,12 +42,14 @@ struct of_endpoint {
 
 #define of_graph_port_type_is_sound(n) of_graph_port_type_is(n, 
"sound")
 #define of_graph_endpoint_type_is_sound(n) of_graph_endpoint_type_is(n, 
"sound")
+#define of_graph_get_sound_endpoint_count(n)   of_graph_get_endpoint_count(n, 
"sound")
 
 #ifdef CONFIG_OF
 int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
 bool of_graph_port_type_is(struct device_node *port, char *type);
 bool of_graph_endpoint_type_is(struct device_node *ep, char *type);
+int of_graph_get_endpoint_count(const struct device_node *np, char *type);
 struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
 struct device_node *of_graph_get_next_endpoint(const struct device_node 
*parent,
struct device_node *previous);
@@ -76,6 +78,12 @@ static bool of_graph_endpoint_type_is(struct device_node 
*ep, char *type)
return false;
 }
 
+static inline int of_graph_get_endpoint_count(const struct device_node *np,
+ char *type)
+{
+   return 0;
+}
+
 static inline struct device_node *of_graph_get_port_by_id(
struct device_node *node, u32 id)
 {
-- 
1.9.1



[PATCH 7/7] of_graph: add for_each_of_port() / for_each_of_endpoint_in_port()

2016-06-23 Thread Kuninori Morimoto
From: Kuninori Morimoto 

OF graph is used mainly from V4L2, but ALSA needs to use it. It already
has for_each_endpoint_of_node() which is for-loop for each endpoint.
But, ALSA needs for-loop for each port[s], and for-loop for each
endpoint of inside port[s]. This patch adds for_each_of_port()
and for_each_of_endpoint_in_port() for this purpose.

And it also adds for_each_of_endpoint() which is similar to
for_each_endpoint_of_node(). The difference is it can catch port
handle during for-loop.

Signed-off-by: Kuninori Morimoto 
---
 drivers/of/base.c| 62 
 include/linux/of_graph.h | 28 ++
 2 files changed, 90 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index e220a16..392a7bb 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2249,6 +2249,68 @@ struct device_node *of_graph_get_top_port(struct device 
*dev)
 EXPORT_SYMBOL(of_graph_get_top_port);
 
 /**
+ * of_graph_get_next_port() - get next port node
+ * @parent: pointer to the parent device node
+ * @prev: previous endpoint node, or NULL to get first
+ *
+ * Return: An 'endpoint' node pointer with refcount incremented. Refcount
+ * of the passed @prev node is decremented.
+ */
+struct device_node *of_graph_get_next_port(const struct device_node *parent,
+  struct device_node *prev)
+{
+   struct device_node *port;
+   struct device_node *node;
+
+   if (!parent)
+   return NULL;
+
+   node = of_get_child_by_name(parent, "ports");
+   if (node)
+   parent = node;
+
+   /*
+* Start by locating the port node. If no previous endpoint is specified
+* search for the first port node, otherwise get the previous endpoint
+* parent port node.
+*/
+   if (!prev) {
+   port = of_get_child_by_name(parent, "port");
+   if (!port)
+   pr_err("%s(): no port node found in %s\n",
+  __func__, parent->full_name);
+   } else {
+   do {
+   port = of_get_next_child(parent, prev);
+   if (!port)
+   break;
+   } while (of_node_cmp(port->name, "port"));
+   }
+
+   of_node_put(node);
+
+   return port;
+}
+EXPORT_SYMBOL(of_graph_get_next_port);
+
+/**
+ * of_graph_get_next_endpoint_in_port() - get next endpoint node in port
+ * @parent: pointer to the parent device node
+ * @prev: previous endpoint node, or NULL to get first
+ *
+ * Return: An 'endpoint' node pointer with refcount incremented. Refcount
+ * of the passed @prev node is decremented.
+ */
+struct device_node *of_graph_get_next_endpoint_in_port(const struct 
device_node *port,
+  struct device_node *prev)
+{
+   if (!port)
+   return NULL;
+
+   return of_get_next_child(port, prev);
+}
+
+/**
  * of_graph_get_next_endpoint() - get next endpoint node
  * @parent: pointer to the parent device node
  * @prev: previous endpoint node, or NULL to get first
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index b87a89f..d140ae3 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -29,6 +29,16 @@ struct of_endpoint {
const struct device_node *local_node;
 };
 
+#define for_each_of_port(parent, port) \
+   for (port = of_graph_get_next_port(parent, NULL); port != NULL; \
+port = of_graph_get_next_port(parent, port))
+#define for_each_of_endpoint_in_port(port, ep) \
+   for (ep = of_graph_get_next_endpoint_in_port(port, NULL); ep != NULL; \
+ep = of_graph_get_next_endpoint_in_port(port, ep))
+#define for_each_of_endpoint(parent, port, ep) \
+   for_each_of_port(parent, port) \
+   for_each_of_endpoint_in_port(port, ep)
+
 /**
  * for_each_endpoint_of_node - iterate over every endpoint in a device node
  * @parent: parent device node containing ports and endpoints
@@ -52,6 +62,10 @@ bool of_graph_endpoint_type_is(struct device_node *ep, char 
*type);
 int of_graph_get_endpoint_count(const struct device_node *np, char *type);
 struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
 struct device_node *of_graph_get_top_port(struct device *dev);
+struct device_node *of_graph_get_next_port(const struct device_node *parent,
+   struct device_node *prev);
+struct device_node *of_graph_get_next_endpoint_in_port(const struct 
device_node *port,
+   struct device_node *prev);
 struct device_node *of_graph_get_next_endpoint(const struct device_node 
*parent,
struct device_node *previous);
 struct device_node *of_graph_get_endpoint_by_regs(
@@ -92,6 +106,20 @@ static inline 

[PATCH 6/7] of_graph: add of_graph_get_top_port()

2016-06-23 Thread Kuninori Morimoto

From: Kuninori Morimoto 

driver want to get top level of port[s] node. This patch adds
of_graph_get_top_port() for this purpose

Signed-off-by: Kuninori Morimoto 
---
 drivers/of/base.c| 24 
 include/linux/of_graph.h |  1 +
 2 files changed, 25 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 283cfbb..e220a16 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2225,6 +2225,30 @@ struct device_node *of_graph_get_port_by_id(struct 
device_node *parent, u32 id)
 EXPORT_SYMBOL(of_graph_get_port_by_id);
 
 /**
+ * of_graph_get_top_port() - get the top port node
+ * @dev: pointer to the device
+ *
+ * Return: A 'port' node pointer with refcount incremented. The caller
+ * has to use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_top_port(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct device_node *node;
+
+   node = of_get_child_by_name(np, "ports");
+   if (node)
+   return node;
+
+   node = of_get_child_by_name(np, "port");
+   if (node)
+   return node;
+
+   return NULL;
+}
+EXPORT_SYMBOL(of_graph_get_top_port);
+
+/**
  * of_graph_get_next_endpoint() - get next endpoint node
  * @parent: pointer to the parent device node
  * @prev: previous endpoint node, or NULL to get first
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index d9868c2..b87a89f 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -51,6 +51,7 @@ bool of_graph_port_type_is(struct device_node *port, char 
*type);
 bool of_graph_endpoint_type_is(struct device_node *ep, char *type);
 int of_graph_get_endpoint_count(const struct device_node *np, char *type);
 struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
+struct device_node *of_graph_get_top_port(struct device *dev);
 struct device_node *of_graph_get_next_endpoint(const struct device_node 
*parent,
struct device_node *previous);
 struct device_node *of_graph_get_endpoint_by_regs(
-- 
1.9.1



[PATCH 3/7] of_graph: add of_graph_port/endpoint_type_is()

2016-06-23 Thread Kuninori Morimoto

From: Kuninori Morimoto 

OF graph endpoint is now used for V4L2 video, but ALSA will use
it too. Then for example HDMI case, it needs to indicate endpoint type.
Otherwise, ALSA can't handle sound endpoint correctly.
This patch adds of_graph_port/endpoint_type_is() for it,
and adds of_graph_port/endpoint_type_is_sound macro

Signed-off-by: Kuninori Morimoto 
---
 drivers/of/base.c| 46 ++
 include/linux/of_graph.h | 15 +++
 2 files changed, 61 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 347118e..a0fc63c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2384,3 +2384,49 @@ struct device_node *of_graph_get_remote_port(const 
struct device_node *node)
return of_get_next_parent(np);
 }
 EXPORT_SYMBOL(of_graph_get_remote_port);
+
+static bool of_graph_node_type_is(struct device_node *np, char *type)
+{
+   const char *prop = NULL;
+
+   of_property_read_string(np, "type", );
+
+   if (prop &&
+   strcmp(prop, type) == 0)
+   return true;
+
+   return false;
+}
+
+bool of_graph_port_type_is(struct device_node *port, char *type)
+{
+   struct device_node *ports;
+   bool ret;
+
+   /* try port side */
+   ret = of_graph_node_type_is(port, type);
+   if (ret)
+   return ret;
+
+   /* try ports side */
+   ports = of_get_next_parent(port);
+   if (ports && of_node_cmp(ports->name, "ports") == 0)
+   return of_graph_node_type_is(ports, type);
+
+   return false;
+}
+EXPORT_SYMBOL(of_graph_port_type_is);
+
+bool of_graph_endpoint_type_is(struct device_node *ep, char *type)
+{
+   bool ret;
+
+   /* try endpoint side */
+   ret = of_graph_node_type_is(ep, type);
+   if (ret)
+   return ret;
+
+   /* try port side */
+   return of_graph_port_type_is(of_get_parent(ep), type);
+}
+EXPORT_SYMBOL(of_graph_endpoint_type_is);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index d9d6d9c..1750d5c 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -40,9 +40,14 @@ struct of_endpoint {
for (child = of_graph_get_next_endpoint(parent, NULL); child != NULL; \
 child = of_graph_get_next_endpoint(parent, child))
 
+#define of_graph_port_type_is_sound(n) of_graph_port_type_is(n, 
"sound")
+#define of_graph_endpoint_type_is_sound(n) of_graph_endpoint_type_is(n, 
"sound")
+
 #ifdef CONFIG_OF
 int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
+bool of_graph_port_type_is(struct device_node *port, char *type);
+bool of_graph_endpoint_type_is(struct device_node *ep, char *type);
 struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
 struct device_node *of_graph_get_next_endpoint(const struct device_node 
*parent,
struct device_node *previous);
@@ -61,6 +66,16 @@ static inline int of_graph_parse_endpoint(const struct 
device_node *node,
return -ENOSYS;
 }
 
+static bool of_graph_port_type_is(struct device_node *port, char *type)
+{
+   return false;
+}
+
+static bool of_graph_endpoint_type_is(struct device_node *ep, char *type)
+{
+   return false;
+}
+
 static inline struct device_node *of_graph_get_port_by_id(
struct device_node *node, u32 id)
 {
-- 
1.9.1



[PATCH 2/7] of_graph: add of_graph_get_remote_endpoint()

2016-06-23 Thread Kuninori Morimoto

From: Kuninori Morimoto 

It should use same method to get same result.
To getting remote-endpoint node,
let's use of_graph_get_remote_endpoint()

Signed-off-by: Kuninori Morimoto 
---
 drivers/of/base.c| 18 --
 include/linux/of_graph.h |  8 
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index ebf84e3..347118e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2327,6 +2327,20 @@ struct device_node *of_graph_get_endpoint_by_regs(
 EXPORT_SYMBOL(of_graph_get_endpoint_by_regs);
 
 /**
+ * of_graph_get_remote_endpoint() - get remote endpoint node
+ * @node: pointer to a local endpoint device_node
+ *
+ * Return: Remote endpoint node associated with remote endpoint node linked
+ *to @node. Use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_remote_endpoint(const struct device_node 
*node)
+{
+   /* Get remote endpoint node. */
+   return of_parse_phandle(node, "remote-endpoint", 0);
+}
+EXPORT_SYMBOL(of_graph_get_remote_endpoint);
+
+/**
  * of_graph_get_remote_port_parent() - get remote port's parent node
  * @node: pointer to a local endpoint device_node
  *
@@ -2340,7 +2354,7 @@ struct device_node *of_graph_get_remote_port_parent(
unsigned int depth;
 
/* Get remote endpoint node. */
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
 
/* Walk 3 levels up only if there is 'ports' node. */
for (depth = 3; depth && np; depth--) {
@@ -2364,7 +2378,7 @@ struct device_node *of_graph_get_remote_port(const struct 
device_node *node)
struct device_node *np;
 
/* Get remote endpoint node. */
-   np = of_parse_phandle(node, "remote-endpoint", 0);
+   np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
return of_get_next_parent(np);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index bb3a5a2..d9d6d9c 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -48,6 +48,8 @@ struct device_node *of_graph_get_next_endpoint(const struct 
device_node *parent,
struct device_node *previous);
 struct device_node *of_graph_get_endpoint_by_regs(
const struct device_node *parent, int port_reg, int reg);
+struct device_node *of_graph_get_remote_endpoint(
+   const struct device_node *node);
 struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -78,6 +80,12 @@ static inline struct device_node 
*of_graph_get_endpoint_by_regs(
return NULL;
 }
 
+static inline struct device_node *of_graph_get_remote_endpoint(
+   const struct device_node *node)
+{
+   return NULL;
+}
+
 static inline struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node)
 {
-- 
1.9.1



[PATCH 1/7] Documentation: of: add type property

2016-06-23 Thread Kuninori Morimoto

From: Kuninori Morimoto 

OF graph is used mainly from V4L2, but ALSA needs to use it too.
Then, ALSA needs to know each port/endpoint type, otherwise it
can't detect ALSA port/endpoint correctly.
This patch enables to use type property on OF graph.

Signed-off-by: Kuninori Morimoto 
---
 Documentation/devicetree/bindings/graph.txt | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/graph.txt 
b/Documentation/devicetree/bindings/graph.txt
index fcb1c6a..b5b9040 100644
--- a/Documentation/devicetree/bindings/graph.txt
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -110,6 +110,32 @@ device-2 {
 };
 };
 
+port / endpoint type
+
+
+Each ports / port / endpoint can have its type if needed.
+child node can take over parent node type. below example indicates
+device0 type is "typeA" && "typeB",
+device1 type is "typeA" && "typeB" && "typeC".
+
+device {
+   ports {
+   type = "typeA";
+
+   port@0 {
+   type = "typeB";
+
+   device0: endpoint@0 {
+   };
+
+   device1: endpoint@1 {
+   type = "typeC";
+   };
+   };
+   ...
+   };
+};
+
 
 Required properties
 ---
-- 
1.9.1



Re: [RFC PATCH v2 0/9] scpi: Add SCPI registry to handle legacy protocol

2016-06-23 Thread Frank Wang

Hi Neil & Caesar,

On 2016/6/23 20:45, Neil Armstrong wrote:

On 06/22/2016 04:54 AM, Frank Wang wrote:

Hi Neil,

On 2016/6/21 18:02, Neil Armstrong wrote:

This patchset aims to support the legacy SCPI firmware implementation that was
delivered as early technology preview for the JUNO platform.

Finally a stable, maintained and public implementation for the SCPI protocol
has been upstreamed part of the JUNO support and it is the recommended way
of implementing SCP communication on ARMv8 platforms.

The Amlogic GXBB platform is using this legacy protocol, as the RK3368 & RK3399
platforms. Only the GXBB example is provided here, but it's unclear if other
Amlogic ARMv8 based SoCs uses this legacy procotol.

In order to support the legacy protocol :
   - Move the scpi_get_ops to a thin registry layer
   - Change the arm_scpi.c to use the registry layer
   - Add a separate config option to build the registry layer
   - Add the legacy SCPI driver based on the new implementation
   - For example, add the Amlogic GXBB MHU and SCPI DT cpufreq & sensors nodes

Two comments may be not very associated with this series.

First, do you have any plan to implement the APIs for extended set ID of SCPI? 
If these APIs do not care commands, just focus on a message transmission 
access, something like a library role, and extended command can define in 
consumers driver module, I think it can more help for other consumers like 
Rockchip to send/receive nonstandard command data conveniently. Can it be?

Yes, Amlogic only have a single extended command, but supporting Rockchips 
extended API is necessary.
I'll need to think about a convenient way to extend vendor API in a separate 
driver with a set or read/write functions, but
keeping the compatibility with the official SCPI extension API.


Well, sounds great, how soon can you deliver it?


Second, As far as I know, some legacy mailbox hardware which like Altera, 
Rockchip...  need write command and data register sequentially, then it can 
create a interrupt, however, arm-scpi first use inner scpi_xfer structure to 
package the message, then data is passed to msg_submit (At mailbox.c), further 
into the bottom mailbox driver, but the data type is converted void*, so the 
mailbox driver could not extract the contents of message, if it do cast type, 
it may become non-general from driver view. Hence, is it possible to add a 
message header into scpi_xfer which for the bottom mailbox driver or dope out 
any other methods to solve it?

Well, the message type should be considered "known" between the mailbox client 
and controller, but here Amlogic did copy ARM's MHU so we can simply cast the data into a 
uint32_t and push the
word in the status register, but the interface was not designed to handle a 
"message", only a status.
In your case, you seem to have used the message capability of the mailbox to 
transmit a proper message containing the command word and return length.


Yeah, you are right, Rockchip mailbox need command word and RX size to 
ensure data integrity in current, however RX size may be replaced from 
other item of xfer data. Plus, as last mail I mentioned that a interrupt 
can only be created via writing command register and data register 
(filled RX size at present) sequentially . So from controller view, 
knowing a proper value of data which it should know is required.



Therefore, I must think about implementing a per-vendor transmit layer, because 
a generic way won't work among the different mailbox controllers.

Would it be possible to actually test the next revision of the legacy SCPI 
implementation on your platform ? I'll try to implement it for rockchip with 
what I understood, but I'll need your help for the DT declaration side.


Of course, I will be glad to.

@Caesar, would you like to share any other good comments?


BR.
Frank


Regards,
Neil

Initial RFC discution tread can be found at https://lkml.org/lkml/2016/5/26/111

Neil Armstrong (9):
mailbox: Add Amlogic Meson Message-Handling-Unit
dt-bindings: mailbox: Add Amlogic Meson MHU Bindings
ARM64: dts: meson-gxbb: Add Meson MHU Node
firmware: Add a SCPI registry to handle multiple implementations
firmware: scpi: Switch arm_scpi to use new registry
firmware: Add legacy SCPI protocol driver
dt-bindings: arm: Update arm,scpi bindings with Meson GXBB SCPI
ARM64: dts: meson-gxbb: Add SRAM node
ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes

   Documentation/devicetree/bindings/arm/arm,scpi.txt |   8 +-
   .../devicetree/bindings/mailbox/meson-mhu.txt  |  33 ++
   arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|  53 ++
   drivers/firmware/Kconfig   |  24 +
   drivers/firmware/Makefile  |   2 +
   drivers/firmware/arm_scpi.c|  14 +-
   drivers/firmware/legacy_scpi.c | 644 
+
   drivers/firmware/scpi.c|  

[PATCH 0/7] of_graph: prepare for ALSA graph support

2016-06-23 Thread Kuninori Morimoto

Hi Rob, Mark
Cc Guennadi, Laurent

Now OF graph is mainly used by V4L2 SoC, and ALSA SoC is using
different style for SoC <-> Codec binding.
But, for example, HDMI case, V4L2 <-> ALSA need to collaborate,
and then ALSA SoC needs to adjust to OF graph.

OTOH, V4L2's "OF graph" position is same as ALSA SoC "sound card" position.
And ALSA SoC side want to keep existing supported feature on new
OF graph style. I'm posting this on ALSA SoC ML now.

Now, current of_graph is indicating port/endpoint,
but there is no way to understand that it is for video port ? or sound port ?
or other device port ?
For example, HDMI has video port, and sound port.
Because of this reason, ALSA SoC side can't handle OF graph correctly.
Thus, this patch-set tries to add new "type" on OF graph.

And this patch-set includes small feature which are useful for ALSA SoC
side OF graph support.

Kuninori Morimoto (7):
  Documentation: of: add type property
  of_graph: add of_graph_get_remote_endpoint()
  of_graph: add of_graph_port/endpoint_type_is()
  of_graph: add of_graph_get_endpoint_count()
  of_graph: add of_graph_get_port_parent()
  of_graph: add of_graph_get_top_port()
  of_graph: add for_each_of_port() / for_each_of_endpoint_in_port()

 Documentation/devicetree/bindings/graph.txt |  26 
 drivers/of/base.c   | 196 ++--
 include/linux/of_graph.h|  67 ++
 3 files changed, 279 insertions(+), 10 deletions(-)

-- 
1.9.1



[PATCH v5 2/7] max8903: store pointer to pdata instead of copying it.

2016-06-23 Thread Chris Lapa
From: Chris Lapa 

Stores pointer to pdata because it easily allows pdata to reference
either platform data or in the future device tree data.

Signed-off-by: Chris Lapa 

Reviewed-by: Krzysztof Kozlowski 
---
 drivers/power/max8903_charger.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 17876ca..0a5b0e1 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -29,7 +29,7 @@
 #include 
 
 struct max8903_data {
-   struct max8903_pdata pdata;
+   struct max8903_pdata *pdata;
struct device *dev;
struct power_supply *psy;
struct power_supply_desc psy_desc;
@@ -53,8 +53,8 @@ static int max8903_get_property(struct power_supply *psy,
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
-   if (data->pdata.chg) {
-   if (gpio_get_value(data->pdata.chg) == 0)
+   if (data->pdata->chg) {
+   if (gpio_get_value(data->pdata->chg) == 0)
val->intval = POWER_SUPPLY_STATUS_CHARGING;
else if (data->usb_in || data->ta_in)
val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
@@ -81,7 +81,7 @@ static int max8903_get_property(struct power_supply *psy,
 static irqreturn_t max8903_dcin(int irq, void *_data)
 {
struct max8903_data *data = _data;
-   struct max8903_pdata *pdata = >pdata;
+   struct max8903_pdata *pdata = data->pdata;
bool ta_in;
enum power_supply_type old_type;
 
@@ -122,7 +122,7 @@ static irqreturn_t max8903_dcin(int irq, void *_data)
 static irqreturn_t max8903_usbin(int irq, void *_data)
 {
struct max8903_data *data = _data;
-   struct max8903_pdata *pdata = >pdata;
+   struct max8903_pdata *pdata = data->pdata;
bool usb_in;
enum power_supply_type old_type;
 
@@ -161,7 +161,7 @@ static irqreturn_t max8903_usbin(int irq, void *_data)
 static irqreturn_t max8903_fault(int irq, void *_data)
 {
struct max8903_data *data = _data;
-   struct max8903_pdata *pdata = >pdata;
+   struct max8903_pdata *pdata = data->pdata;
bool fault;
 
fault = gpio_get_value(pdata->flt) ? false : true;
@@ -190,12 +190,18 @@ static int max8903_probe(struct platform_device *pdev)
int ta_in = 0;
int usb_in = 0;
 
+   if (pdata == NULL) {
+   dev_err(dev, "No platform data.\n");
+   return -EINVAL;
+   }
+
data = devm_kzalloc(dev, sizeof(struct max8903_data), GFP_KERNEL);
if (data == NULL) {
dev_err(dev, "Cannot allocate memory.\n");
return -ENOMEM;
}
-   memcpy(>pdata, pdata, sizeof(struct max8903_pdata));
+
+   data->pdata = pdev->dev.platform_data;
data->dev = dev;
platform_set_drvdata(pdev, data);
 
-- 
1.9.1



[PATCH v5 4/7] max8903: adds requesting of gpios.

2016-06-23 Thread Chris Lapa
From: Chris Lapa 

This change ensures all gpios are available for the driver to use and also
splits off gpio setup into its own function for readability.

Signed-off-by: Chris Lapa 

Reviewed-by: Krzysztof Kozlowski 
---
 drivers/power/max8903_charger.c | 136 ++--
 1 file changed, 102 insertions(+), 34 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 6ec705f..3f35593 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -179,39 +179,27 @@ static irqreturn_t max8903_fault(int irq, void *_data)
return IRQ_HANDLED;
 }
 
-static int max8903_probe(struct platform_device *pdev)
+static int max8903_setup_gpios(struct platform_device *pdev)
 {
-   struct max8903_data *data;
+   struct max8903_data *data = platform_get_drvdata(pdev);
struct device *dev = >dev;
struct max8903_pdata *pdata = pdev->dev.platform_data;
-   struct power_supply_config psy_cfg = {};
int ret = 0;
int gpio;
int ta_in = 0;
int usb_in = 0;
 
-   if (pdata == NULL) {
-   dev_err(dev, "No platform data.\n");
-   return -EINVAL;
-   }
-
-   data = devm_kzalloc(dev, sizeof(struct max8903_data), GFP_KERNEL);
-   if (data == NULL) {
-   dev_err(dev, "Cannot allocate memory.\n");
-   return -ENOMEM;
-   }
-
-   data->pdata = pdev->dev.platform_data;
-   data->dev = dev;
-   platform_set_drvdata(pdev, data);
-
-   if (pdata->dc_valid == false && pdata->usb_valid == false) {
-   dev_err(dev, "No valid power sources.\n");
-   return -EINVAL;
-   }
-
if (pdata->dc_valid) {
if (pdata->dok && gpio_is_valid(pdata->dok)) {
+   ret = devm_gpio_request(dev, pdata->dok,
+   data->psy_desc.name);
+   if (ret) {
+   dev_err(dev,
+   "Failed GPIO request for dok: %d err 
%d\n",
+   pdata->dok, ret);
+   return ret;
+   }
+
gpio = pdata->dok; /* PULL_UPed Interrupt */
ta_in = gpio_get_value(gpio) ? 0 : 1;
} else {
@@ -222,6 +210,15 @@ static int max8903_probe(struct platform_device *pdev)
 
if (pdata->dcm) {
if (gpio_is_valid(pdata->dcm)) {
+   ret = devm_gpio_request(dev, pdata->dcm,
+   data->psy_desc.name);
+   if (ret) {
+   dev_err(dev,
+   "Failed GPIO request for dcm: %d err 
%d\n",
+   pdata->dcm, ret);
+   return ret;
+   }
+
gpio = pdata->dcm; /* Output */
gpio_set_value(gpio, ta_in);
} else {
@@ -232,6 +229,15 @@ static int max8903_probe(struct platform_device *pdev)
 
if (pdata->usb_valid) {
if (pdata->uok && gpio_is_valid(pdata->uok)) {
+   ret = devm_gpio_request(dev, pdata->uok,
+   data->psy_desc.name);
+   if (ret) {
+   dev_err(dev,
+   "Failed GPIO request for uok: %d err 
%d\n",
+   pdata->uok, ret);
+   return ret;
+   }
+
gpio = pdata->uok;
usb_in = gpio_get_value(gpio) ? 0 : 1;
} else {
@@ -243,6 +249,15 @@ static int max8903_probe(struct platform_device *pdev)
 
if (pdata->cen) {
if (gpio_is_valid(pdata->cen)) {
+   ret = devm_gpio_request(dev, pdata->cen,
+   data->psy_desc.name);
+   if (ret) {
+   dev_err(dev,
+   "Failed GPIO request for cen: %d err 
%d\n",
+   pdata->cen, ret);
+   return ret;
+   }
+
gpio_set_value(pdata->cen, (ta_in || usb_in) ? 0 : 1);
} else {
dev_err(dev, "Invalid pin: cen.\n");
@@ -251,23 +266,41 @@ static int max8903_probe(struct platform_device *pdev)
}
 
if (pdata->chg) {
-   if (!gpio_is_valid(pdata->chg)) {
-   dev_err(dev, "Invalid pin: chg.\n");
-   return -EINVAL;
+   if (gpio_is_valid(pdata->chg)) {
+

[PATCH v5 5/7] max8903: removes non zero validity checks on gpios.

2016-06-23 Thread Chris Lapa
From: Chris Lapa 

Prior to this commit a zero gpio was treated as invalid. Whereas
gpio_is_valid() will treat a zero gpio as valid.

This commit removes the confusion and explicitly uses gpio_is_valid()
throughout. Which in turn results in several of the error messages becoming
redundant and thus removed.

Signed-off-by: Chris Lapa 

Reviewed-by: Krzysztof Kozlowski 
---
 drivers/power/max8903_charger.c | 115 
 1 file changed, 47 insertions(+), 68 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 3f35593..643a87a 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -53,7 +53,7 @@ static int max8903_get_property(struct power_supply *psy,
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
-   if (data->pdata->chg) {
+   if (gpio_is_valid(data->pdata->chg)) {
if (gpio_get_value(data->pdata->chg) == 0)
val->intval = POWER_SUPPLY_STATUS_CHARGING;
else if (data->usb_in || data->ta_in)
@@ -93,11 +93,11 @@ static irqreturn_t max8903_dcin(int irq, void *_data)
data->ta_in = ta_in;
 
/* Set Current-Limit-Mode 1:DC 0:USB */
-   if (pdata->dcm)
+   if (gpio_is_valid(pdata->dcm))
gpio_set_value(pdata->dcm, ta_in ? 1 : 0);
 
/* Charger Enable / Disable (cen is negated) */
-   if (pdata->cen)
+   if (gpio_is_valid(pdata->cen))
gpio_set_value(pdata->cen, ta_in ? 0 :
(data->usb_in ? 0 : 1));
 
@@ -136,7 +136,7 @@ static irqreturn_t max8903_usbin(int irq, void *_data)
/* Do not touch Current-Limit-Mode */
 
/* Charger Enable / Disable (cen is negated) */
-   if (pdata->cen)
+   if (gpio_is_valid(pdata->cen))
gpio_set_value(pdata->cen, usb_in ? 0 :
(data->ta_in ? 0 : 1));
 
@@ -190,7 +190,7 @@ static int max8903_setup_gpios(struct platform_device *pdev)
int usb_in = 0;
 
if (pdata->dc_valid) {
-   if (pdata->dok && gpio_is_valid(pdata->dok)) {
+   if (gpio_is_valid(pdata->dok)) {
ret = devm_gpio_request(dev, pdata->dok,
data->psy_desc.name);
if (ret) {
@@ -208,27 +208,21 @@ static int max8903_setup_gpios(struct platform_device 
*pdev)
}
}
 
-   if (pdata->dcm) {
-   if (gpio_is_valid(pdata->dcm)) {
-   ret = devm_gpio_request(dev, pdata->dcm,
-   data->psy_desc.name);
-   if (ret) {
-   dev_err(dev,
-   "Failed GPIO request for dcm: %d err 
%d\n",
-   pdata->dcm, ret);
-   return ret;
-   }
-
-   gpio = pdata->dcm; /* Output */
-   gpio_set_value(gpio, ta_in);
-   } else {
-   dev_err(dev, "Invalid pin: dcm.\n");
-   return -EINVAL;
+   if (gpio_is_valid(pdata->dcm)) {
+   ret = devm_gpio_request(dev, pdata->dcm, data->psy_desc.name);
+   if (ret) {
+   dev_err(dev,
+   "Failed GPIO request for dcm: %d err %d\n",
+   pdata->dcm, ret);
+   return ret;
}
+
+   gpio = pdata->dcm; /* Output */
+   gpio_set_value(gpio, ta_in);
}
 
if (pdata->usb_valid) {
-   if (pdata->uok && gpio_is_valid(pdata->uok)) {
+   if (gpio_is_valid(pdata->uok)) {
ret = devm_gpio_request(dev, pdata->uok,
data->psy_desc.name);
if (ret) {
@@ -247,60 +241,45 @@ static int max8903_setup_gpios(struct platform_device 
*pdev)
}
}
 
-   if (pdata->cen) {
-   if (gpio_is_valid(pdata->cen)) {
-   ret = devm_gpio_request(dev, pdata->cen,
-   data->psy_desc.name);
-   if (ret) {
-   dev_err(dev,
-   "Failed GPIO request for cen: %d err 
%d\n",
-   pdata->cen, ret);
-   return ret;
-   }
-
-   gpio_set_value(pdata->cen, (ta_in || usb_in) ? 0 : 1);
-   } else {
-   dev_err(dev, "Invalid pin: cen.\n");
-   return 

[PATCH v5 3/7] max8903: cleans up confusing relationship between dc_valid, dok and dcm.

2016-06-23 Thread Chris Lapa
From: Chris Lapa 

The max8903_charger.h file indicated that dcm and dok were not optional
when dc_valid is set.

It makes sense to have dok as a compulsory pin when dc_valid is given.
However dcm can be optionally wired to a fixed level especially when the
circuit is configured for dc power exclusively.

The previous implementation already allowed for this somewhat, however no
error was given if dok wasn't given whilst dc_valid was.

The new implementation enforces dok presence when dc_valid is given. Whilst
allowing dcm to be optional.

Signed-off-by: Chris Lapa 

Reviewed-by: Krzysztof Kozlowski 
---
 drivers/power/max8903_charger.c   | 22 +-
 include/linux/power/max8903_charger.h |  6 +++---
 2 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 0a5b0e1..6ec705f 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -211,27 +211,23 @@ static int max8903_probe(struct platform_device *pdev)
}
 
if (pdata->dc_valid) {
-   if (pdata->dok && gpio_is_valid(pdata->dok) &&
-   pdata->dcm && gpio_is_valid(pdata->dcm)) {
+   if (pdata->dok && gpio_is_valid(pdata->dok)) {
gpio = pdata->dok; /* PULL_UPed Interrupt */
ta_in = gpio_get_value(gpio) ? 0 : 1;
+   } else {
+   dev_err(dev, "When DC is wired, DOK should be wired as 
well.\n");
+   return -EINVAL;
+   }
+   }
 
+   if (pdata->dcm) {
+   if (gpio_is_valid(pdata->dcm)) {
gpio = pdata->dcm; /* Output */
gpio_set_value(gpio, ta_in);
} else {
-   dev_err(dev, "When DC is wired, DOK and DCM should"
-   " be wired as well.\n");
+   dev_err(dev, "Invalid pin: dcm.\n");
return -EINVAL;
}
-   } else {
-   if (pdata->dcm) {
-   if (gpio_is_valid(pdata->dcm))
-   gpio_set_value(pdata->dcm, 0);
-   else {
-   dev_err(dev, "Invalid pin: dcm.\n");
-   return -EINVAL;
-   }
-   }
}
 
if (pdata->usb_valid) {
diff --git a/include/linux/power/max8903_charger.h 
b/include/linux/power/max8903_charger.h
index 24f51db..89d3f1c 100644
--- a/include/linux/power/max8903_charger.h
+++ b/include/linux/power/max8903_charger.h
@@ -26,8 +26,8 @@
 struct max8903_pdata {
/*
 * GPIOs
-* cen, chg, flt, and usus are optional.
-* dok, dcm, and uok are not optional depending on the status of
+* cen, chg, flt, dcm and usus are optional.
+* dok and uok are not optional depending on the status of
 * dc_valid and usb_valid.
 */
int cen;/* Charger Enable input */
@@ -41,7 +41,7 @@ struct max8903_pdata {
/*
 * DC(Adapter/TA) is wired
 * When dc_valid is true,
-*  dok and dcm should be valid.
+*  dok should be valid.
 *
 * At least one of dc_valid or usb_valid should be true.
 */
-- 
1.9.1



[PATCH v5 7/7] max8903: adds support for initiation via device tree

2016-06-23 Thread Chris Lapa
From: Chris Lapa 

Adds support for device tree to setup a max8903 battery charger. DC and USB
validity are determined by looking the presence of the dok and uok gpios.

Signed-off-by: Chris Lapa 
---
 drivers/power/max8903_charger.c | 78 +
 1 file changed, 72 insertions(+), 6 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 9453bbf..fdc73d6 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -23,6 +23,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -75,6 +78,7 @@ static int max8903_get_property(struct power_supply *psy,
default:
return -EINVAL;
}
+
return 0;
 }
 
@@ -179,6 +183,56 @@ static irqreturn_t max8903_fault(int irq, void *_data)
return IRQ_HANDLED;
 }
 
+static struct max8903_pdata *max8903_parse_dt_data(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct max8903_pdata *pdata = NULL;
+
+   if (!np)
+   return NULL;
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata->dc_valid = false;
+   pdata->usb_valid = false;
+
+   pdata->cen = of_get_named_gpio(np, "cen-gpios", 0);
+   if (!gpio_is_valid(pdata->cen))
+   pdata->cen = -EINVAL;
+
+   pdata->chg = of_get_named_gpio(np, "chg-gpios", 0);
+   if (!gpio_is_valid(pdata->chg))
+   pdata->chg = -EINVAL;
+
+   pdata->flt = of_get_named_gpio(np, "flt-gpios", 0);
+   if (!gpio_is_valid(pdata->flt))
+   pdata->flt = -EINVAL;
+
+   pdata->usus = of_get_named_gpio(np, "usus-gpios", 0);
+   if (!gpio_is_valid(pdata->usus))
+   pdata->usus = -EINVAL;
+
+   pdata->dcm = of_get_named_gpio(np, "dcm-gpios", 0);
+   if (!gpio_is_valid(pdata->dcm))
+   pdata->dcm = -EINVAL;
+
+   pdata->dok = of_get_named_gpio(np, "dok-gpios", 0);
+   if (!gpio_is_valid(pdata->dok))
+   pdata->dok = -EINVAL;
+   else
+   pdata->dc_valid = true;
+
+   pdata->uok = of_get_named_gpio(np, "uok-gpios", 0);
+   if (!gpio_is_valid(pdata->uok))
+   pdata->uok = -EINVAL;
+   else
+   pdata->usb_valid = true;
+
+   return pdata;
+}
+
 static int max8903_setup_gpios(struct platform_device *pdev)
 {
struct max8903_data *data = platform_get_drvdata(pdev);
@@ -298,16 +352,20 @@ static int max8903_probe(struct platform_device *pdev)
struct power_supply_config psy_cfg = {};
int ret = 0;
 
-   if (pdata == NULL) {
-   dev_err(dev, "No platform data.\n");
-   return -EINVAL;
-   }
-
data = devm_kzalloc(dev, sizeof(struct max8903_data), GFP_KERNEL);
if (!data)
return -ENOMEM;
 
-   data->pdata = pdev->dev.platform_data;
+   if (IS_ENABLED(CONFIG_OF) && !pdata && dev->of_node)
+   pdata = max8903_parse_dt_data(dev);
+
+   if (!pdata) {
+   dev_err(dev, "No platform data.\n");
+   return -EINVAL;
+   }
+
+   pdev->dev.platform_data = pdata;
+   data->pdata = pdata;
data->dev = dev;
platform_set_drvdata(pdev, data);
 
@@ -328,6 +386,7 @@ static int max8903_probe(struct platform_device *pdev)
data->psy_desc.properties = max8903_charger_props;
data->psy_desc.num_properties = ARRAY_SIZE(max8903_charger_props);
 
+   psy_cfg.of_node = dev->of_node;
psy_cfg.drv_data = data;
 
data->psy = devm_power_supply_register(dev, >psy_desc, _cfg);
@@ -378,10 +437,17 @@ static int max8903_probe(struct platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id max8903_match_ids[] = {
+   { .compatible = "maxim,max8903", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, max8903_match_ids);
+
 static struct platform_driver max8903_driver = {
.probe  = max8903_probe,
.driver = {
.name   = "max8903-charger",
+   .of_match_table = max8903_match_ids
},
 };
 
-- 
1.9.1



[PATCH v5 6/7] max8903: remove unnecessary 'out of memory' error message.

2016-06-23 Thread Chris Lapa
From: Chris Lapa 

Remove the 'out of memory' error message as it is printed by the core.

Signed-off-by: Chris Lapa 

Reviewed-by: Krzysztof Kozlowski 
---
 drivers/power/max8903_charger.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 643a87a..9453bbf 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -304,10 +304,8 @@ static int max8903_probe(struct platform_device *pdev)
}
 
data = devm_kzalloc(dev, sizeof(struct max8903_data), GFP_KERNEL);
-   if (data == NULL) {
-   dev_err(dev, "Cannot allocate memory.\n");
+   if (!data)
return -ENOMEM;
-   }
 
data->pdata = pdev->dev.platform_data;
data->dev = dev;
-- 
1.9.1



[PATCH v5 1/7] max8903: adds documentation for device tree bindings.

2016-06-23 Thread Chris Lapa
From: Chris Lapa 

Signed-off-by: Chris Lapa 
---
 .../devicetree/bindings/power/max8903-charger.txt  | 25 +++
 arch/arm/boot/dts/dairytest-servo.dtsi | 36 ++
 2 files changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/max8903-charger.txt
 create mode 100644 arch/arm/boot/dts/dairytest-servo.dtsi

diff --git a/Documentation/devicetree/bindings/power/max8903-charger.txt 
b/Documentation/devicetree/bindings/power/max8903-charger.txt
new file mode 100644
index 000..f0f4e12
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/max8903-charger.txt
@@ -0,0 +1,25 @@
+Maxim Semiconductor MAX8903 Battery Charger bindings
+
+Required properties:
+- compatible: "maxim,max8903" for MAX8903 Battery Charger
+- dok-gpios: Valid DC power has been detected (active low, input), optional if 
uok-gpios is provided
+- uok-gpios: Valid USB power has been detected (active low, input), optional 
if dok-gpios is provided
+
+Optional properties:
+- cen-gpios: Charge enable pin (active low, output)
+- chg-gpios: Charger status pin (active low, input)
+- flt-gpios: Fault pin (active low, output)
+- dcm-gpios: Current limit mode setting (DC=1 or USB=0, output)
+- usus-gpios: USB suspend pin (active high, output)
+
+
+Example:
+
+   max8903-charger {
+   compatible = "maxim,max8903";
+   dok-gpios = < 3 GPIO_ACTIVE_LOW>;
+   flt-gpios = < 2 GPIO_ACTIVE_LOW>;
+   chg-gpios = < 15 GPIO_ACTIVE_LOW>;
+   cen-gpios = < 5 GPIO_ACTIVE_LOW>;
+   status = "okay";
+   };
diff --git a/arch/arm/boot/dts/dairytest-servo.dtsi 
b/arch/arm/boot/dts/dairytest-servo.dtsi
new file mode 100644
index 000..3fbe81d
--- /dev/null
+++ b/arch/arm/boot/dts/dairytest-servo.dtsi
@@ -0,0 +1,36 @@
+#include 
+#include 
+#include 
+
+_pinmux {
+servo_power_pin: pinmux_servo_power_pin{
+pinctrl-single,pins = <
+BONE_P9_27 (PIN_OUTPUT| MUX_MODE7)  /* ZCZ(C13) - gpio3_19, OUTPUT 
| MODE7 */
+>;
+};
+
+ehrpwm2_pin: pinmux_ehrpwm2_pin{
+pinctrl-single,pins = <
+BONE_P8_19 (PIN_OUTPUT | MUX_MODE4) /* ZCZ(R1) - ehrpwm2a, OUTPUT 
| MODE3 */
+>;
+};
+};
+
+/ {
+servo_power {
+status = "okay";
+compatible = "pinctrl-single";
+pinctrl-names = "default";
+pinctrl-0 = <_power_pin>;
+};
+};
+
+ {
+status = "okay";
+};
+
+ {
+pinctrl-names = "default";
+pinctrl-0 = <_pin>;
+status = "okay";
+};
-- 
1.9.1



[PATCH v5 0/7] max8903: Add device tree support and misc fixes

2016-06-23 Thread Chris Lapa
From: Chris Lapa 

This patch set adds device tree support for the MAX8903 battery charger.
It also cleans up logic with dc_valid, dok and dcm pins as well as
fixing up validity checking of gpios.

I verified these patches work on a board I have here, which uses the
DC power side (not the USB portition) of the MAX8903.

Changes v4 -> v5:
 * Changes compatible field from max8903_charger to max8903 in 1/7 and 7/7
 * Improves DT documentation to include direction and state for each gpio

Changes v3 -> v4:
 * Fixed formatting, such as multiline strings and indentation mistakes
 * Moved gpio setup code into max8903_setup_gpios() in 3/7
 * Fixed typo in 5/7
 * Renamed of_node to np in 7/7

Changes v2 -> v3:
 * Separate requesting of gpio's into its own commit
 * Fixed up validity checking of GPIO's
 * Remove dc_valid and usb_valid from device tree
 * Remove some unncessary init to psy_cfg.num_supplicants and 
psy_cfg.supplied_to
 * Reorder patches so device tree implementation is final patch

Changes v1 -> v2:
 * Separate DT bindings documentation into its own commit
 * Add maxim prefix to DT compatible field
 * Add gpios suffix to gpio's in DT
 * Remove malloc failed error message


Chris Lapa (7):
  max8903: adds documentation for device tree bindings.
  max8903: store pointer to pdata instead of copying it.
  max8903: cleans up confusing relationship between dc_valid, dok and
dcm.
  max8903: adds requesting of gpios.
  max8903: removes non zero validity checks on gpios.
  max8903: remove unnecessary 'out of memory' error message.
  max8903: adds support for initiation via device tree

 .../devicetree/bindings/power/max8903-charger.txt  |  25 +++
 arch/arm/boot/dts/dairytest-servo.dtsi |  36 
 drivers/power/max8903_charger.c| 239 +++--
 include/linux/power/max8903_charger.h  |   6 +-
 4 files changed, 240 insertions(+), 66 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/max8903-charger.txt
 create mode 100644 arch/arm/boot/dts/dairytest-servo.dtsi

-- 
1.9.1



Re: [PATCH v4 0/3] acpi/pmic: add opregion driver for Intel BXT WhiskeyCove PMIC

2016-06-23 Thread Aaron Lu
On 06/24/2016 08:43 AM, Bin Gao wrote:
> This series modifies the pen function signature to take bit field
> and adds a new opregion driver for Intel BXT WhiskeyCove PMIC. It
> also adds support for PMIC regs operation region.

Reviewed-by: Aaron Lu 

Thanks,
Aaron

> 
> Yegnesh Iyer (1):
>   acpi: pmic: Modifying the pen function signature to take bit field
> 
> Ajay Thomas (1):
>   acpi: pmic: Add opregion driver for Intel BXT WhiskeyCove PMIC
> 
> Chandra Sekhar Anagani (1):
>  acpi: pmic: Add support for Intel BXT PMIC regs operation region
> 
>  drivers/acpi/pmic/intel_pmic.c   | 87  +++--
>  drivers/acpi/pmic/intel_pmic.h   | 11  ++--
>  drivers/acpi/pmic/intel_pmic_crc.c   |  5  +++--
>  drivers/acpi/Kconfig |  6  +
>  drivers/acpi/Makefile|  1  +
>  drivers/acpi/pmic/intel_pmic_bxtwc.c |449  
> +++
>  6 files changed, 559 insertions(+), 10 deletions(-)
>  create mode 100644 drivers/acpi/pmic/intel_pmic_bxtwc.c
> --
> 1.9.1
> 



Re: [PATCH V2 2/4] STM Ftrace: Adding generic buffer interface driver

2016-06-23 Thread kbuild test robot
Hi,

[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.7-rc4 next-20160623]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chunyan-Zhang/Integration-of-function-trace-with-System-Trace-IP-blocks/20160622-115305
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `stm_ftrace_unlink':
>> ftrace.c:(.text+0x12197ac): undefined reference to `trace_rm_output'
   drivers/built-in.o: In function `stm_ftrace_link':
>> ftrace.c:(.text+0x12197be): undefined reference to `trace_add_output'

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


.config.gz
Description: Binary data


[PATCH v5 3/8] iommu/rockchip: Fix allocation of bases array in driver probe

2016-06-23 Thread Shunqian Zheng
In .probe(), devm_kzalloc() is called with size == 0 and works only
by luck, due to internal behavior of the allocator and the fact
that the proper allocation size is small. Let's use proper value for
calculating the size.

Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves")

Signed-off-by: Shunqian Zheng 
Signed-off-by: Tomasz Figa 
Reviewed-by: Douglas Anderson 
---
 drivers/iommu/rockchip-iommu.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 53fa0d9..8a5bac7 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -1034,6 +1034,7 @@ static int rk_iommu_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct rk_iommu *iommu;
struct resource *res;
+   int num_res = pdev->num_resources;
int i;
 
iommu = devm_kzalloc(dev, sizeof(*iommu), GFP_KERNEL);
@@ -1043,12 +1044,13 @@ static int rk_iommu_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, iommu);
iommu->dev = dev;
iommu->num_mmu = 0;
-   iommu->bases = devm_kzalloc(dev, sizeof(*iommu->bases) * iommu->num_mmu,
+
+   iommu->bases = devm_kzalloc(dev, sizeof(*iommu->bases) * num_res,
GFP_KERNEL);
if (!iommu->bases)
return -ENOMEM;
 
-   for (i = 0; i < pdev->num_resources; i++) {
+   for (i = 0; i < num_res; i++) {
res = platform_get_resource(pdev, IORESOURCE_MEM, i);
if (!res)
continue;
-- 
1.9.1



[PATCH v5 8/8] iommu/rockchip: Enable Rockchip IOMMU on ARM64

2016-06-23 Thread Shunqian Zheng
From: Simon Xue 

This patch makes it possible to compile the rockchip-iommu driver on
ARM64, so that it can be used with 64-bit SoCs equipped with this type
of IOMMU.

Signed-off-by: Simon Xue 
Signed-off-by: Shunqian Zheng 
Signed-off-by: Tomasz Figa 
---
 drivers/iommu/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index ad08603..5572621 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -218,7 +218,7 @@ config OMAP_IOMMU_DEBUG
 
 config ROCKCHIP_IOMMU
bool "Rockchip IOMMU Support"
-   depends on ARM
+   depends on ARM || ARM64
depends on ARCH_ROCKCHIP || COMPILE_TEST
select IOMMU_API
select ARM_DMA_USE_IOMMU
-- 
1.9.1



[PATCH v5 6/8] drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

2016-06-23 Thread Shunqian Zheng
From: Tomasz Figa 

The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.

This patch should not introduce any functional changes until the driver
is made to attach subdevices into an IOMMU domain with the generic IOMMU
API, which will happen in following patch. Based heavily on GEM
implementation of Tegra DRM driver.

Signed-off-by: Tomasz Figa 
Signed-off-by: Shunqian Zheng 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 221 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   9 ++
 3 files changed, 222 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index ea39329..5ab1223 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -30,6 +30,7 @@
 
 struct drm_device;
 struct drm_connector;
+struct iommu_domain;
 
 /*
  * Rockchip drm private crtc funcs.
@@ -61,6 +62,8 @@ struct rockchip_drm_private {
struct drm_gem_object *fbdev_bo;
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
struct drm_atomic_state *state;
+   struct iommu_domain *domain;
+   struct drm_mm mm;
 };
 
 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 394f92b..e7cd93d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -19,11 +19,135 @@
 #include 
 
 #include 
+#include 
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
 
-static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj,
+static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   struct rockchip_drm_private *private = drm->dev_private;
+   int prot = IOMMU_READ | IOMMU_WRITE;
+   ssize_t ret;
+
+   ret = drm_mm_insert_node_generic(>mm, _obj->mm,
+rk_obj->base.size, PAGE_SIZE,
+0, 0, 0);
+   if (ret < 0) {
+   DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
+   return ret;
+   }
+
+   rk_obj->dma_addr = rk_obj->mm.start;
+
+   ret = iommu_map_sg(private->domain, rk_obj->dma_addr, rk_obj->sgt->sgl,
+  rk_obj->sgt->nents, prot);
+   if (ret < 0) {
+   DRM_ERROR("failed to map buffer: %zd\n", ret);
+   goto err_remove_node;
+   }
+
+   rk_obj->size = ret;
+
+   return 0;
+
+err_remove_node:
+   drm_mm_remove_node(_obj->mm);
+
+   return ret;
+}
+
+static int rockchip_gem_iommu_unmap(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   struct rockchip_drm_private *private = drm->dev_private;
+
+   iommu_unmap(private->domain, rk_obj->dma_addr, rk_obj->size);
+   drm_mm_remove_node(_obj->mm);
+
+   return 0;
+}
+
+static int rockchip_gem_get_pages(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   int ret, i;
+   struct scatterlist *s;
+
+   rk_obj->pages = drm_gem_get_pages(_obj->base);
+   if (IS_ERR(rk_obj->pages))
+   return PTR_ERR(rk_obj->pages);
+
+   rk_obj->num_pages = rk_obj->base.size >> PAGE_SHIFT;
+
+   rk_obj->sgt = drm_prime_pages_to_sg(rk_obj->pages, rk_obj->num_pages);
+   if (IS_ERR(rk_obj->sgt)) {
+   ret = PTR_ERR(rk_obj->sgt);
+   goto err_put_pages;
+   }
+
+   /*
+* Fake up the SG table so that dma_sync_sg_for_device() can be used
+* to flush the pages associated with it.
+*
+* TODO: Replace this by drm_clflush_sg() once it can be implemented
+* without relying on symbols that are not exported.
+*/
+   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
+   sg_dma_address(s) = sg_phys(s);
+
+   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents,
+  DMA_TO_DEVICE);
+
+   return 0;
+
+err_put_pages:
+   drm_gem_put_pages(_obj->base, rk_obj->pages, false, false);
+   return ret;
+}
+
+static void rockchip_gem_put_pages(struct rockchip_gem_object *rk_obj)
+{
+   sg_free_table(rk_obj->sgt);
+   kfree(rk_obj->sgt);
+   drm_gem_put_pages(_obj->base, rk_obj->pages, false, false);
+}
+
+static int rockchip_gem_alloc_iommu(struct rockchip_gem_object *rk_obj,
+   bool alloc_kmap)
+{
+   int ret;
+
+   

[PATCH v5 4/8] iommu/rockchip: Use DMA API to manage coherency

2016-06-23 Thread Shunqian Zheng
Use DMA API instead of architecture internal functions like
__cpuc_flush_dcache_area() etc.

The biggest difficulty here is that dma_map and _sync calls require some
struct device, while there is no real 1:1 relation between an IOMMU
domain and some device. To overcome this, a simple platform device is
registered for each allocated IOMMU domain.

With this patch, this driver can be used on both ARM and ARM64
platforms, such as RK3288 and RK3399 respectively.

Signed-off-by: Shunqian Zheng 
Signed-off-by: Tomasz Figa 
---
 drivers/iommu/rockchip-iommu.c | 162 +++--
 1 file changed, 123 insertions(+), 39 deletions(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 8a5bac7..712ed75 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -4,11 +4,10 @@
  * published by the Free Software Foundation.
  */
 
-#include 
-#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -77,7 +76,9 @@
 
 struct rk_iommu_domain {
struct list_head iommus;
+   struct platform_device *pdev;
u32 *dt; /* page directory table */
+   dma_addr_t dt_dma;
spinlock_t iommus_lock; /* lock for iommus list */
spinlock_t dt_lock; /* lock for modifying page directory table */
 
@@ -93,14 +94,12 @@ struct rk_iommu {
struct iommu_domain *domain; /* domain to which iommu is attached */
 };
 
-static inline void rk_table_flush(u32 *va, unsigned int count)
+static inline void rk_table_flush(struct rk_iommu_domain *dom, dma_addr_t dma,
+ unsigned int count)
 {
-   phys_addr_t pa_start = virt_to_phys(va);
-   phys_addr_t pa_end = virt_to_phys(va + count);
-   size_t size = pa_end - pa_start;
+   size_t size = count * sizeof(u32); /* count of u32 entry */
 
-   __cpuc_flush_dcache_area(va, size);
-   outer_flush_range(pa_start, pa_end);
+   dma_sync_single_for_device(>pdev->dev, dma, size, DMA_TO_DEVICE);
 }
 
 static struct rk_iommu_domain *to_rk_domain(struct iommu_domain *dom)
@@ -183,10 +182,9 @@ static inline bool rk_dte_is_pt_valid(u32 dte)
return dte & RK_DTE_PT_VALID;
 }
 
-static u32 rk_mk_dte(u32 *pt)
+static inline u32 rk_mk_dte(dma_addr_t pt_dma)
 {
-   phys_addr_t pt_phys = virt_to_phys(pt);
-   return (pt_phys & RK_DTE_PT_ADDRESS_MASK) | RK_DTE_PT_VALID;
+   return (pt_dma & RK_DTE_PT_ADDRESS_MASK) | RK_DTE_PT_VALID;
 }
 
 /*
@@ -603,13 +601,16 @@ static void rk_iommu_zap_iova_first_last(struct 
rk_iommu_domain *rk_domain,
 static u32 *rk_dte_get_page_table(struct rk_iommu_domain *rk_domain,
  dma_addr_t iova)
 {
+   struct device *dev = _domain->pdev->dev;
u32 *page_table, *dte_addr;
-   u32 dte;
+   u32 dte_index, dte;
phys_addr_t pt_phys;
+   dma_addr_t pt_dma;
 
assert_spin_locked(_domain->dt_lock);
 
-   dte_addr = _domain->dt[rk_iova_dte_index(iova)];
+   dte_index = rk_iova_dte_index(iova);
+   dte_addr = _domain->dt[dte_index];
dte = *dte_addr;
if (rk_dte_is_pt_valid(dte))
goto done;
@@ -618,19 +619,27 @@ static u32 *rk_dte_get_page_table(struct rk_iommu_domain 
*rk_domain,
if (!page_table)
return ERR_PTR(-ENOMEM);
 
-   dte = rk_mk_dte(page_table);
-   *dte_addr = dte;
+   pt_dma = dma_map_single(dev, page_table, SPAGE_SIZE, DMA_TO_DEVICE);
+   if (dma_mapping_error(dev, pt_dma)) {
+   dev_err(dev, "DMA mapping error while allocating page table\n");
+   free_page((unsigned long)page_table);
+   return ERR_PTR(-ENOMEM);
+   }
 
-   rk_table_flush(page_table, NUM_PT_ENTRIES);
-   rk_table_flush(dte_addr, 1);
+   dte = rk_mk_dte(pt_dma);
+   *dte_addr = dte;
 
+   rk_table_flush(rk_domain, pt_dma, NUM_PT_ENTRIES);
+   rk_table_flush(rk_domain,
+  rk_domain->dt_dma + dte_index * sizeof(u32), 1);
 done:
pt_phys = rk_dte_pt_address(dte);
return (u32 *)phys_to_virt(pt_phys);
 }
 
 static size_t rk_iommu_unmap_iova(struct rk_iommu_domain *rk_domain,
- u32 *pte_addr, dma_addr_t iova, size_t size)
+ u32 *pte_addr, dma_addr_t pte_dma,
+ size_t size)
 {
unsigned int pte_count;
unsigned int pte_total = size / SPAGE_SIZE;
@@ -645,14 +654,14 @@ static size_t rk_iommu_unmap_iova(struct rk_iommu_domain 
*rk_domain,
pte_addr[pte_count] = rk_mk_pte_invalid(pte);
}
 
-   rk_table_flush(pte_addr, pte_count);
+   rk_table_flush(rk_domain, pte_dma, pte_count);
 
return pte_count * SPAGE_SIZE;
 }
 
 static int rk_iommu_map_iova(struct rk_iommu_domain *rk_domain, u32 *pte_addr,
-dma_addr_t iova, phys_addr_t paddr, size_t 

[PATCH v5 7/8] drm/rockchip: Use common IOMMU API to attach devices

2016-06-23 Thread Shunqian Zheng
Rockchip DRM used the arm special API, arm_iommu_*(), to attach
iommu for ARM32 SoCs. This patch convert to common iommu API
so it would support ARM64 like RK3399.

Since previous patch added support for direct IOMMU address space
management, there is no need to use DMA API anymore and this patch wires
things to use the new method.

Signed-off-by: Shunqian Zheng 
Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 100 +++-
 1 file changed, 53 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 8b96c69..ca9624f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -14,18 +14,18 @@
  * GNU General Public License for more details.
  */
 
-#include 
-
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -51,28 +51,31 @@ static struct drm_driver rockchip_drm_driver;
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev)
 {
-   struct dma_iommu_mapping *mapping = drm_dev->dev->archdata.mapping;
+   struct rockchip_drm_private *private = drm_dev->dev_private;
int ret;
 
if (!is_support_iommu)
return 0;
 
-   ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
-   if (ret)
+   ret = iommu_attach_device(private->domain, dev);
+   if (ret) {
+   dev_err(dev, "Failed to attach iommu device\n");
return ret;
+   }
 
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
-
-   return arm_iommu_attach_device(dev, mapping);
+   return 0;
 }
 
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev)
 {
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+   struct iommu_domain *domain = private->domain;
+
if (!is_support_iommu)
return;
 
-   arm_iommu_detach_device(dev);
+   iommu_detach_device(domain, dev);
 }
 
 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
@@ -137,11 +140,45 @@ static void rockchip_drm_crtc_disable_vblank(struct 
drm_device *dev,
priv->crtc_funcs[pipe]->disable_vblank(crtc);
 }
 
+static int rockchip_drm_init_iommu(struct drm_device *drm_dev)
+{
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+   struct iommu_domain_geometry *geometry;
+   u64 start, end;
+
+   if (!is_support_iommu)
+   return 0;
+
+   private->domain = iommu_domain_alloc(_bus_type);
+   if (!private->domain)
+   return -ENOMEM;
+
+   geometry = >domain->geometry;
+   start = geometry->aperture_start;
+   end = geometry->aperture_end;
+
+   DRM_DEBUG("IOMMU context initialized (aperture: %#llx-%#llx)\n",
+ start, end);
+   drm_mm_init(>mm, start, end - start + 1);
+
+   return 0;
+}
+
+static void rockchip_iommu_cleanup(struct drm_device *drm_dev)
+{
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+
+   if (!is_support_iommu)
+   return;
+
+   drm_mm_takedown(>mm);
+   iommu_domain_free(private->domain);
+}
+
 static int rockchip_drm_bind(struct device *dev)
 {
struct drm_device *drm_dev;
struct rockchip_drm_private *private;
-   struct dma_iommu_mapping *mapping = NULL;
int ret;
 
drm_dev = drm_dev_alloc(_drm_driver, dev);
@@ -162,38 +199,14 @@ static int rockchip_drm_bind(struct device *dev)
 
rockchip_drm_mode_config_init(drm_dev);
 
-   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
- GFP_KERNEL);
-   if (!dev->dma_parms) {
-   ret = -ENOMEM;
+   ret = rockchip_drm_init_iommu(drm_dev);
+   if (ret)
goto err_config_cleanup;
-   }
-
-   if (is_support_iommu) {
-   /* TODO(djkurtz): fetch the mapping start/size from somewhere */
-   mapping = arm_iommu_create_mapping(_bus_type,
-  0x,
-  SZ_2G);
-   if (IS_ERR(mapping)) {
-   ret = PTR_ERR(mapping);
-   goto err_config_cleanup;
-   }
-
-   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
-   if (ret)
-   goto err_release_mapping;
-
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
-
-   ret = arm_iommu_attach_device(dev, mapping);
-   if (ret)
-   goto err_release_mapping;
-   }
 
/* Try to bind all sub drivers. */
ret = component_bind_all(dev, drm_dev);
  

[PATCH v5 2/8] iommu/rockchip: Add map_sg callback for rk_iommu_ops

2016-06-23 Thread Shunqian Zheng
From: Simon Xue 

The iommu_dma_alloc() in iommu/dma-iommu.c calls iommu_map_sg()
that requires the callback iommu_ops .map_sg(). Adding the
default_iommu_map_sg() to Rockchip IOMMU accordingly.

Signed-off-by: Simon Xue 
Signed-off-by: Shunqian Zheng 
Reviewed-by: Douglas Anderson 
Signed-off-by: Tomasz Figa 
---
 drivers/iommu/rockchip-iommu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 5a9659a..53fa0d9 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -1022,6 +1022,7 @@ static const struct iommu_ops rk_iommu_ops = {
.detach_dev = rk_iommu_detach_device,
.map = rk_iommu_map,
.unmap = rk_iommu_unmap,
+   .map_sg = default_iommu_map_sg,
.add_device = rk_iommu_add_device,
.remove_device = rk_iommu_remove_device,
.iova_to_phys = rk_iommu_iova_to_phys,
-- 
1.9.1



[PATCH v5 5/8] iommu/rockchip: Prepare to support generic DMA mapping

2016-06-23 Thread Shunqian Zheng
Set geometry for allocated domains and fix .domain_alloc() callback to
work with IOMMU_DOMAIN_DMA domain type, which is used for implicit
domains on ARM64.

Signed-off-by: Shunqian Zheng 
Signed-off-by: Tomasz Figa 
---
 drivers/iommu/rockchip-iommu.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 712ed75..9afcbf7 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -889,7 +889,7 @@ static struct iommu_domain *rk_iommu_domain_alloc(unsigned 
type)
struct platform_device *pdev;
struct device *iommu_dev;
 
-   if (type != IOMMU_DOMAIN_UNMANAGED)
+   if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
return NULL;
 
/* Register a pdev per domain, so DMA API can base on this *dev
@@ -906,8 +906,8 @@ static struct iommu_domain *rk_iommu_domain_alloc(unsigned 
type)
 
rk_domain->pdev = pdev;
 
-   /* To init the iovad which is required by iommu_dma_init_domain() */
-   if (iommu_get_dma_cookie(_domain->domain))
+   if (type == IOMMU_DOMAIN_DMA &&
+   iommu_get_dma_cookie(_domain->domain))
goto err_unreg_pdev;
 
/*
@@ -933,12 +933,17 @@ static struct iommu_domain 
*rk_iommu_domain_alloc(unsigned type)
spin_lock_init(_domain->dt_lock);
INIT_LIST_HEAD(_domain->iommus);
 
+   rk_domain->domain.geometry.aperture_start = 0;
+   rk_domain->domain.geometry.aperture_end   = DMA_BIT_MASK(32);
+   rk_domain->domain.geometry.force_aperture = true;
+
return _domain->domain;
 
 err_free_dt:
free_page((unsigned long)rk_domain->dt);
 err_put_cookie:
-   iommu_put_dma_cookie(_domain->domain);
+   if (type == IOMMU_DOMAIN_DMA)
+   iommu_put_dma_cookie(_domain->domain);
 err_unreg_pdev:
platform_device_unregister(pdev);
 
@@ -967,7 +972,8 @@ static void rk_iommu_domain_free(struct iommu_domain 
*domain)
 SPAGE_SIZE, DMA_TO_DEVICE);
free_page((unsigned long)rk_domain->dt);
 
-   iommu_put_dma_cookie(_domain->domain);
+   if (domain->type == IOMMU_DOMAIN_DMA)
+   iommu_put_dma_cookie(_domain->domain);
 
platform_device_unregister(rk_domain->pdev);
 }
-- 
1.9.1



Re: [PATCH] ceph: fix spelling mistake: "resgister" -> "register"

2016-06-23 Thread Yan, Zheng

> On Jun 24, 2016, at 00:01, Joe Perches  wrote:
> 
> On Thu, 2016-06-23 at 14:45 +0100, Colin King wrote:
>> trivial fix to spelling mistake in pr_err message
> []
>> diff --git a/fs/ceph/cache.c b/fs/ceph/cache.c
> []
>> @@ -71,7 +71,7 @@ int ceph_fscache_register_fs(struct ceph_fs_client* fsc)
>>_fscache_fsid_object_def,
>>fsc, true);
>>  if (!fsc->fscache)
>> -pr_err("Unable to resgister fsid: %p fscache cookie", fsc);
>> +pr_err("Unable to register fsid: %p fscache cookie", fsc);
> 
> Could change to "cookie\n" to avoid possible interleaving
> from other messages too.

Applied , thanks

Yan, Zheng





  1   2   3   4   5   6   7   8   9   10   >