Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

2015-10-22 Thread Wangnan (F)



On 2015/10/22 17:06, Peter Zijlstra wrote:

On Wed, Oct 21, 2015 at 02:19:49PM -0700, Alexei Starovoitov wrote:


Urgh, that's still horridly inconsistent. Can we please come up with a
consistent interface to perf?

My suggestion was to do ioctl(enable/disable) of events from userspace
after receiving notification from kernel via my bpf_perf_event_output()
helper.
Wangnan's argument was that display refresh happens often and it's fast,
so the time taken by user space to enable events on all cpus is too
slow and ioctl does ipi and disturbs other cpus even more.
So soft_disable done by the program to enable/disable particular events
on all cpus kinda makes sense.

And this all makes me think I still have no clue what you're all trying
to do here.

Who cares about display updates and why. And why should there be an
active userspace part to eBPF programs?


So you want the background story? OK, let me describe it. This mail is not
short so please be patient.

On a smartphone, if time between two frames is longer than 16ms, user
can aware it. This is a display glitch. We want to check those glitches
with perf to find what cause them. The basic idea is: use 'perf record'
to collect enough information, find those samples generated just before
the glitch form perf.data then analysis them offline.

There are many works need to be done before perf can support such
analysis. One improtant thing is to reduce the overhead from perf to
avoid perf itself become the reason of glitches. We can do this by reduce
the number of events perf collects, but then we won't have enough
information to analysis when glitch happen. Another way we are trying to 
implement

now is to dynamically turn events on and off, or at least enable/disable
sampling dynamically because the overhead of copying those samples
is a big part of perf's total overhead. After that we can trace as many
event as possible, but only fetch data from them when we detect a glitch.

BPF program is the best choice to describe our relative complex glitch
detection model. For simplicity, you can think our glitch detection model
contain 3 points at user programs: point A means display refreshing begin,
point B means display refreshing has last for 16ms, point C means
display refreshing finished. They can be found in user programs and
probed through uprobe, on which we can attach BPF programs on.

Then we want to use perf this way:

Sample 'cycles' event to collect callgraph so we know what all CPUs are
doing during the refreshing, but only start sampling when we detect a
frame refreshing last for 16ms.

We can translate the above logic into BPF programs: at point B, enable
'cycles' event to generate samples; at point C, disable 'cycles' event
to avoid useless samples to be generated.

Then, make 'perf record -e cycles' to collect call graph and other
information through cycles event. From perf.data, we can use 'perf script'
and other tools to analysis resuling data.

We have consider some potential solution and find them inapproate or need
too much work to do:

 1. As you may prefer, create BPF functions to call pmu->stop() /
pmu->start() for perf event on the CPU on which BPF programs get
triggered.

The shortcoming of this method is we can only turn on the perf event on
the CPU execute point B. We are unable to know what other CPU are doing
during glitching. But what we want is system-wide information. In 
addition,
point C and point B are not necessarily be executed at one core, so 
we may
shut down wrong event if scheduler decide to run point C on another 
core.


 2. As Alexei's suggestion, output something through his 
bpf_perf_event_output(),

let perf disable and enable those events using ioctl in userspace.

This is a good idea, but introduces asynchronization problem.
bpf_perf_event_output() output something to perf's ring buffer, but 
perf
get noticed about this message when epoll_wait() return. We tested 
a tracepoint

event and found that an event may awared by perf sereval seconds after
it generated. One solution is to use --no-buffer, but it still need 
perf to be
scheduled on time and parse its ringbuffer quickly. Also, please 
note that point
C is possible to appear very shortly after point B because some 
APPs are optimized

to make their refreshing time very near to 16ms.

This is the background story. Looks like whether we implement some 
corss-CPU controling
or we satisified with coarse grained controlling. The best method we can 
think is to
use atomic operation to soft enable/disable perf events. We believe it 
is simple enough

and won't cause problem.

Thank you.

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


Re: [PATCH v4 1/2] sched: make __update_cpu_load() handle active tickless case

2015-10-22 Thread Byungchul Park
On Tue, Oct 20, 2015 at 11:48:48AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 20, 2015 at 09:49:32AM +0900, Byungchul Park wrote:
> > > > = A^i * cpu_load(n-i) + (A^(i-1) + A^(i-2) + ... + 1) * B
> > > > , where i = pending_updates - 1
> > > 
> > > You missed an opportunity here, if you take i==n you avoid the need for
> > > i entirely.
> > 
> > i don't think so. as i said, _n_ is the current tick -1 and _i_ is
> > pending_updates - 1. we cannot take i == n, but should keep (n-i).
> 
> Just think relative; it doesn't matter when in time we do this.
> So 0 to n is identical to any other interval.

You are right. I'm always tired these days. I was confused.
Sorry for that.

> 
> > > > = A^i * cpu_load(n-i) + B * (A^i - 1) / (A - 1)
> > > > , by geometric series formula for sum
> > > 
> > > That's wrong; the limited geometric series expands to:
> > 
> > NO, that's not wrong. it doesn't matter at all.
> > 
> > a * (1 - r^n) / (1 - r)
> > = a * (-1)(r^n - 1) / (-1)(r - 1)
> > = a * (r^n - 1) / (r - 1)
> > 
> > i mean these two are exactly same.
> 
> Ah indeed! Sorry for that. I clearly didn't think beyond the series
> expansion I found.
> 
> > > I've rewritten the things a little; does this look good to you?
> > 
> > however, your expressions and descriptions below look better than me,
> > except some logical errors. could you keep my logical flow unchagned?
> 
> > > + *   load[i]_n = (1 - 1/2^i) * load[i]_n-1 + (1/2^i) * load_n-1
> > > + * = A * load[i]_n-1 + B ; A := (1 - 1/2^i), B := (1/2^i) * 
> > > load
> > > + * = A * (A * load[i]_n-2 + B) + B
> > > + * = A * (A * (A * load[i]_n-3 + B) + B) + B
> > > + * = A^3 * load[i]_n-3 + (A^2 + A + 1) * B
> > > + * = A^n * load[i]_0 + (A^(n-1) + A^(n-2) + ... + 1) * B
> > > + * = A^n * load[i]_0 + ((1 - A^n) / (1 - A)) * B
> > > + * = (1 - 1/2^i)^n * (load[i]_0 - load) + load
> 
> That is the same logic, right?

Yes, absolutely same logic.

Thanks a lot,
byungchul

> 
> Please be more specific as to what you'd like restored.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 6/6] vfio: platform: move get/put reset at open/release

2015-10-22 Thread Arnd Bergmann
On Thursday 22 October 2015 11:42:02 Eric Auger wrote:
> Currently reset lookup is done on probe. This introduces a
> race with new registration mechanism in the case where the
> vfio-platform driver is bound to the device before its module
> is loaded: on the load, the probe happens which triggers the
> reset module load which itself attempts to get the symbol for
> the registration function (vfio_platform_register_reset). The
> symbol is not yet available hence the lookup fails. In case we
> do the lookup in the first open we are sure the vfio-platform
> module is loaded and vfio_platform_register_reset is available.
> 
> Signed-off-by: Eric Auger 

I don't understand the explanation. I would expect the request_module()
call to block until the module is actually loaded. Is this not
what happens?

> mutex_unlock(&driver_lock);
> @@ -181,6 +182,8 @@ static int vfio_platform_open(void *device_data)
> if (ret)
> goto err_irq;
>  
> +   vfio_platform_get_reset(vdev);
> +
> if (vdev->reset)
> vdev->reset(vdev);
> 

This needs some error handling to ensure that the open() fails
if there is no reset handler.

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


Re: [PATCH] printk: Don't discard earlier unprinted messages to make space

2015-10-22 Thread David Woodhouse
On Thu, 2015-10-22 at 11:16 +0100, David Howells wrote:
> printk() currently discards earlier messages to make space for new messages
> arriving.  This has the distinct downside that if the kernel starts
> churning out messages because of some initial incident, the report of the
> initial incident is likely to be lost under a blizzard of:
> 
> ** NNN printk messages dropped **
> 
> messages from console_unlock().
> 
> The first message generated (typically an oops) is usually the most
> important - the one you want to solve first - so we really want to see
> that.

But wait... didn't I watch you muttering on IRC about the actual bug
you were trying to catch here... and didn't you have a *serial* console
hooked up?

What broke such that serial console stopped giving you *every* message?

Serial console was always *synchronous*.

We could do stuff like...

   printk("Going to do foo...\n");
   outb(foo, baz);
   printk("Did foo and the machine didn't catch fire! Now bar\n");
   outb(bar, baz);
   printk("Done\n");

And with a serial console I could know *precisely* the point at which
the machine locked up.

And I could enable the silly debugging levels on things like JFFS2 and
be sure that with a serial console I could catch *every* printk
reliably — which led to a number of cases where people would reproduce
a bug with a serial console and debugging, mail me a huge log file, and
get a patch back in reply.

We *need* to have a mode where serial console is actually *reliable*,
and we can know that the message has been sent out the port before the
printk() call returns.

What happened to it? And how do we fix it?

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature


Re: Problem about CPU stalling in hrtimer_intterrupts()

2015-10-22 Thread Thomas Gleixner
On Thu, 22 Oct 2015, Ding Tianhong wrote:
> On 2015/10/22 15:43, Thomas Gleixner wrote:
> >> Jan 01 00:03:32 Linux kernel: i:0 basenow.tv64:4809284991830
> >> hrtimer_get_softexpires_tv64(timer):444012000 ccpu0
> >> timer:ffdffdec6138, timer->function:ffc000129b84
> >> Jan 01 00:03:32 Linux kernel: i:0 basenow.tv64:4809284991830
> >> hrtimer_get_softexpires_tv64(timer):444012000 ccpu0

> This problem could only occur on the system with 32 cores, when I
> cut the cores to 16, this problem disappeared, so I think there is
> some parallel problem when the 32 core set clock time together:

> I try to reproduce the scene:
> 
> 1.do_settimeofday64
> 2.update tk time
> 3.update base time offset
> 4.update expires_next
> 
> the 3 and 4 will be called in softirq, but the hrtimer_interrupt may
> break the order and run before 3, I am not sure whether this could
> make the problem, do we need to update base time and expires_next in
> the hrtimer_interrupt?  maybe I miss something, thanks for any
> suggestion.

Base offset is updated in hrtimer_interrupt as
well. hrtimer_update_base() does that. So that's not the problem.

Can you apply the patch below and enable the hrtimer tracepoints and
collect trace data across the point where the problem happens?

Thanks,

tglx


diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 44d2cc0436f4..614f8d272cb0 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -575,8 +575,14 @@ static void timekeeping_update(struct timekeeper *tk, 
unsigned int action)
update_fast_timekeeper(&tk->tkr_mono, &tk_fast_mono);
update_fast_timekeeper(&tk->tkr_raw,  &tk_fast_raw);
 
-   if (action & TK_CLOCK_WAS_SET)
+   if (action & TK_CLOCK_WAS_SET) {
tk->clock_was_set_seq++;
+   trace_printk("TK: Seq: %u R: %lld B: %lld T: %lld\n",
+tk->clock_was_set_seq,
+tk->offs_real,
+tk->offs_boot,
+tk->offs_tai);
+   }
/*
 * The mirroring of the data to the shadow-timekeeper needs
 * to happen last here to ensure we don't over-write the
@@ -1954,6 +1960,11 @@ ktime_t ktime_get_update_offsets_now(unsigned int 
*cwsseq, ktime_t *offs_real,
base = ktime_add_ns(base, nsecs);
 
if (*cwsseq != tk->clock_was_set_seq) {
+   trace_printk("HR: Seq: %u R: %lld B: %lld T: %lld\n",
+tk->clock_was_set_seq,
+tk->offs_real,
+tk->offs_boot,
+tk->offs_tai);
*cwsseq = tk->clock_was_set_seq;
*offs_real = tk->offs_real;
*offs_boot = tk->offs_boot;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] soc: qcom: Introduce WCNSS_CTRL SMD client

2015-10-22 Thread yfw

Hi Bjorn,

On 2015/9/22 1:52, Bjorn Andersson wrote:

The WCNSS_CTRL SMD client is used for among other things upload nv
firmware to a newly booted WCNSS chip.

Signed-off-by: Bjorn Andersson 
---
This driver probes on the WCNSS_CTRL SMD channel as it comes up upon loading
the wcnss firmware, it currenly request version information from the wcnss and
downloads the nv binary.

This is needed for bringing up the individual functions of the wcnss chip.

  drivers/soc/qcom/Kconfig  |   7 ++
  drivers/soc/qcom/Makefile |   1 +
  drivers/soc/qcom/wcnss_ctrl.c | 272 ++
  3 files changed, 280 insertions(+)
  create mode 100644 drivers/soc/qcom/wcnss_ctrl.c

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index ba47b70f4d85..453ceb1af682 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -48,3 +48,10 @@ config QCOM_SMEM
  Say y here to enable support for the Qualcomm Shared Memory Manager.
  The driver provides an interface to items in a heap shared among all
  processors in a Qualcomm platform.
+
+config QCOM_WCNSS_CTRL
+   tristate "Qualcomm WCNSS control driver"
+   depends on QCOM_SMD
+   help
+ Client driver for the WCNSS_CTRL SMD channel, used to download nv
+ firmware to a newly booted WCNSS chip.
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 10a93d168e0e..9823103ea843 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_QCOM_PM)   +=  spm.o
  obj-$(CONFIG_QCOM_SMD) += smd.o
  obj-$(CONFIG_QCOM_SMD_RPM)+= smd-rpm.o
  obj-$(CONFIG_QCOM_SMEM) +=smem.o
+obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
diff --git a/drivers/soc/qcom/wcnss_ctrl.c b/drivers/soc/qcom/wcnss_ctrl.c
new file mode 100644
index ..7a986f881d5c
--- /dev/null
+++ b/drivers/soc/qcom/wcnss_ctrl.c
@@ -0,0 +1,272 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 
+
+#define WCNSS_REQUEST_TIMEOUT  (5 * HZ)
+
+#define NV_FRAGMENT_SIZE   3072
+#define NVBIN_FILE "wlan/prima/WCNSS_qcom_wlan_nv.bin"
+
+/**
+ * struct wcnss_ctrl - driver context
+ * @dev:   device handle
+ * @channel:   SMD channel handle
+ * @ack:   completion for outstanding requests
+ * @ack_status:status of the outstanding request
+ * @download_nv_work: worker for uploading nv binary
+ */
+struct wcnss_ctrl {
+   struct device *dev;
+   struct qcom_smd_channel *channel;
+
+   struct completion ack;
+   int ack_status;
+
+   struct work_struct download_nv_work;
+};
+
+/* message types */
+enum {
+   WCNSS_VERSION_REQ = 0x0100,
+   WCNSS_VERSION_RESP,
+   WCNSS_DOWNLOAD_NV_REQ,
+   WCNSS_DOWNLOAD_NV_RESP,
+   WCNSS_UPLOAD_CAL_REQ,
+   WCNSS_UPLOAD_CAL_RESP,
+   WCNSS_DOWNLOAD_CAL_REQ,
+   WCNSS_DOWNLOAD_CAL_RESP,
+};
+
+/**
+ * struct wcnss_msg_hdr - common packet header for requests and responses
+ * @type:  packet message type
+ * @len:   total length of the packet, including this header
+ */
+struct wcnss_msg_hdr {
+   u32 type;
+   u32 len;
+} __packed;
+
+/**
+ * struct wcnss_version_resp - version request response
+ * @hdr:   common packet wcnss_msg_hdr header
+ */
+struct wcnss_version_resp {
+   struct wcnss_msg_hdr hdr;
+   u8 major;
+   u8 minor;
+   u8 version;
+   u8 revision;
+} __packed;
+
+/**
+ * struct wcnss_download_nv_req - firmware fragment request
+ * @hdr:   common packet wcnss_msg_hdr header
+ * @seq:   sequence number of this fragment
+ * @last:  boolean indicator of this being the last fragment of the binary
+ * @frag_size: length of this fragment
+ * @fragment:  fragment data
+ */
+struct wcnss_download_nv_req {
+   struct wcnss_msg_hdr hdr;
+   u16 seq;
+   u16 last;
+   u32 frag_size;
+   u8 fragment[];
+} __packed;
+
+/**
+ * struct wcnss_download_nv_resp - firmware download response
+ * @hdr:   common packet wcnss_msg_hdr header
+ * @status:boolean to indicate success of the download
+ */
+struct wcnss_download_nv_resp {
+   struct wcnss_msg_hdr hdr;
+   u8 status;
+} __packed;
+
+/**
+ * wcnss_ctrl_smd_callback() - handler from SMD responses
+ * @qsdev: smd device handle
+ * @data:  pointer to the incoming data packet
+ * @count: size of the incoming data packet
+ *
+ * Handles any incoming packets from the remote W

[PATCH 3/3] f2fs: fix to skip shrinking extent nodes

2015-10-22 Thread Chao Yu
In f2fs_shrink_extent_tree we should stop shrink flow if we have already
shrunk enough nodes in extent cache.

Signed-off-by: Chao Yu 
---
 fs/f2fs/extent_cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
index a38ee9b..7ddba81 100644
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -620,7 +620,7 @@ unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info 
*sbi, int nr_shrink)
write_unlock(&et->lock);
 
if (node_cnt + tree_cnt >= nr_shrink)
-   break;
+   goto unlock_out;
}
}
 unlock_out:
-- 
2.6.1


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


Re: [PATCH v6 05/11] block: remove split code in blkdev_issue_{discard,write_same}

2015-10-22 Thread Christoph Hellwig
On Wed, Oct 21, 2015 at 01:13:09PM -0700, Ming Lin wrote:
> How about below?
> It actually reverts commit b49a0871 and adds patch at
> https://www.redhat.com/archives/dm-devel/2015-August/msg0.html
> 
> Christoph, could you help to try it?

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


[PATCH 2/3] f2fs: fix error path of ->symlink

2015-10-22 Thread Chao Yu
Now, in ->symlink of f2fs, we kept the fixed invoking order between
f2fs_add_link and page_symlink since we should init node info firstly
in f2fs_add_link, then such node info can be used in page_symlink.

But we didn't fix to release meta info which was done before page_symlink
in our error path, so this will leave us corrupt symlink entry in its
parent's dentry page. Fix this issue by adding f2fs_unlink in the error
path for removing such linking.

Signed-off-by: Chao Yu 
---
 fs/f2fs/namei.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index dfa01c8..e48b80c 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -410,11 +410,14 @@ err_out:
 * If the symlink path is stored into inline_data, there is no
 * performance regression.
 */
-   if (!err)
+   if (!err) {
filemap_write_and_wait_range(inode->i_mapping, 0, p_len - 1);
 
-   if (IS_DIRSYNC(dir))
-   f2fs_sync_fs(sbi->sb, 1);
+   if (IS_DIRSYNC(dir))
+   f2fs_sync_fs(sbi->sb, 1);
+   } else {
+   f2fs_unlink(dir, dentry);
+   }
 
kfree(sd);
f2fs_fname_crypto_free_buffer(&disk_link);
-- 
2.6.1


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


Re: [PATCH v2 5/6] vfio: platform: use list of registered reset function

2015-10-22 Thread Arnd Bergmann
On Thursday 22 October 2015 11:42:01 Eric Auger wrote:
> Remove the static lookup table and use the dynamic list of registered
> reset functions instead. Also load the reset module through its alias.
> The reset struct module pointer is stored in vfio_platform_device.
> 
> We also remove the useless struct device pointer parameter in
> vfio_platform_get_reset.
> 
> This patch fixes the issue related to the usage of __symbol_get, which
> besides from being moot, prevented compilation with CONFIG_MODULES
> disabled.
> 
> Also usage of MODULE_ALIAS makes possible to add a new reset module
> without needing to update the framework. This was suggested by Arnd.
> 
> Signed-off-by: Eric Auger 
> Reported-by: Arnd Bergmann 

Looks good, just small style issues:

> 
> - }
> + mutex_lock(&reset_lock);
> + list_for_each_entry(iter, &reset_list, link) {
> + if (!strcmp(iter->compat, compat) &&
> + try_module_get(iter->owner)) {
> + *module = iter->owner;
> + mutex_unlock(&reset_lock);
> + return iter->reset;
>   }
>   }
> +
> + mutex_unlock(&reset_lock);
> + return NULL;

Better use 'break' to have a single mutex_unlock and return  statement.

> +
>  
>  static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
>  {
> - if (vdev->reset)
> - symbol_put_addr(vdev->reset);
> + if (vdev->reset) {
> + module_put(vdev->reset_module);
> + vdev->reset_module = NULL;
> + vdev->reset = NULL;
> + }
>  }

This gets called from the remove callback. No need to clear those
struct members immediately before the kfree().

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


Re: [PATCH v2 2/2] dmaengine: hdmac: Add scatter-gathered memset support

2015-10-22 Thread Nicolas Ferre
Le 22/10/2015 11:41, Maxime Ripard a écrit :
> Just like memset support, the HDMAC might be used to do a memset over a
> discontiguous memory area.
> 
> In such a case, we'll just build up a chain of memset descriptors over the
> contiguous chunks of memory to set, in order to allow such a support.
> 
> Signed-off-by: Maxime Ripard 

Yep, seems good!
Acked-by: Nicolas Ferre 

Thanks Maxime, bye.


> ---
>  drivers/dma/at_hdmac.c | 79 
> ++
>  1 file changed, 79 insertions(+)
> 
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index cad18f3660ae..4e55239c7a30 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -986,6 +986,83 @@ err_free_buffer:
>   return NULL;
>  }
>  
> +static struct dma_async_tx_descriptor *
> +atc_prep_dma_memset_sg(struct dma_chan *chan,
> +struct scatterlist *sgl,
> +unsigned int sg_len, int value,
> +unsigned long flags)
> +{
> + struct at_dma_chan  *atchan = to_at_dma_chan(chan);
> + struct at_dma   *atdma = to_at_dma(chan->device);
> + struct at_desc  *desc = NULL, *first = NULL, *prev = NULL;
> + struct scatterlist  *sg;
> + void __iomem*vaddr;
> + dma_addr_t  paddr;
> + size_t  total_len = 0;
> + int i;
> +
> + dev_vdbg(chan2dev(chan), "%s: v0x%x l0x%zx f0x%lx\n", __func__,
> +  value, sg_len, flags);
> +
> + if (unlikely(!sgl || !sg_len)) {
> + dev_dbg(chan2dev(chan), "%s: scatterlist is empty!\n",
> + __func__);
> + return NULL;
> + }
> +
> + vaddr = dma_pool_alloc(atdma->memset_pool, GFP_ATOMIC, &paddr);
> + if (!vaddr) {
> + dev_err(chan2dev(chan), "%s: couldn't allocate buffer\n",
> + __func__);
> + return NULL;
> + }
> + *(u32*)vaddr = value;
> +
> + for_each_sg(sgl, sg, sg_len, i) {
> + dma_addr_t dest = sg_dma_address(sg);
> + size_t len = sg_dma_len(sg);
> +
> + dev_vdbg(chan2dev(chan), "%s: d0x%08x, l0x%zx\n",
> +  __func__, dest, len);
> +
> + if (!is_dma_fill_aligned(chan->device, dest, 0, len)) {
> + dev_err(chan2dev(chan), "%s: buffer is not aligned\n",
> + __func__);
> + goto err_put_desc;
> + }
> +
> + desc = atc_create_memset_desc(chan, paddr, dest, len);
> + if (!desc)
> + goto err_put_desc;
> +
> + atc_desc_chain(&first, &prev, desc);
> +
> + total_len += len;
> + }
> +
> + /*
> +  * Only set the buffer pointers on the last descriptor to
> +  * avoid free'ing while we have our transfer still going
> +  */
> + desc->memset_paddr = paddr;
> + desc->memset_vaddr = vaddr;
> + desc->memset_buffer = true;
> +
> + first->txd.cookie = -EBUSY;
> + first->total_len = total_len;
> +
> + /* set end-of-link on the descriptor */
> + set_desc_eol(desc);
> +
> + first->txd.flags = flags;
> +
> + return &first->txd;
> +
> +err_put_desc:
> + atc_desc_put(atchan, first);
> + return NULL;
> +}
> +
>  /**
>   * atc_prep_slave_sg - prepare descriptors for a DMA_SLAVE transaction
>   * @chan: DMA channel
> @@ -1868,6 +1945,7 @@ static int __init at_dma_probe(struct platform_device 
> *pdev)
>   dma_cap_set(DMA_INTERLEAVE, at91sam9g45_config.cap_mask);
>   dma_cap_set(DMA_MEMCPY, at91sam9g45_config.cap_mask);
>   dma_cap_set(DMA_MEMSET, at91sam9g45_config.cap_mask);
> + dma_cap_set(DMA_MEMSET_SG, at91sam9g45_config.cap_mask);
>   dma_cap_set(DMA_PRIVATE, at91sam9g45_config.cap_mask);
>   dma_cap_set(DMA_SLAVE, at91sam9g45_config.cap_mask);
>   dma_cap_set(DMA_SG, at91sam9g45_config.cap_mask);
> @@ -1989,6 +2067,7 @@ static int __init at_dma_probe(struct platform_device 
> *pdev)
>  
>   if (dma_has_cap(DMA_MEMSET, atdma->dma_common.cap_mask)) {
>   atdma->dma_common.device_prep_dma_memset = atc_prep_dma_memset;
> + atdma->dma_common.device_prep_dma_memset_sg = 
> atc_prep_dma_memset_sg;
>   atdma->dma_common.fill_align = DMAENGINE_ALIGN_4_BYTES;
>   }
>  
> 


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


[PATCH 1/3] f2fs: fix to clear GCed flag for atomic written page

2015-10-22 Thread Chao Yu
Atomic write page can be GCed, after committing this kind of page, we should
clear the GCed flag for it.

Signed-off-by: Chao Yu 
---
 fs/f2fs/segment.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 7efd96ad..f77b325 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -253,6 +253,7 @@ int commit_inmem_pages(struct inode *inode, bool abort)
unlock_page(cur->page);
break;
}
+   clear_cold_data(cur->page);
submit_bio = true;
}
} else {
-- 
2.6.1


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


[PATCH] printk: Don't discard earlier unprinted messages to make space

2015-10-22 Thread David Howells
printk() currently discards earlier messages to make space for new messages
arriving.  This has the distinct downside that if the kernel starts
churning out messages because of some initial incident, the report of the
initial incident is likely to be lost under a blizzard of:

** NNN printk messages dropped **

messages from console_unlock().

The first message generated (typically an oops) is usually the most
important - the one you want to solve first - so we really want to see
that.

To this end, change log_store() to only write a message into the buffer if
there is sufficient space to hold that message.  The message may be
truncated if it will then fit.

This patch could be improved by noting that some messages got discarded
when next there is space to do so.

Signed-off-by: David Howells 
---

 kernel/printk/printk.c |   96 ++--
 1 file changed, 35 insertions(+), 61 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8f0324ef72ab..c2099ede0bc8 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -336,48 +337,6 @@ static u32 log_next(u32 idx)
return idx + msg->len;
 }
 
-/*
- * Check whether there is enough free space for the given message.
- *
- * The same values of first_idx and next_idx mean that the buffer
- * is either empty or full.
- *
- * If the buffer is empty, we must respect the position of the indexes.
- * They cannot be reset to the beginning of the buffer.
- */
-static int logbuf_has_space(u32 msg_size, bool empty)
-{
-   u32 free;
-
-   if (log_next_idx > log_first_idx || empty)
-   free = max(log_buf_len - log_next_idx, log_first_idx);
-   else
-   free = log_first_idx - log_next_idx;
-
-   /*
-* We need space also for an empty header that signalizes wrapping
-* of the buffer.
-*/
-   return free >= msg_size + sizeof(struct printk_log);
-}
-
-static int log_make_free_space(u32 msg_size)
-{
-   while (log_first_seq < log_next_seq) {
-   if (logbuf_has_space(msg_size, false))
-   return 0;
-   /* drop old messages until we have enough contiguous space */
-   log_first_idx = log_next(log_first_idx);
-   log_first_seq++;
-   }
-
-   /* sequence numbers are equal, so the log buffer is empty */
-   if (logbuf_has_space(msg_size, true))
-   return 0;
-
-   return -ENOMEM;
-}
-
 /* compute the message size including the padding bytes */
 static u32 msg_used_size(u16 text_len, u16 dict_len, u32 *pad_len)
 {
@@ -423,32 +382,47 @@ static int log_store(int facility, int level,
 const char *text, u16 text_len)
 {
struct printk_log *msg;
-   u32 size, pad_len;
+   u32 size, wsize, pad_len;
u16 trunc_msg_len = 0;
 
/* number of '\0' padding bytes to next message */
size = msg_used_size(text_len, dict_len, &pad_len);
 
-   if (log_make_free_space(size)) {
-   /* truncate the message if it is too long for empty buffer */
-   size = truncate_msg(&text_len, &trunc_msg_len,
-   &dict_len, &pad_len);
-   /* survive when the log buffer is too small for trunc_msg */
-   if (log_make_free_space(size))
-   return 0;
-   }
+   /* See if we have sufficient space to insert a message.  Note we also
+* need to keep a gap right at the end of the buffer to insert a 'wrap
+* here' marker.
+*/
+   wsize = size + sizeof(struct printk_log);
 
-   if (log_next_idx + size + sizeof(struct printk_log) > log_buf_len) {
-   /*
-* This message + an additional empty header does not fit
-* at the end of the buffer. Add an empty header with len == 0
-* to signify a wrap around.
-*/
-   memset(log_buf + log_next_idx, 0, sizeof(struct printk_log));
-   log_next_idx = 0;
-   }
+   if (log_first_seq != log_next_seq && log_first_idx == log_next_idx)
+   return 0; /* Buffer is completely full */
+
+   if (CIRC_SPACE_TO_END(log_next_idx, log_first_idx, log_buf_len) >= 
wsize)
+   goto have_space_no_wrap;
+
+   if (CIRC_SPACE(log_next_idx, log_first_idx, log_buf_len) >= size)
+   goto have_space_wrap;
+
+   /* Try to truncate the message. */
+   size = truncate_msg(&text_len, &trunc_msg_len, &dict_len, &pad_len);
+   wsize = size + sizeof(struct printk_log);
+
+   if (CIRC_SPACE_TO_END(log_next_idx, log_first_idx, log_buf_len) >= 
wsize)
+   goto have_space_no_wrap;
+
+   if (CIRC_SPACE(log_next_idx, log_first_idx, log_buf_len) < size)
+   return 0;
+
+have_space_wrap:
+   /* This message plus an addi

Re: [PATCH] x86/spinlocks: Avoid a deadlock when someone unlock a zapped ticked spinlock

2015-10-22 Thread Peter Zijlstra
On Thu, Oct 22, 2015 at 11:39:38AM +0200, Petr Mladek wrote:
> Maybe, we could add support to use early console in case of Oops and
> panic. But we should not do this by default. It would help, especially
> when the problem is reproducible and we get stacked with the normal
> console.

What I typically do is route everything to 8250 early console and rip
out everything printk buffer nonsense.

That gets you a fairly reliable console, no locking, only vscnprintf()
and OUTB banging.

No printk() wanting to do wakeups and other such nonsense that doesn't
work.

I appreciate that might not be for everybody, but it also shouldn't be
this hard to get something reliable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 1/2] dmaengine: hdmac: factorise memset descriptor allocation

2015-10-22 Thread Nicolas Ferre
Le 22/10/2015 11:40, Maxime Ripard a écrit :
> The memset and scatter gathered memset are going to use some common logic
> to create their descriptors.
> 
> Move that logic into a function of its own so that we can share it with the
> future memset_sg callback.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/dma/at_hdmac.c  | 97 
> ++---
>  drivers/dma/at_hdmac_regs.h |  2 +-
>  2 files changed, 58 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index 58d406230d89..cad18f3660ae 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -458,10 +458,10 @@ atc_chain_complete(struct at_dma_chan *atchan, struct 
> at_desc *desc)
>   dma_cookie_complete(txd);
>  
>   /* If the transfer was a memset, free our temporary buffer */
> - if (desc->memset) {
> + if (desc->memset_buffer) {
>   dma_pool_free(atdma->memset_pool, desc->memset_vaddr,
> desc->memset_paddr);
> - desc->memset = false;
> + desc->memset_buffer = false;
>   }
>  
>   /* move children to free_list */
> @@ -881,6 +881,46 @@ err_desc_get:
>   return NULL;
>  }
>  
> +static struct at_desc *atc_create_memset_desc(struct dma_chan *chan,
> +   dma_addr_t psrc,
> +   dma_addr_t pdst,
> +   size_t len)
> +{
> + struct at_dma_chan *atchan = to_at_dma_chan(chan);
> + struct at_desc *desc;
> + size_t xfer_count;
> +
> + u32 ctrla = ATC_SRC_WIDTH(2) | ATC_DST_WIDTH(2);
> + u32 ctrlb = ATC_DEFAULT_CTRLB | ATC_IEN |
> + ATC_SRC_ADDR_MODE_FIXED |
> + ATC_DST_ADDR_MODE_INCR |
> + ATC_FC_MEM2MEM;
> +
> + xfer_count = len >> 2;
> + if (xfer_count > ATC_BTSIZE_MAX) {
> + dev_err(chan2dev(chan), "%s: buffer is too big\n",
> + __func__);
> + return NULL;
> + }
> +
> + desc = atc_desc_get(atchan);
> + if (!desc) {
> + dev_err(chan2dev(chan), "%s: can't get a descriptor\n",
> + __func__);
> + return NULL;
> + }
> +
> + desc->lli.saddr = psrc;
> + desc->lli.daddr = pdst;
> + desc->lli.ctrla = ctrla | xfer_count;
> + desc->lli.ctrlb = ctrlb;
> +
> + desc->txd.cookie = 0;
> + desc->len = len;
> +
> + return desc;
> +}
> +
>  /**
>   * atc_prep_dma_memset - prepare a memcpy operation
>   * @chan: the channel to prepare operation on
> @@ -893,12 +933,10 @@ static struct dma_async_tx_descriptor *
>  atc_prep_dma_memset(struct dma_chan *chan, dma_addr_t dest, int value,
>   size_t len, unsigned long flags)
>  {
> - struct at_dma_chan  *atchan = to_at_dma_chan(chan);
>   struct at_dma   *atdma = to_at_dma(chan->device);
> - struct at_desc  *desc = NULL;
> - size_t  xfer_count;
> - u32 ctrla;
> - u32 ctrlb;
> + struct at_desc  *desc;
> + void __iomem*vaddr;
> + dma_addr_t  paddr;
>  
>   dev_vdbg(chan2dev(chan), "%s: d0x%x v0x%x l0x%zx f0x%lx\n", __func__,
>   dest, value, len, flags);
> @@ -914,46 +952,26 @@ atc_prep_dma_memset(struct dma_chan *chan, dma_addr_t 
> dest, int value,
>   return NULL;
>   }
>  
> - xfer_count = len >> 2;
> - if (xfer_count > ATC_BTSIZE_MAX) {
> - dev_err(chan2dev(chan), "%s: buffer is too big\n",
> + vaddr = dma_pool_alloc(atdma->memset_pool, GFP_ATOMIC, &paddr);
> + if (!vaddr) {
> + dev_err(chan2dev(chan), "%s: couldn't allocate buffer\n",
>   __func__);
>   return NULL;
>   }
> + *(u32*)vaddr = value;
>  
> - ctrlb =   ATC_DEFAULT_CTRLB | ATC_IEN
> - | ATC_SRC_ADDR_MODE_FIXED
> - | ATC_DST_ADDR_MODE_INCR
> - | ATC_FC_MEM2MEM;
> -
> - ctrla = ATC_SRC_WIDTH(2) |
> - ATC_DST_WIDTH(2);
> -
> - desc = atc_desc_get(atchan);
> + desc = atc_create_memset_desc(chan, paddr, dest, len);
>   if (!desc) {
> - dev_err(chan2dev(chan), "%s: can't get a descriptor\n",
> + dev_err(chan2dev(chan), "%s: couldn't get a descriptor\n",
>   __func__);

Nitpicking: as you already have a dev_err() for each error possible in
the called function, you wouldn't need more log hereunder...

otherwise, I'm okay:
Acked-by: Nicolas Ferre 


> - return NULL;
> + goto err_free_buffer;
>   }
>  
> - desc->memset_vaddr = dma_pool_alloc(atdma->memset_pool, GFP_ATOMIC,
> - &desc->memset_paddr);
> - if (!desc->memset_vaddr) {
> - dev_err(chan2dev(chan), "%s: couldn't allocate buffer\n",
> -

Re: [PATCH v2 2/6] vfio: platform: reset: add vfio_platform_reset_private.h

2015-10-22 Thread Arnd Bergmann
On Thursday 22 October 2015 11:41:58 Eric Auger wrote:
> v2: creation
> - this defines the module_vfio_reset_handler macro as suggested by Arnd
> 
> Although Arnd suggested me to remove the vfio_platform_register_reset
> symbol_get (since the module manager can handle the case where the
> vfio-platform driver is not loaded), I prefered to keep it while
> introducing the macro. The rationale is, when using symbol_get/put
> we are able to release the hold from the reset module on vfio-platform
> as soon as the registration is complete and I think this makes sense.

This makes it highly unusual. I can't think of a good reason to allow
unloading the vfio platform module while a reset module is registered,
that just causes a memory leak (or possibly a crash) when you do
unload the core module while it's used by a reset driver, it
prevents the reset module from getting loaded without loading the
vfio module first (because the autoloading doesn't work), and it
means we don't catch build errors in invalid configurations where you
have only the reset driver but not the vfio driver enabled.

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


Re: [PATCH v2 3/6] vfio: platform: reset: calxedaxgmac: add reset function registration

2015-10-22 Thread Arnd Bergmann
On Thursday 22 October 2015 11:41:59 Eric Auger wrote:
> This patch adds the reset function registration/unregistration.
> 
> Signed-off-by: Eric Auger 

Looks good, except one thing:
> @@ -70,6 +69,8 @@ int vfio_platform_calxedaxgmac_reset(struct 
> vfio_platform_device *vdev)
>   return -ENOMEM;
>   }
>  
> + pr_info("VFIO reset of %s\n", vdev->name);
> +
>   /* disable IRQ */
>   writel(0, reg.ioaddr + XGMAC_DMA_INTR_ENA);
>  

This probably slipped in from debugging, please remove it.

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


Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

2015-10-22 Thread Marek Szyprowski

Hello,

On 2015-10-22 06:14, Alim Akhtar wrote:

CCing Doug, Heiko and Enric Balletbo
To help us by testing on rk3288-veyron and am335x-sl50 boards.

On 10/22/2015 08:22 AM, Javier Martinez Canillas wrote:

Hello Krzysztof,

On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote:

On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof,


Thanks for your feedback.

On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote:

On 22.10.2015 00:15, Javier Martinez Canillas wrote:
The pwrseq_emmc driver does a eMMC card reset before a system 
reboot to
allow broken or limited ROM boot-loaders (that don't have an eMMC 
reset

logic) to be able to read the second stage from the eMMC.

But this has to be called before a system reboot handler and 
while most
of them use the priority 128, there are other restart handlers 
(such as
the syscon-reboot one) that use a higher priority. So, use the 
highest
priority to make sure that the eMMC hw is reset before a system 
reboot.


Signed-off-by: Javier Martinez Canillas 
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
Reviewed-by: Alim Akhtar 

---
Hello,

This patch was needed since a recent series from Alim [0] added
syscon reboot and poweroff support to Exynos SoCs and removed
the reset handler in the Exynos Power Management Unit (PMU) code.

But the PMU and syscon-reboot restart handler have a different
priority so [0] breaks restart when eMMC is used on these boards.

[0]: http://www.spinics.net/lists/arm-kernel/msg454396.html

So this patch must be merged before [0] to avoid regressions.

Best regards,
Javier

  drivers/mmc/core/pwrseq_emmc.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/pwrseq_emmc.c 
b/drivers/mmc/core/pwrseq_emmc.c

index 137c97fb7aa8..ad4f94ec7e8d 100644
--- a/drivers/mmc/core/pwrseq_emmc.c
+++ b/drivers/mmc/core/pwrseq_emmc.c
@@ -84,11 +84,11 @@ struct mmc_pwrseq 
*mmc_pwrseq_emmc_alloc(struct mmc_host *host,


  /*
   * register reset handler to ensure emmc reset also from
- * emergency_reboot(), priority 129 schedules it just before
- * system reboot
+ * emergency_reboot(), priority 255 is the highest priority
+ * so it will be executed before any system reboot handler.
   */
  pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb;
-pwrseq->reset_nb.priority = 129;
+pwrseq->reset_nb.priority = 255;


I see the problem which you are trying to solve but this may be 
tricker

then just kicking the number. Some of restart handlers are registered
with priority 192. I found few of such, like: at91_restart_nb,
zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep 
too

much).



Yes, the syscon-reboot restart handler also uses a priority 192 and 
that
is why reboot with eMMC broke with Alim's patches since the PMU 
restart

handler priority is 128.


I guess they chose the "192" priority on purpose.



I tried to understand what's the policy w.r.t priority numbering for
restart handlers but only found this in the register_restart_handler
kernel-doc [0]:

/**
  *register_restart_handler - Register function to be called to 
reset

  *   the system
  *@nb: Info about handler function to be called
  *@nb->priority:Handler priority. Handlers should follow the
  *following guidelines for setting priorities.
  *0:Restart handler of last resort,
  *with limited restart capabilities
  *128:Default restart handler; use if no other
  *restart handler is expected to be available,
  *and/or if restart functionality is
  *sufficient to restart the entire system
  *255:Highest priority restart handler, will
  *preempt all other restart handlers

So, reading that is not clear to me if only the values 0, 128 and 255
should be used or any value from 0-255.

What's clear to me is that restart handlers to reset a specific hw 
block
should be called before the restart handler that resets the whole 
system.


The 192 seems to be used because there are other default restart 
handlers
that are using a prio of 128. See for example the commit that 
changed the

syscon-reboot prio from 128 to 192:

b81180b3fd48 power: reset: adjust priority of simple syscon reboot 
driver


But were are here not talking about syscon handler but the others. Now
you will be ahead of them.



Yes, I know that. My point was that the platforms were either not 
using the
mmc-pwrseq-emmc or their system restart handler already had a lower 
priority

but that is not true for at least rk3288-veyron as you said.



So probably the 192 value was chosen because is in the middle of 
128 and
255 but it seems to me a rather arbitrary value and I would prefer 
it to

be documented in some place.


Effectively, now the emmc handler will be executed before their
handlers... is it an issue? Maybe some testing on these platforms is
necessa

Re: [PATCH v2 1/6] vfio: platform: add capability to register a reset function

2015-10-22 Thread Arnd Bergmann
On Thursday 22 October 2015 11:41:57 Eric Auger wrote:
> In preparation for subsequent changes in reset function lookup,
> lets introduce a dynamic list of reset combos (compat string,
> reset module, reset function). The list can be populated/voided with
> two new functions, vfio_platform_register/unregister_reset. Those are
> not yet used in this patch.
> 
> Signed-off-by: Eric Auger 

Looks correct to me now, just a little style comments.

>  drivers/vfio/platform/vfio_platform_common.c  | 77 
> +++
>  drivers/vfio/platform/vfio_platform_private.h |  7 +++
>  2 files changed, 84 insertions(+)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index e43efb5..52a4c7b 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -23,6 +23,15 @@
>  
>  #include "vfio_platform_private.h"
>  
> +struct vfio_platform_reset_node {
> + struct list_head link;
> + char *compat;
> + struct module *owner;
> + vfio_platform_reset_fn_t reset;
> +};
> +
> +static LIST_HEAD(reset_list);
> +static DEFINE_MUTEX(reset_lock);
>  static DEFINE_MUTEX(driver_lock);

I wonder if having a single mutex here would be enough. If you don't expect
drivers to register/unregister a lot, you could just use driver_lock here
as well.

>  static const struct vfio_platform_reset_combo reset_lookup_table[] = {
> @@ -573,3 +582,71 @@ struct vfio_platform_device 
> *vfio_platform_remove_common(struct device *dev)
>   return vdev;
>  }
>  EXPORT_SYMBOL_GPL(vfio_platform_remove_common);
> +
> +int vfio_platform_register_reset(struct module *reset_owner,
> +  const char *compat,
> +  vfio_platform_reset_fn_t reset)
> +{
> + struct vfio_platform_reset_node *node, *iter;
> + bool found = false;
> +
> + mutex_lock(&reset_lock);
> + list_for_each_entry(iter, &reset_list, link) {
> + if (!strcmp(iter->compat, compat)) {
> + found = true;
> + break;
> + }
> + }
> + if (found) {
> + mutex_unlock(&reset_lock);
> + return -EINVAL;
> + }

This seems to be an unnecesssary safeguard. I would not bother
with the search, or otherwise do a WARN_ON here.

> + node = kmalloc(sizeof(*node), GFP_KERNEL);
> + if (!node) {
> + mutex_unlock(&reset_lock);
> + return -ENOMEM;
> + }
> +
> + node->compat = kstrdup(compat, GFP_KERNEL);
> + if (!node->compat) {
> + kfree(node);
> + mutex_unlock(&reset_lock);
> + return -ENOMEM;
> + }

If you hold a lock, it's better to use a goto for handling errors
and put the unlock and kfree there. I think it can be avoided
entirely here though:

It should be safe to define the interface as keeping a reference
on the string and not do a kstrdup here. I would expect users to
pass a string literal.

We could even go as far as defining the entire interface as a shim,
like

#define vfio_platform_register_reset(__compat, __reset) \
static struct vfio_platform_reset_node __reset ## _node = { \
.owner = THIS_MODULE,   \
.compat = __compat, \
.reset = __reset,   \
};  \
__vfio_platform_register_reset(&__reset ## node);

to make the function really simple.

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


Re: [PATCH 1/2] can: xilinx: use readl/writel instead of ioread/iowrite

2015-10-22 Thread Michal Simek
On 10/22/2015 11:02 AM, Arnd Bergmann wrote:
> On Thursday 22 October 2015 08:34:53 Appana Durga Kedareswara Rao wrote:
>>> On Thursday 22 October 2015 10:16:02 Kedareswara rao Appana wrote:
 The driver only supports memory-mapped I/O [by ioremap()], so
 readl/writel is actually the right thing to do, IMO.
 During the validation of this driver or IP on ARM 64-bit processor
 while sending lot of packets observed that the tx packet drop with
 iowrite Putting the barriers for each tx fifo register write fixes
 this issue Instead of barriers using writel also fixed this issue.

 Signed-off-by: Kedareswara rao Appana 
>>>
>>> The two should really do the same thing: iowrite32() is just a static 
>>> inline calling
>>> writel() on both ARM32 and ARM64. On which kernel version did you observe 
>>> the
>>> difference? It's possible that an older version used CONFIG_GENERIC_IOMAP,
>>> which made this slightly more expensive.
>>
>> I observed this issue with the 4.0.0 kernel version
> 
> Is it possible that you have nonstandard patches on your kernel? If so, can
> you send a diff against the mainline version?

Kedar: Can you please retest this on mainline kernel?
We shouldn't have any patches which should influence this.

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


Re: [PATCH] mm: Introduce kernelcore=reliable option

2015-10-22 Thread Kamezawa Hiroyuki

On 2015/10/22 3:17, Luck, Tony wrote:

+   if (reliable_kernelcore) {
+   for_each_memblock(memory, r) {
+   if (memblock_is_mirror(r))
+   continue;

Should we have a safety check here that there is some mirrored memory?  If you 
give
the kernelcore=reliable option on a machine which doesn't have any mirror 
configured,
then we'll mark all memory as removable.


You're right.


What happens then?  Do kernel allocations fail?  Or do they fall back to using 
removable memory?


Maybe the kernel cannot boot because NORMAL zone is empty.


Is there a /proc or /sys file that shows the current counts for the removable 
zone?  I just
tried this patch with a high percentage of memory marked as mirror ... but I'd 
like to see
how much is actually being used to tune things a bit.



I think /proc/zoneinfo can show detailed numbers per zone. Do we need some for 
meminfo ?

Thanks,
-Kame


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


Re: [PATCHv12 14/37] futex, thp: remove special case for THP in get_futex_key

2015-10-22 Thread Kirill A. Shutemov
On Thu, Oct 22, 2015 at 10:24:33AM +0200, Artem Savkov wrote:
> On Tue, Oct 06, 2015 at 06:23:41PM +0300, Kirill A. Shutemov wrote:
> > With new THP refcounting, we don't need tricks to stabilize huge page.
> > If we've got reference to tail page, it can't split under us.
> > 
> > This patch effectively reverts a5b338f2b0b1.
> > 
> > Signed-off-by: Kirill A. Shutemov 
> > Tested-by: Sasha Levin 
> > Tested-by: Aneesh Kumar K.V 
> > Acked-by: Jerome Marchand 
> > ---
> >  kernel/futex.c | 61 
> > --
> >  1 file changed, 12 insertions(+), 49 deletions(-)
> 
> This patch breaks compound page futexes with the following panic:
> 
> [   33.465456] general protection fault:  [#1] SMP 
> [   33.465991] CPU: 1 PID: 523 Comm: tst Not tainted 4.3.0-rc6-next-20151022 
> #139
> [   33.466585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.7.5-20140709_153950- 04/01/2014
> [   33.467370] task: 88007bf13a80 ti: 88006bdac000 task.ti: 
> 88006bdac000
> [   33.467960] RIP: 0010:[]  [] 
> get_futex_key+0x2ba/0x410
> [   33.468332] RSP: 0018:88006bdafc18  EFLAGS: 00010202
> [   33.468332] RAX: dead RBX: ea0001a50040 RCX: 
> 0001
> [   33.468332] RDX: ea0001a50001 RSI:  RDI: 
> ea0001a50040
> [   33.468332] RBP: 88006bdafc58 R08:  R09: 
> 
> [   33.468332] R10:  R11: 0001 R12: 
> 7f4983601000
> [   33.468332] R13: 0001 R14: 88006bdafd70 R15: 
> 
> [   33.468332] FS:  7f4983fa4700() GS:88007fd0() 
> knlGS:
> [   33.468332] CS:  0010 DS:  ES:  CR0: 8005003b
> [   33.468332] CR2: 7f4983601000 CR3: 7becb000 CR4: 
> 06a0
> [   33.468332] Stack:
> [   33.468332]  88006bf2ed00 831169c0 ea0001a50040 
> 7f4983601000
> [   33.468332]  88006bdafce8 88006bdafd38 88006bdafd70 
> 88007bf13a80
> [   33.468332]  88006bdafcb0 8113329a 88006bdafd80 
> 
> [   33.468332] Call Trace:
> [   33.468332]  [] futex_wait_setup+0x4a/0x1d0
> [   33.468332]  [] futex_wait+0x120/0x330
> [   33.468332]  [] ? enqueue_hrtimer+0x50/0x50
> [   33.468332]  [] do_futex+0x11e/0x1050
> [   33.468332]  [] ? __lock_acquire+0x8c5/0x2830
> [   33.468332]  [] ? kvm_clock_read+0x35/0x50
> [   33.468332]  [] ? kvm_clock_get_cycles+0x11/0x20
> [   33.468332]  [] SyS_futex+0xb0/0x240
> [   33.468332]  [] entry_SYSCALL_64_fastpath+0x12/0x76
> [   33.468332] Code: 48 83 05 c9 e2 54 02 01 e9 56 ff ff ff 48 8b 57 20 f6 c2 
> 01 0f 85 43 01 00 00 a8 01 0f 85 d2 00 00 00 41 83 4e 10 01 48 8b 47 08 <48> 
> 8b 10 49 89 56 08 48 8b 07 f6 c4 40 0f 84 82 00 00 00 48 83 
> [   33.468332] RIP  [] get_futex_key+0x2ba/0x410
> [   33.468332]  RSP 
> [   33.483135] ---[ end trace 537578e223c13ed1 ]---
> [   33.483502] Kernel panic - not syncing: Fatal exception
> [   33.484020] Kernel Offset: disabled
> [   33.484313] ---[ end Kernel panic - not syncing: Fatal exception
> 
> This can be triggered with the following reproducer (based on
> futex_wake04 test from ltp):
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define HPGSZ 2097152
> int main(int argc, char **argv) {
>   long ret = 0;
>   void *addr;
>   uint32_t *futex;
>   int pgsz = getpagesize();
> 
>   addr = mmap(NULL, HPGSZ, PROT_WRITE | PROT_READ,
>   MAP_SHARED | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);
>   if (addr == MAP_FAILED) {
> fprintf(stderr, "Failed to alloc hugepage\n");
> return -1;
>   }
> 
>   futex = (uint32_t *)((char *)addr + pgsz);
>   *futex = 0;
> 
>   ret = syscall(SYS_futex, futex, FUTEX_WAIT, *futex, NULL, NULL, 0);
>   if (ret < 0) {
> perror("Syscall failed");
>   }
> 
>   munmap(addr, HPGSZ);
> 
>   return 0;
> }

Thanks for report. Patch below fixes the issue for me.
Could you test it as well?

diff --git a/kernel/futex.c b/kernel/futex.c
index 470c06c3299a..b29add22c454 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -470,6 +470,7 @@ get_futex_key(u32 __user *uaddr, int fshared, union 
futex_key *key, int rw)
unsigned long address = (unsigned long)uaddr;
struct mm_struct *mm = current->mm;
struct page *page;
+   struct address_space *mapping;
int err, ro = 0;
 
/*
@@ -535,7 +536,8 @@ again:
 * shmem_writepage move it from filecache to swapcache beneath us:
 * an unlikely race,

Re: [RFC/PATCH 3/3] perf tools: Defaults to 'caller' callchain order only if --children is enabled

2015-10-22 Thread Brendan Gregg
On Thu, Oct 22, 2015 at 12:38 AM, Namhyung Kim  wrote:
> Hi Ingo,
>
> On Thu, Oct 22, 2015 at 4:32 PM, Ingo Molnar  wrote:
>>
>> * Namhyung Kim  wrote:
>>
>>> The caller callchain order is useful with --children option since it can
>>> show 'overview' style output, but other commands which don't use
>>>  --children feature like 'perf script' or even 'perf report/top' without
>>>  --children are better to keep caller order.
>
> Oops, there's a typo:  s/caller order/callee order/ :)

Thanks, I was wondering about that (and I've made that typo myself).
Thanks for the patch!

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


Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

2015-10-22 Thread Peter Zijlstra
On Thu, Oct 22, 2015 at 11:12:16AM +0800, Wangnan (F) wrote:
> On 2015/10/22 11:09, Alexei Starovoitov wrote:
> >On 10/21/15 6:56 PM, Wangnan (F) wrote:
> >>>One alternative solution I can image is to attach a BPF program
> >>>at sampling like kprobe, and return 0 if we don't want sampling
> >>>take action. Thought?
> >>
> >>Do you think attaching BPF programs to sampling is an acceptable idea?
> >
> >If you mean to extend 'filter' concept to sampling events?
> >So instead of soft_disable of non-local events, you'll attach bpf
> >program to sampling events and use map lookup to decide whether
> >to filter out or not such sampling event?
> 
> Yes.

One could overload or stack the overflow handler I suppose. But this
would be in line with the software/tracepoint events calling eBPF muck
on trigger, right?

> >What pt_regs would be in such case?

> Sampling is based on interruption. We can use pt_reg captured by the IRQ
> handler,

s/IRQ/NMI/

Also, we 'edit' the pt_regs on the way down to the overflow handler as
sometimes 'better' information can be had from PMU state. But a pt_regs
is available there.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] mmc: dw_mmc: add hw_reset extension hook

2015-10-22 Thread Ulf Hansson
On 22 October 2015 at 08:19, Shawn Lin  wrote:
> This patch add hw_reset for dw_mmc to implement hw reset
> procedure. It's useful for mmc core to recover emmc devices
> if emmc runs into unexpected state. Add MMC_CAP_HW_RESET
> capability to dw_mmc extension driver directly if it needs hw_reset.
>
> Signed-off-by: Shawn Lin 
> ---
>
>  drivers/mmc/host/dw_mmc.c | 4 
>  drivers/mmc/host/dw_mmc.h | 2 ++
>  2 files changed, 6 insertions(+)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 8a0f2995..46b12de 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1482,6 +1482,10 @@ static void dw_mci_hw_reset(struct mmc_host *mmc)
>  {
> struct dw_mci_slot *slot = mmc_priv(mmc);
> struct dw_mci *host = slot->host;
> +   const struct dw_mci_drv_data *drv_data = host->drv_data;
> +
> +   if (drv_data && drv_data->hw_reset)
> +   return drv_data->hw_reset(host);

dw_mmc is starting to walk the same bad path as sdhci has done.

Please, try to avoid adding non-needed callbacks and start to turn
dw_mmc into a library instead.

Kind regards
Uffe

>
> if (host->use_dma == TRANS_MODE_IDMAC)
> dw_mci_idmac_reset(host);
> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
> index 9df18c1..21b9df4 100644
> --- a/drivers/mmc/host/dw_mmc.h
> +++ b/drivers/mmc/host/dw_mmc.h
> @@ -282,6 +282,7 @@ struct dw_mci_slot {
>   * @set_ios: handle bus specific extensions.
>   * @parse_dt: parse implementation specific device tree properties.
>   * @execute_tuning: implementation specific tuning procedure.
> + * @hw_reset: implementation specific hw reset procedure.
>   *
>   * Provide controller implementation specific extensions. The usage of this
>   * data structure is fully optional and usage of each member in this 
> structure
> @@ -299,5 +300,6 @@ struct dw_mci_drv_data {
> struct mmc_ios *ios);
> int (*switch_voltage)(struct mmc_host *mmc,
>   struct mmc_ios *ios);
> +   void(*hw_reset)(struct dw_mci *host);
>  };
>  #endif /* _DW_MMC_H_ */
> --
> 2.3.7
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCHv2 4.3-rc6] proc: fix convert from oom_score_adj to oom_adj

2015-10-22 Thread Michal Hocko
On Thu 22-10-15 06:49:01, Hongjie Fang (方洪杰) wrote:
> 
> The oom_adj has been replaced by oom_score_adj in kernel,
> but the /proc/pid/oom_adj is provided for legacy purposes.
> When write/read a value into/from /proc/pid/oom_adj,
> there is a transformation between oom_adj and oom_score_adj.
> 
> After writing a new value into /proc/pid/oom_adj, then read it.
> The return value is a different value than you wrote.
> Fix this by adding a adjustment factor.

... when printing the value.

Your previous patch has changed the stored value while this one only
changes the presented value. The previous one was more correct IMO
but in reality the difference (+-1) in oom_score_adj should be hardly
noticeable and nobody has complained about the current scaling for years
so this approach is probably more conservative.

> Signed-off-by: Hongjie Fang 

Acked-by: Michal Hocko 

> ---
> Encountered the problem when I changed a task's oom_adj on
> an Android smart phone. As follows,
> 1. # cat /proc/1450/oom_adj
>15
> 2. # echo 10 > /proc/1450/oom_adj
> 3. # cat /proc/1450/oom_adj
>9
> 
> 
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index b25eee4..2312e43 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1019,15 +1019,19 @@ static ssize_t oom_adj_read(struct file *file, char 
> __user *buf, size_t count,
>   int oom_adj = OOM_ADJUST_MIN;
>   size_t len;
>   unsigned long flags;
> + int adjust;
>  
>   if (!task)
>   return -ESRCH;
>   if (lock_task_sighand(task, &flags)) {
> - if (task->signal->oom_score_adj == OOM_SCORE_ADJ_MAX)
> + if (task->signal->oom_score_adj == OOM_SCORE_ADJ_MAX) {
>   oom_adj = OOM_ADJUST_MAX;
> - else
> - oom_adj = (task->signal->oom_score_adj * -OOM_DISABLE) /
> + } else {
> + adjust = task->signal->oom_score_adj > 0 ?
> +  (OOM_SCORE_ADJ_MAX-1) : -(OOM_SCORE_ADJ_MAX-1);
> + oom_adj = (task->signal->oom_score_adj * -OOM_DISABLE + 
> adjust) /
> OOM_SCORE_ADJ_MAX;
> + }
>   unlock_task_sighand(task, &flags);
>   }
>   put_task_struct(task);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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


[PATCH v2 1/6] vfio: platform: add capability to register a reset function

2015-10-22 Thread Eric Auger
In preparation for subsequent changes in reset function lookup,
lets introduce a dynamic list of reset combos (compat string,
reset module, reset function). The list can be populated/voided with
two new functions, vfio_platform_register/unregister_reset. Those are
not yet used in this patch.

Signed-off-by: Eric Auger 

---

v1 -> v2:
- reset_list becomes static
- vfio_platform_register/unregister_reset take a const char * as compat
- fix node leak
- add reset_lock to protect the reset list manipulation
- move vfio_platform_reset_node declaration in vfio_platform_common.c
---
 drivers/vfio/platform/vfio_platform_common.c  | 77 +++
 drivers/vfio/platform/vfio_platform_private.h |  7 +++
 2 files changed, 84 insertions(+)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index e43efb5..52a4c7b 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -23,6 +23,15 @@
 
 #include "vfio_platform_private.h"
 
+struct vfio_platform_reset_node {
+   struct list_head link;
+   char *compat;
+   struct module *owner;
+   vfio_platform_reset_fn_t reset;
+};
+
+static LIST_HEAD(reset_list);
+static DEFINE_MUTEX(reset_lock);
 static DEFINE_MUTEX(driver_lock);
 
 static const struct vfio_platform_reset_combo reset_lookup_table[] = {
@@ -573,3 +582,71 @@ struct vfio_platform_device 
*vfio_platform_remove_common(struct device *dev)
return vdev;
 }
 EXPORT_SYMBOL_GPL(vfio_platform_remove_common);
+
+int vfio_platform_register_reset(struct module *reset_owner,
+const char *compat,
+vfio_platform_reset_fn_t reset)
+{
+   struct vfio_platform_reset_node *node, *iter;
+   bool found = false;
+
+   mutex_lock(&reset_lock);
+   list_for_each_entry(iter, &reset_list, link) {
+   if (!strcmp(iter->compat, compat)) {
+   found = true;
+   break;
+   }
+   }
+   if (found) {
+   mutex_unlock(&reset_lock);
+   return -EINVAL;
+   }
+
+   node = kmalloc(sizeof(*node), GFP_KERNEL);
+   if (!node) {
+   mutex_unlock(&reset_lock);
+   return -ENOMEM;
+   }
+
+   node->compat = kstrdup(compat, GFP_KERNEL);
+   if (!node->compat) {
+   kfree(node);
+   mutex_unlock(&reset_lock);
+   return -ENOMEM;
+   }
+
+   node->owner = reset_owner;
+   node->reset = reset;
+
+   list_add(&node->link, &reset_list);
+   mutex_unlock(&reset_lock);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_platform_register_reset);
+
+int vfio_platform_unregister_reset(const char *compat)
+{
+   struct vfio_platform_reset_node *iter;
+   bool found = false;
+
+   mutex_lock(&reset_lock);
+   list_for_each_entry(iter, &reset_list, link) {
+   if (!strcmp(iter->compat, compat)) {
+   found = true;
+   break;
+   }
+   }
+   if (!found) {
+   mutex_unlock(&reset_lock);
+   return -EINVAL;
+   }
+
+   list_del(&iter->link);
+   kfree(iter->compat);
+   kfree(iter);
+   mutex_unlock(&reset_lock);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_platform_unregister_reset);
+
diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index 1c9b3d5..1fb1410 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -89,4 +89,11 @@ extern int vfio_platform_set_irqs_ioctl(struct 
vfio_platform_device *vdev,
unsigned start, unsigned count,
void *data);
 
+typedef int (*vfio_platform_reset_fn_t)(struct vfio_platform_device *vdev);
+
+extern int vfio_platform_register_reset(struct module *owner,
+   const char *compat,
+   vfio_platform_reset_fn_t reset);
+extern int vfio_platform_unregister_reset(const char *compat);
+
 #endif /* VFIO_PLATFORM_PRIVATE_H */
-- 
1.9.1

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


Re: [PATCH v11 07/14] HMM: mm add helper to update page table when migrating memory v2.

2015-10-22 Thread Hillf Danton
> 
> This is a multi-stage process, first we save and replace page table
> entry with special HMM entry, also flushing tlb in the process. If
> we run into non allocated entry we either use the zero page or we
> allocate new page. For swaped entry we try to swap them in.
> 
Please elaborate why swap entry is handled this way.


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


Re: [RESEND PATCH v4 3/3] mmc: sdhci-of-arasan: add runtime pm support

2015-10-22 Thread Michal Simek
On 10/22/2015 11:06 AM, Shawn Lin wrote:
> This patch add runtime_suspend and runtime_resume for
> sdhci-of-arasan. Currently we also power-off phy at
> runtime_suspend for power-saving.
> 
> Signed-off-by: Shawn Lin 
> 
> Serise-changes: 4
> - remove ifdef for PM callback statement
> - fix missing pm_runtime_set_active
> - remove pm_runtime_dont_use_autosuspend from remove hook
> - add pm_runtime_force_suspend|resume for PM callback to
>   deal with suspend invoked from rpm
> - remove wrappers of phy ops
> 
> ---
> 
> Changes in v2: None
> 
>  drivers/mmc/host/sdhci-of-arasan.c | 85 
> --
>  1 file changed, 82 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
> b/drivers/mmc/host/sdhci-of-arasan.c
> index 4f30716..fb1915c 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -30,6 +30,8 @@
>  #define CLK_CTRL_TIMEOUT_MASK(0xf << CLK_CTRL_TIMEOUT_SHIFT)
>  #define CLK_CTRL_TIMEOUT_MIN_EXP 13
>  
> +#define ARASAN_RPM_DELAY_MS  50
> +
>  /**
>   * struct sdhci_arasan_data
>   * @clk_ahb: Pointer to the AHB clock
> @@ -71,6 +73,46 @@ static struct sdhci_pltfm_data sdhci_arasan_pdata = {
>   SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN,
>  };
>  
> +#ifdef CONFIG_PM
> +static int sdhci_arasan_runtime_suspend(struct device *dev)
> +{
> + struct sdhci_host *host = dev_get_drvdata(dev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
> + int ret;
> +
> + ret = sdhci_runtime_suspend_host(host);
> + if (ret)
> + return ret;
> +
> + if (!IS_ERR(sdhci_arasan->phy))
> + phy_power_off(sdhci_arasan->phy);
> +
> + clk_disable(sdhci_arasan->clk_ahb);
> + clk_disable(pltfm_host->clk);
> +
> + return 0;
> +}
> +
> +static int sdhci_arasan_runtime_resume(struct device *dev)
> +{
> + struct sdhci_host *host = dev_get_drvdata(dev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
> +
> + clk_enable(pltfm_host->clk);
> + clk_enable(sdhci_arasan->clk_ahb);
> +
> + if (!IS_ERR(sdhci_arasan->phy))
> + phy_power_on(sdhci_arasan->phy);
> +
> + return sdhci_runtime_resume_host(host);
> +}
> +#else
> +#define sdhci_arasan_runtime_suspend NULL
> +#define sdhci_arasan_runtime_resume NULL

Remove these 3 lines - they are not needed.

> +#endif
> +
>  #ifdef CONFIG_PM_SLEEP
>  /**
>   * sdhci_arasan_suspend - Suspend method for the driver
> @@ -87,6 +129,12 @@ static int sdhci_arasan_suspend(struct device *dev)
>   struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
>   int ret;
>  
> + ret = pm_runtime_force_suspend(dev);
> + if (ret) {
> + dev_err(dev, "problem force suspending\n");
> + return ret;
> + }
> +
>   ret = sdhci_suspend_host(host);
>   if (ret)
>   return ret;
> @@ -140,18 +188,39 @@ static int sdhci_arasan_resume(struct device *dev)
>   }
>   }
>  
> - return sdhci_resume_host(host);
> + ret = sdhci_resume_host(host);
> + if (ret)
> + goto err_resume_host;
> +
> + ret = pm_runtime_force_resume(dev);
> + if (ret) {
> + dev_err(dev, "problem force resuming\n");
> + goto err_force_resume;
> + }
> +
> + return 0;
>  
> +err_force_resume:
> + sdhci_suspend_host(host);
> +err_resume_host:
> + if (!IS_ERR(sdhci_arasan->phy))
> + phy_power_off(sdhci_arasan->phy);
>  err_phy_power:
>   clk_disable(pltfm_host->clk);
>  err_clk_en:
>   clk_disable(sdhci_arasan->clk_ahb);
>   return ret;
>  }
> +#else
> +#define sdhci_arasan_suspend NULL
> +#define sdhci_arasan_resume NULL

Remove these 3 lines - they are not needed.

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


Re: [PATCH 4/5] block: introduce file_bd_inode()

2015-10-22 Thread Jan Kara
On Thu 22-10-15 02:42:05, Dan Williams wrote:
> Similar to the file_inode() helper, provide a helper to lookup the inode for a
> raw block device itself.

So I somewhat dislike the name file_bd_inode() since for struct file
pointing to a regular file, the result would be equivalent to file_inode()
but the name suggests (at least to me) it should return block device inode.
I'd name it like bdev_file_inode() to make it clear this is local to
block device code...

Honza

> Cc: Al Viro 
> Signed-off-by: Dan Williams 
> ---
>  fs/block_dev.c |   19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/block_dev.c b/fs/block_dev.c
> index 0a793c7930eb..3255dcec96b4 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -147,11 +147,16 @@ blkdev_get_block(struct inode *inode, sector_t iblock,
>   return 0;
>  }
>  
> +static struct inode *file_bd_inode(struct file *file)
> +{
> + return file->f_mapping->host;
> +}
> +
>  static ssize_t
>  blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter, loff_t offset)
>  {
>   struct file *file = iocb->ki_filp;
> - struct inode *inode = file->f_mapping->host;
> + struct inode *inode = file_bd_inode(file);
>  
>   if (IS_DAX(inode))
>   return dax_do_io(iocb, inode, iter, offset, blkdev_get_block,
> @@ -329,7 +334,7 @@ static int blkdev_write_end(struct file *file, struct 
> address_space *mapping,
>   */
>  static loff_t block_llseek(struct file *file, loff_t offset, int whence)
>  {
> - struct inode *bd_inode = file->f_mapping->host;
> + struct inode *bd_inode = file_bd_inode(file);
>   loff_t retval;
>  
>   mutex_lock(&bd_inode->i_mutex);
> @@ -340,7 +345,7 @@ static loff_t block_llseek(struct file *file, loff_t 
> offset, int whence)
>   
>  int blkdev_fsync(struct file *filp, loff_t start, loff_t end, int datasync)
>  {
> - struct inode *bd_inode = filp->f_mapping->host;
> + struct inode *bd_inode = file_bd_inode(filp);
>   struct block_device *bdev = I_BDEV(bd_inode);
>   int error;
>   
> @@ -1579,14 +1584,14 @@ EXPORT_SYMBOL(blkdev_put);
>  
>  static int blkdev_close(struct inode * inode, struct file * filp)
>  {
> - struct block_device *bdev = I_BDEV(filp->f_mapping->host);
> + struct block_device *bdev = I_BDEV(file_bd_inode(filp));
>   blkdev_put(bdev, filp->f_mode);
>   return 0;
>  }
>  
>  static long block_ioctl(struct file *file, unsigned cmd, unsigned long arg)
>  {
> - struct block_device *bdev = I_BDEV(file->f_mapping->host);
> + struct block_device *bdev = I_BDEV(file_bd_inode(file));
>   fmode_t mode = file->f_mode;
>  
>   /*
> @@ -1611,7 +1616,7 @@ static long block_ioctl(struct file *file, unsigned 
> cmd, unsigned long arg)
>  ssize_t blkdev_write_iter(struct kiocb *iocb, struct iov_iter *from)
>  {
>   struct file *file = iocb->ki_filp;
> - struct inode *bd_inode = file->f_mapping->host;
> + struct inode *bd_inode = file_bd_inode(file);
>   loff_t size = i_size_read(bd_inode);
>   struct blk_plug plug;
>   ssize_t ret;
> @@ -1643,7 +1648,7 @@ EXPORT_SYMBOL_GPL(blkdev_write_iter);
>  ssize_t blkdev_read_iter(struct kiocb *iocb, struct iov_iter *to)
>  {
>   struct file *file = iocb->ki_filp;
> - struct inode *bd_inode = file->f_mapping->host;
> + struct inode *bd_inode = file_bd_inode(file);
>   loff_t size = i_size_read(bd_inode);
>   loff_t pos = iocb->ki_pos;
>  
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC PATCH v6 3/3] arm: fix a migrating irq bug when hotplug cpu

2015-10-22 Thread Geert Uytterhoeven
Hi Russell,

On Thu, Oct 22, 2015 at 11:26 AM, Russell King - ARM Linux
 wrote:
> On Wed, Oct 21, 2015 at 09:29:08PM +0100, Russell King - ARM Linux wrote:
>> On Wed, Oct 21, 2015 at 01:47:49PM +0200, Geert Uytterhoeven wrote:
>> > On Thu, Sep 24, 2015 at 11:32 AM, Yang Yingliang
>> >  wrote:
>> > > When cpu is disabled, all irqs will be migratged to another cpu.
>> > > In some cases, a new affinity is different, the old affinity need
>> > > to be updated and if irq_set_affinity's return value is 
>> > > IRQ_SET_MASK_OK_DONE,
>> > > the old affinity can not be updated. Fix it by using irq_do_set_affinity.
>> > >
>> > > And migrating interrupts is a core code matter, so use the generic
>> > > function irq_migrate_all_off_this_cpu() to migrate interrupts in
>> > > kernel/irq/migration.c.
>> > >
>> > > Cc: Jiang Liu 
>> > > Cc: Thomas Gleixner 
>> > > Cc: Marc Zyngier 
>> > > Cc: Mark Rutland 
>> > > Cc: Will Deacon 
>> > > Cc: Russell King - ARM Linux 
>> > > Cc: Hanjun Guo 
>> > > Signed-off-by: Yang Yingliang 
>> > > ---
>> > >  arch/arm/Kconfig   |  1 +
>> > >  arch/arm/include/asm/irq.h |  1 -
>> > >  arch/arm/kernel/irq.c  | 62 
>> > > --
>> > >  arch/arm/kernel/smp.c  |  2 +-
>> > >  4 files changed, 2 insertions(+), 64 deletions(-)
>> > >
>> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> > > index 72ad724..bffba78 100644
>> > > --- a/arch/arm/Kconfig
>> > > +++ b/arch/arm/Kconfig
>> > > @@ -1492,6 +1492,7 @@ config NR_CPUS
>> > >  config HOTPLUG_CPU
>> > > bool "Support for hot-pluggable CPUs"
>> > > depends on SMP
>> > > +   select GENERIC_IRQ_MIGRATION
>> >
>> > This causes the following warnings during s2ram on r8a7791/koelsch
>> > (dual-core CA15):
>>
>> Thanks for the report.  I'll see what tonight's boot run says for my
>> platforms.  Hopefully, the author of these changes can help debug
>> this.
>
> What's happened is that:
>
> -   c = irq_data_get_irq_chip(d);
> -   if (!c->irq_set_affinity)
> -   pr_debug("IRQ%u: unable to set affinity\n", d->irq);
>
> has become:
>
> +   c = irq_data_get_irq_chip(d);
> +   if (!c->irq_set_affinity) {
> +   pr_warn_ratelimited("IRQ%u: unable to set affinity\n", 
> d->irq);
>
> which makes things more noisy.
>
> This is a change that was not described in the commit message for the
> patch Thomas merged.
>
> So, I think the right thing to do is to drop the patch set and revert
> back to what we knew was sane, and get the submitter to do the job
> properly: cleanly move the code from one location to another with _no_
> changes what so ever, convert ARM and ARM64 to use it, and _then_ to
> modify the resulting code.
>
> From what I can see, both ARM and ARM64 implementations here are
> identical.
>
> I'm certainly dropping this from the ARM tree.

Thanks for your analysis!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 5/6] vfio: platform: use list of registered reset function

2015-10-22 Thread Eric Auger
Remove the static lookup table and use the dynamic list of registered
reset functions instead. Also load the reset module through its alias.
The reset struct module pointer is stored in vfio_platform_device.

We also remove the useless struct device pointer parameter in
vfio_platform_get_reset.

This patch fixes the issue related to the usage of __symbol_get, which
besides from being moot, prevented compilation with CONFIG_MODULES
disabled.

Also usage of MODULE_ALIAS makes possible to add a new reset module
without needing to update the framework. This was suggested by Arnd.

Signed-off-by: Eric Auger 
Reported-by: Arnd Bergmann 

---

v1 -> v2:
- use reset_lock in vfio_platform_lookup_reset
- remove vfio_platform_reset_combo declaration
- remove struct device *dev parameter in vfio_platform_get_reset
- set reset_module and reset to NULL in put function
---
 drivers/vfio/platform/vfio_platform_common.c  | 57 ---
 drivers/vfio/platform/vfio_platform_private.h |  7 +---
 2 files changed, 34 insertions(+), 30 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index e7d615f..95b8294 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -34,37 +34,46 @@ static LIST_HEAD(reset_list);
 static DEFINE_MUTEX(reset_lock);
 static DEFINE_MUTEX(driver_lock);
 
-static const struct vfio_platform_reset_combo reset_lookup_table[] = {
-   {
-   .compat = "calxeda,hb-xgmac",
-   .reset_function_name = "vfio_platform_calxedaxgmac_reset",
-   .module_name = "vfio-platform-calxedaxgmac",
-   },
-};
-
-static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
-   struct device *dev)
+static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
+   struct module **module)
 {
-   int (*reset)(struct vfio_platform_device *);
-   int i;
+   struct vfio_platform_reset_node *iter;
 
-   for (i = 0 ; i < ARRAY_SIZE(reset_lookup_table); i++) {
-   if (!strcmp(reset_lookup_table[i].compat, vdev->compat)) {
-   request_module(reset_lookup_table[i].module_name);
-   reset = __symbol_get(
-   reset_lookup_table[i].reset_function_name);
-   if (reset) {
-   vdev->reset = reset;
-   return;
-   }
+   mutex_lock(&reset_lock);
+   list_for_each_entry(iter, &reset_list, link) {
+   if (!strcmp(iter->compat, compat) &&
+   try_module_get(iter->owner)) {
+   *module = iter->owner;
+   mutex_unlock(&reset_lock);
+   return iter->reset;
}
}
+
+   mutex_unlock(&reset_lock);
+   return NULL;
+}
+
+static void vfio_platform_get_reset(struct vfio_platform_device *vdev)
+{
+   char modname[256];
+
+   vdev->reset = vfio_platform_lookup_reset(vdev->compat,
+   &vdev->reset_module);
+   if (!vdev->reset) {
+   snprintf(modname, 256, "vfio-reset:%s", vdev->compat);
+   request_module(modname);
+   vdev->reset = vfio_platform_lookup_reset(vdev->compat,
+&vdev->reset_module);
+   }
 }
 
 static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
 {
-   if (vdev->reset)
-   symbol_put_addr(vdev->reset);
+   if (vdev->reset) {
+   module_put(vdev->reset_module);
+   vdev->reset_module = NULL;
+   vdev->reset = NULL;
+   }
 }
 
 static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
@@ -561,7 +570,7 @@ int vfio_platform_probe_common(struct vfio_platform_device 
*vdev,
return ret;
}
 
-   vfio_platform_get_reset(vdev, dev);
+   vfio_platform_get_reset(vdev);
 
mutex_init(&vdev->igate);
 
diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index 620ee40..e968454 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -57,6 +57,7 @@ struct vfio_platform_device {
int refcnt;
struct mutexigate;
const char  *compat;
+   struct module   *reset_module;
 
/*
 * These fields should be filled by the bus specific binder
@@ -71,12 +72,6 @@ struct vfio_platform_device {
int (*reset)(struct vfio_platform_device *vdev);
 };
 
-struct vfio_platform_reset_combo {
-   const char *compat;
-   const char *reset_function_name;
-   const c

[PATCH v2 2/6] vfio: platform: reset: add vfio_platform_reset_private.h

2015-10-22 Thread Eric Auger
This header is to be included in all vfio reset modules. It
defines the module_vfio_reset_handler macro whose role is
- to define a module alias
- implement module init/exit function which respectively registers
  and unregisters the reset function.

Signed-off-by: Eric Auger 

---

v2: creation
- this defines the module_vfio_reset_handler macro as suggested by Arnd

Although Arnd suggested me to remove the vfio_platform_register_reset
symbol_get (since the module manager can handle the case where the
vfio-platform driver is not loaded), I prefered to keep it while
introducing the macro. The rationale is, when using symbol_get/put
we are able to release the hold from the reset module on vfio-platform
as soon as the registration is complete and I think this makes sense.
---
 drivers/vfio/platform/reset/Makefile   |  2 +-
 .../platform/reset/vfio_platform_reset_private.h   | 66 ++
 2 files changed, 67 insertions(+), 1 deletion(-)
 create mode 100644 drivers/vfio/platform/reset/vfio_platform_reset_private.h

diff --git a/drivers/vfio/platform/reset/Makefile 
b/drivers/vfio/platform/reset/Makefile
index 2a486af..154a7d5 100644
--- a/drivers/vfio/platform/reset/Makefile
+++ b/drivers/vfio/platform/reset/Makefile
@@ -1,5 +1,5 @@
 vfio-platform-calxedaxgmac-y := vfio_platform_calxedaxgmac.o
 
-ccflags-y += -Idrivers/vfio/platform
+ccflags-y += -Idrivers/vfio/platform -Idrivers/vfio/platform/reset
 
 obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += vfio-platform-calxedaxgmac.o
diff --git a/drivers/vfio/platform/reset/vfio_platform_reset_private.h 
b/drivers/vfio/platform/reset/vfio_platform_reset_private.h
new file mode 100644
index 000..f212a61
--- /dev/null
+++ b/drivers/vfio/platform/reset/vfio_platform_reset_private.h
@@ -0,0 +1,66 @@
+/*
+ * Interface used by VFIO platform reset modules to register/unregister
+ * their reset function
+ *
+ * Copyright (c) 2015 Linaro Ltd.
+ *  www.linaro.org
+ *
+ * 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.
+ *
+ * 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.
+ */
+
+#ifndef VFIO_PLATFORM_RESET_PRIVATE_H
+#define VFIO_PLATFORM_RESET_PRIVATE_H
+
+#include 
+#include "vfio_platform_private.h"
+
+static int reset_module_register(struct module *module,
+   const char *compat,
+   vfio_platform_reset_fn_t reset)
+{
+   int (*register_reset)(struct module *, const char*,
+   vfio_platform_reset_fn_t);
+   int ret;
+
+   register_reset = symbol_get(vfio_platform_register_reset);
+   if (!register_reset)
+   return -EINVAL;
+   ret = register_reset(module, compat, reset);
+   symbol_put(vfio_platform_register_reset);
+   return ret;
+}
+
+static void reset_module_unregister(const char *compat)
+{
+   int (*unregister_reset)(const char *);
+
+   unregister_reset = symbol_get(vfio_platform_unregister_reset);
+   if (!unregister_reset)
+   return;
+
+   unregister_reset(compat);
+
+   symbol_put(vfio_platform_unregister_reset);
+}
+
+#define module_vfio_reset_handler(compat, reset)   \
+MODULE_ALIAS("vfio-reset:" compat);\
+static int __init reset ## _module_init(void)  \
+{  \
+   return reset_module_register(THIS_MODULE, compat, &reset);  \
+}; \
+static void __exit reset ## _module_exit(void) \
+{   \
+   reset_module_unregister(compat);\
+}; \
+module_init(reset ## _module_init);\
+module_exit(reset ## _module_exit)
+
+#endif /* VFIO_PLATFORM_RESET_PRIVATE_H */
-- 
1.9.1

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


[PATCH v2 6/6] vfio: platform: move get/put reset at open/release

2015-10-22 Thread Eric Auger
Currently reset lookup is done on probe. This introduces a
race with new registration mechanism in the case where the
vfio-platform driver is bound to the device before its module
is loaded: on the load, the probe happens which triggers the
reset module load which itself attempts to get the symbol for
the registration function (vfio_platform_register_reset). The
symbol is not yet available hence the lookup fails. In case we
do the lookup in the first open we are sure the vfio-platform
module is loaded and vfio_platform_register_reset is available.

Signed-off-by: Eric Auger 
---
 drivers/vfio/platform/vfio_platform_common.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 95b8294..5ebae8c 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -155,6 +155,7 @@ static void vfio_platform_release(void *device_data)
vdev->reset(vdev);
vfio_platform_regions_cleanup(vdev);
vfio_platform_irq_cleanup(vdev);
+   vfio_platform_put_reset(vdev);
}
 
mutex_unlock(&driver_lock);
@@ -181,6 +182,8 @@ static int vfio_platform_open(void *device_data)
if (ret)
goto err_irq;
 
+   vfio_platform_get_reset(vdev);
+
if (vdev->reset)
vdev->reset(vdev);
}
@@ -570,8 +573,6 @@ int vfio_platform_probe_common(struct vfio_platform_device 
*vdev,
return ret;
}
 
-   vfio_platform_get_reset(vdev);
-
mutex_init(&vdev->igate);
 
return 0;
@@ -585,7 +586,6 @@ struct vfio_platform_device 
*vfio_platform_remove_common(struct device *dev)
vdev = vfio_del_group_dev(dev);
 
if (vdev) {
-   vfio_platform_put_reset(vdev);
iommu_group_put(dev->iommu_group);
}
 
-- 
1.9.1

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


[PATCH v2 4/6] vfio: platform: add compat in vfio_platform_device

2015-10-22 Thread Eric Auger
Let's retrieve the compatibility string on probe and store it
in the vfio_platform_device struct

Signed-off-by: Eric Auger 
---
 drivers/vfio/platform/vfio_platform_common.c  | 15 ---
 drivers/vfio/platform/vfio_platform_private.h |  1 +
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 52a4c7b..e7d615f 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -45,16 +45,11 @@ static const struct vfio_platform_reset_combo 
reset_lookup_table[] = {
 static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
struct device *dev)
 {
-   const char *compat;
int (*reset)(struct vfio_platform_device *);
-   int ret, i;
-
-   ret = device_property_read_string(dev, "compatible", &compat);
-   if (ret)
-   return;
+   int i;
 
for (i = 0 ; i < ARRAY_SIZE(reset_lookup_table); i++) {
-   if (!strcmp(reset_lookup_table[i].compat, compat)) {
+   if (!strcmp(reset_lookup_table[i].compat, vdev->compat)) {
request_module(reset_lookup_table[i].module_name);
reset = __symbol_get(
reset_lookup_table[i].reset_function_name);
@@ -545,6 +540,12 @@ int vfio_platform_probe_common(struct vfio_platform_device 
*vdev,
struct iommu_group *group;
int ret;
 
+   ret = device_property_read_string(dev, "compatible", &vdev->compat);
+   if (ret) {
+   pr_err("VFIO: cannot retrieve compat for %s\n", vdev->name);
+   return -EINVAL;
+   }
+
if (!vdev)
return -EINVAL;
 
diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index 1fb1410..620ee40 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -56,6 +56,7 @@ struct vfio_platform_device {
u32 num_irqs;
int refcnt;
struct mutexigate;
+   const char  *compat;
 
/*
 * These fields should be filled by the bus specific binder
-- 
1.9.1

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


[PATCH v2 0/6] VFIO platform reset module rework

2015-10-22 Thread Eric Auger
This series fixes the current implementation by getting rid of the
usage of __symbol_get which caused a compilation issue with
CONFIG_MODULES disabled. On top of this, the usage of MODULE_ALIAS makes
possible to add a new reset module without being obliged to update the
framework. The new implementation relies on the reset module registering
its reset function to the vfio-platform driver.

The series is available at

https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.3-rc6-rework-v2

Best Regards

Eric

v1 -> v2:
* in vfio_platform_common.c:
  - move reset lookup at load time and put reset at release: this is to
prevent a race between the 2 load module loads
  - reset_list becomes static
  - vfio_platform_register/unregister_reset take a const char * as compat
  - fix node link
  - remove old combo struct and cleanup proto of vfio_platform_get_reset
  - add mutex to protect the reset list
* in calxeda xgmac reset module
  - introduce vfio_platform_reset_private.h
  - use module_vfio_reset_handler macro
  - do not export vfio_platform_calxedaxgmac_reset symbol anymore
  - add a pr_info to show the device is reset by vfio reset module


Eric Auger (6):
  vfio: platform: add capability to register a reset function
  vfio: platform: reset: add vfio_platform_reset_private.h
  vfio: platform: reset: calxedaxgmac: add reset function registration
  vfio: platform: add compat in vfio_platform_device
  vfio: platform: use list of registered reset function
  vfio: platform: move get/put reset at open/release

 drivers/vfio/platform/reset/Makefile   |   2 +-
 .../platform/reset/vfio_platform_calxedaxgmac.c|   9 +-
 .../platform/reset/vfio_platform_reset_private.h   |  66 +
 drivers/vfio/platform/vfio_platform_common.c   | 151 -
 drivers/vfio/platform/vfio_platform_private.h  |  15 +-
 5 files changed, 201 insertions(+), 42 deletions(-)
 create mode 100644 drivers/vfio/platform/reset/vfio_platform_reset_private.h

-- 
1.9.1

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


Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

2015-10-22 Thread Anand Moon
Hi Javier,

On 22 October 2015 at 14:06, Javier Martinez Canillas
 wrote:
> Hello Anand,
>
> On 10/22/2015 07:03 AM, Anand Moon wrote:
>> Hi Javier,
>>
>> On 22 October 2015 at 08:22, Javier Martinez Canillas
>>  wrote:
>>> Hello Krzysztof,
>>>
>>> On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote:
 On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof,
>
> Thanks for your feedback.
>
> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote:
>> On 22.10.2015 00:15, Javier Martinez Canillas wrote:
>>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to
>>> allow broken or limited ROM boot-loaders (that don't have an eMMC reset
>>> logic) to be able to read the second stage from the eMMC.
>>>
>>> But this has to be called before a system reboot handler and while most
>>> of them use the priority 128, there are other restart handlers (such as
>>> the syscon-reboot one) that use a higher priority. So, use the highest
>>> priority to make sure that the eMMC hw is reset before a system reboot.
>>>
>>> Signed-off-by: Javier Martinez Canillas 
>>> Tested-by: Markus Reichl 
>>> Tested-by: Anand Moon 
>>> Reviewed-by: Alim Akhtar 
>>>
>>> ---
>>> Hello,
>>>
>>> This patch was needed since a recent series from Alim [0] added
>>> syscon reboot and poweroff support to Exynos SoCs and removed
>>> the reset handler in the Exynos Power Management Unit (PMU) code.
>>>
>>> But the PMU and syscon-reboot restart handler have a different
>>> priority so [0] breaks restart when eMMC is used on these boards.
>>>
>>> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html
>>>
>>> So this patch must be merged before [0] to avoid regressions.
>>>
>>> Best regards,
>>> Javier
>>>
>>>  drivers/mmc/core/pwrseq_emmc.c | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/mmc/core/pwrseq_emmc.c 
>>> b/drivers/mmc/core/pwrseq_emmc.c
>>> index 137c97fb7aa8..ad4f94ec7e8d 100644
>>> --- a/drivers/mmc/core/pwrseq_emmc.c
>>> +++ b/drivers/mmc/core/pwrseq_emmc.c
>>> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct 
>>> mmc_host *host,
>>>
>>>/*
>>> * register reset handler to ensure emmc reset also from
>>> -   * emergency_reboot(), priority 129 schedules it just before
>>> -   * system reboot
>>> +   * emergency_reboot(), priority 255 is the highest priority
>>> +   * so it will be executed before any system reboot handler.
>>> */
>>>pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb;
>>> -  pwrseq->reset_nb.priority = 129;
>>> +  pwrseq->reset_nb.priority = 255;
>>
>> I see the problem which you are trying to solve but this may be tricker
>> then just kicking the number. Some of restart handlers are registered
>> with priority 192. I found few of such, like: at91_restart_nb,
>> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too
>> much).
>>
>
> Yes, the syscon-reboot restart handler also uses a priority 192 and that
> is why reboot with eMMC broke with Alim's patches since the PMU restart
> handler priority is 128.
>
>> I guess they chose the "192" priority on purpose.
>>
>
> I tried to understand what's the policy w.r.t priority numbering for
> restart handlers but only found this in the register_restart_handler
> kernel-doc [0]:
>
> /**
>  *   register_restart_handler - Register function to be called to reset
>  *  the system
>  *   @nb: Info about handler function to be called
>  *   @nb->priority:  Handler priority. Handlers should follow the
>  *   following guidelines for setting priorities.
>  *   0:  Restart handler of last resort,
>  *   with limited restart capabilities
>  *   128:Default restart handler; use if no other
>  *   restart handler is expected to be available,
>  *   and/or if restart functionality is
>  *   sufficient to restart the entire system
>  *   255:Highest priority restart handler, will
>  *   preempt all other restart handlers
>
> So, reading that is not clear to me if only the values 0, 128 and 255
> should be used or any value from 0-255.
>
> What's clear to me is that restart handlers to reset a specific hw block
> should be called before the restart handler that resets the whole system.
>
> The 192 seems to be used because there are other default restart handlers
> that are using a prio of 128. See for example the commit that changed the
> syscon-reboot pr

[PATCH v2 3/6] vfio: platform: reset: calxedaxgmac: add reset function registration

2015-10-22 Thread Eric Auger
This patch adds the reset function registration/unregistration.

Signed-off-by: Eric Auger 

---

v1 -> v2:
- uses the module_vfio_reset_handler macro
- add pr_info on vfio reset
- do not export vfio_platform_calxedaxgmac_reset symbol anymore
---
 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c 
b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
index 619dc7d..8b2 100644
--- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
+++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
@@ -25,13 +25,12 @@
 #include 
 
 #include "vfio_platform_private.h"
+#include "vfio_platform_reset_private.h"
 
 #define DRIVER_VERSION  "0.1"
 #define DRIVER_AUTHOR   "Eric Auger "
 #define DRIVER_DESC "Reset support for Calxeda xgmac vfio platform device"
 
-#define CALXEDAXGMAC_COMPAT "calxeda,hb-xgmac"
-
 /* XGMAC Register definitions */
 #define XGMAC_CONTROL   0x  /* MAC Configuration */
 
@@ -70,6 +69,8 @@ int vfio_platform_calxedaxgmac_reset(struct 
vfio_platform_device *vdev)
return -ENOMEM;
}
 
+   pr_info("VFIO reset of %s\n", vdev->name);
+
/* disable IRQ */
writel(0, reg.ioaddr + XGMAC_DMA_INTR_ENA);
 
@@ -78,7 +79,9 @@ int vfio_platform_calxedaxgmac_reset(struct 
vfio_platform_device *vdev)
 
return 0;
 }
-EXPORT_SYMBOL_GPL(vfio_platform_calxedaxgmac_reset);
+
+module_vfio_reset_handler("calxeda,hb-xgmac",
+ vfio_platform_calxedaxgmac_reset);
 
 MODULE_VERSION(DRIVER_VERSION);
 MODULE_LICENSE("GPL v2");
-- 
1.9.1

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


[PATCH v2 2/2] dmaengine: hdmac: Add scatter-gathered memset support

2015-10-22 Thread Maxime Ripard
Just like memset support, the HDMAC might be used to do a memset over a
discontiguous memory area.

In such a case, we'll just build up a chain of memset descriptors over the
contiguous chunks of memory to set, in order to allow such a support.

Signed-off-by: Maxime Ripard 
---
 drivers/dma/at_hdmac.c | 79 ++
 1 file changed, 79 insertions(+)

diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index cad18f3660ae..4e55239c7a30 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -986,6 +986,83 @@ err_free_buffer:
return NULL;
 }
 
+static struct dma_async_tx_descriptor *
+atc_prep_dma_memset_sg(struct dma_chan *chan,
+  struct scatterlist *sgl,
+  unsigned int sg_len, int value,
+  unsigned long flags)
+{
+   struct at_dma_chan  *atchan = to_at_dma_chan(chan);
+   struct at_dma   *atdma = to_at_dma(chan->device);
+   struct at_desc  *desc = NULL, *first = NULL, *prev = NULL;
+   struct scatterlist  *sg;
+   void __iomem*vaddr;
+   dma_addr_t  paddr;
+   size_t  total_len = 0;
+   int i;
+
+   dev_vdbg(chan2dev(chan), "%s: v0x%x l0x%zx f0x%lx\n", __func__,
+value, sg_len, flags);
+
+   if (unlikely(!sgl || !sg_len)) {
+   dev_dbg(chan2dev(chan), "%s: scatterlist is empty!\n",
+   __func__);
+   return NULL;
+   }
+
+   vaddr = dma_pool_alloc(atdma->memset_pool, GFP_ATOMIC, &paddr);
+   if (!vaddr) {
+   dev_err(chan2dev(chan), "%s: couldn't allocate buffer\n",
+   __func__);
+   return NULL;
+   }
+   *(u32*)vaddr = value;
+
+   for_each_sg(sgl, sg, sg_len, i) {
+   dma_addr_t dest = sg_dma_address(sg);
+   size_t len = sg_dma_len(sg);
+
+   dev_vdbg(chan2dev(chan), "%s: d0x%08x, l0x%zx\n",
+__func__, dest, len);
+
+   if (!is_dma_fill_aligned(chan->device, dest, 0, len)) {
+   dev_err(chan2dev(chan), "%s: buffer is not aligned\n",
+   __func__);
+   goto err_put_desc;
+   }
+
+   desc = atc_create_memset_desc(chan, paddr, dest, len);
+   if (!desc)
+   goto err_put_desc;
+
+   atc_desc_chain(&first, &prev, desc);
+
+   total_len += len;
+   }
+
+   /*
+* Only set the buffer pointers on the last descriptor to
+* avoid free'ing while we have our transfer still going
+*/
+   desc->memset_paddr = paddr;
+   desc->memset_vaddr = vaddr;
+   desc->memset_buffer = true;
+
+   first->txd.cookie = -EBUSY;
+   first->total_len = total_len;
+
+   /* set end-of-link on the descriptor */
+   set_desc_eol(desc);
+
+   first->txd.flags = flags;
+
+   return &first->txd;
+
+err_put_desc:
+   atc_desc_put(atchan, first);
+   return NULL;
+}
+
 /**
  * atc_prep_slave_sg - prepare descriptors for a DMA_SLAVE transaction
  * @chan: DMA channel
@@ -1868,6 +1945,7 @@ static int __init at_dma_probe(struct platform_device 
*pdev)
dma_cap_set(DMA_INTERLEAVE, at91sam9g45_config.cap_mask);
dma_cap_set(DMA_MEMCPY, at91sam9g45_config.cap_mask);
dma_cap_set(DMA_MEMSET, at91sam9g45_config.cap_mask);
+   dma_cap_set(DMA_MEMSET_SG, at91sam9g45_config.cap_mask);
dma_cap_set(DMA_PRIVATE, at91sam9g45_config.cap_mask);
dma_cap_set(DMA_SLAVE, at91sam9g45_config.cap_mask);
dma_cap_set(DMA_SG, at91sam9g45_config.cap_mask);
@@ -1989,6 +2067,7 @@ static int __init at_dma_probe(struct platform_device 
*pdev)
 
if (dma_has_cap(DMA_MEMSET, atdma->dma_common.cap_mask)) {
atdma->dma_common.device_prep_dma_memset = atc_prep_dma_memset;
+   atdma->dma_common.device_prep_dma_memset_sg = 
atc_prep_dma_memset_sg;
atdma->dma_common.fill_align = DMAENGINE_ALIGN_4_BYTES;
}
 
-- 
2.6.2

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


[PATCH v2 1/2] dmaengine: hdmac: factorise memset descriptor allocation

2015-10-22 Thread Maxime Ripard
The memset and scatter gathered memset are going to use some common logic
to create their descriptors.

Move that logic into a function of its own so that we can share it with the
future memset_sg callback.

Signed-off-by: Maxime Ripard 
---
 drivers/dma/at_hdmac.c  | 97 ++---
 drivers/dma/at_hdmac_regs.h |  2 +-
 2 files changed, 58 insertions(+), 41 deletions(-)

diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 58d406230d89..cad18f3660ae 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -458,10 +458,10 @@ atc_chain_complete(struct at_dma_chan *atchan, struct 
at_desc *desc)
dma_cookie_complete(txd);
 
/* If the transfer was a memset, free our temporary buffer */
-   if (desc->memset) {
+   if (desc->memset_buffer) {
dma_pool_free(atdma->memset_pool, desc->memset_vaddr,
  desc->memset_paddr);
-   desc->memset = false;
+   desc->memset_buffer = false;
}
 
/* move children to free_list */
@@ -881,6 +881,46 @@ err_desc_get:
return NULL;
 }
 
+static struct at_desc *atc_create_memset_desc(struct dma_chan *chan,
+ dma_addr_t psrc,
+ dma_addr_t pdst,
+ size_t len)
+{
+   struct at_dma_chan *atchan = to_at_dma_chan(chan);
+   struct at_desc *desc;
+   size_t xfer_count;
+
+   u32 ctrla = ATC_SRC_WIDTH(2) | ATC_DST_WIDTH(2);
+   u32 ctrlb = ATC_DEFAULT_CTRLB | ATC_IEN |
+   ATC_SRC_ADDR_MODE_FIXED |
+   ATC_DST_ADDR_MODE_INCR |
+   ATC_FC_MEM2MEM;
+
+   xfer_count = len >> 2;
+   if (xfer_count > ATC_BTSIZE_MAX) {
+   dev_err(chan2dev(chan), "%s: buffer is too big\n",
+   __func__);
+   return NULL;
+   }
+
+   desc = atc_desc_get(atchan);
+   if (!desc) {
+   dev_err(chan2dev(chan), "%s: can't get a descriptor\n",
+   __func__);
+   return NULL;
+   }
+
+   desc->lli.saddr = psrc;
+   desc->lli.daddr = pdst;
+   desc->lli.ctrla = ctrla | xfer_count;
+   desc->lli.ctrlb = ctrlb;
+
+   desc->txd.cookie = 0;
+   desc->len = len;
+
+   return desc;
+}
+
 /**
  * atc_prep_dma_memset - prepare a memcpy operation
  * @chan: the channel to prepare operation on
@@ -893,12 +933,10 @@ static struct dma_async_tx_descriptor *
 atc_prep_dma_memset(struct dma_chan *chan, dma_addr_t dest, int value,
size_t len, unsigned long flags)
 {
-   struct at_dma_chan  *atchan = to_at_dma_chan(chan);
struct at_dma   *atdma = to_at_dma(chan->device);
-   struct at_desc  *desc = NULL;
-   size_t  xfer_count;
-   u32 ctrla;
-   u32 ctrlb;
+   struct at_desc  *desc;
+   void __iomem*vaddr;
+   dma_addr_t  paddr;
 
dev_vdbg(chan2dev(chan), "%s: d0x%x v0x%x l0x%zx f0x%lx\n", __func__,
dest, value, len, flags);
@@ -914,46 +952,26 @@ atc_prep_dma_memset(struct dma_chan *chan, dma_addr_t 
dest, int value,
return NULL;
}
 
-   xfer_count = len >> 2;
-   if (xfer_count > ATC_BTSIZE_MAX) {
-   dev_err(chan2dev(chan), "%s: buffer is too big\n",
+   vaddr = dma_pool_alloc(atdma->memset_pool, GFP_ATOMIC, &paddr);
+   if (!vaddr) {
+   dev_err(chan2dev(chan), "%s: couldn't allocate buffer\n",
__func__);
return NULL;
}
+   *(u32*)vaddr = value;
 
-   ctrlb =   ATC_DEFAULT_CTRLB | ATC_IEN
-   | ATC_SRC_ADDR_MODE_FIXED
-   | ATC_DST_ADDR_MODE_INCR
-   | ATC_FC_MEM2MEM;
-
-   ctrla = ATC_SRC_WIDTH(2) |
-   ATC_DST_WIDTH(2);
-
-   desc = atc_desc_get(atchan);
+   desc = atc_create_memset_desc(chan, paddr, dest, len);
if (!desc) {
-   dev_err(chan2dev(chan), "%s: can't get a descriptor\n",
+   dev_err(chan2dev(chan), "%s: couldn't get a descriptor\n",
__func__);
-   return NULL;
+   goto err_free_buffer;
}
 
-   desc->memset_vaddr = dma_pool_alloc(atdma->memset_pool, GFP_ATOMIC,
-   &desc->memset_paddr);
-   if (!desc->memset_vaddr) {
-   dev_err(chan2dev(chan), "%s: couldn't allocate buffer\n",
-   __func__);
-   goto err_put_desc;
-   }
-
-   *desc->memset_vaddr = value;
-   desc->memset = true;
-
-   desc->lli.saddr = desc->memset_paddr;
-   desc->lli.daddr = dest;
-   desc->lli.ctrla = ctrla | xfer_count;
-   desc->lli.ctrlb = ctrlb;
+   desc->memset_paddr = pad

[PATCH v2 0/2] dmaengine: hdmac: Add scatter-gathered memset support

2015-10-22 Thread Maxime Ripard
Hi Vinod,

Here is a patch serie that adds support in the Atmel HDMAC for memset
over a discontiguous memory area.

Just like for the memset, it's used on those SoCs to support
framebuffer related operations that cannot be performed either by the
display engine or the (non-existent) GPU.

Let me know what you think,
Maxime

Changes from v1:
  - Cosmetic change in the first patch to not wrap a line anymore
  - Rebased on top of current dma/next

Maxime Ripard (2):
  dmaengine: hdmac: factorise memset descriptor allocation
  dmaengine: hdmac: Add scatter-gathered memset support

 drivers/dma/at_hdmac.c  | 168 ++--
 drivers/dma/at_hdmac_regs.h |   2 +-
 2 files changed, 133 insertions(+), 37 deletions(-)

-- 
2.6.2

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


Re: [PATCH] x86/spinlocks: Avoid a deadlock when someone unlock a zapped ticked spinlock

2015-10-22 Thread Petr Mladek
On Wed 2015-10-21 13:11:20, Peter Zijlstra wrote:
> On Wed, Oct 21, 2015 at 11:18:09AM +0200, Petr Mladek wrote:
> > There are few situations when we reinitialize (zap) ticket spinlocks. It
> > typically happens when the system is going down after an error and we
> > want to avoid deadlock in some important services. For example,
> > zap_locks() in printk.c and ioapic_zap_locks().
> 
> So there's a few problems here. On x86 the code you patch is dead code,
> x86 no longer uses ticket locks. Other archs might still.
>
> And I entirely detest adding instructions to any lock path, be it the
> utmost fast path or not, for something that will _never_ happen (on a
> healthy system).

OK

> I would still very much recommend getting rid of the need for
> zap_locks() in the first place.
>
> What I did back when is punt on the whole printk buffer madness and dump
> things to early_printk() without any locking.

My problem with this approach is that the early console is a black hole if
people do not watch it on a remote machine. We would stop using the
really used console even when it would work in most cases. IMHO,
zap_locks() is far from ideal but it would give better results in most
cases.

Maybe, we could add support to use early console in case of Oops and
panic. But we should not do this by default. It would help, especially
when the problem is reproducible and we get stacked with the normal
console.


> I think that as long as the printk buffer has locks you have to accept
> to loose some data when really bad stuff goes down.

Yup, but we could try a bit harder. I am afraid that lockless buffer,
e.g. ring_buffer is not an option here because it would be too complex,
rather slow, and hard to handle in a crash dump.

Thanks a lot for feedback.


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


[PATCH v4 00/10] Add Intel FieldsPeak NFC solution driver

2015-10-22 Thread Robert Dolca
These patches add support for Intel's FieldsPeak NFC solution.

Fields Peak complies with the ISO/IEC 14443A/B, 15693, 18092,
and JIS X 6319-4. It is an NCI based controller.

RF Protocols supported:
 - NFC Forum Type 1 Tags (Jewel, Topaz)
 - NFC Forum Type 2 Tags (Mifare UL)
 - NFC Forum Type 3 Tags (FeliCa)
 - NFC Forum Type 4A (ISO/IEC 14443 A-4 106kbps to 848kbps)
 - NFC Forum Type 4B (ISO/IEC 14443 B-4 106kbps to 848kbps)
 - NFCIP in passive and active modes (ISO/IEC 18092 106kbps to 424kbps)
 - B’ (based on ISO/IEC 14443 B-2)
 - iCLASS (based on ISO/IEC 15693-2)
 - Vicinity cards (ISO/IEC 15693-3)
 - Kovio tags (NFC Forum Type 2)

The device can be enumerated using ACPI using the id INT339A.
The 1st GPIO is the IRQ and the 2nd is the RESET pin.


Changes since v3:
 - replace u32 with le32 where appropriate
 - make nci_prop_ops struct instances static
 - simplify return for fdp_nci_setup and fdp_nci_post_setup
 - change return type from u8 to int for nci_conn_max_data_pkt_payload_size
 - set FDP_NCI_I2C_MAX_PAYLOAD to 261 (255 + NCI header (3) + lrc(2) + size 
byte)
 - add sleep during patching to make sure that the NFCC processed the last data 
packet
 - patch droped "nfc: nci: Use a separate mutex for nci open and close"
 - patch droped "nfc: nci: Add a parameter to get the new connection id"
 - add patch "nfc: nci: fix possible crash in nci_core_conn_create"
 - add patch "nfc: nci: add nci_get_conn_info_by_id function"
 - add patch "nfc: nci: rename nci_prop_ops to nci_driver_ops"
 - edit "ecee665 nfc: nci: Allow the driver to set handler for core nci ops" to
   add wrappers for core ops and prop ops in order to simplify the code
 - removed "atomic_t intercept;" from fdp_nci_info struct
 - make functions inline: fdp_nci_get_versions, fdp_nci_patch_cmd, 
fdp_nci_set_production_data
 - moved otp and ram patching to separate functions that are called from 
fdp_nci_post_setup

Changes since v2:
 - rename reset gpio to power gpio because it really is a power switch
 - use named gpio for power with fallback to the indexed gpio 0
 - use device managed gpio for power
 - rely on the i2c subsystem to fill in the irq field of the i2c_client struct
 - remove the internal driver state (the nfc subsystem takes care of what
   we need)
 - removed the power status field (not needed any more)
 - change i2c / device tree id name s/INT339A/int339a
 - make clock type and clock frequency configurable with device properties
   (use defauls if not set)
 - firmware vendor specific commands configurable with device properties
   (default none)
 - other small fixes

Changes since v1:
 - removed .owner
 - made local functions static
 - droped "NFC: NCI: Adds NCI init and reset API for drivers"
 - replaced nfc_info with dev_dbg
 - make controller setup possible without OTP patch
 - retoved the commint that was adding nci_init/reset and using
   the newly added functions nci_core_init/reset
 - fixed typo and use full controller name instead of abreviation in Kconfig
 - added more info about the controller in the commit message
 - moved NCI_OP_CORE_RESET_NTF, NCI_OP_CORE_GET_CONFIG_RSP and
   NCI_OP_CORE_GET_CONFIG_CMD into the core header files
 - added MODULE_DEVICE_TABLE for ACPI
 - defined FDP_FW_UPDATE_DEST 0xC2
 - release the firmware buffers
 - settings the vendor configuration and clock on post setup
 - platform data enumerations removed (ACPI enumeration left)
 - packet reception intercept logic remove
 - nci: removed nci_send_cmd symbol export
 - nci: removed nci_request_driver and nci_req_complete_driver
 - removed mutex from driver (no need for it)
 - nci: check the setup return code before callig post_setup
 - nci: add function to allow sending core commands from driver
 - nci: Use a separate mutex for nci open and close
 - nci: mutex for: Adds a way to get the new connection ID
 - nci: Allow the driver to set handler for core nci ops


Robert Dolca (10):
  nfc: nci: Export nci data send API
  nfc: nci: Add function to get max packet size for conn
  nfc: nci: Introduce new core opcodes
  nfc: nci: Do not call post_setup when setup fails
  nfc: nci: Introduce nci_core_cmd
  nfc: nci: Allow the driver to set handler for core nci ops
  nfc: nci: rename nci_prop_ops to nci_driver_ops
  nfc: nci: fix possible crash in nci_core_conn_create
  nfc: nci: add nci_get_conn_info_by_id function
  nfc: Add Intel Fields Peak NFC solution driver

 drivers/nfc/Kconfig|   1 +
 drivers/nfc/Makefile   |   1 +
 drivers/nfc/fdp/Kconfig|  23 ++
 drivers/nfc/fdp/Makefile   |   9 +
 drivers/nfc/fdp/fdp.c  | 817 +
 drivers/nfc/fdp/fdp.h  |  38 +++
 drivers/nfc/fdp/i2c.c  | 388 +
 drivers/nfc/s3fwrn5/nci.c  |   4 +-
 drivers/nfc/st-nci/core.c  |   2 +-
 include/net/nfc/nci.h  |   7 +
 include/net/nfc/nci_core.h |  18 +-
 net/nfc/nci/core.c | 120 +--
 net/nfc/nci/data.c |  13 +
 net/nfc/nci/ntf.c  |   3 +-
 net/nfc/nci/r

Re: Problem about CPU stalling in hrtimer_intterrupts()

2015-10-22 Thread Ding Tianhong
On 2015/10/22 15:43, Thomas Gleixner wrote:
> On Thu, 22 Oct 2015, Yang Yingliang wrote:
>> I use the kernel-4.1.6 running on arm64.
>> My testcase is that it calls clock_settime and clock_adjtime alternately with
>> random params on each core. My system has 32 cores.
>>
>> I found the cpu stalling in  hrtimer_intterrupts(). So I added some debug 
>> info
>> in hrtimer_intterrupts() and found that the while loop runs 1020437660 times
>> and takes 98761 jiffies(HZ=250).
>>
>> Some debug log is here:
>> ---start---
>> Jan 01 00:03:32 Linux kernel: i:0 basenow.tv64:4809284991830
>> hrtimer_get_softexpires_tv64(timer):444012000 ccpu0
>> timer:ffdffdec6138, timer->function:ffc000129b84
>> Jan 01 00:03:32 Linux kernel: i:0 basenow.tv64:4809284991830
>> hrtimer_get_softexpires_tv64(timer):444012000 ccpu0
> 
> Something is rearming a timer over and over with expiry time in the
> past.
> 
> Thanks,
> 
>   tglx
> 


Hi Thomas:

This problem could only occur on the system with 32 cores, when I cut the cores 
to 16, this problem disappeared, 
so I think there is some parallel problem when the 32 core set clock time 
together:

I try to reproduce the scene:

1.do_settimeofday64
2.update tk time
3.update base time offset
4.update expires_next

the 3 and 4 will be called in softirq, but the hrtimer_interrupt may break the 
order and run before 3, I am not
sure whether this could make the problem, do we need to update base time and 
expires_next in the hrtimer_interrupt?
maybe I miss something, thanks for any suggestion.

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 93ef7190..9adab23 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1254,6 +1254,7 @@ void hrtimer_interrupt(struct clock_event_device *dev)

raw_spin_lock(&cpu_base->lock);
entry_time = now = hrtimer_update_base(cpu_base);
+ hrtimer_force_reprogram(cpu_base, 0);
retry:
cpu_base->in_hrtirq = 1;


Thanks

Ding


> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 


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


Re: [PATCH 14/19] ARM: dts: shmobile/r8a7xxx: replace gpio-key,wakeup with wakeup-source property

2015-10-22 Thread Sudeep Holla



On 22/10/15 01:50, Simon Horman wrote:

On Wed, Oct 21, 2015 at 11:23:03AM +0100, Sudeep Holla wrote:



On 21/10/15 11:18, Geert Uytterhoeven wrote:

On Wed, Oct 21, 2015 at 12:10 PM, Sudeep Holla  wrote:

Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.

This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any futher copy-paste
duplication.


Thanks!

I made the same changes to my local tree a few weeks ago, but never found
time to send them out...



Ah OK, even I had these changes for long. I waited until I fixed all the
binding documents(which was boring ;))


Cc: Simon Horman 
Cc: Magnus Damm 
Cc: linux...@vger.kernel.org
Signed-off-by: Sudeep Holla 


Acked-by: Geert Uytterhoeven 


Can I clarify that you would like me to pick up this patch?
If so I'm happy to do so.



Yes you can pick up this patch as it has no dependency on driver changes.


Else:

Acked-by: Simon Horman 



Thanks.

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


Re: [Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

2015-10-22 Thread Darren Hart
Bruno, can you please have a look at the following regression attributed to:

4eebd5a apple-gmux: lock iGP IO to protect from vgaarb changes
 2015-03-18 (7 months ago), Bruno Prémont 


On Thu, Oct 15, 2015 at 04:47:13AM +, bugzilla-dae...@bugzilla.kernel.org 
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=105051
> 
> Felipe Ortiz  changed:
> 
>What|Removed |Added
> 
>  CC||fort...@gmail.com
> 
> --- Comment #14 from Felipe Ortiz  ---
> I can confirm the problem with 4eebd5a4e72697aac25a8a57d3f888a9d5f80370. I 
> have
> a MPB 11,5 with AMD/Intel graphics. I recompile the module (a previous version
> of 4eebd5a4e72697aac25a8a57d3f888a9d5f80370) and brightness adjusts is working
> again.
> 
> I see two problems: 
> 
> 1) If someone uses gpu-switch (https://github.com/0xbb/gpu-switch) with this
> bug screen seem not work, after severals reboots (with different kernels) I 
> can
> access a terminal and execute gpu-switch -d and then screen seems work again.
> 
> 2) If you use a Intel card (swiched with gpu-switch) the OSD (activated with
> functions keys) is so slow and chromium have the same problem (temporary fix 
> is
> deactivate chromium hw acceleration) is this a intel driver bug?
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
> 

Thanks,

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


[PATCH v4 02/10] nfc: nci: Add function to get max packet size for conn

2015-10-22 Thread Robert Dolca
FDP driver needs to send the firmware as regular packets
(not fragmented). The driver should have a way to
get the max packet size for a given connection.

Signed-off-by: Robert Dolca 
---
 include/net/nfc/nci_core.h |  1 +
 net/nfc/nci/data.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index d0d0f1e..aaada20 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -351,6 +351,7 @@ int nci_prop_ntf_packet(struct nci_dev *ndev, __u16 opcode,
 void nci_rx_data_packet(struct nci_dev *ndev, struct sk_buff *skb);
 int nci_send_cmd(struct nci_dev *ndev, __u16 opcode, __u8 plen, void *payload);
 int nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb);
+int nci_conn_max_data_pkt_payload_size(struct nci_dev *ndev, __u8 conn_id);
 void nci_data_exchange_complete(struct nci_dev *ndev, struct sk_buff *skb,
__u8 conn_id, int err);
 void nci_hci_data_received_cb(void *context, struct sk_buff *skb, int err);
diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
index 83acd18..dbd2425 100644
--- a/net/nfc/nci/data.c
+++ b/net/nfc/nci/data.c
@@ -90,6 +90,18 @@ static inline void nci_push_data_hdr(struct nci_dev *ndev,
nci_pbf_set((__u8 *)hdr, pbf);
 }
 
+int nci_conn_max_data_pkt_payload_size(struct nci_dev *ndev, __u8 conn_id)
+{
+   struct nci_conn_info *conn_info;
+
+   conn_info = nci_get_conn_info_by_conn_id(ndev, conn_id);
+   if (!conn_info)
+   return -EPROTO;
+
+   return conn_info->max_pkt_payload_len;
+}
+EXPORT_SYMBOL(nci_conn_max_data_pkt_payload_size);
+
 static int nci_queue_tx_data_frags(struct nci_dev *ndev,
   __u8 conn_id,
   struct sk_buff *skb) {
-- 
1.9.1

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


[PATCH v4 01/10] nfc: nci: Export nci data send API

2015-10-22 Thread Robert Dolca
For the firmware update the driver may use nci_send_data.

Signed-off-by: Robert Dolca 
---
 net/nfc/nci/data.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
index 566466d..83acd18 100644
--- a/net/nfc/nci/data.c
+++ b/net/nfc/nci/data.c
@@ -203,6 +203,7 @@ free_exit:
 exit:
return rc;
 }
+EXPORT_SYMBOL(nci_send_data);
 
 /* - NCI RX Data - */
 
-- 
1.9.1

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


Re: [PATCH 5/5] block: enable dax for raw block devices

2015-10-22 Thread Jan Kara
On Thu 22-10-15 02:42:11, Dan Williams wrote:
> If an application wants exclusive access to all of the persistent memory
> provided by an NVDIMM namespace it can use this raw-block-dax facility
> to forgo establishing a filesystem.  This capability is targeted
> primarily to hypervisors wanting to provision persistent memory for
> guests.
> 
> Cc: Jan Kara 
> Cc: Jeff Moyer 
> Cc: Christoph Hellwig 
> Cc: Dave Chinner 
> Cc: Andrew Morton 
> Cc: Ross Zwisler 
> Signed-off-by: Dan Williams 
> ---
>  fs/block_dev.c |   54 +-
>  1 file changed, 53 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/block_dev.c b/fs/block_dev.c
> index 3255dcec96b4..c27cd1a21a13 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -1687,13 +1687,65 @@ static const struct address_space_operations 
> def_blk_aops = {
>   .is_dirty_writeback = buffer_check_dirty_writeback,
>  };
>  
> +#ifdef CONFIG_FS_DAX
> +/*
> + * In the raw block case we do not need to contend with truncation nor
> + * unwritten file extents.  Without those concerns there is no need for
> + * additional locking beyond the mmap_sem context that these routines
> + * are already executing under.
> + *
> + * Note, there is no protection if the block device is dynamically
> + * resized (partition grow/shrink) during a fault. A stable block device
> + * size is already not enforced in the blkdev_direct_IO path.
> + *
> + * For DAX, it is the responsibility of the block device driver to
> + * ensure the whole-disk device size is stable while requests are in
> + * flight.
> + *
> + * Finally, these paths do not synchronize against freezing
> + * (sb_start_pagefault(), etc...) since bdev_sops does not support
> + * freezing.

Well, for devices freezing is handled directly in the block layer code
(blk_stop_queue()) since there's no need to put some metadata structures
into a consistent state. So the comment about bdev_sops is somewhat
strange. Otherwise the patch looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza
 
> + */
> +static int blkdev_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> +{
> + return __dax_fault(vma, vmf, blkdev_get_block, NULL);
> +}
> +
> +static int blkdev_dax_pmd_fault(struct vm_area_struct *vma, unsigned long 
> addr,
> + pmd_t *pmd, unsigned int flags)
> +{
> + return __dax_pmd_fault(vma, addr, pmd, flags, blkdev_get_block, NULL);
> +}
> +
> +static const struct vm_operations_struct blkdev_dax_vm_ops = {
> + .page_mkwrite   = blkdev_dax_fault,
> + .fault  = blkdev_dax_fault,
> + .pmd_fault  = blkdev_dax_pmd_fault,
> +};
> +
> +static int blkdev_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + struct inode *bd_inode = file_bd_inode(file);
> +
> + if (!IS_DAX(bd_inode))
> + return generic_file_mmap(file, vma);
> +
> + file_accessed(file);
> + vma->vm_ops = &blkdev_dax_vm_ops;
> + vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE;
> + return 0;
> +}
> +#else
> +#define blkdev_mmap generic_file_mmap
> +#endif
> +
>  const struct file_operations def_blk_fops = {
>   .open   = blkdev_open,
>   .release= blkdev_close,
>   .llseek = block_llseek,
>   .read_iter  = blkdev_read_iter,
>   .write_iter = blkdev_write_iter,
> - .mmap   = generic_file_mmap,
> + .mmap   = blkdev_mmap,
>   .fsync  = blkdev_fsync,
>   .unlocked_ioctl = block_ioctl,
>  #ifdef CONFIG_COMPAT
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v4 06/10] nfc: nci: Allow the driver to set handler for core nci ops

2015-10-22 Thread Robert Dolca
The driver may be required to act when some responses or notifications
arrive. For example the NCI core does not have a handler for
NCI_OP_CORE_GET_CONFIG_RSP. The NFCC can send a config response that has
to be read by the driver and the packet may contain vendor specific data.

The Fields Peak driver needs to take certain actions when a reset
notification arrives (packet also not handled by the nfc core).

The driver handlers do not interfere with the core and they are called
after the core processes the packet.

Signed-off-by: Robert Dolca 
---
 include/net/nfc/nci_core.h | 11 +--
 net/nfc/nci/core.c | 71 +-
 net/nfc/nci/ntf.c  |  3 +-
 net/nfc/nci/rsp.c  |  1 +
 4 files changed, 63 insertions(+), 23 deletions(-)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 4ca1b6d..d5a1caa 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -96,6 +96,9 @@ struct nci_ops {
 
struct nci_prop_ops *prop_ops;
size_t n_prop_ops;
+
+   struct nci_prop_ops *core_ops;
+   size_t n_core_ops;
 };
 
 #define NCI_MAX_SUPPORTED_RF_INTERFACES4
@@ -345,9 +348,13 @@ static inline int nci_set_vendor_cmds(struct nci_dev *ndev,
 
 void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff *skb);
 void nci_ntf_packet(struct nci_dev *ndev, struct sk_buff *skb);
-int nci_prop_rsp_packet(struct nci_dev *ndev, __u16 opcode,
+inline int nci_prop_rsp_packet(struct nci_dev *ndev, __u16 opcode,
+   struct sk_buff *skb);
+inline int nci_prop_ntf_packet(struct nci_dev *ndev, __u16 opcode,
+   struct sk_buff *skb);
+inline int nci_core_rsp_packet(struct nci_dev *ndev, __u16 opcode,
struct sk_buff *skb);
-int nci_prop_ntf_packet(struct nci_dev *ndev, __u16 opcode,
+inline int nci_core_ntf_packet(struct nci_dev *ndev, __u16 opcode,
struct sk_buff *skb);
 void nci_rx_data_packet(struct nci_dev *ndev, struct sk_buff *skb);
 int nci_send_cmd(struct nci_dev *ndev, __u16 opcode, __u8 plen, void *payload);
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 5b4f48a..30c2708 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -1242,46 +1242,77 @@ int nci_send_cmd(struct nci_dev *ndev, __u16 opcode, 
__u8 plen, void *payload)
 }
 
 /* Proprietary commands API */
-static struct nci_prop_ops *prop_cmd_lookup(struct nci_dev *ndev,
-   __u16 opcode)
+static struct nci_prop_ops *ops_cmd_lookup(struct nci_prop_ops *ops,
+  size_t n_ops,
+  __u16 opcode)
 {
size_t i;
-   struct nci_prop_ops *prop_op;
+   struct nci_prop_ops *op;
 
-   if (!ndev->ops->prop_ops || !ndev->ops->n_prop_ops)
+   if (!ops || !n_ops)
return NULL;
 
-   for (i = 0; i < ndev->ops->n_prop_ops; i++) {
-   prop_op = &ndev->ops->prop_ops[i];
-   if (prop_op->opcode == opcode)
-   return prop_op;
+   for (i = 0; i < n_ops; i++) {
+   op = &ops[i];
+   if (op->opcode == opcode)
+   return op;
}
 
return NULL;
 }
 
-int nci_prop_rsp_packet(struct nci_dev *ndev, __u16 rsp_opcode,
-   struct sk_buff *skb)
+static int nci_op_rsp_packet(struct nci_dev *ndev, __u16 rsp_opcode,
+struct sk_buff *skb, struct nci_prop_ops *ops,
+size_t n_ops)
 {
-   struct nci_prop_ops *prop_op;
+   struct nci_prop_ops *op;
 
-   prop_op = prop_cmd_lookup(ndev, rsp_opcode);
-   if (!prop_op || !prop_op->rsp)
+   op = ops_cmd_lookup(ops, n_ops, rsp_opcode);
+   if (!op || !op->rsp)
return -ENOTSUPP;
 
-   return prop_op->rsp(ndev, skb);
+   return op->rsp(ndev, skb);
 }
 
-int nci_prop_ntf_packet(struct nci_dev *ndev, __u16 ntf_opcode,
-   struct sk_buff *skb)
+static int nci_op_ntf_packet(struct nci_dev *ndev, __u16 ntf_opcode,
+struct sk_buff *skb, struct nci_prop_ops *ops,
+size_t n_ops)
 {
-   struct nci_prop_ops *prop_op;
+   struct nci_prop_ops *op;
 
-   prop_op = prop_cmd_lookup(ndev, ntf_opcode);
-   if (!prop_op || !prop_op->ntf)
+   op = ops_cmd_lookup(ops, n_ops, ntf_opcode);
+   if (!op || !op->ntf)
return -ENOTSUPP;
 
-   return prop_op->ntf(ndev, skb);
+   return op->ntf(ndev, skb);
+}
+
+inline int nci_prop_rsp_packet(struct nci_dev *ndev, __u16 opcode,
+  struct sk_buff *skb)
+{
+   return nci_op_rsp_packet(ndev, opcode, skb, ndev->ops->prop_ops,
+ndev->ops->n_prop_ops);
+}
+
+inline int nci_prop_ntf_packet(struct nci_dev *ndev, __u16 opcode,
+  st

[PATCH v4 07/10] nfc: nci: rename nci_prop_ops to nci_driver_ops

2015-10-22 Thread Robert Dolca
Initially it was used to create hooks in the driver for proprietary
operations. Currently it is being used for hooks for both proprietary
and generic operations.

Signed-off-by: Robert Dolca 
---
 drivers/nfc/s3fwrn5/nci.c  |  4 ++--
 drivers/nfc/st-nci/core.c  |  2 +-
 include/net/nfc/nci_core.h |  6 +++---
 net/nfc/nci/core.c | 16 
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/nfc/s3fwrn5/nci.c b/drivers/nfc/s3fwrn5/nci.c
index ace0071..075e4e8 100644
--- a/drivers/nfc/s3fwrn5/nci.c
+++ b/drivers/nfc/s3fwrn5/nci.c
@@ -31,7 +31,7 @@ static int s3fwrn5_nci_prop_rsp(struct nci_dev *ndev, struct 
sk_buff *skb)
return 0;
 }
 
-static struct nci_prop_ops s3fwrn5_nci_prop_ops[] = {
+static struct nci_driver_ops s3fwrn5_nci_prop_ops[] = {
{
.opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
NCI_PROP_AGAIN),
@@ -79,7 +79,7 @@ static struct nci_prop_ops s3fwrn5_nci_prop_ops[] = {
},
 };
 
-void s3fwrn5_nci_get_prop_ops(struct nci_prop_ops **ops, size_t *n)
+void s3fwrn5_nci_get_prop_ops(struct nci_driver_ops **ops, size_t *n)
 {
*ops = s3fwrn5_nci_prop_ops;
*n = ARRAY_SIZE(s3fwrn5_nci_prop_ops);
diff --git a/drivers/nfc/st-nci/core.c b/drivers/nfc/st-nci/core.c
index c419d39..dd7b1c14 100644
--- a/drivers/nfc/st-nci/core.c
+++ b/drivers/nfc/st-nci/core.c
@@ -98,7 +98,7 @@ static int st_nci_prop_rsp_packet(struct nci_dev *ndev,
return 0;
 }
 
-static struct nci_prop_ops st_nci_prop_ops[] = {
+static struct nci_driver_ops st_nci_prop_ops[] = {
{
.opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
  ST_NCI_CORE_PROP),
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index d5a1caa..5daf004 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -67,7 +67,7 @@ enum nci_state {
 
 struct nci_dev;
 
-struct nci_prop_ops {
+struct nci_driver_ops {
__u16 opcode;
int (*rsp)(struct nci_dev *dev, struct sk_buff *skb);
int (*ntf)(struct nci_dev *dev, struct sk_buff *skb);
@@ -94,10 +94,10 @@ struct nci_ops {
void  (*hci_cmd_received)(struct nci_dev *ndev, u8 pipe, u8 cmd,
  struct sk_buff *skb);
 
-   struct nci_prop_ops *prop_ops;
+   struct nci_driver_ops *prop_ops;
size_t n_prop_ops;
 
-   struct nci_prop_ops *core_ops;
+   struct nci_driver_ops *core_ops;
size_t n_core_ops;
 };
 
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 30c2708..f66a5da 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -1242,12 +1242,12 @@ int nci_send_cmd(struct nci_dev *ndev, __u16 opcode, 
__u8 plen, void *payload)
 }
 
 /* Proprietary commands API */
-static struct nci_prop_ops *ops_cmd_lookup(struct nci_prop_ops *ops,
-  size_t n_ops,
-  __u16 opcode)
+static struct nci_driver_ops *ops_cmd_lookup(struct nci_driver_ops *ops,
+size_t n_ops,
+__u16 opcode)
 {
size_t i;
-   struct nci_prop_ops *op;
+   struct nci_driver_ops *op;
 
if (!ops || !n_ops)
return NULL;
@@ -1262,10 +1262,10 @@ static struct nci_prop_ops *ops_cmd_lookup(struct 
nci_prop_ops *ops,
 }
 
 static int nci_op_rsp_packet(struct nci_dev *ndev, __u16 rsp_opcode,
-struct sk_buff *skb, struct nci_prop_ops *ops,
+struct sk_buff *skb, struct nci_driver_ops *ops,
 size_t n_ops)
 {
-   struct nci_prop_ops *op;
+   struct nci_driver_ops *op;
 
op = ops_cmd_lookup(ops, n_ops, rsp_opcode);
if (!op || !op->rsp)
@@ -1275,10 +1275,10 @@ static int nci_op_rsp_packet(struct nci_dev *ndev, 
__u16 rsp_opcode,
 }
 
 static int nci_op_ntf_packet(struct nci_dev *ndev, __u16 ntf_opcode,
-struct sk_buff *skb, struct nci_prop_ops *ops,
+struct sk_buff *skb, struct nci_driver_ops *ops,
 size_t n_ops)
 {
-   struct nci_prop_ops *op;
+   struct nci_driver_ops *op;
 
op = ops_cmd_lookup(ops, n_ops, ntf_opcode);
if (!op || !op->ntf)
-- 
1.9.1

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


Re: [PATCH net-next RFC 2/2] vhost_net: basic polling support

2015-10-22 Thread Michael S. Tsirkin
On Thu, Oct 22, 2015 at 01:27:29AM -0400, Jason Wang wrote:
> This patch tries to poll for new added tx buffer for a while at the
> end of tx processing. The maximum time spent on polling were limited
> through a module parameter. To avoid block rx, the loop will end it
> there's new other works queued on vhost so in fact socket receive
> queue is also be polled.
> 
> busyloop_timeout = 50 gives us following improvement on TCP_RR test:
> 
> size/session/+thu%/+normalize%
> 1/ 1/   +5%/  -20%
> 1/50/  +17%/   +3%

Is there a measureable increase in cpu utilization
with busyloop_timeout = 0?

> Signed-off-by: Jason Wang 

We might be able to shave off the minor regression
by careful use of likely/unlikely, or maybe
deferring 

> ---
>  drivers/vhost/net.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 9eda69e..bbb522a 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -31,7 +31,9 @@
>  #include "vhost.h"
>  
>  static int experimental_zcopytx = 1;
> +static int busyloop_timeout = 50;
>  module_param(experimental_zcopytx, int, 0444);
> +module_param(busyloop_timeout, int, 0444);

Pls add a description, including the units and the special
value 0.

>  MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
>  " 1 -Enable; 0 - Disable");
>  
> @@ -287,12 +289,23 @@ static void vhost_zerocopy_callback(struct ubuf_info 
> *ubuf, bool success)
>   rcu_read_unlock_bh();
>  }
>  
> +static bool tx_can_busy_poll(struct vhost_dev *dev,
> +  unsigned long endtime)
> +{
> + unsigned long now = local_clock() >> 10;

local_clock might go backwards if we jump between CPUs.
One way to fix would be to record the CPU id and break
out of loop if that changes.

Also - defer this until we actually know we need it?

> +
> + return busyloop_timeout && !need_resched() &&
> +!time_after(now, endtime) && !vhost_has_work(dev) &&
> +single_task_running();

signal pending as well?

> +}
> +
>  /* Expects to be always run from workqueue - which acts as
>   * read-size critical section for our kind of RCU. */
>  static void handle_tx(struct vhost_net *net)
>  {
>   struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
>   struct vhost_virtqueue *vq = &nvq->vq;
> + unsigned long endtime;
>   unsigned out, in;
>   int head;
>   struct msghdr msg = {
> @@ -331,6 +344,8 @@ static void handle_tx(struct vhost_net *net)
> % UIO_MAXIOV == nvq->done_idx))
>   break;
>  
> + endtime  = (local_clock() >> 10) + busyloop_timeout;
> +again:
>   head = vhost_get_vq_desc(vq, vq->iov,
>ARRAY_SIZE(vq->iov),
>&out, &in,
> @@ -340,6 +355,10 @@ static void handle_tx(struct vhost_net *net)
>   break;
>   /* Nothing new?  Wait for eventfd to tell us they refilled. */
>   if (head == vq->num) {
> + if (tx_can_busy_poll(vq->dev, endtime)) {
> + cpu_relax();
> + goto again;
> + }
>   if (unlikely(vhost_enable_notify(&net->dev, vq))) {
>   vhost_disable_notify(&net->dev, vq);
>   continue;
> -- 
> 1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH for-next] EDAC: fix misuse of PAGES_TO_MiB macros

2015-10-22 Thread Borislav Petkov
On Tue, Oct 20, 2015 at 07:45:38PM +0800, Tan Xiaojun wrote:
> The PAGES_TO_MiB macros is only used for unit conversion.
> 
> Signed-off-by: Tan Xiaojun 
> ---
>  drivers/edac/edac_mc.c   | 2 +-
>  drivers/edac/ghes_edac.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
> index 943ed8c..77ecd6a 100644
> --- a/drivers/edac/edac_mc.c
> +++ b/drivers/edac/edac_mc.c
> @@ -1302,7 +1302,7 @@ void edac_mc_handle_error(const enum 
> hw_event_mc_err_type type,
>   grain_bits = fls_long(e->grain) + 1;
>   trace_mc_event(type, e->msg, e->label, e->error_count,
>  mci->mc_idx, e->top_layer, e->mid_layer, e->low_layer,
> -PAGES_TO_MiB(e->page_frame_number) | e->offset_in_page,
> +(e->page_frame_number << PAGE_SHIFT) | e->offset_in_page,
>  grain_bits, e->syndrome, e->other_detail);
>  
>   edac_raw_mc_handle_error(type, mci, e);
> diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
> index b1e4512..e3fa439 100644
> --- a/drivers/edac/ghes_edac.c
> +++ b/drivers/edac/ghes_edac.c
> @@ -397,7 +397,7 @@ void ghes_edac_report_mem_error(struct ghes *ghes, int 
> sev,
>"APEI location: %s %s", e->location, e->other_detail);
>   trace_mc_event(type, e->msg, e->label, e->error_count,
>  mci->mc_idx, e->top_layer, e->mid_layer, e->low_layer,
> -PAGES_TO_MiB(e->page_frame_number) | e->offset_in_page,
> +(e->page_frame_number << PAGE_SHIFT) | e->offset_in_page,
>  grain_bits, e->syndrome, pvt->detail_location);
>  
>   /* Report the error via EDAC API */
> -- 

Applied, thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v4 2/2] i2c: add ACPI support for I2C mux ports

2015-10-22 Thread Dustin Byford
Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
device property compatible string match), enumerating I2C client devices
connected through an I2C mux needs a little extra work.

This change implements a method for describing an I2C device hierarchy that
includes mux devices by using an ACPI Device() for each mux channel along
with an _ADR to set the channel number for the device.  See
Documentation/acpi/i2c-muxes.txt for a simple example.

To make this work the ismt, i801, and designware pci/platform devs now
share an ACPI companion with their I2C adapter dev similar to how it's done
in OF.  This is done on the assumption that power management functions will
not be called directly on the I2C dev that is sharing the ACPI node.

Signed-off-by: Dustin Byford 
---
 Documentation/acpi/i2c-muxes.txt| 58 +
 drivers/i2c/busses/i2c-designware-pcidrv.c  |  1 +
 drivers/i2c/busses/i2c-designware-platdrv.c |  6 ++-
 drivers/i2c/busses/i2c-i801.c   |  9 ++---
 drivers/i2c/busses/i2c-ismt.c   |  8 +---
 drivers/i2c/i2c-core.c  |  4 +-
 drivers/i2c/i2c-mux.c   |  8 
 7 files changed, 78 insertions(+), 16 deletions(-)
 create mode 100644 Documentation/acpi/i2c-muxes.txt

diff --git a/Documentation/acpi/i2c-muxes.txt b/Documentation/acpi/i2c-muxes.txt
new file mode 100644
index 000..9fcc4f0
--- /dev/null
+++ b/Documentation/acpi/i2c-muxes.txt
@@ -0,0 +1,58 @@
+ACPI I2C Muxes
+--
+
+Describing an I2C device hierarchy that includes I2C muxes requires an ACPI
+Device () scope per mux channel.
+
+Consider this topology:
+
++--+   +--+
+| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
+|  |   | 0x70 |--CH01--> i2c client B (0x50)
++--+   +--+
+
+which corresponds to the following ASL:
+
+Device (SMB1)
+{
+Name (_HID, ...)
+Device (MUX0)
+{
+Name (_HID, ...)
+Name (_CRS, ResourceTemplate () {
+I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
+  AddressingMode7Bit, "^SMB1", 0x00,
+  ResourceConsumer,,)
+}
+
+Device (CH00)
+{
+Name (_ADR, 0)
+
+Device (CLIA)
+{
+Name (_HID, ...)
+Name (_CRS, ResourceTemplate () {
+I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
+  AddressingMode7Bit, "^CH00", 0x00,
+  ResourceConsumer,,)
+}
+}
+}
+
+Device (CH01)
+{
+Name (_ADR, 1)
+
+Device (CLIB)
+{
+Name (_HID, ...)
+Name (_CRS, ResourceTemplate () {
+I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
+  AddressingMode7Bit, "^CH01", 0x00,
+  ResourceConsumer,,)
+}
+}
+}
+}
+}
diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c 
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index df23e8c..5b9dcdb 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -256,6 +256,7 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
adap->class = 0;
adap->algo = &i2c_dw_algo;
adap->dev.parent = &pdev->dev;
+   ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
adap->nr = controller->bus_num;
 
snprintf(adap->name, sizeof(adap->name), "i2c-designware-pci");
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 472b882..9efeac6 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -267,12 +267,14 @@ static int dw_i2c_probe(struct platform_device *pdev)
i2c_set_adapdata(adap, dev);
adap->owner = THIS_MODULE;
adap->class = I2C_CLASS_DEPRECATED;
-   strlcpy(adap->name, "Synopsys DesignWare I2C adapter",
-   sizeof(adap->name));
adap->algo = &i2c_dw_algo;
adap->dev.parent = &pdev->dev;
+   ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
adap->dev.of_node = pdev->dev.of_node;
 
+   strlcpy(adap->name, "Synopsys DesignWare I2C adapter",
+   sizeof(adap->name));
+
if (dev->pm_runtime_disabled) {
pm_runtime_forbid(&pdev->dev);
} else {
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index eaef9bc..d4a6e77 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1251,6 +1251,9 @@ static int i801_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
priv->adapter.owner = THIS_MODULE;
priv->adapter.class = i801_get_adapter_class(priv);
priv->adapter.algo = &smbus_a

[PATCH v4 05/10] nfc: nci: Introduce nci_core_cmd

2015-10-22 Thread Robert Dolca
This allows sending core commands from the driver. The driver should be
able to send NCI core commands like CORE_GET_CONFIG_CMD.

Signed-off-by: Robert Dolca 
---
 include/net/nfc/nci_core.h |  1 +
 net/nfc/nci/core.c | 24 +++-
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index aaada20..4ca1b6d 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -278,6 +278,7 @@ int nci_request(struct nci_dev *ndev,
unsigned long opt),
unsigned long opt, __u32 timeout);
 int nci_prop_cmd(struct nci_dev *ndev, __u8 oid, size_t len, __u8 *payload);
+int nci_core_cmd(struct nci_dev *ndev, __u16 opcode, size_t len, __u8 
*payload);
 int nci_core_reset(struct nci_dev *ndev);
 int nci_core_init(struct nci_dev *ndev);
 
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 5362d8f..5b4f48a 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -325,32 +325,46 @@ static void nci_rf_deactivate_req(struct nci_dev *ndev, 
unsigned long opt)
 sizeof(struct nci_rf_deactivate_cmd), &cmd);
 }
 
-struct nci_prop_cmd_param {
+struct nci_cmd_param {
__u16 opcode;
size_t len;
__u8 *payload;
 };
 
-static void nci_prop_cmd_req(struct nci_dev *ndev, unsigned long opt)
+static void nci_generic_req(struct nci_dev *ndev, unsigned long opt)
 {
-   struct nci_prop_cmd_param *param = (struct nci_prop_cmd_param *)opt;
+   struct nci_cmd_param *param =
+   (struct nci_cmd_param *)opt;
 
nci_send_cmd(ndev, param->opcode, param->len, param->payload);
 }
 
 int nci_prop_cmd(struct nci_dev *ndev, __u8 oid, size_t len, __u8 *payload)
 {
-   struct nci_prop_cmd_param param;
+   struct nci_cmd_param param;
 
param.opcode = nci_opcode_pack(NCI_GID_PROPRIETARY, oid);
param.len = len;
param.payload = payload;
 
-   return __nci_request(ndev, nci_prop_cmd_req, (unsigned long)¶m,
+   return __nci_request(ndev, nci_generic_req, (unsigned long)¶m,
 msecs_to_jiffies(NCI_CMD_TIMEOUT));
 }
 EXPORT_SYMBOL(nci_prop_cmd);
 
+int nci_core_cmd(struct nci_dev *ndev, __u16 opcode, size_t len, __u8 *payload)
+{
+   struct nci_cmd_param param;
+
+   param.opcode = opcode;
+   param.len = len;
+   param.payload = payload;
+
+   return __nci_request(ndev, nci_generic_req, (unsigned long)¶m,
+msecs_to_jiffies(NCI_CMD_TIMEOUT));
+}
+EXPORT_SYMBOL(nci_core_cmd);
+
 int nci_core_reset(struct nci_dev *ndev)
 {
return __nci_request(ndev, nci_reset_req, 0,
-- 
1.9.1

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


[PATCH v11 1/6] arm: add msi.h to Kbuild

2015-10-22 Thread Ley Foon Tan
Include asm-generic/msi.h to support CONFIG_GENERIC_MSI_IRQ_DOMAIN.
This to fix compilation error:
"include/linux/msi.h:123:21: fatal error: asm/msi.h:
No such file or directory"

Signed-off-by: Ley Foon Tan 
---
 arch/arm/include/asm/Kbuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index be648eb..bd42530 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -14,6 +14,7 @@ generic-y += local.h
 generic-y += local64.h
 generic-y += mm-arch-hooks.h
 generic-y += msgbuf.h
+generic-y += msi.h
 generic-y += param.h
 generic-y += parport.h
 generic-y += poll.h
-- 
1.8.2.1

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


[PATCH v11 3/6] pci:host: Add Altera PCIe host controller driver

2015-10-22 Thread Ley Foon Tan
This patch adds the Altera PCIe host controller driver.

Signed-off-by: Ley Foon Tan 
Reviewed-by: Marc Zyngier 
---
 drivers/pci/host/Kconfig   |   8 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pcie-altera.c | 579 +
 3 files changed, 588 insertions(+)
 create mode 100644 drivers/pci/host/pcie-altera.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..a67c9de 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,12 @@ config PCIE_IPROC_BCMA
  Say Y here if you want to use the Broadcom iProc PCIe controller
  through the BCMA bus interface
 
+config PCIE_ALTERA
+   tristate "Altera PCIe controller"
+   depends on ARM || NIOS2
+   select PCI_DOMAINS
+   help
+ Say Y here if you want to enable PCIe controller support on Altera
+ FPGA.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6954f76 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
 obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
+obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
new file mode 100644
index 000..3503d9c
--- /dev/null
+++ b/drivers/pci/host/pcie-altera.c
@@ -0,0 +1,579 @@
+/*
+ * Copyright Altera Corporation (C) 2013-2015. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RP_TX_REG0 0x2000
+#define RP_TX_REG1 0x2004
+#define RP_TX_CNTRL0x2008
+#define RP_TX_EOP  0x2
+#define RP_TX_SOP  0x1
+#define RP_RXCPL_STATUS0x2010
+#define RP_RXCPL_EOP   0x2
+#define RP_RXCPL_SOP   0x1
+#define RP_RXCPL_REG0  0x2014
+#define RP_RXCPL_REG1  0x2018
+#define P2A_INT_STATUS 0x3060
+#define P2A_INT_STS_ALL0xf
+#define P2A_INT_ENABLE 0x3070
+#define P2A_INT_ENA_ALL0xf
+#define RP_LTSSM   0x3c64
+#define LTSSM_L0   0xf
+
+/* TLP configuration type 0 and 1 */
+#define TLP_FMTTYPE_CFGRD0 0x04/* Configuration Read Type 0 */
+#define TLP_FMTTYPE_CFGWR0 0x44/* Configuration Write Type 0 */
+#define TLP_FMTTYPE_CFGRD1 0x05/* Configuration Read Type 1 */
+#define TLP_FMTTYPE_CFGWR1 0x45/* Configuration Write Type 1 */
+#define TLP_PAYLOAD_SIZE   0x01
+#define TLP_READ_TAG   0x1d
+#define TLP_WRITE_TAG  0x10
+#define TLP_CFG_DW0(fmttype)   (((fmttype) << 24) | TLP_PAYLOAD_SIZE)
+#define TLP_CFG_DW1(reqid, tag, be)(((reqid) << 16) | (tag << 8) | (be))
+#define TLP_CFG_DW2(bus, devfn, offset)\
+   (((bus) << 24) | ((devfn) << 16) | (offset))
+#define TLP_REQ_ID(bus, devfn) (((bus) << 8) | (devfn))
+#define TLP_HDR_SIZE   3
+#define TLP_LOOP   500
+
+#define INTX_NUM   4
+
+#define DWORD_MASK 3
+
+struct altera_pcie {
+   struct platform_device  *pdev;
+   void __iomem*cra_base;
+   int irq;
+   u8  root_bus_nr;
+   struct irq_domain   *irq_domain;
+   struct resource bus_range;
+   struct list_headresources;
+};
+
+struct tlp_rp_regpair_t {
+   u32 ctrl;
+   u32 reg0;
+   u32 reg1;
+};
+
+static void altera_pcie_retrain(struct pci_dev *dev)
+{
+   u16 linkcap, linkstat;
+
+   /*
+* Set the retrain bit if the PCIe rootport support > 2.5GB/s, but
+* current speed is 2.5 GB/s.
+*/
+   pcie_capability_read_word(dev, PCI_EXP_LNKCAP, &linkcap);
+
+   if ((linkcap & PCI_EXP_LNKCAP_SLS) <= PCI_EXP_LNKCAP_SLS_2_5GB)
+   return;
+
+   pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &linkstat);
+   

Re: [PATCH 2/5] mmc: omap_hsmmc: Enable omap_hsmmc for Keystone 2

2015-10-22 Thread Ulf Hansson
On 20 October 2015 at 23:50, Franklin S Cooper Jr  wrote:
>
> From: Lokesh Vutla 
>
> Enable omap_hsmmc for Keystone 2 architecture which reuses the HSMMC
> IP found on OMAP platforms.
>
> Signed-off-by: Franklin S Cooper Jr 
> ---
>  drivers/mmc/host/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 8a1e349..2ccec71 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -366,7 +366,7 @@ config MMC_OMAP
>  config MMC_OMAP_HS
> tristate "TI OMAP High Speed Multimedia Card Interface support"
> depends on HAS_DMA
> -   depends on ARCH_OMAP2PLUS || COMPILE_TEST
> +   depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST

How about:
"depends on ARM || COMPILE_TEST"

>
> help
>   This selects the TI OMAP High Speed Multimedia card Interface.
>   If you have an omap2plus board with a Multimedia Card slot,
> --
> 2.6.1
>

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


[PATCH v11 5/6] Documentation: dt-bindings: pci: altera pcie device tree binding

2015-10-22 Thread Ley Foon Tan
This patch adds the bindings for Altera PCIe host controller driver and
Altera PCIe MSI driver.

Signed-off-by: Ley Foon Tan 
---
 .../devicetree/bindings/pci/altera-pcie-msi.txt| 28 +
 .../devicetree/bindings/pci/altera-pcie.txt| 49 ++
 2 files changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt 
b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
new file mode 100644
index 000..09cd3bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
@@ -0,0 +1,28 @@
+* Altera PCIe MSI controller
+
+Required properties:
+- compatible:  should contain "altr,msi-1.0"
+- reg: specifies the physical base address of the controller and
+   the length of the memory mapped region.
+- reg-names:   must include the following entries:
+   "csr": CSR registers
+   "vector_slave": vectors slave port region
+- interrupt-parent:interrupt source phandle.
+- interrupts:  specifies the interrupt source of the parent interrupt
+   controller. The format of the interrupt specifier depends on the
+   parent interrupt controller.
+- num-vectors: number of vectors, range 1 to 32.
+- msi-controller:  indicates that this is MSI controller node
+
+
+Example
+msi0: msi@0xFF20 {
+   compatible = "altr,msi-1.0";
+   reg = <0xFF20 0x0010
+   0xFF200010 0x0080>;
+   reg-names = "csr", "vector_slave";
+   interrupt-parent = <&hps_0_arm_gic_0>;
+   interrupts = <0 42 4>;
+   msi-controller;
+   num-vectors = <32>;
+};
diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt 
b/Documentation/devicetree/bindings/pci/altera-pcie.txt
new file mode 100644
index 000..2951a6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altera-pcie.txt
@@ -0,0 +1,49 @@
+* Altera PCIe controller
+
+Required properties:
+- compatible : should contain "altr,pcie-root-port-1.0"
+- reg: a list of physical base address and length for TXS and CRA.
+- reg-names:   must include the following entries:
+   "Txs": TX slave port region
+   "Cra": Control register access region
+- interrupt-parent:interrupt source phandle.
+- interrupts:  specifies the interrupt source of the parent interrupt 
controller.
+   The format of the interrupt specifier depends on the parent 
interrupt
+   controller.
+- device_type: must be "pci"
+- #address-cells:  set to <3>
+- #size-cells: set to <2>
+- #interrupt-cells:set to <1>
+- ranges:  describes the translation of addresses for root ports 
and standard
+   PCI regions.
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+   mapping of the PCIe interface to interrupt numbers.
+
+Optional properties:
+- msi-parent:  Link to the hardware entity that serves as the MSI controller 
for this PCIe
+   controller.
+- bus-range:   PCI bus numbers covered
+
+Example
+   pcie_0: pcie@0xc {
+   compatible = "altr,pcie-root-port-1.0";
+   reg = <0xc000 0x2000>,
+   <0xff22 0x4000>;
+   reg-names = "Txs", "Cra";
+   interrupt-parent = <&hps_0_arm_gic_0>;
+   interrupts = <0 40 4>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   bus-range = <0x0 0xFF>;
+   device_type = "pci";
+   msi-parent = <&msi_to_gic_gen_0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = <0 0 0 1 &pcie_0 1>,
+   <0 0 0 2 &pcie_0 2>,
+   <0 0 0 3 &pcie_0 3>,
+   <0 0 0 4 &pcie_0 4>;
+   ranges = <0x8200 0x 0x 0xc000 
0x 0x1000
+   0x8200 0x 0x1000 0xd000 
0x 0x1000>;
+   };
-- 
1.8.2.1

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


[PATCH v11 4/6] pci: altera: Add Altera PCIe MSI driver

2015-10-22 Thread Ley Foon Tan
This patch adds Altera PCIe MSI driver. This soft IP supports configurable
number of vectors, which is a dts parameter.

Signed-off-by: Ley Foon Tan 
Reviewed-by: Marc Zyngier 
---
 drivers/pci/host/Kconfig   |   8 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pcie-altera-msi.c | 314 +
 3 files changed, 323 insertions(+)
 create mode 100644 drivers/pci/host/pcie-altera-msi.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index a67c9de..101208f 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -153,4 +153,12 @@ config PCIE_ALTERA
  Say Y here if you want to enable PCIe controller support on Altera
  FPGA.
 
+config PCIE_ALTERA_MSI
+   bool "Altera PCIe MSI feature"
+   depends on PCI_MSI
+   select PCI_MSI_IRQ_DOMAIN
+   help
+ Say Y here if you want PCIe MSI support for the Altera FPGA.
+ This MSI driver supports Altera MSI to GIC controller IP.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 6954f76..6c4913d 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
+obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
diff --git a/drivers/pci/host/pcie-altera-msi.c 
b/drivers/pci/host/pcie-altera-msi.c
new file mode 100644
index 000..367b462
--- /dev/null
+++ b/drivers/pci/host/pcie-altera-msi.c
@@ -0,0 +1,314 @@
+/*
+ * Copyright Altera Corporation (C) 2013-2015. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MSI_STATUS 0x0
+#define MSI_ERROR  0x4
+#define MSI_INTMASK0x8
+
+#define MAX_MSI_VECTORS32
+
+struct altera_msi {
+   DECLARE_BITMAP(used, MAX_MSI_VECTORS);
+   struct mutexlock;   /* proctect used variable */
+   struct platform_device  *pdev;
+   struct irq_domain   *msi_domain;
+   struct irq_domain   *inner_domain;
+   void __iomem*csr_base;
+   void __iomem*vector_base;
+   phys_addr_t vector_phy;
+   u32 num_of_vectors;
+   int irq;
+};
+
+static inline void msi_writel(struct altera_msi *msi, const u32 value,
+ const u32 reg)
+{
+   writel_relaxed(value, msi->csr_base + reg);
+}
+
+static inline u32 msi_readl(struct altera_msi *msi, const u32 reg)
+{
+   return readl_relaxed(msi->csr_base + reg);
+}
+
+static void altera_msi_isr(struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   struct altera_msi *msi;
+   unsigned long status;
+   u32 num_of_vectors;
+   u32 bit;
+   u32 virq;
+
+   chained_irq_enter(chip, desc);
+   msi = irq_desc_get_handler_data(desc);
+   num_of_vectors = msi->num_of_vectors;
+
+   while ((status = msi_readl(msi, MSI_STATUS)) != 0) {
+   for_each_set_bit(bit, &status, msi->num_of_vectors) {
+   /* Dummy read from vector to clear the interrupt */
+   readl_relaxed(msi->vector_base + (bit * sizeof(u32)));
+
+   virq = irq_find_mapping(msi->inner_domain, bit);
+   if (virq)
+   generic_handle_irq(virq);
+   else
+   dev_err(&msi->pdev->dev, "unexpected MSI\n");
+   }
+   }
+
+   chained_irq_exit(chip, desc);
+}
+
+static struct irq_chip altera_msi_irq_chip = {
+   .name = "Altera PCIe MSI",
+   .irq_mask = pci_msi_mask_irq,
+   .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info altera_msi_domain_info = {
+   .flags  = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+MSI_FLAG_PCI_MSIX),
+   .chip   = &altera_msi_irq_chip,
+};
+
+static void altera_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+   struct altera_msi *msi = irq_data_get_irq_chip_data(data);
+   phys_addr_t addr = msi->vector_phy + (data->hwirq

[PATCH v11 6/6] MAINTAINERS: Add Altera PCIe and MSI drivers maintainer

2015-10-22 Thread Ley Foon Tan
Signed-off-by: Ley Foon Tan 
---
 MAINTAINERS | 16 
 1 file changed, 16 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b8577ad9..96b9fac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7958,6 +7958,14 @@ F:   include/linux/pci*
 F: arch/x86/pci/
 F: arch/x86/kernel/quirks.c
 
+PCI DRIVER FOR ALTERA PCIE IP
+M: Ley Foon Tan 
+L: r...@lists.rocketboards.org (moderated for non-subscribers)
+L: linux-...@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/pci/altera-pcie.txt
+F: drivers/pci/host/pcie-altera.c
+
 PCI DRIVER FOR ARM VERSATILE PLATFORM
 M: Rob Herring 
 L: linux-...@vger.kernel.org
@@ -8059,6 +8067,14 @@ L:   linux-...@vger.kernel.org
 S: Maintained
 F: drivers/pci/host/*spear*
 
+PCI MSI DRIVER FOR ALTERA MSI IP
+M: Ley Foon Tan 
+L: r...@lists.rocketboards.org (moderated for non-subscribers)
+L: linux-...@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
+F: drivers/pci/host/pcie-altera-msi.c
+
 PCI MSI DRIVER FOR APPLIEDMICRO XGENE
 M: Duc Dang 
 L: linux-...@vger.kernel.org
-- 
1.8.2.1

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


[PATCH v11 2/6] pci: add Altera PCI vendor ID

2015-10-22 Thread Ley Foon Tan
Signed-off-by: Ley Foon Tan 
---
 include/linux/pci_ids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index d9ba49c..08e4462 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1550,6 +1550,8 @@
 #define PCI_DEVICE_ID_SERVERWORKS_CSB6LPC 0x0227
 #define PCI_DEVICE_ID_SERVERWORKS_HT1100LD 0x0408
 
+#define PCI_VENDOR_ID_ALTERA   0x1172
+
 #define PCI_VENDOR_ID_SBE  0x1176
 #define PCI_DEVICE_ID_SBE_WANXL100 0x0301
 #define PCI_DEVICE_ID_SBE_WANXL200 0x0302
-- 
1.8.2.1

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


[PATCH v11 0/6] Altera PCIe host controller driver with MSI support

2015-10-22 Thread Ley Foon Tan
This is the 11th version of patch set to add support for Altera PCIe host
controller with MSI feature on Altera FPGA device families. This patchset
mainly resovle the warning/error caught by kbuild test.

Hi Bjorn,
Do you have further comment on this patchset? Any chance this can go into 4.4?
Thanks.

This patchset is based on v4.3-rc6.

v10->v11 changes:
- altera-pcie: change altera_pcie_fixups to static function
- Kconfig: add depends on ARM || NIOS2 for PCIE_ALTERA

History:
---
[v1]: https://lkml.org/lkml/2015/7/28/395
[v2]: https://lkml.org/lkml/2015/7/31/267
[v3]: http://www.kernelhub.org/?msg=811940&p=2
[v4]: https://lkml.org/lkml/2015/8/17/141
[v5]: https://lkml.org/lkml/2015/8/25/238
[v6]: https://lkml.org/lkml/2015/9/1/177
[v7]: https://lkml.org/lkml/2015/9/20/193
[v8]: http://www.kernelhub.org/?msg=853553&p=2
[v9]: https://lkml.org/lkml/2015/10/13/998
[v10]: https://lkml.org/lkml/2015/10/19/139

Ley Foon Tan (6):
  arm: add msi.h to Kbuild
  pci: add Altera PCI vendor ID
  pci:host: Add Altera PCIe host controller driver
  pci: altera: Add Altera PCIe MSI driver
  Documentation: dt-bindings: pci: altera pcie device tree binding
  MAINTAINERS: Add Altera PCIe and MSI drivers maintainer

 .../devicetree/bindings/pci/altera-pcie-msi.txt|  28 +
 .../devicetree/bindings/pci/altera-pcie.txt|  49 ++
 MAINTAINERS|  16 +
 arch/arm/include/asm/Kbuild|   1 +
 drivers/pci/host/Kconfig   |  16 +
 drivers/pci/host/Makefile  |   2 +
 drivers/pci/host/pcie-altera-msi.c | 314 +++
 drivers/pci/host/pcie-altera.c | 579 +
 include/linux/pci_ids.h|   2 +
 9 files changed, 1007 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt
 create mode 100644 drivers/pci/host/pcie-altera-msi.c
 create mode 100644 drivers/pci/host/pcie-altera.c

-- 
1.8.2.1

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


Re: [PATCH] clk: Remove clk_{register,unregister}_multiplier()

2015-10-22 Thread Michael Turquette
Quoting Maxime Ripard (2015-10-22 01:36:47)
> Hi!
> 
> On Wed, Oct 21, 2015 at 04:33:53PM -0700, Stephen Boyd wrote:
> > These APIs aren't used, so remove them. This can be reverted if
> > we get a user at some point.
> > 
> > Cc: Maxime Ripard 
> > Suggested-by: Michael Turquette 
> > Signed-off-by: Stephen Boyd 
> 
> Reviewed-by: Maxime Ripard 

Applied.

Thanks,
Mike

> 
> Thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports

2015-10-22 Thread Dustin Byford
On Thu Oct 22 00:39, Rafael J. Wysocki wrote:
> Hi,
> 
> On Wed, Oct 21, 2015 at 11:25 AM, Dustin Byford
>  wrote:
> > On Wed Oct 21 12:08, Mika Westerberg wrote:
> >> I don't really have strong feelings whether it should be the I2C core or
> >> individual drivers setting the ACPI companion. However, it would be nice
> >> to match DT here and they assign their of_node per driver.
> >
> > OK with me, if we can convince Rafael this is a good idea, I'll send a
> > new revision with drivers setting the companion.
> 
> If you can guarantee that ACPI PM or anything like _DS or _SRS will
> never be invoked for the device objects that "inherit" the ACPI
> companion from their parent, it at least is not outright dangerous.

I'm hoping an ack from Mika will suffice, but please let me know if
there's something I can do to verify or help ensure this.

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


Re: [RFC PATCH v6 3/3] arm: fix a migrating irq bug when hotplug cpu

2015-10-22 Thread Russell King - ARM Linux
On Wed, Oct 21, 2015 at 09:29:08PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 01:47:49PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Sep 24, 2015 at 11:32 AM, Yang Yingliang
> >  wrote:
> > > When cpu is disabled, all irqs will be migratged to another cpu.
> > > In some cases, a new affinity is different, the old affinity need
> > > to be updated and if irq_set_affinity's return value is 
> > > IRQ_SET_MASK_OK_DONE,
> > > the old affinity can not be updated. Fix it by using irq_do_set_affinity.
> > >
> > > And migrating interrupts is a core code matter, so use the generic
> > > function irq_migrate_all_off_this_cpu() to migrate interrupts in
> > > kernel/irq/migration.c.
> > >
> > > Cc: Jiang Liu 
> > > Cc: Thomas Gleixner 
> > > Cc: Marc Zyngier 
> > > Cc: Mark Rutland 
> > > Cc: Will Deacon 
> > > Cc: Russell King - ARM Linux 
> > > Cc: Hanjun Guo 
> > > Signed-off-by: Yang Yingliang 
> > > ---
> > >  arch/arm/Kconfig   |  1 +
> > >  arch/arm/include/asm/irq.h |  1 -
> > >  arch/arm/kernel/irq.c  | 62 
> > > --
> > >  arch/arm/kernel/smp.c  |  2 +-
> > >  4 files changed, 2 insertions(+), 64 deletions(-)
> > >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index 72ad724..bffba78 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -1492,6 +1492,7 @@ config NR_CPUS
> > >  config HOTPLUG_CPU
> > > bool "Support for hot-pluggable CPUs"
> > > depends on SMP
> > > +   select GENERIC_IRQ_MIGRATION
> > 
> > This causes the following warnings during s2ram on r8a7791/koelsch
> > (dual-core CA15):
> 
> Thanks for the report.  I'll see what tonight's boot run says for my
> platforms.  Hopefully, the author of these changes can help debug
> this.

What's happened is that:

-   c = irq_data_get_irq_chip(d);
-   if (!c->irq_set_affinity)
-   pr_debug("IRQ%u: unable to set affinity\n", d->irq);

has become:

+   c = irq_data_get_irq_chip(d);
+   if (!c->irq_set_affinity) {
+   pr_warn_ratelimited("IRQ%u: unable to set affinity\n", d->irq);

which makes things more noisy.

This is a change that was not described in the commit message for the
patch Thomas merged.

So, I think the right thing to do is to drop the patch set and revert
back to what we knew was sane, and get the submitter to do the job
properly: cleanly move the code from one location to another with _no_
changes what so ever, convert ARM and ARM64 to use it, and _then_ to
modify the resulting code.

>From what I can see, both ARM and ARM64 implementations here are
identical.

I'm certainly dropping this from the ARM tree.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/4] arm: plat-omap: add DT support for ti,dm816-timer

2015-10-22 Thread Neil Armstrong
Adds ti,dm816-timer to the dmtimer OF match table.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/plat-omap/dmtimer.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 8ca94d3..28a6550 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -943,6 +943,10 @@ static const struct of_device_id omap_timer_match[] = {
.compatible = "ti,am335x-timer-1ms",
.data = &omap3plus_pdata,
},
+   {
+   .compatible = "ti,dm816-timer",
+   .data = &omap3plus_pdata,
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, omap_timer_match);
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/5] dax: increase granularity of dax_clear_blocks() operations

2015-10-22 Thread Jan Kara
On Thu 22-10-15 02:41:54, Dan Williams wrote:
> dax_clear_blocks is currently performing a cond_resched() after every
> PAGE_SIZE memset.  We need not check so frequently, for example md-raid
> only calls cond_resched() at stripe granularity.  Also, in preparation
> for introducing a dax_map_atomic() operation that temporarily pins a dax
> mapping move the call to cond_resched() to the outer loop.
> 
> Signed-off-by: Dan Williams 

The patch looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza
> ---
>  fs/dax.c |   27 ---
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index 5dc33d788d50..f8e543839e5c 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  int dax_clear_blocks(struct inode *inode, sector_t block, long size)
>  {
> @@ -38,24 +39,20 @@ int dax_clear_blocks(struct inode *inode, sector_t block, 
> long size)
>   do {
>   void __pmem *addr;
>   unsigned long pfn;
> - long count;
> + long count, sz;
>  
> - count = bdev_direct_access(bdev, sector, &addr, &pfn, size);
> + sz = min_t(long, size, SZ_1M);
> + count = bdev_direct_access(bdev, sector, &addr, &pfn, sz);
>   if (count < 0)
>   return count;
> - BUG_ON(size < count);
> - while (count > 0) {
> - unsigned pgsz = PAGE_SIZE - offset_in_page(addr);
> - if (pgsz > count)
> - pgsz = count;
> - clear_pmem(addr, pgsz);
> - addr += pgsz;
> - size -= pgsz;
> - count -= pgsz;
> - BUG_ON(pgsz & 511);
> - sector += pgsz / 512;
> - cond_resched();
> - }
> + if (count < sz)
> + sz = count;
> + clear_pmem(addr, sz);
> + addr += sz;
> + size -= sz;
> + BUG_ON(sz & 511);
> + sector += sz / 512;
> + cond_resched();
>   } while (size);
>  
>   wmb_pmem();
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 0/4] arm: omap2+: complete dm816x hwmod and clkdev

2015-10-22 Thread Neil Armstrong
In order to fix support for the dm816x platform, add missing bits in
the 81xx hwmod data.

The clk related patch adds the missing clkdev entries to fix all source
selection in the dmtimer driver.

The last patch adds hwmod support of the spinbox module.

Neil Armstrong (4):
  arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data
  clk: ti816x: Add missing dmtimer clkdev entries
  arm: plat-omap: add DT support for ti,dm816-timer
  arm: omap2+: Add hwmod spinbox support for dm816x

 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 38 ++
 arch/arm/plat-omap/dmtimer.c   |  4 
 drivers/clk/ti/clk-816x.c  |  2 ++
 3 files changed, 44 insertions(+)

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


Re: [PATCH 1/3] x86, perf: Use a new PMU ack sequence

2015-10-22 Thread Ingo Molnar

* Andi Kleen  wrote:

> > > v2:
> > > Use new ack sequence unconditionally. Remove pmu reset code.
> > 
> > So this is not something we can easily revert if things go bad. Esp.
> > since you build on it with the next patches.
> 
> Ok, and?

Sigh, you are being disruptive again.

> You want me to go back to the previous patch? That one is easily
> undoable (just disable the flag for the model)
> 
> Another alternative would be to fork the PMI handler into a new and
> an old version, that is switchable.

Here you pretend that you didn't read the sane solution that was suggested to 
you 
just three days ago:

  http://lkml.kernel.org/r/20151019070812.gb17...@gmail.com

  " > > Ingo, do you want to first merge the safe patch and then clean up?
>
> Yeah, would be nice to structure it that way, out of general paranoia.
  "

I.e. first apply the safe approach, then, after the dependent changes, clean it 
up 
by introducing the dangerous change.

The thing is, I'm close to summarily NAK-ing any patches from you to the perf 
subsystem, due to the unacceptably low quality patches combined with obtuse 
passive-aggressive obstruction you are routinely burdening maintainers with.

Btw., I noticed that you routinely don't Cc me to perf patches. Please always 
Cc: 
me to perf patches (both kernel and tooling patches). I still will not apply 
them 
directly, only if another perf maintainer signs off on them, but I'd like to 
have 
a record of all your submissions.

Thanks,

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


Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

2015-10-22 Thread Peter Zijlstra
On Thu, Oct 22, 2015 at 03:51:37PM +0800, Wangnan (F) wrote:
> Because I'm not very sure what the meaning of "inconsistent" in
> Peter's words...

What's inconsistent is that some perf actions can be done only on local
events while others can be done on !local.

And I can't say I particularly like having to pass in events from
userspace, but I think that Alexei convinced me that it made some sense
at some point in time.


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


[tip:perf/core] perf annotate: Add debug message for out of bounds sample

2015-10-22 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  e3d006ce8180a0c025ce66bdc89bbc125f85be57
Gitweb: http://git.kernel.org/tip/e3d006ce8180a0c025ce66bdc89bbc125f85be57
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 21 Oct 2015 15:45:13 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Oct 2015 18:12:37 -0300

perf annotate: Add debug message for out of bounds sample

Cc: Adrian Hunter 
Cc: Borislav Petkov 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Stephane Eranian 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-q0lde9ajs84oi38nlyjcq...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/annotate.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index d1eece7..0fc8d7a 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -548,8 +548,11 @@ static int __symbol__inc_addr_samples(struct symbol *sym, 
struct map *map,
 
pr_debug3("%s: addr=%#" PRIx64 "\n", __func__, map->unmap_ip(map, 
addr));
 
-   if (addr < sym->start || addr >= sym->end)
+   if (addr < sym->start || addr >= sym->end) {
+   pr_debug("%s(%d): ERANGE! sym->name=%s, start=%#" PRIx64 ", 
addr=%#" PRIx64 ", end=%#" PRIx64 "\n",
+  __func__, __LINE__, sym->name, sym->start, addr, 
sym->end);
return -ERANGE;
+   }
 
offset = addr - sym->start;
h = annotation__histogram(notes, evidx);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[tip:perf/core] perf cpu_map: Fix core dump caused by per-socket/ core system-wide stat

2015-10-22 Thread tip-bot for Kan Liang
Commit-ID:  bc1d03687b9be3a30aab8e8d78c7884449b6e511
Gitweb: http://git.kernel.org/tip/bc1d03687b9be3a30aab8e8d78c7884449b6e511
Author: Kan Liang 
AuthorDate: Fri, 9 Oct 2015 06:59:23 -0400
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 20 Oct 2015 15:54:20 -0300

perf cpu_map: Fix core dump caused by per-socket/core system-wide stat

Perf will core dump if --per-socket/core -a are applied for perf stat.

The root cause is that cpu_map__build_map set refcnt of evlist's cpu_map
to 1.  It should set refcnt for the newly created cpu_map, not evlist's
cpu_map.

Here is the example:

  # perf stat -e cycles --per-socket -a sleep 1

   Performance counter stats for 'system wide':

  S0   36 30,196,257  cycles
  S1   28 15,823,536  cycles

   1.001126828 seconds time elapsed

  *** Error in `./perf': corrupted double-linked list: 0x021f9090 ***
  === Backtrace: =
  /lib64/libc.so.6[0x3002e7bbe7]
  /lib64/libc.so.6[0x3002e7d2b5]
  ./perf(perf_evsel__delete+0x28)[0x485bdd]
  ./perf[0x4800e8]
  ./perf(perf_evlist__delete+0x5e)[0x482cd5]
  ./perf(cmd_stat+0xf25)[0x432328]
  ./perf[0x4768e0]
  ./perf[0x476ad6]
  ./perf[0x476b41]
  ./perf(main+0x1d0)[0x476db2]
  /lib64/libc.so.6(__libc_start_main+0xf5)[0x3002e21b45]
  ./perf[0x4202c5]

Signed-off-by: Kan Liang 
Acked-by: Jiri Olsa 
Cc: Andi Kleen 
Link: 
http://lkml.kernel.org/r/1444388363-35936-1-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cpumap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
index b368453..aa6b490 100644
--- a/tools/perf/util/cpumap.c
+++ b/tools/perf/util/cpumap.c
@@ -285,7 +285,7 @@ int cpu_map__build_map(struct cpu_map *cpus, struct cpu_map 
**res,
/* ensure we process id in increasing order */
qsort(c->map, c->nr, sizeof(int), cmp_ids);
 
-   atomic_set(&cpus->refcnt, 1);
+   atomic_set(&c->refcnt, 1);
*res = c;
return 0;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[tip:perf/core] perf evsel: Print branch filter state with -vv

2015-10-22 Thread tip-bot for Andi Kleen
Commit-ID:  8b8cde49586566471d65af9a59e25d3edb941387
Gitweb: http://git.kernel.org/tip/8b8cde49586566471d65af9a59e25d3edb941387
Author: Andi Kleen 
AuthorDate: Tue, 20 Oct 2015 11:46:36 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 21 Oct 2015 18:12:29 -0300

perf evsel: Print branch filter state with -vv

Add a missing field to the perf_event_attr debug output.

Signed-off-by: Andi Kleen 
Acked-by: Peter Zijlstra (Intel) 
Cc: Jiri Olsa 
Link: 
http://lkml.kernel.org/r/1445366797-30894-4-git-send-email-a...@firstfloor.org
[ Print it between config2 and sample_regs_user (peterz)]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evsel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 8be867c..ab05fa5 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1262,6 +1262,7 @@ int perf_event_attr__fprintf(FILE *fp, struct 
perf_event_attr *attr,
PRINT_ATTRf(bp_type, p_unsigned);
PRINT_ATTRn("{ bp_addr, config1 }", bp_addr, p_hex);
PRINT_ATTRn("{ bp_len, config2 }", bp_len, p_hex);
+   PRINT_ATTRf(branch_sample_type, p_unsigned);
PRINT_ATTRf(sample_regs_user, p_hex);
PRINT_ATTRf(sample_stack_user, p_unsigned);
PRINT_ATTRf(clockid, p_signed);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[tip:perf/core] perf build: Add fixdep to .gitignore

2015-10-22 Thread tip-bot for Yunlong Song
Commit-ID:  e1d040cfcf76c1c1b5d71fc08ab577a0cf72fefd
Gitweb: http://git.kernel.org/tip/e1d040cfcf76c1c1b5d71fc08ab577a0cf72fefd
Author: Yunlong Song 
AuthorDate: Thu, 15 Oct 2015 16:51:56 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 20 Oct 2015 10:43:28 -0300

perf build: Add fixdep to .gitignore

Commit 7c422f5572667fef0db38d2046ecce69dcf0afc8 ("tools build: Build
fixdep helper from perf and basic libs") dynamically creates fixdep
during the perf building. Add it to .gitignore.

Signed-off-by: Yunlong Song 
Cc: Adrian Hunter 
Cc: Alexei Starovoitov 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Fixes: 7c422f557266 ("tools build: Build fixdep helper from perf and basic 
libs")
Link: 
http://lkml.kernel.org/r/1444899116-8220-1-git-send-email-yunlong.s...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 {scripts/basic => tools/build}/.gitignore | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/basic/.gitignore b/tools/build/.gitignore
similarity index 53%
copy from scripts/basic/.gitignore
copy to tools/build/.gitignore
index 9528ec9..a776371 100644
--- a/scripts/basic/.gitignore
+++ b/tools/build/.gitignore
@@ -1,2 +1 @@
 fixdep
-bin2c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[tip:perf/core] tools lib traceevent: update KVM plugin

2015-10-22 Thread tip-bot for Paolo Bonzini
Commit-ID:  2f465deef7ce8c722121b782dd91c284f5ae80ca
Gitweb: http://git.kernel.org/tip/2f465deef7ce8c722121b782dd91c284f5ae80ca
Author: Paolo Bonzini 
AuthorDate: Thu, 1 Oct 2015 12:28:11 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 20 Oct 2015 15:54:14 -0300

tools lib traceevent: update KVM plugin

The format of the role word has changed through the years and the plugin
was never updated; some VMX exit reasons were missing too.

Signed-off-by: Paolo Bonzini 
Acked-by: Steven Rostedt 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: k...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1443695293-31127-1-git-send-email-pbonz...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/traceevent/plugin_kvm.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/tools/lib/traceevent/plugin_kvm.c 
b/tools/lib/traceevent/plugin_kvm.c
index 88fe83d..18536f7 100644
--- a/tools/lib/traceevent/plugin_kvm.c
+++ b/tools/lib/traceevent/plugin_kvm.c
@@ -124,7 +124,10 @@ static const char *disassemble(unsigned char *insn, int 
len, uint64_t rip,
_ER(WBINVD,  54)\
_ER(XSETBV,  55)\
_ER(APIC_WRITE,  56)\
-   _ER(INVPCID, 58)
+   _ER(INVPCID, 58)\
+   _ER(PML_FULL,62)\
+   _ER(XSAVES,  63)\
+   _ER(XRSTORS, 64)
 
 #define SVM_EXIT_REASONS \
_ER(EXIT_READ_CR0,  0x000)  \
@@ -352,15 +355,18 @@ static int kvm_nested_vmexit_handler(struct trace_seq *s, 
struct pevent_record *
 union kvm_mmu_page_role {
unsigned word;
struct {
-   unsigned glevels:4;
unsigned level:4;
+   unsigned cr4_pae:1;
unsigned quadrant:2;
-   unsigned pad_for_nice_hex_output:6;
unsigned direct:1;
unsigned access:3;
unsigned invalid:1;
-   unsigned cr4_pge:1;
unsigned nxe:1;
+   unsigned cr0_wp:1;
+   unsigned smep_and_not_wp:1;
+   unsigned smap_and_not_wp:1;
+   unsigned pad_for_nice_hex_output:8;
+   unsigned smm:8;
};
 };
 
@@ -385,15 +391,18 @@ static int kvm_mmu_print_role(struct trace_seq *s, struct 
pevent_record *record,
if (pevent_is_file_bigendian(event->pevent) ==
pevent_is_host_bigendian(event->pevent)) {
 
-   trace_seq_printf(s, "%u/%u q%u%s %s%s %spge %snxe",
+   trace_seq_printf(s, "%u q%u%s %s%s %spae %snxe %swp%s%s%s",
 role.level,
-role.glevels,
 role.quadrant,
 role.direct ? " direct" : "",
 access_str[role.access],
 role.invalid ? " invalid" : "",
-role.cr4_pge ? "" : "!",
-role.nxe ? "" : "!");
+role.cr4_pae ? "" : "!",
+role.nxe ? "" : "!",
+role.cr0_wp ? "" : "!",
+role.smep_and_not_wp ? " smep" : "",
+role.smap_and_not_wp ? " smap" : "",
+role.smm ? " smm" : "");
} else
trace_seq_printf(s, "WORD: %08x", role.word);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 5/5] clk: scpi: add missing of_node_put

2015-10-22 Thread Sudeep Holla



On 21/10/15 21:41, Julia Lawall wrote:

for_each_available_child_of_node performs an of_node_get on each iteration,
so a break out of the loop requires an of_node_put.

The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

  for_each_available_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
(
return child;
|
+  of_node_put(child);
?  return ...;
)
...
  }
// 

Signed-off-by: Julia Lawall 


Thanks for the fix.

Acked-by: Sudeep Holla 

PS: Since this driver is queued via arm-soc, it needs to go via them or
wait for v4.4-rc1 and then queue via clk tree.

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


[PATCH 1/4] arm: dts: add dm816x missing #mbox-cells

2015-10-22 Thread Neil Armstrong
Add missing #mbox-cells for dm816x mbox DT node.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/dm816x.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 3c99cfa..a7a34e4 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -218,6 +218,7 @@
reg = <0x480c8000 0x2000>;
interrupts = <77>;
ti,hwmods = "mailbox";
+   #mbox-cells = <1>;
ti,mbox-num-users = <4>;
ti,mbox-num-fifos = <12>;
mbox_dsp: mbox_dsp {
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/4] arm: dts: add dm816x missing spi DT dma handles

2015-10-22 Thread Neil Armstrong
Add the missing SPI controller DMA handler in the dm816x DT
node, only properties for the two channels on four were present.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/dm816x.dtsi | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index a7a34e4..eee636d 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -280,8 +280,11 @@
ti,spi-num-cs = <4>;
ti,hwmods = "mcspi1";
dmas = <&edma 16 &edma 17
-   &edma 18 &edma 19>;
-   dma-names = "tx0", "rx0", "tx1", "rx1";
+   &edma 18 &edma 19
+   &edma 20 &edma 21
+   &edma 22 &edma 23>;
+   dma-names = "tx0", "rx0", "tx1", "rx1",
+   "tx2", "rx2", "tx3", "rx3";
};

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


[PATCH 4/4] arm: dts: Add omap4-hwspinlock support in dm816x

2015-10-22 Thread Neil Armstrong
Add dm816x DT entries for omap4-hwspinlock support as hwmod spinbox.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/dm816x.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 51ad4a9..f655ce1 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -227,6 +227,13 @@
};
};

+   spinbox: spinbox@480ca000 {
+   compatible = "ti,omap4-hwspinlock";
+   reg = <0x480ca000 0x2000>;
+   ti,hwmods = "spinbox";
+   #hwlock-cells = <1>;
+   };
+
mdio: mdio@4a100800 {
compatible = "ti,davinci_mdio";
#address-cells = <1>;
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 1/3] dt-bindings: Consolidate SRAM bindings from all vendors

2015-10-22 Thread Krzysztof Kozlowski
On 22.10.2015 18:05, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Oct 22, 2015 at 10:25:28AM +0900, Krzysztof Kozlowski wrote:
>> SRAM bindings for various SoCs, using the mmio-sram genalloc
>> API, are spread over different places - per SoC vendor. Since all of
>> these are quite similar (they depend on mmio-sram) move them to a common
>> place.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> Cc: Heiko Stuebner 
>> Cc: Maxime Ripard 
>> Cc: Chen-Yu Tsai 
>> Cc: Kukjin Kim 
>> Suggested-by: Rob Herring 
>>
>> ---
>>
>> Changes since v1:
>> 1. New patch. Extended suggestion from Rob.
>> ---
>>  .../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt}| >> 0
>>  .../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt}| >> 0
>>  .../bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt} | >> 0
>>  Documentation/devicetree/bindings/{misc => sram}/sram.txt | >> 0
>>  .../devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt}   | >> 0
>>  5 files changed, 0 insertions(+), 0 deletions(-)
>>  rename Documentation/devicetree/bindings/{arm/rockchip/pmu-sram.txt => 
>> sram/rockchip-pmu-sram.txt} (100%)
>>  rename Documentation/devicetree/bindings/{arm/rockchip/smp-sram.txt => 
>> sram/rockchip-smp-sram.txt} (100%)
>>  rename Documentation/devicetree/bindings/{arm/exynos/smp-sysram.txt => 
>> sram/samsung-sram.txt} (100%)
>>  rename Documentation/devicetree/bindings/{misc => sram}/sram.txt (100%)
>>  rename Documentation/devicetree/bindings/{soc/sunxi/sram.txt => 
>> sram/sunxi-sram.txt} (100%)
> 
> I'm not sure about that one. The SRAM bindins we have for sunxi is for
> an SRAM controller, that maps the SRAM either to the CPU or to the
> devices.
> 
> It's not really related to the other users, and wouldn't it be
> confusing to have a driver in drivers/soc, and a Documentation in
> another sub-directory?

I guess the only relation to other users is the "mmio-sram". In the same
time this is still similar to e.g. Samsung's sram bindings (where the
memory is mapped to CPU only).

Being located in drivers/soc is not an issue here - code for other
vendors may be moved there as well in the future.

Of course I do not insist. Actually Rob's comment was only about moving
sram.txt and Samsung's sram to common place.

Anyway I will be sending v3 of these because while looking more
carefully I found hard-coded paths to bindings/misc/sram.txt. I'll fix
it in next version.

Best regards,
Krzysztof

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


[PATCH 3/4] arm: dts: add dm816x pwm property to timers

2015-10-22 Thread Neil Armstrong
Adds ti,timer-pwm property to timers 4 to 7 to permit usage of their
PWM output fonctionnality via the dmtimer driver.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/dm816x.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index eee636d..51ad4a9 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -323,6 +323,7 @@
reg = <0x48044000 0x2000>;
interrupts = <92>;
ti,hwmods = "timer4";
+   ti,timer-pwm;
};

timer5: timer@48046000 {
@@ -330,6 +331,7 @@
reg = <0x48046000 0x2000>;
interrupts = <93>;
ti,hwmods = "timer5";
+   ti,timer-pwm;
};

timer6: timer@48048000 {
@@ -337,6 +339,7 @@
reg = <0x48048000 0x2000>;
interrupts = <94>;
ti,hwmods = "timer6";
+   ti,timer-pwm;
};

timer7: timer@4804a000 {
@@ -344,6 +347,7 @@
reg = <0x4804a000 0x2000>;
interrupts = <95>;
ti,hwmods = "timer7";
+   ti,timer-pwm;
};

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


[PATCH 4/4] arm: omap2+: Add hwmod spinbox support for dm816x

2015-10-22 Thread Neil Armstrong
Add dm81xx hwmod data entries for dm816x spinbox support.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 35 ++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 6256052..275b16c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -1036,6 +1036,40 @@ static struct omap_hwmod_ocp_if dm81xx_l4_ls__mailbox = {
.user   = OCP_USER_MPU,
 };

+static struct omap_hwmod_class_sysconfig dm81xx_spinbox_sysc = {
+   .rev_offs   = 0x000,
+   .sysc_offs  = 0x010,
+   .syss_offs  = 0x014,
+   .sysc_flags = SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+   SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE,
+   .idlemodes  = SIDLE_FORCE | SIDLE_NO | SIDLE_SMART,
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dm81xx_spinbox_hwmod_class = {
+   .name = "spinbox",
+   .sysc = &dm81xx_spinbox_sysc,
+};
+
+static struct omap_hwmod dm81xx_spinbox_hwmod = {
+   .name   = "spinbox",
+   .clkdm_name = "alwon_l3s_clkdm",
+   .class  = &dm81xx_spinbox_hwmod_class,
+   .main_clk   = "sysclk6_ck",
+   .prcm   = {
+   .omap4 = {
+   .clkctrl_offs = DM81XX_CM_ALWON_SPINBOX_CLKCTRL,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+static struct omap_hwmod_ocp_if dm81xx_l4_ls__spinbox = {
+   .master = &dm81xx_l4_ls_hwmod,
+   .slave  = &dm81xx_spinbox_hwmod,
+   .user   = OCP_USER_MPU,
+};
+
 static struct omap_hwmod_class dm81xx_tpcc_hwmod_class = {
.name   = "tpcc",
 };
@@ -1298,6 +1332,7 @@ static struct omap_hwmod_ocp_if *dm816x_hwmod_ocp_ifs[] 
__initdata = {
&dm816x_l4_ls__timer7,
&dm81xx_l4_ls__mcspi1,
&dm81xx_l4_ls__mailbox,
+   &dm81xx_l4_ls__spinbox,
&dm81xx_l4_hs__emac0,
&dm81xx_emac0__mdio,
&dm816x_l4_hs__emac1,
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/4] clk: ti816x: Add missing dmtimer clkdev entries

2015-10-22 Thread Neil Armstrong
Add missing clkdev dmtimer related entries for dm816x.
32Khz and ext sources were missing.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 drivers/clk/ti/clk-816x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/ti/clk-816x.c b/drivers/clk/ti/clk-816x.c
index 1dfad0c..2a5d84f 100644
--- a/drivers/clk/ti/clk-816x.c
+++ b/drivers/clk/ti/clk-816x.c
@@ -20,6 +20,8 @@ static struct ti_dt_clk dm816x_clks[] = {
DT_CLK(NULL, "sys_clkin", "sys_clkin_ck"),
DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"),
DT_CLK(NULL, "sys_32k_ck", "sys_32k_ck"),
+   DT_CLK(NULL, "timer_32k_ck", "sysclk18_ck"),
+   DT_CLK(NULL, "timer_ext_ck", "tclkin_ck"),
DT_CLK(NULL, "mpu_ck", "mpu_ck"),
DT_CLK(NULL, "timer1_fck", "timer1_fck"),
DT_CLK(NULL, "timer2_fck", "timer2_fck"),
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 0/4] arm: dts: complete dm816x device tree

2015-10-22 Thread Neil Armstrong
In order to fix support for the dm816x platform, add missing bits in
the dm816x dtsi.

The last patch adds support for the omap4-hwspinlock.

Neil Armstrong (4):
  arm: dts: add dm816x missing #mbox-cells
  arm: dts: add dm816x missing spi DT dma handles
  arm: dts: add dm816x pwm property to timers
  arm: dts: Add omap4-hwspinlock support in dm816x

 arch/arm/boot/dts/dm816x.dtsi | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

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


[PATCH 1/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data

2015-10-22 Thread Neil Armstrong
Add missing HWMOD_NO_IDLEST hwmod flag for entries no
having omap4 clkctrl values.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index b1288f5..6256052 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -144,6 +144,7 @@ static struct omap_hwmod dm81xx_l4_ls_hwmod = {
.name   = "l4_ls",
.clkdm_name = "alwon_l3s_clkdm",
.class  = &l4_hwmod_class,
+   .flags  = HWMOD_NO_IDLEST,
 };

 /*
@@ -155,6 +156,7 @@ static struct omap_hwmod dm81xx_l4_hs_hwmod = {
.name   = "l4_hs",
.clkdm_name = "alwon_l3_med_clkdm",
.class  = &l4_hwmod_class,
+   .flags  = HWMOD_NO_IDLEST,
 };

 /* L3 slow -> L4 ls peripheral interface running at 125MHz */
@@ -850,6 +852,7 @@ static struct omap_hwmod dm816x_emac0_hwmod = {
.name   = "emac0",
.clkdm_name = "alwon_ethernet_clkdm",
.class  = &dm816x_emac_hwmod_class,
+   .flags  = HWMOD_NO_IDLEST,
 };

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


[PATCH v4 1/2] acpi: add acpi_preset_companion() stub

2015-10-22 Thread Dustin Byford
Add a stub for acpi_preset_companion().  Fixes build failures when
acpi_preset_companion() is used and CONFIG_ACPI is not set.

Signed-off-by: Dustin Byford 
---
 include/linux/acpi.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 51a96a8..66564f8 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -505,6 +505,12 @@ static inline bool has_acpi_companion(struct device *dev)
return false;
 }
 
+static inline void acpi_preset_companion(struct device *dev,
+struct acpi_device *parent, u64 addr)
+{
+   return;
+}
+
 static inline const char *acpi_dev_name(struct acpi_device *adev)
 {
return NULL;
-- 
2.1.4

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


[PATCH v4 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels

2015-10-22 Thread Dustin Byford
The following series adds support for describing ACPI enumerated I2C mux
ports like this (added as Documentation/acpi/i2c-muxes.txt):

+--+   +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
|  |   | 0x70 |--CH01--> i2c client B (0x50)
+--+   +--+

Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
  AddressingMode7Bit, "^SMB1", 0x00,
  ResourceConsumer,,)
}

Device (CH00)
{
Name (_ADR, 0)

Device (CLIA)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
  AddressingMode7Bit, "^CH00", 0x00,
  ResourceConsumer,,)
}
}
}

Device (CH01)
{
Name (_ADR, 1)

Device (CLIB)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
  AddressingMode7Bit, "^CH01", 0x00,
  ResourceConsumer,,)
}
}
}
}
}

v4:
- Moved the acpi_preset_companion() stub to a separate patch.
- Moved ACPI companion set from i2c-core to i801, ismt, and designware
  drivers.  With a minor rearrangement it was much easier to verify the
  drivers are all consistent (hopefully a little extra churn is warranted)

I was able to test i801 and ismt myself, but I could use some help making
sure the designware driver is OK since I don't have the hardware.

v3:
- Correct to and cc list (sorry git-send-email trouble again)

v2:
- Drop duplicate patch already submitted by Andy Shevchenko (i2c / ACPI:
  Rework I2C device scanning)
- Whitespace cleanup suggested by Mika
- Implement a acpi_preset_companion() stub for when CONFIG_ACPI is not set.
- Instead of special casing I2C muxes with regards to enumerating client
  devices, make sure adap->dev always has an ACPI companion.

I based this on linux-pm/bleeding-edge, but now it depends on Andy's change
(i2c / ACPI: Rework I2C device scanning) and I don't know where the rest of
his patch set is going.  Let me know if there's a more appropriate branch
and I'll be happy to rebase.

Thanks,

--Dustin

Dustin Byford (2):
  acpi: add acpi_preset_companion() stub
  i2c: add ACPI support for I2C mux ports

 Documentation/acpi/i2c-muxes.txt| 58 +
 drivers/i2c/busses/i2c-designware-pcidrv.c  |  1 +
 drivers/i2c/busses/i2c-designware-platdrv.c |  6 ++-
 drivers/i2c/busses/i2c-i801.c   |  9 ++---
 drivers/i2c/busses/i2c-ismt.c   |  8 +---
 drivers/i2c/i2c-core.c  |  4 +-
 drivers/i2c/i2c-mux.c   |  8 
 include/linux/acpi.h|  6 +++
 8 files changed, 84 insertions(+), 16 deletions(-)
 create mode 100644 Documentation/acpi/i2c-muxes.txt

-- 
2.1.4

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


Re: [PATCH 5/6] ARM: dts: sunxi: Add Allwinner H3 DTSI

2015-10-22 Thread Maxime Ripard
On Thu, Oct 22, 2015 at 10:57:45AM +0200, Jean-Francois Moine wrote:
> On Thu, 22 Oct 2015 10:47:35 +0200
> Maxime Ripard  wrote:
> 
> > Not really. The uart0 reset is the bit 16, in the reset register 4.
> > 
> > 4 * 32 + 16 = 44.
> > 
> > Not 112, but still not 208 either.
> 
> The registers are numbered 1..5, then
> 
> (4 - 1) * 32 + 16 = 112

Not on my version, and even then, UARTs are on the last reset
register, which would still make 144.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature


[PATCH 3/4] of/unittest: add missing of_node_put

2015-10-22 Thread Julia Lawall
for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Combine the puts into code at the end of the function, for conciseness.

Signed-off-by: Julia Lawall 

---
 drivers/of/unittest.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 9f71770..e16ea57 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -205,16 +205,20 @@ static int __init of_unittest_check_node_linkage(struct 
device_node *np)
if (child->parent != np) {
pr_err("Child node %s links to wrong parent %s\n",
 child->name, np->name);
-   return -EINVAL;
+   rc = -EINVAL;
+   goto put_child;
}
 
rc = of_unittest_check_node_linkage(child);
if (rc < 0)
-   return rc;
+   goto put_child;
count += rc;
}
 
return count + 1;
+put_child:
+   of_node_put(child);
+   return rc;
 }
 
 static void __init of_unittest_check_tree_linkage(void)

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


[PATCH 2/4] of/platform: add missing of_node_put

2015-10-22 Thread Julia Lawall
for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
local idexpression n;
expression root,e;
@@

 for_each_child_of_node(root,n) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  break;
)
   ...
 }
... when != n
// 

Signed-off-by: Julia Lawall 

---
 drivers/of/platform.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7b33e03..64daf05 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -409,8 +409,10 @@ int of_platform_bus_probe(struct device_node *root,
if (!of_match_node(matches, child))
continue;
rc = of_platform_bus_create(child, matches, NULL, parent, 
false);
-   if (rc)
+   if (rc) {
+   of_node_put(child);
break;
+   }
}
 
of_node_put(root);
@@ -451,8 +453,10 @@ int of_platform_populate(struct device_node *root,
 
for_each_child_of_node(root, child) {
rc = of_platform_bus_create(child, matches, lookup, parent, 
true);
-   if (rc)
+   if (rc) {
+   of_node_put(child);
break;
+   }
}
of_node_set_flag(root, OF_POPULATED_BUS);
 

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


Re: blk-mq: takes hours for scsi scanning finish when thousands of LUNs

2015-10-22 Thread jason



On Thursday, October 22, 2015 04:47 PM, Tejun Heo wrote:

Hello,

On Mon, Oct 19, 2015 at 07:40:13AM -0700, Zhangqing Luo wrote:

> So every time blk_mq_freeze_queue_start, it runs in this way
>
> blk_mq_freeze_queue_start
> ->percpu_ref_kill->percpu_ref_kill_and_confirm
> ->__percpu_ref_switch_to_atomic
> ->call_rcu_sched(&ref->rcu,percpu_ref_switch_to_atomic_rcu)
>
> and blk_mq_freeze_queue_wait blocks on queue->mq_usage_counter
> as it is not zero, and wake up by percpu_ref_switch_to_atomic_rcu
> after a grace period
>
>
> My question here is why should we change ref to PERCPU at blk_mq_finish_init?
> because of this changing, delay appears.

Because percpu operation is way cheaper than atomic ones and we want
to optimize hot paths (request issue and completion) over cold paths
(init and config changes).  That's the whole point of percpu
refcnting.

The reason why percpu ref starts in atomic mode is to avoid expensive
percpu freezing if the queue is created and abandoned in quick
succession as SCSI does during LUN scanning.  If percpu freezing is
happening during that, the right solution is moving finish_init to
late enough point so that percpu switching happens only after it's
known that the queue won't be abandoned.

Thanks.


I agree with the optimizing hot paths by cheaper percpu operation,
but how much does it affect the performance?

as you know the switching causes delay, when the the LUN  number is increasing
the delay is becoming higher, so do you have any idea
about the problem?

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


[PATCH 1/4] of/overlay: add missing of_node_put

2015-10-22 Thread Julia Lawall
for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/of/overlay.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 24e025f..54e5af9 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -149,6 +149,7 @@ static int of_overlay_apply_one(struct of_overlay *ov,
pr_err("%s: Failed to apply single node @%s/%s\n",
__func__, target->full_name,
child->name);
+   of_node_put(child);
return ret;
}
}
@@ -417,8 +418,10 @@ static int overlay_subtree_check(struct device_node *tree,
return 1;
 
for_each_child_of_node(tree, child) {
-   if (overlay_subtree_check(child, dn))
+   if (overlay_subtree_check(child, dn)) {
+   of_node_put(child);
return 1;
+   }
}
 
return 0;

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


Re: [GIT PULL] On-demand device probing

2015-10-22 Thread Tomeu Vizoso
On 22 October 2015 at 02:54, Rafael J. Wysocki  wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern  wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > Furthermore, that applies only to devices that use synchronous suspend.
>> >> > Async suspend is becoming common, and there the only restrictions are
>> >> > parent-child relations plus whatever explicit requirements that drivers
>> >> > impose by calling device_pm_wait_for_dev().
>> >>
>> >> Hrm, this is the first I'd noticed that feature though I see the initial
>> >> commit dates from January.
>> >
>> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
>> > not 2015!
>> >
>> >>  It looks like most of the users are PCs at
>> >> the minute but we should be using it more widely for embedded things,
>> >> there's definitely some cases I'm aware of where it will allow us to
>> >> remove some open coding.
>> >>
>> >> It does seem like we want to be feeding dependency information we
>> >> discover for probing way into the suspend dependencies...
>> >
>> > Rafael has been thinking about a way to do this systematically.
>> > Nothing concrete has emerged yet.
>>
>> This iteration of the series would make this quite easy, as
>> dependencies are calculated before probes are attempted:
>>
>> https://lkml.org/lkml/2015/6/17/311
>
> Well, if you know how to represent "links" between devices, the mechanism
> introduced here doesn't really add much value, because in that case the
> core knows what the dependencies are in the first place and can only
> defer the probes that have to be deferred.

By "here" you mean what you are proposing for ordering device
suspends, or on-demand probing?

If you meant that probing on-demand is unneeded if we already have
dependency information, I agree with you and that's why I only pushed
forward on-demand, as the approach linked above introduced some
duplication when inferring the dependencies. Maybe that could be
avoided without too much refactoring.

In any case, Thierry mentioned the other day in #tegra that one could
also collect dependency information as a follow up to the on-demand
series by calling device_depend() or such instead of
of_device_probe().

Regards,

Tomeu

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


[PATCH 0/4] add missing of_node_put

2015-10-22 Thread Julia Lawall
The various for_each device_node iterators performs an of_node_get on each
iteration, so a break out of the loop requires an of_node_put.

The complete semantic patch that fixes this problem is
(http://coccinelle.lip6.fr):

// 
@r@
local idexpression n;
expression e1,e2;
iterator name for_each_node_by_name, for_each_node_by_type,
for_each_compatible_node, for_each_matching_node,
for_each_matching_node_and_match, for_each_child_of_node,
for_each_available_child_of_node, for_each_node_with_property;
iterator i;
statement S;
expression list [n1] es;
@@

(
(
for_each_node_by_name(n,e1) S
|
for_each_node_by_type(n,e1) S
|
for_each_compatible_node(n,e1,e2) S
|
for_each_matching_node(n,e1) S
|
for_each_matching_node_and_match(n,e1,e2) S
|
for_each_child_of_node(e1,n) S
|
for_each_available_child_of_node(e1,n) S
|
for_each_node_with_property(n,e1) S
)
&
i(es,n,...) S
)

@@
local idexpression r.n;
iterator r.i;
expression e;
expression list [r.n1] es;
@@

 i(es,n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
   return n;
|
+  of_node_put(n);
?  return ...;
)
   ...
 }

@@
local idexpression r.n;
iterator r.i;
expression e;
expression list [r.n1] es;
@@

 i(es,n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  break;
)
   ...
 }
... when != n

@@
local idexpression r.n;
iterator r.i;
expression e;
identifier l;
expression list [r.n1] es;
@@

 i(es,n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  goto l;
)
   ...
 }
...
l: ... when != n// 

---

 drivers/of/irq.c  |7 +--
 drivers/of/overlay.c  |5 -
 drivers/of/platform.c |8 ++--
 drivers/of/unittest.c |8 ++--
 4 files changed, 21 insertions(+), 7 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v4 08/10] nfc: nci: fix possible crash in nci_core_conn_create

2015-10-22 Thread Robert Dolca
If the number of destination speific parameters supplied is 0 the call
will fail. If the first destination specific parameter does not have a
value, curr_id will be set to 0.

Signed-off-by: Robert Dolca 
---
 net/nfc/nci/core.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index f66a5da..9d5f7a2 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -602,12 +602,19 @@ int nci_core_conn_create(struct nci_dev *ndev, u8 
destination_type,
if (!cmd)
return -ENOMEM;
 
+   if (!number_destination_params)
+   return -EINVAL;
+
cmd->destination_type = destination_type;
cmd->number_destination_params = number_destination_params;
memcpy(cmd->params, params, params_len);
 
data.cmd = cmd;
-   ndev->cur_id = params->value[DEST_SPEC_PARAMS_ID_INDEX];
+
+   if (params->length > 0)
+   ndev->cur_id = params->value[DEST_SPEC_PARAMS_ID_INDEX];
+   else
+   ndev->cur_id = 0;
 
r = __nci_request(ndev, nci_core_conn_create_req,
  (unsigned long)&data,
-- 
1.9.1

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


[PATCH 4/4] of/irq: add missing of_node_put

2015-10-22 Thread Julia Lawall
for_each_matching_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
local idexpression n;
expression e;
identifier l;
@@

 for_each_matching_node(n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  goto l;
)
   ...
 }
...
l: ... when != n
// 

Besides the issue found by the semantic patch, this code also stores the
device_node value in a list, which requires an of_node_get, and then cleans
up the list on exit from the function, which requires an of_node_put.

Signed-off-by: Julia Lawall 

---
 drivers/of/irq.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 171798d..902b89b 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -501,10 +501,12 @@ void __init of_irq_init(const struct of_device_id 
*matches)
 * pointer, interrupt-parent device_node etc.
 */
desc = kzalloc(sizeof(*desc), GFP_KERNEL);
-   if (WARN_ON(!desc))
+   if (WARN_ON(!desc)) {
+   of_node_put(np);
goto err;
+   }
 
-   desc->dev = np;
+   desc->dev = of_node_get(np);
desc->interrupt_parent = of_irq_find_parent(np);
if (desc->interrupt_parent == np)
desc->interrupt_parent = NULL;
@@ -575,6 +577,7 @@ void __init of_irq_init(const struct of_device_id *matches)
 err:
list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
list_del(&desc->list);
+   of_node_put(desc->dev);
kfree(desc);
}
 }

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


[PATCH v4 10/10] nfc: Add Intel Fields Peak NFC solution driver

2015-10-22 Thread Robert Dolca
Fields Peak complies with the ISO/IEC 14443A/B, 15693, 18092,
and JIS X 6319-4. It is an NCI based controller.

RF Protocols supported:
 - NFC Forum Type 1 Tags (Jewel, Topaz)
 - NFC Forum Type 2 Tags (Mifare UL)
 - NFC Forum Type 3 Tags (FeliCa)
 - NFC Forum Type 4A (ISO/IEC 14443 A-4 106kbps to 848kbps)
 - NFC Forum Type 4B (ISO/IEC 14443 B-4 106kbps to 848kbps)
 - NFCIP in passive and active modes (ISO/IEC 18092 106kbps to 424kbps)
 - B’ (based on ISO/IEC 14443 B-2)
 - iCLASS (based on ISO/IEC 15693-2)
 - Vicinity cards (ISO/IEC 15693-3)
 - Kovio tags (NFC Forum Type 2)

The device can be enumerated using ACPI using the id INT339A.
The 1st GPIO is the IRQ and the 2nd is the RESET pin.

Signed-off-by: Robert Dolca 
---
 drivers/nfc/Kconfig  |   1 +
 drivers/nfc/Makefile |   1 +
 drivers/nfc/fdp/Kconfig  |  23 ++
 drivers/nfc/fdp/Makefile |   9 +
 drivers/nfc/fdp/fdp.c| 817 +++
 drivers/nfc/fdp/fdp.h|  38 +++
 drivers/nfc/fdp/i2c.c| 388 ++
 7 files changed, 1277 insertions(+)
 create mode 100644 drivers/nfc/fdp/Kconfig
 create mode 100644 drivers/nfc/fdp/Makefile
 create mode 100644 drivers/nfc/fdp/fdp.c
 create mode 100644 drivers/nfc/fdp/fdp.h
 create mode 100644 drivers/nfc/fdp/i2c.c

diff --git a/drivers/nfc/Kconfig b/drivers/nfc/Kconfig
index 6639cd1..0d6003d 100644
--- a/drivers/nfc/Kconfig
+++ b/drivers/nfc/Kconfig
@@ -68,6 +68,7 @@ config NFC_PORT100
 
  If unsure, say N.
 
+source "drivers/nfc/fdp/Kconfig"
 source "drivers/nfc/pn544/Kconfig"
 source "drivers/nfc/microread/Kconfig"
 source "drivers/nfc/nfcmrvl/Kconfig"
diff --git a/drivers/nfc/Makefile b/drivers/nfc/Makefile
index 2757fe1..e362141 100644
--- a/drivers/nfc/Makefile
+++ b/drivers/nfc/Makefile
@@ -2,6 +2,7 @@
 # Makefile for nfc devices
 #
 
+obj-$(CONFIG_NFC_FDP)  += fdp/
 obj-$(CONFIG_NFC_PN544)+= pn544/
 obj-$(CONFIG_NFC_MICROREAD)+= microread/
 obj-$(CONFIG_NFC_PN533)+= pn533.o
diff --git a/drivers/nfc/fdp/Kconfig b/drivers/nfc/fdp/Kconfig
new file mode 100644
index 000..fbccd9d
--- /dev/null
+++ b/drivers/nfc/fdp/Kconfig
@@ -0,0 +1,23 @@
+config NFC_FDP
+   tristate "Intel FDP NFC driver"
+   depends on NFC_NCI
+   select CRC_CCITT
+   default n
+   ---help---
+ Intel Fields Peak NFC controller core driver.
+ This is a driver based on the NCI NFC kernel layers.
+
+ To compile this driver as a module, choose m here. The module will
+ be called fdp.
+ Say N if unsure.
+
+config NFC_FDP_I2C
+   tristate "NFC FDP i2c support"
+   depends on NFC_FDP && I2C
+   ---help---
+ This module adds support for the Intel Fields Peak NFC controller
+ i2c interface.
+ Select this if your platform is using the i2c bus.
+
+ If you choose to build a module, it'll be called fdp_i2c.
+ Say N if unsure.
diff --git a/drivers/nfc/fdp/Makefile b/drivers/nfc/fdp/Makefile
new file mode 100644
index 000..e79d51b
--- /dev/null
+++ b/drivers/nfc/fdp/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for FDP NCI based NFC driver
+#
+
+obj-$(CONFIG_NFC_FDP) += fdp.o
+obj-$(CONFIG_NFC_FDP_I2C) += fdp_i2c.o
+
+fdp_i2c-objs  = i2c.o
+
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
new file mode 100644
index 000..ccb07a1
--- /dev/null
+++ b/drivers/nfc/fdp/fdp.c
@@ -0,0 +1,817 @@
+/* -
+ * Copyright (C) 2014-2016, Intel Corporation
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it 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 "fdp.h"
+
+#define FDP_OTP_PATCH_NAME "otp.bin"
+#define FDP_RAM_PATCH_NAME "ram.bin"
+#define FDP_FW_HEADER_SIZE 576
+#define FDP_FW_UPDATE_SLEEP1000
+
+#define NCI_GET_VERSION_TIMEOUT8000
+#define NCI_PATCH_REQUEST_TIMEOUT  8000
+#define FDP_PATCH_CONN_DEST0xC2
+#define FDP_PATCH_CONN_PARAM_TYPE  0xA0
+
+#define NCI_PATCH_TYPE_RAM 0x00
+#define NCI_PATCH_TYPE_OTP 0x01
+#define NCI_PATCH_TYPE_EOT 0xFF
+
+#define NCI_PARAM_ID_FW_RAM_VERSION0xA0
+#define NCI_PARAM_ID_FW_OTP_VERSION0xA1
+#define NCI_PARAM_ID_O

[PATCH v4 09/10] nfc: nci: add nci_get_conn_info_by_id function

2015-10-22 Thread Robert Dolca
This functin takes as a parameter a pointer to the nci_dev struct and
the first byte from the values of the first domain specific parameter that
was used for the connection creation.

Signed-off-by: Robert Dolca 
---
 include/net/nfc/nci_core.h |  1 +
 net/nfc/nci/core.c | 13 +
 2 files changed, 14 insertions(+)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 5daf004..0569cb2 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -374,6 +374,7 @@ void nci_clear_target_list(struct nci_dev *ndev);
 void nci_req_complete(struct nci_dev *ndev, int result);
 struct nci_conn_info *nci_get_conn_info_by_conn_id(struct nci_dev *ndev,
   int conn_id);
+int nci_get_conn_info_by_id(struct nci_dev *ndev, u8 id);
 
 /* - NCI status code - */
 int nci_to_errno(__u8 code);
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 9d5f7a2..75bda34 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -64,6 +64,19 @@ struct nci_conn_info *nci_get_conn_info_by_conn_id(struct 
nci_dev *ndev,
return NULL;
 }
 
+int nci_get_conn_info_by_id(struct nci_dev *ndev, u8 id)
+{
+   struct nci_conn_info *conn_info;
+
+   list_for_each_entry(conn_info, &ndev->conn_info_list, list) {
+   if (conn_info->id == id)
+   return conn_info->conn_id;
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(nci_get_conn_info_by_id);
+
 /*  NCI requests  */
 
 void nci_req_complete(struct nci_dev *ndev, int result)
-- 
1.9.1

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


[PATCH v4 03/10] nfc: nci: Introduce new core opcodes

2015-10-22 Thread Robert Dolca
Add NCI_OP_CORE_GET_CONFIG_CMD, NCI_OP_CORE_GET_CONFIG_RSP
and NCI_OP_CORE_RESET_NTF.

Signed-off-by: Robert Dolca 
---
 include/net/nfc/nci.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
index 75d2e18..b495825 100644
--- a/include/net/nfc/nci.h
+++ b/include/net/nfc/nci.h
@@ -315,6 +315,8 @@ struct nci_nfcee_mode_set_cmd {
__u8nfcee_mode;
 } __packed;
 
+#define NCI_OP_CORE_GET_CONFIG_CMD nci_opcode_pack(NCI_GID_CORE, 0x03)
+
 /* --- */
 /*  NCI Responses  */
 /* --- */
@@ -375,6 +377,9 @@ struct nci_nfcee_discover_rsp {
 } __packed;
 
 #define NCI_OP_NFCEE_MODE_SET_RSP nci_opcode_pack(NCI_GID_NFCEE_MGMT, 0x01)
+
+#define NCI_OP_CORE_GET_CONFIG_RSP nci_opcode_pack(NCI_GID_CORE, 0x03)
+
 /* --- */
 /*  NCI Notifications  */
 /* --- */
@@ -528,4 +533,6 @@ struct nci_nfcee_discover_ntf {
struct nci_nfcee_information_tlvinformation_tlv;
 } __packed;
 
+#define NCI_OP_CORE_RESET_NTF  nci_opcode_pack(NCI_GID_CORE, 0x00)
+
 #endif /* __NCI_H */
-- 
1.9.1

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


<    3   4   5   6   7   8   9   >