Re: h8300 build failures ijn linux-next

[Yoshinori Sato]

On Tue, 25 Aug 2015 03:34:20 +0900,
Guenter Roeck wrote:
 
 Hi,
 
 In linux-next as of today (0824), all h8300 builds fail for me with an 
 internal
 compiler error.
 
 Building h8300:allnoconfig ... failed
 --
 Error log:
 
 In file included from include/linux/rcupdate.h:429:0,
  from include/linux/rcusync.h:5,
  from kernel/rcu/sync.c:1:
 include/linux/rcutiny.h: In function ‘rcu_barrier_sched’:
 include/linux/rcutiny.h:55:20: internal compiler error: Segmentation fault
  static inline void rcu_barrier_sched(void)
 ^
 
 I tried both gcc 5.1 and 5.2, built with the patch set available to me.
 
 Is there a more recent compiler / patch set available that might fix the 
 problem ?
 

No.
I tried gcc 6.0. It got same error.
It looks optimization problem on h8300 target.
I will investigate it.

 Thanks,
 Guenter

-- 
Yoshinori Sato
ys...@users.sourceforge.jp
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc

[Zhao Qiang]

On 08/25/2015 07:11 AM, Laura Abbott wrote:
 -Original Message-
 From: Laura Abbott [mailto:labb...@redhat.com]
 Sent: Tuesday, August 25, 2015 7:11 AM
 To: Zhao Qiang-B45475; Wood Scott-B07421
 Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
 lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
 Yang-Leo-R58472; pau...@samba.org
 Subject: Re: [PATCH v6 1/3] genalloc:support memory-allocation with
 bytes-alignment to genalloc
 
 On 08/24/2015 02:31 AM, Zhao Qiang wrote:
  Bytes alignment is required to manage some special RAM, so add
  gen_pool_first_fit_align to genalloc, meanwhile add
  gen_pool_alloc_data to pass data to gen_pool_first_fit_align(modify
  gen_pool_alloc as a wrapper)
 
  Signed-off-by: Zhao Qiang qiang.z...@freescale.com
  ---
  Changes for v6:
  - patches set v6 include a new patch because of using
  - genalloc to manage QE MURAM, patch 0001 is the new
  - patch, adding bytes alignment for allocation for use.
 
include/linux/genalloc.h | 23 +++
lib/genalloc.c   | 58
 +++-
2 files changed, 72 insertions(+), 9 deletions(-)
 
  diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h index
  1ccaab4..55da07e 100644
  --- a/include/linux/genalloc.h
  +++ b/include/linux/genalloc.h
  @@ -34,6 +34,7 @@
 
struct device;
struct device_node;
  +struct gen_pool;
 
/**
 * Allocation callback function type definition @@ -47,7 +48,7 @@
  typedef unsigned long (*genpool_algo_t)(unsigned long *map,
  unsigned long size,
  unsigned long start,
  unsigned int nr,
  -   void *data);
  +   void *data, struct gen_pool *pool);
 
/*
 *  General purpose special memory pool descriptor.
  @@ -73,6 +74,13 @@ struct gen_pool_chunk {
  unsigned long bits[0];  /* bitmap for allocating memory chunk
 */
};
 
  +/*
  + *  gen_pool data descriptor for gen_pool_first_fit_align.
  + */
  +struct genpool_data_align {
  +   int align;  /* alignment by bytes for starting address */
  +};
  +
 
 (sorry for chiming in late, I've been traveling)
 
 Is there an advantage here to wrapping this in a structure instead of
 just passing a pointer to an align integer?


Please look at the commit message for
ca279cf1065fb689abea1dc7d8c11787729bb185 which adds data:

As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a free field 'void *data' to pass any needed 
information to the allocation function.  For example 'data' could be used 
to handle a structure where you store the alignment, the expected memory 
bank, the requester device, or any information that could influence the 
allocation algorithm.

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

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Kamezawa Hiroyuki]

On 2015/08/25 8:15, Paul Turner wrote:

On Mon, Aug 24, 2015 at 3:49 PM, Tejun Heo t...@kernel.org wrote:

Hello,

On Mon, Aug 24, 2015 at 03:03:05PM -0700, Paul Turner wrote:

Hmm... I was hoping for an actual configurations and usage scenarios.
Preferably something people can set up and play with.


This is much easier to set up and play with synthetically.  Just
create the 10 threads and 100 threads above then experiment with
configurations designed at guaranteeing the set of 100 threads
relatively uniform throughput regardless of how many are active.   I
don't think trying to run a VM stack adds anything except complexity
of reproduction here.


Well, but that loses most of details and why such use cases matter to
begin with.  We can imagine up stuff to induce arbitrary set of
requirements.


All that's being proved or disproved here is that it's difficult to
coordinate the consumption of asymmetric thread pools using nice.  The
constraints here were drawn from a real-world example.




I take that the
CPU intensive helper threads are usually IO workers?  Is the scenario
where the VM is set up with a lot of IO devices and different ones may
consume large amount of CPU cycles at any given point?


Yes, generally speaking there are a few major classes of IO (flash,
disk, network) that a guest may invoke.  Each of these backends is
separate and chooses its own threading.


Hmmm... if that's the case, would limiting iops on those IO devices
(or classes of them) work?  qemu already implements IO limit mechanism
after all.


No.

1) They should proceed at the maximum rate that they can that's still
within their provisioning budget.
2) The cost/IO is both inconsistent and changes over time.  Attempting
to micro-optimize every backend for this is infeasible, this is
exactly the type of problem that the scheduler can usefully help
arbitrate.
3) Even pretending (2) is fixable, dynamically dividing these
right-to-work tokens between different I/O device backends is
extremely complex.



I think I should explain my customer's use case of qemu + cpuset/cpu (via 
libvirt)

(1) Isolating hypervisor thread.
   As already discussed, hypervisor threads are isolated by cpuset. But their 
purpose
   is to avoid _latency_ spike caused by hypervisor behavior. So, nice cannot 
be solution
   as already discussed.

(2) Fixed rate vcpu service.
   With using cpu controller's quota/period feature, my customer creates  vcpu 
models like
   Low(1GHz), Mid(2GHz), High(3GHz) for IaaS system.

   To do this, each vcpus should be quota-limited independently, with 
per-thread cpu control.

Especially, the method (1) is used in several enterprise customers for 
stabilizing their system.

Sub-process control should be provided by some way.

Thanks,
-Kame





Anyways, a point here is that threads of the same process competing
isn't a new problem.  There are many ways to make those threads play
nice as the application itself often has to be involved anyway,
especially for something like qemu which is heavily involved in
provisioning resources.


It's certainly not a new problem, but it's a real one, and it's
_hard_.  You're proposing removing the best known solution.



cgroups can be a nice brute-force add-on which lets sysadmins do wild
things but it's inherently hacky and incomplete for coordinating
threads.  For example, what is it gonna do if qemu cloned vcpus and IO
helpers dynamically off of the same parent thread?


We're talking about sub-process usage here.  This is the application
coordinating itself, NOT the sysadmin.  Processes are becoming larger
and larger, we need many of the same controls within them that we have
between them.


  It requires
application's cooperation anyway but at the same time is painful to
actually interact from those applications.


As discussed elsewhere on thread this is really not a problem if you
define consistent rules with respect to which parts are managed by
who.  The argument of potential interference is no different to
messing with an application's on-disk configuration behind its back.
Alternate strawmen which greatly improve this from where we are today
have also been proposed.



Thanks.

--
tejun

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] clk: Add missing header for 'bool' definition to clk-conf.h

[Chen-Yu Tsai]

On Tue, Aug 25, 2015 at 5:28 AM, Stephen Boyd sb...@codeaurora.org wrote:
 On 08/18, Chen-Yu Tsai wrote:
 of_clk_set_defaults uses the type 'bool', but clk-conf.h does not
 include its definition.

 This results in a compile error when only clk-conf.h is used.

 Signed-off-by: Chen-Yu Tsai w...@csie.org
 Cc: sta...@vger.kernel.org

 Why is stable Cc-ed? Is there some sort of compilation failure on
 stable kernels?

There isn't for now. Though I don't see why we shouldn't fix this for
stable kernels as well. It's possible other people or third-party
vendors working with stable/LTS kernels (Android?) may run into it.

I'm perfectly fine with not Cc-ing stable. It just seemed like the
right thing to do.


Regards
ChenYu
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] kernel/sysctl.c: If count including the terminating byte '\0' the write system call should retrun success.

[Sean Fu]

Call path is 
proc_dointvec--do_proc_dointvec--__do_proc_dointvec--proc_get_long.
file: kernel/sysctl.c
function: proc_get_long
...
1927 if (len  *size  perm_tr_len  !memchr(perm_tr, *p,
perm_tr_len))   //this line should accept two bytes
1\0.
1928 return -EINVAL;
...


The latest upstream kernel is also tested, and it is same as 3.16.7 kernel.

3.16.7 kernel:
sean@linux-dunz:~/work/suse_lab/proc_test cat /proc/version
Linux version 3.16.7-7-desktop (geeko@buildhost) (gcc version 4.8.3
20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) #1 SMP
PREEMPT Wed Dec 17 18:00:44 UTC 2014 (762f27a)
sean@linux-dunz:~/work/suse_lab/proc_test gcc ./proc_test.c -o proc_test
sean@linux-dunz:~/work/suse_lab/proc_test sudo ./proc_test enp0s25
Input: ./proc_test, enp0s25
file is: /proc/sys/net/ipv4/conf/enp0s25/rp_filter.
open /proc/sys/net/ipv4/conf/enp0s25/rp_filter ok, fd=3
write 3: len=-1, errno=22, Invalid argument

2.6.16.60 kernel:
linux-8lij:~ # gcc ./proc_test.c -o ./proc_test
linux-8lij:~ # cat /proc/version
Linux version 2.6.16.60-0.83.2-bigsmp (geeko@buildhost) (gcc version
4.1.2 20070115 (SUSE Linux)) #1 SMP Fri Sep 2 13:49:16 UTC 2011
linux-8lij:~ # gcc ./proc_test.c -o ./proc_test
linux-8lij:~ # ./proc_test eth7
Input: ./proc_test, eth7
file is: /proc/sys/net/ipv4/conf/eth7/rp_filter.
open /proc/sys/net/ipv4/conf/eth7/rp_filter ok, fd=3
write 3: len=1, errno=0, Success

On Tue, Aug 25, 2015 at 8:57 AM, Sean Fu fxinr...@gmail.com wrote:
 An application from HuaWei which works fine on 2.6 encounters this
 issue on 3.0 or later kernel.

 Test code:

 #include sys/types.h
 #include sys/stat.h
 #include fcntl.h
 #include unistd.h
 #include stdio.h
 #include string.h
 #include errno.h

 #define MAXLEN (100)

 int main(int argc, char** argv)
 {
 int fd = 0;
 int len = 0;
 char pathname[MAXLEN] = {0};
 char buf[2] = {0};
 int ret = 0xF;
 int value = 0xF;

 if (argc  2)
 {
 printf(Input param error, less 2 param: %s, %s.\n,
 argv[0], argv[1]);
 return 1;
 }

 printf(Input: %s, %s \n, argv[0], argv[1]);

 ret = sprintf(pathname,
 /proc/sys/net/ipv4/conf/%s/rp_filter, argv[1]);
 if (ret  0)
 printf(sprintf error, errno %d, %s\n, errno, 
 strerror(errno));
 printf(file is: %s. \n, pathname);

 fd = open(pathname, O_RDWR, S_IRUSR);
 if (fd =0 )
 {
 printf(open %s failed, errno=%d, %s.\n, pathname,
 errno, strerror(errno));
 return 1;
 }
 printf(open %s ok, fd=%d\n, pathname, fd);

 len = write(fd, 0\0, 2);
 printf(write %d: len=%d, errno=%d, %s\n, fd, len, errno,
 strerror(errno));

 close(fd);
 return 0;
 }

 On Tue, Aug 25, 2015 at 12:59 AM, Steven Rostedt rost...@goodmis.org wrote:
 On Mon, 24 Aug 2015 16:56:13 +0800
 Sean Fu fxinr...@gmail.com wrote:

 when the input argument count including the terminating byte \0,
 The write system call return EINVAL on proc file.
 But it return success on regular file.

 E.g. Writting two bytes (1\0) to /proc/sys/net/ipv4/conf/eth0/rp_filter.
 write(fd, 1\0, 2) return EINVAL.

 And what would do that? What tool broke because of this?

  echo 1  /proc/sys/net/ipv4/conf/eth0/rp_filter

 works just fine. strlen(string) would not include the nul character.
 The only thing I could think of would be a sizeof(str), but then that
 would include someone hardcoding an integer in a string, like:

 char val[] = 1

 write(fd, val, sizeof(val));

 Again, what tool does that?

 If there is a tool out in the wild that use to work on 2.6 (and was
 running on 2.6 then, and not something that was created after that
 change), then we can consider this fix.

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

[PATCH 1/1] of: to support binding numa node to specified device in devicetree

[Zhen Lei]

For now, in function device_add, the new device will be forced to
inherit the numa node of its parent. But this will override the device's
numa node which configured in devicetree.

Signed-off-by: Zhen Lei thunder.leiz...@huawei.com
---
 drivers/base/core.c |  2 +-
 drivers/of/device.c | 11 ++-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index dafae6d..e06de82 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1017,7 +1017,7 @@ int device_add(struct device *dev)
dev-kobj.parent = kobj;

/* use parent numa_node */
-   if (parent)
+   if (parent  (dev_to_node(dev) == NUMA_NO_NODE))
set_dev_node(dev, dev_to_node(parent));

/* first, register with generic layer. */
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 8b91ea2..e5f47ce 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -60,11 +60,12 @@ int of_device_add(struct platform_device *ofdev)
ofdev-name = dev_name(ofdev-dev);
ofdev-id = -1;

-   /* device_add will assume that this device is on the same node as
-* the parent. If there is no parent defined, set the node
-* explicitly */
-   if (!ofdev-dev.parent)
-   set_dev_node(ofdev-dev, of_node_to_nid(ofdev-dev.of_node));
+   /*
+* If this device has not binding numa node in devicetree, that is
+* of_node_to_nid returns NUMA_NO_NODE. device_add will assume that this
+* device is on the same node as the parent.
+*/
+   set_dev_node(ofdev-dev, of_node_to_nid(ofdev-dev.of_node));

return device_add(ofdev-dev);
 }
--
2.5.0


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

[PATCH 0/1] of: to support binding numa node to specified device

[Zhen Lei]

Changelog:
v1 - v2:
In patch v1, binding numa node to specified device only take effect for dt-nodes
directly of root. Patch v2 removed this limitation, we can binding numa node to
any specified device in devicetree.

Zhen Lei (1):
  of: to support binding numa node to specified device in devicetree

 drivers/base/core.c |  2 +-
 drivers/of/device.c | 11 ++-
 2 files changed, 7 insertions(+), 6 deletions(-)

-- 
2.5.0


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

[PATCH] usb: message: remove redundant declaration

[Kris Borer]

Fix the Sparse warning:

message.c:1390:21: warning: symbol 'i' shadows an earlier one
message.c:1294:13: originally declared here

Signed-off-by: Kris Borer kbo...@gmail.com
---
 drivers/usb/core/message.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index f368d20..e83648d 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1387,7 +1387,6 @@ int usb_set_interface(struct usb_device *dev, int 
interface, int alternate)
 * new altsetting.
 */
if (manual) {
-   int i;
 
for (i = 0; i  alt-desc.bNumEndpoints; i++) {
epaddr = alt-endpoint[i].desc.bEndpointAddress;
-- 
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 16/20] ACPICA: Debugger: Split debugger initialization/termination APIs.

[Lv Zheng]

ACPICA commit 7a3f22baab000b186779dac64ad71d9776b8f432

It is likely that the debugger is enabled only when a userspace program
explicitly tells a kernel to do so, so it shouldn't be initialized as
early as current implementation.

The only tool requiring ACPI_DEBUGGER is acpiexec, so acpiexec need to call
the new APIs by itself. And BSD developers may also get notified to invoke
the APIs for DDB enabling. Lv Zheng.

This patch doesn't affect Linux kernel as debugger is currently not enabled
in the Linux kernel.

Link: https://github.com/acpica/acpica/commit/7a3f22ba
Signed-off-by: Lv Zheng lv.zh...@intel.com
Signed-off-by: Bob Moore robert.mo...@intel.com
---
 drivers/acpi/acpica/acdebug.h  |4 
 drivers/acpi/acpica/utxface.c  |7 ---
 drivers/acpi/acpica/utxfinit.c |   11 ---
 include/acpi/acpixf.h  |3 +++
 4 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h
index b5a9c51..447f6d3 100644
--- a/drivers/acpi/acpica/acdebug.h
+++ b/drivers/acpi/acpica/acdebug.h
@@ -77,10 +77,6 @@ struct acpi_db_execute_walk {
 /*
  * dbxface - external debugger interfaces
  */
-acpi_status acpi_db_initialize(void);
-
-void acpi_db_terminate(void);
-
 acpi_status
 acpi_db_single_step(struct acpi_walk_state *walk_state,
union acpi_parse_object *op, u32 op_type);
diff --git a/drivers/acpi/acpica/utxface.c b/drivers/acpi/acpica/utxface.c
index c2bd5e2..4f33281 100644
--- a/drivers/acpi/acpica/utxface.c
+++ b/drivers/acpi/acpica/utxface.c
@@ -92,13 +92,6 @@ acpi_status __init acpi_terminate(void)
 
acpi_ut_mutex_terminate();
 
-#ifdef ACPI_DEBUGGER
-
-   /* Shut down the debugger */
-
-   acpi_db_terminate();
-#endif
-
/* Now we can shutdown the OS-dependent layer */
 
status = acpi_os_terminate();
diff --git a/drivers/acpi/acpica/utxfinit.c b/drivers/acpi/acpica/utxfinit.c
index 42a32a6..a7137ec 100644
--- a/drivers/acpi/acpica/utxfinit.c
+++ b/drivers/acpi/acpica/utxfinit.c
@@ -124,17 +124,6 @@ acpi_status __init acpi_initialize_subsystem(void)
return_ACPI_STATUS(status);
}
 
-   /* If configured, initialize the AML debugger */
-
-#ifdef ACPI_DEBUGGER
-   status = acpi_db_initialize();
-   if (ACPI_FAILURE(status)) {
-   ACPI_EXCEPTION((AE_INFO, status,
-   During Debugger initialization));
-   return_ACPI_STATUS(status);
-   }
-#endif
-
return_ACPI_STATUS(AE_OK);
 }
 
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index f2e2327..d3d7ea0 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -917,6 +917,9 @@ ACPI_DBG_DEPENDENT_RETURN_VOID(void
 ACPI_APP_DEPENDENT_RETURN_VOID(ACPI_PRINTF_LIKE(1)
void ACPI_INTERNAL_VAR_XFACE
acpi_log_error(const char *format, ...))
+ acpi_status acpi_initialize_debugger(void);
+
+void acpi_terminate_debugger(void);
 
 /*
  * Divergences
-- 
1.7.10

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

Re: [PATCH 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses

[Jason Wang]

On 08/24/2015 10:05 PM, Cornelia Huck wrote:
 On Mon, 24 Aug 2015 11:29:29 +0800
 Jason Wang jasow...@redhat.com wrote:

 On 08/21/2015 05:29 PM, Cornelia Huck wrote:
 On Fri, 21 Aug 2015 16:03:52 +0800
 Jason Wang jasow...@redhat.com wrote:
 @@ -850,9 +845,15 @@ kvm_assign_ioeventfd(struct kvm *kvm, struct 
 kvm_ioeventfd *args)
 Unfortunately snipped by diff, but the check here is on !len  !PIO,
 which only does the desired thing as VIRTIO_CCW always uses len == 8.
 Should the check be for !len  MMIO instead?
 I think the answer depends on whether len == 0 is valid for ccw. If not
 we can fail the assign earlier. Since even without this patch, if
 userspace tries to register a dev with len equals to zero, it will also
 be registered to KVM_FAST_MMIO_BUS. If yes, we need check as you
 suggested here.
 I don't think len != 8 makes much sense for the way ioeventfd is
 defined for ccw (we handle hypercalls with a payload specifying the
 device), but we currently don't actively fence it.

 But regardless, I'd prefer to decide directly upon whether userspace
 actually tried to register for the mmio bus.

Ok.


ret = kvm_io_bus_register_dev(kvm, KVM_FAST_MMIO_BUS,
  p-addr, 0, p-dev);
if (ret  0)
 -  goto register_fail;
 +  goto unlock_fail;
 +  } else {
 +  ret = kvm_io_bus_register_dev(kvm, bus_idx, p-addr, p-length,
 +p-dev);
 +  if (ret  0)
 +  goto unlock_fail;
}
 Hm... maybe the following would be more obvious:

 my_bus = (p-length == 0)  (bus_idx == KVM_MMIO_BUS) ? KVM_FAST_MMIO_BUS 
 : bus_idx;
 ret = kvm_io_bus_register_dev(kvm, my_bus, p-addr, p-length, pdev-dev); 

  
 +
kvm-buses[bus_idx]-ioeventfd_count++;
list_add_tail(p-list, kvm-ioeventfds);
 (...)

 @@ -900,10 +899,11 @@ kvm_deassign_ioeventfd(struct kvm *kvm, struct 
 kvm_ioeventfd *args)
if (!p-wildcard  p-datamatch != args-datamatch)
continue;
  
 -  kvm_io_bus_unregister_dev(kvm, bus_idx, p-dev);
if (!p-length) {
kvm_io_bus_unregister_dev(kvm, KVM_FAST_MMIO_BUS,
  p-dev);
 +  } else {
 +  kvm_io_bus_unregister_dev(kvm, bus_idx, p-dev);
}
 Similar comments here... do you want to check for bus_idx ==
 KVM_MMIO_BUS as well?
 Good catch. I think keep the original code as is will be also ok to
 solve this. (with changing the bus_idx to KVM_FAST_MMIO_BUS during
 registering if it was an wildcard mmio).
 Do you need to handle the ioeventfd_count changes on the fast mmio bus
 as well?

Yes. So actually, it needs some changes: checking the return value of
kvm_io_bus_unregister_dev() and decide which bus does the device belongs to.


kvm-buses[bus_idx]-ioeventfd_count--;
ioeventfd_release(p);

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

Re: [PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations

[Olof Johansson]

On Mon, Aug 24, 2015 at 6:50 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
 Hi Olof,


 2015-08-25 6:47 GMT+09:00 Olof Johansson o...@lixom.net:
 Hi,

 On Sun, Aug 23, 2015 at 7:18 PM, Masahiro Yamada
 yamada.masah...@socionext.com wrote:
 1/3: add outer cache support
 2/3: rework SMP operations
 3/3: add device tree nodes

 Timing of this is unfortunate, please resend after 4.3-rc1 is out and
 we can queue it up.

 Given that rc8 is out and the merge window has been delayed,
 is it still too late for 4.3-rc1?

Yes.

 Because 2/3 highly depends on 1/3, I hope whole of this series
 is applied to ARM-SOC tree.

 Review or acked-by from Russell would be appreciated in that case.

 Olof,
 From this series, I am using ARM: uniphier: rather than ARM: UniPhier:
 for the subject prefixes because I noticed you often rephased so when you
 applied my patches.
 Are sub-arch names in lower cases preferable in subject prefixes?

 If you look at git log --no-merges --oneline arch/arm/mach-* you'll
 see that most platforms use either all-caps or all-lowercase.

 I see.

 But, we use UniPhier (with only U and P capitalized) in our official
 documents.

That's OK, others surely capitalize their platform names too in
documentation. Some of them even have funkier capitalization than
that, such as SPEAr.


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

RE: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it is KCS_IDLE

[河合英宏 / KAWAI，HIDEHIRO]

 From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
 
 On 08/23/2015 08:52 PM, 河合英宏 / KAWAI，HIDEHIRO wrote:
  From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
 
  On 08/17/2015 09:54 PM, 河合英宏 / KAWAI，HIDEHIRO wrote:
  From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey 
  Minyard
 
  This patch will break ATN handling on the interfaces.  So we can't do 
  this.
  I understand.  So how about doing like this:
 
/* All states wait for ibf, so just do it here. */
  - if (!check_ibf(kcs, status, time))
  + if (kcs-state != KCS_IDLE  !check_ibf(kcs, status, time))
return SI_SM_CALL_WITH_DELAY;
 
  I think it is not necessary to wait IBF when the state is IDLE.
  In this way, we can also handle the ATN case.
  I think it would be more reliable to go up a level and add a timeout.
  It may be so, but we should address this issue separately (at least
  I think above solution reasonably solves the issue).
 
  This issue happens after all queued messages are processed or dropped
  by timeout.  There is no current message.  So what should we set
  a timeout against?  We can add a timeout into my new flush_messages(),
  but that is meaningful only in panic context.  That doesn't help
  in normal context; we would perform a busy loop of smi_event_handler()
  and schedule() in ipmi_thread().
 
 I'm a little confused here.  Is the problem that the ATN bit is stuck
 high?  If so, it's going to be really hard to work around this without
 breaking ATN handling.

Sorry for my insufficient explanation.  I assume the case where
IBF bit is always 1.  I don't know what happens when
BMC hangs up, but I guess IBF stays in 1 because my server's
BMC behaves as such while rebooting.

Regards,

Hidehiro Kawai

  One should
  be there, anyway.  I thought they were all covered, but I may have missed
  something.
 
  -corey
 
  Regards,
 
  Hidehiro Kawai
  Hitachi, Ltd. Research  Development Group
 
  It's going to be extremely hard to recover if the BMC is not working
  correctly when a panic happens.  I'm not sure what can be done, but if
  you can fix it another way it would be good.
 
  -corey
 
  On 07/27/2015 12:55 AM, Hidehiro Kawai wrote:
  If a BMC is unresponsive for some reason, it ends up completing
  the requested message as an error, then kcs_event() is called once
  to advance the state machine.  However, since the BMC is
  unresponsive now, the status of the KCS interface may not be
  idle.  As the result, the state machine can continue to run and
  comsume CPU time indefinitely even if there is no more request
  message.  Moreover, if this happens in run-to-completion mode
  (i.e. context of panic_event()), the kernel hangs up.
 
  To fix this problem, this patch ignores kcs_event() call if there
  is no request message to be processed.
 
  Signed-off-by: Hidehiro Kawai hidehiro.kawai...@hitachi.com
  ---
   drivers/char/ipmi/ipmi_kcs_sm.c |4 
   1 file changed, 4 insertions(+)
 
  diff --git a/drivers/char/ipmi/ipmi_kcs_sm.c 
  b/drivers/char/ipmi/ipmi_kcs_sm.c
  index 8c25f59..0e187fb 100644
  --- a/drivers/char/ipmi/ipmi_kcs_sm.c
  +++ b/drivers/char/ipmi/ipmi_kcs_sm.c
  @@ -353,6 +353,10 @@ static enum si_sm_result kcs_event(struct 
  si_sm_data *kcs, long time)
  if (kcs_debug  KCS_DEBUG_STATES)
  printk(KERN_DEBUG KCS: State = %d, %x\n, kcs-state, 
  status);
 
  +   /* We don't want to run the state machine when the state is 
  IDLE */
  +   if (kcs-state == KCS_IDLE)
  +   return SI_SM_IDLE;
  +
  /* All states wait for ibf, so just do it here. */
  if (!check_ibf(kcs, status, time))
  return SI_SM_CALL_WITH_DELAY;
 
 

Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7

[Alex Deucher]

On Thu, Aug 13, 2015 at 6:13 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, Aug 13, 2015 at 4:15 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, Aug 13, 2015 at 3:46 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Aug 10, 2015 at 9:06 PM, Jiang Liu jiang@linux.intel.com 
 wrote:
 On 2015/8/10 23:00, Alex Deucher wrote:
 On Sun, Aug 9, 2015 at 4:15 AM, Jiang Liu jiang@linux.intel.com 
 wrote:
 Alex Deucher, Mark Rustad and Alexander Holler reported a regression
 with the latest v4.2-rc4 kernel, which breaks some SATA controllers.
 With multi-MSI capable SATA controllers, only the first port works,
 all other ports times out when executing SATA commands. This regression
 bisects to 52f518a3a7c2 (x86/MSI: Use hierarchical irqdomains to manage
 MSI interrupts), but it's not the root cause, it just triggers a bug
 caused by b5dc8e6c21e7 (x86/irq: Use hierarchical irqdomain to manage
 CPU interrupt vectors).

 With this patch applied, the affected SATA controllers work as expected.

 Yes, this fixes the SATA regression:
 Tested-by: Alex Deucher alexander.deuc...@amd.com

 I'm not sure if it's related to this patch or not (I haven't bisected
 it independently yet), but MSIs don't seem to work on GPUs.  See the
 line for amdgpu.  This is just after loading the driver.
 Hi Alex,
 This patch only affects multiple-MSI, and it seems that your
 gpu only uses one MSI interrupt, so it may not be related to this patch.
 And this seems like a sort of interrupt storm.
   52:   16579895   16579562   16580988   16583443  IR-PCI-MSI
 524288-edge  amdgpu

 Does it make any change by disable interrupt remapping?

 Nope.  Still going crazy:
   46:4769660476913047758994784657   PCI-MSI
 524288-edge  amdgpu


 Does it make any change by disable MSI?

 If I set pci=nomsi, the sata controllers time out.  If I disable MSIs
 just for the gpu, I don't get any interrupts:
   25:  0  0  0  0  IR-IO-APIC
 0-fasteoi   amdgpu


 Strangely, it only seems to affect certain boards.  E.g., this card works 
 fine:
 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
 [AMD/ATI] Bonaire XT [Radeon HD 7790/8770 / R9 260 OEM] (prog-if 00
 [VGA controller])
 Subsystem: Diamond Multimedia Systems Device 2329
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
 ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort+ MAbort- SERR- PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 52
 Region 0: Memory at c000 (64-bit, prefetchable) [size=256M]
 Region 2: Memory at d000 (64-bit, prefetchable) [size=8M]
 Region 4: I/O ports at e000 [size=256]
 Region 5: Memory at ff60 (32-bit, non-prefetchable) [size=256K]
 Expansion ROM at ff64 [disabled] [size=128K]
 Capabilities: [48] Vendor Specific Information: Len=08 ?
 Capabilities: [50] Power Management version 3
 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
 PME(D0-,D1+,D2+,D3hot+,D3cold-)
 Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
 DevCap:MaxPayload 256 bytes, PhantFunc 0, Latency L0s
 4us, L1 unlimited
 ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
 DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
 RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
 MaxPayload 256 bytes, MaxReadReq 512 bytes
 DevSta:CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- 
 TransPend-
 LnkCap:Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit
 Latency L0s 64ns, L1 1us
 ClockPM- Surprise- LLActRep- BwNot-
 LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- CommClk+
 ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
 LnkSta:Speed 8GT/s, Width x16, TrErr- Train- SlotClk+
 DLActive- BWMgmt- ABWMgmt-
 DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-,
 OBFF Not Supported
 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
 OBFF Disabled
 LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
  Transmit Margin: Normal Operating Range,
 EnterModifiedCompliance- ComplianceSOS-
  Compliance De-emphasis: -6dB
 LnkSta2: Current De-emphasis Level: -6dB,
 EqualizationComplete+, EqualizationPhase1+
  EqualizationPhase2+, EqualizationPhase3+, 
 LinkEqualizationRequest-
 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Address: fee0  Data: 
 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1
 Len=010 ?
 Capabilities: [150 v2] Advanced Error Reporting
 UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
 RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
 UEMsk:DLP- SDES- TLP- FCP- CmpltTO- 

Re: [PATCH v6 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc

[Laura Abbott]

On 08/24/2015 07:40 PM, Zhao Qiang wrote:

On 08/25/2015 07:11 AM, Laura Abbott wrote:

-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Tuesday, August 25, 2015 7:11 AM
To: Zhao Qiang-B45475; Wood Scott-B07421
Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
Yang-Leo-R58472; pau...@samba.org
Subject: Re: [PATCH v6 1/3] genalloc:support memory-allocation with
bytes-alignment to genalloc

On 08/24/2015 02:31 AM, Zhao Qiang wrote:

Bytes alignment is required to manage some special RAM, so add
gen_pool_first_fit_align to genalloc, meanwhile add
gen_pool_alloc_data to pass data to gen_pool_first_fit_align(modify
gen_pool_alloc as a wrapper)

Signed-off-by: Zhao Qiang qiang.z...@freescale.com
---
Changes for v6:
- patches set v6 include a new patch because of using
- genalloc to manage QE MURAM, patch 0001 is the new
- patch, adding bytes alignment for allocation for use.

   include/linux/genalloc.h | 23 +++
   lib/genalloc.c   | 58

+++-

   2 files changed, 72 insertions(+), 9 deletions(-)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h index
1ccaab4..55da07e 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -34,6 +34,7 @@

   struct device;
   struct device_node;
+struct gen_pool;

   /**
* Allocation callback function type definition @@ -47,7 +48,7 @@
typedef unsigned long (*genpool_algo_t)(unsigned long *map,
unsigned long size,
unsigned long start,
unsigned int nr,
-   void *data);
+   void *data, struct gen_pool *pool);

   /*
*  General purpose special memory pool descriptor.
@@ -73,6 +74,13 @@ struct gen_pool_chunk {
unsigned long bits[0];  /* bitmap for allocating memory chunk

*/

   };

+/*
+ *  gen_pool data descriptor for gen_pool_first_fit_align.
+ */
+struct genpool_data_align {
+   int align;  /* alignment by bytes for starting address */
+};
+


(sorry for chiming in late, I've been traveling)

Is there an advantage here to wrapping this in a structure instead of
just passing a pointer to an align integer?



Please look at the commit message for
ca279cf1065fb689abea1dc7d8c11787729bb185 which adds data:

As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a free field 'void *data' to pass any needed
information to the allocation function.  For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm.



Right, I understand what the purpose is but I'm not sure what you're getting
from the structure vs passing a pointer, e.g.

int align;

align = 4;

gen_pool_alloc_data(pool, size, align);

it just seems to obfuscate what's going on by wrapping a single integer in
a structure that's narrowly defined in a generic function right now. I guess
it could change later which would necessitate having the structure but again
it's so generic I'm not sure what else you would pass that would be applicable
to all clients.

Thanks,
Laura
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/5] mfd: 88pm800: Add support for clk subdevice

[Krzysztof Kozlowski]

On 25.08.2015 03:56, Vaibhav Hiremath wrote:
 This patch adds mfd_cell/clk-subdevice for 88PM800 MFD
 (and family of devices).
 
 Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
 ---
  drivers/mfd/88pm800.c | 25 +
  1 file changed, 25 insertions(+)
 
 diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
 index c4e097d..a928eed 100644
 --- a/drivers/mfd/88pm800.c
 +++ b/drivers/mfd/88pm800.c
 @@ -173,6 +173,14 @@ static const struct mfd_cell regulator_devs[] = {
   },
  };
  
 +static struct mfd_cell clk_devs[] = {
 + {
 + .name = 88pm80x-clk,
 + .of_compatible = marvell,88pm800-clk,
 + .id = -1,

The -1 here stands for PLATFORM_DEVID_NONE?

Best regards,
Krzysztof

 + },
 +};
 +
  static const struct regmap_irq pm800_irqs[] = {
   /* INT0 */
   [PM800_IRQ_ONKEY] = {
 @@ -344,6 +352,17 @@ static int device_regulator_init(struct pm80x_chip *chip)
   ARRAY_SIZE(regulator_devs), NULL, 0, NULL);
  }
  
 +static int device_clk_init(struct pm80x_chip *chip)
 +{
 + if (chip-type == CHIP_PM800)
 + clk_devs[0].name = 88pm800-clk;
 + else if (chip-type == CHIP_PM860)
 + clk_devs[0].name = 88pm860-clk;
 +
 + return mfd_add_devices(chip-dev, 0, clk_devs[0],
 + ARRAY_SIZE(clk_devs), NULL, 0, NULL);
 +}
 +
  static int device_irq_init_800(struct pm80x_chip *chip)
  {
   struct regmap *map = chip-regmap;
 @@ -511,6 +530,12 @@ static int device_800_init(struct pm80x_chip *chip)
   goto out;
   }
  
 + ret = device_clk_init(chip);
 + if (ret) {
 + dev_err(chip-dev, Failed to add clk subdev\n);
 + goto out;
 + }
 +
   return 0;
  out_dev:
   mfd_remove_devices(chip-dev);
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] mfd: cros_ec: i2c: Add OF match table

[Javier Martinez Canillas]

The Documentation/devicetree/bindings/mfd/cros-ec.txt DT binding doc lists
google,cros-ec-i2c as a compatible string but the corresponding driver
does not have an OF match table. Add the table to the driver so the I2C
core can do an OF style match.

Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com

---

 drivers/mfd/cros_ec_i2c.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index d06e4b46db80..56a466469664 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -344,6 +344,12 @@ static int cros_ec_i2c_resume(struct device *dev)
 static SIMPLE_DEV_PM_OPS(cros_ec_i2c_pm_ops, cros_ec_i2c_suspend,
  cros_ec_i2c_resume);
 
+static const struct of_device_id cros_ec_i2c_of_match[] = {
+   { .compatible = google,cros-ec-i2c, },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, cros_ec_i2c_of_match);
+
 static const struct i2c_device_id cros_ec_i2c_id[] = {
{ cros-ec-i2c, 0 },
{ }
@@ -353,6 +359,7 @@ MODULE_DEVICE_TABLE(i2c, cros_ec_i2c_id);
 static struct i2c_driver cros_ec_driver = {
.driver = {
.name   = cros-ec-i2c,
+   .of_match_table = of_match_ptr(cros_ec_i2c_of_match),
.pm = cros_ec_i2c_pm_ops,
},
.probe  = cros_ec_i2c_probe,
-- 
2.4.3

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver

[Yoshihiro Shimoda]

Hi Geert-san,

 Sent: Monday, August 24, 2015 9:13 PM
 
 Hi Shimoda-san,
 
 On Thu, Aug 20, 2015 at 8:28 AM, Yoshihiro Shimoda
 yoshihiro.shimoda...@renesas.com wrote:
  This patch adds support for R-Car generation 3 USB2 PHY driver.
  This SoC has 3 EHCI/OHCI channels, and the channel 0 is shared
  with the HSUSB (USB2.0 peripheral) device.
 
  So, the purpose of this driver is:
   1) initializes some registers of SoC specific to use the
  {ehci,ohci}-platform driver.
 
   2) detects id pin to select host or peripheral on the channel 0.
 
  For now, this driver only supports 1) above.
 
 Thanks for your patch!

Thank you very much for your review!

  --- /dev/null
  +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
  @@ -0,0 +1,37 @@
  +* Renesas R-Car generation 3 USB 2.0 PHY
  +
  +This file provides information on what the device node for the R-Car 
  generation
  +3 USB 2.0 PHY contains.
  +
  +Required properties:
  +- compatible: renesas,usb2-phy-r8a7795 if the device is a part of 
  R8A7795 SoC.
 
 an R8A7795 SoC.

I will fix this in v2.
(I will submit v2 patch late today.)

  +- reg: offset and length of the USB2.0 host register block.
  +- reg-names: must be usb2.
  +- clocks: clock phandle and specifier pair.
 
 pair(s).

I will fix this.

  +- clock-names: string, clock input name, must be usb2, and optional 
  hsusb.
 
 names

Thank you for the point.
As you mentioned about runtime PM below, I will remove this property.

  +- #phy-cells: see phy-bindings.txt in the same directory, must be 0.
  +
  +Optional proparies:
 
 properties

Oops, I will fix it.
I should have done aspell command before I submitted.
If I did that command, I found other typo in this patch :)

  +To use a USB channel which EHCI/OHCI and HSUSB are combined, the device 
  tree
 
 s/which/where/
 
  +node should set HSUSB proparies to reg and reg-names proparies:
 
 properties (x2)

I will fix it.

  +- reg: offset and length of the HSUSB register block.
  +- reg-names: must be hsusb.
  +
  +Example (R-Car H3):
  +
  +   usb-phy@ee080200 {
  +   compatible = renesas,usb2-phy-r8a7795;
  +   reg = 0 0xee080200 0 0x6ff, 0 0xe6590100 0 0x100;
  +   reg-names = usb2, hsusb;
  +   clocks = mstp7_clks R8A7795_CLK_EHCI0,
  +mstp7_clks R8A7795_CLK_HSUSB;
 
 If you ever want to enable Runtime PM, do you want the first MSTP clock to be
 managed automatically?
 What about the second optional clock?

Thank you very much for the point.
I didn't take care about Runtime PM. However, I want to enable Runtime PM
because usb host and function drivers support it.

  +   clock-names = usb2, hsusb;
  +   };
  +
  +   usb-phy@ee0a0200 {
  +   compatible = renesas,usb2-phy-r8a7795;
  +   reg = 0 0xee0a0200 0 0x6ff;
  +   reg-names = usb2;
  +   clocks = mstp7_clks R8A7795_CLK_EHCI0;
  +   clock-names = usb2;
  +   };
 
  --- /dev/null
  +++ b/drivers/phy/phy-rcar-gen3-usb2.c
 
  +static int rcar_gen3_phy_usb2_init(struct phy *p)
  +{
  +   struct rcar_gen3_phy_usb2_channel *channel = phy_get_drvdata(p);
  +   unsigned long flags;
  +   void __iomem *usb2_base = channel-usb2.base;
  +   void __iomem *hsusb_base = channel-hsusb.base;
  +   u32 tmp;
  +
  +   /* Since ops-init() is called once, this driver enables both 
  clocks */
  +   clk_prepare_enable(channel-usb2.clk);
  +   clk_prepare_enable(channel-hsusb.clk);
 
 So this driver manages its clock(s) itself, and doesn't support Runtime PM.

So, I will use remove clk APIs in this driver.

Best regards,
Yoshihiro Shimoda

  +static int rcar_gen3_phy_usb2_exit(struct phy *p)
  +{
  +   struct rcar_gen3_phy_usb2_channel *channel = phy_get_drvdata(p);
  +
  +   writel(0, channel-usb2.base + USB2_INT_ENABLE);
  +
  +   clk_disable_unprepare(channel-hsusb.clk);
  +   clk_disable_unprepare(channel-usb2.clk);
  +
  +   return 0;
  +}
 
 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
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH 02/20] ACPICA: Disassembler: Remove duplicate code in _PLD processing.

[Lv Zheng]

From: Bob Moore robert.mo...@intel.com

ACPICA commit 6d9c827b540837b6e54059e17756a06985e4a196

ACPICA BZ 1176.

Link: https://bugs.acpica.org/show_bug.cgi?id=1176
Link: https://github.com/acpica/acpica/commit/6d9c827b
Signed-off-by: Bob Moore robert.mo...@intel.com
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
 drivers/acpi/acpica/utxface.c |5 +++--
 include/acpi/acbuffer.h   |1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/utxface.c b/drivers/acpi/acpica/utxface.c
index 51cf52d..c2bd5e2 100644
--- a/drivers/acpi/acpica/utxface.c
+++ b/drivers/acpi/acpica/utxface.c
@@ -517,7 +517,8 @@ acpi_decode_pld_buffer(u8 *in_buffer,
 
/* Parameter validation */
 
-   if (!in_buffer || !return_buffer || (length  16)) {
+   if (!in_buffer || !return_buffer
+   || (length  ACPI_PLD_REV1_BUFFER_SIZE)) {
return (AE_BAD_PARAMETER);
}
 
@@ -567,7 +568,7 @@ acpi_decode_pld_buffer(u8 *in_buffer,
pld_info-rotation = ACPI_PLD_GET_ROTATION(dword);
pld_info-order = ACPI_PLD_GET_ORDER(dword);
 
-   if (length = ACPI_PLD_BUFFER_SIZE) {
+   if (length = ACPI_PLD_REV2_BUFFER_SIZE) {
 
/* Fifth 32-bit DWord (Revision 2 of _PLD) */
 
diff --git a/include/acpi/acbuffer.h b/include/acpi/acbuffer.h
index 6b040f4..fcf9080 100644
--- a/include/acpi/acbuffer.h
+++ b/include/acpi/acbuffer.h
@@ -147,6 +147,7 @@ struct acpi_pld_info {
  *(Intended for BIOS use only)
  */
 #define ACPI_PLD_REV1_BUFFER_SIZE   16 /* For Revision 1 of 
the buffer (From ACPI spec) */
+#define ACPI_PLD_REV2_BUFFER_SIZE   20 /* For Revision 2 of 
the buffer (From ACPI spec) */
 #define ACPI_PLD_BUFFER_SIZE20 /* For Revision 2 of 
the buffer (From ACPI spec) */
 
 /* First 32-bit dword, bits 0:32 */
-- 
1.7.10

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

RE: [PATCH 3/3] mtd: spi-nor: sf: Add clear flag status register support

[Hou Zhiqiang]

Hi Jagan,

 -Original Message-
 From: Jagan Teki [mailto:jt...@openedev.com]
 Sent: 2015年8月21日 15:12
 To: Hou Zhiqiang-B48286
 Cc: linux-...@lists.infradead.org; Hu Mingkai-B21284; Brian Norris; David
 Woodhouse; linux-kernel@vger.kernel.org
 Subject: Re: [PATCH 3/3] mtd: spi-nor: sf: Add clear flag status register
 support
 
 Hi Zhiqiang,
 
 On 20 August 2015 at 08:36, Hou Zhiqiang b48...@freescale.com wrote:
  Hello Jagan,
 
  -Original Message-
  From: Jagan Teki [mailto:jt...@openedev.com]
  Sent: 2015年8月20日 1:49
  To: Hou Zhiqiang-B48286
  Cc: linux-...@lists.infradead.org; Hu Mingkai-B21284; Brian Norris;
  David Woodhouse; linux-kernel@vger.kernel.org
  Subject: Re: [PATCH 3/3] mtd: spi-nor: sf: Add clear flag status
  register support
 
  Hi Zhiqiang,
 
  On 19 August 2015 at 17:42, Hou Zhiqiang b48...@freescale.com wrote:
   Hi Jagan,
  
   -Original Message-
   From: Jagan Teki [mailto:jt...@openedev.com]
   Sent: 2015年8月19日 17:57
   To: linux-...@lists.infradead.org
   Cc: linux-kernel@vger.kernel.org; Jagan Teki; Hou Zhiqiang-B48286;
   Hu Mingkai-B21284; David Woodhouse; Brian Norris
   Subject: [PATCH 3/3] mtd: spi-nor: sf: Add clear flag status
   register support
  
   The clear flag status register operation was required by Micron
   SPI-NOR chips, which support FSR. And if an error bit of FSR have
   been set like protection, voltage, erase, and program, it must be
   cleared by the clear FSR operation.
  
   Signed-off-by: Jagan Teki jt...@openedev.com
   Cc: Hou Zhiqiang b48...@freescale.com
   Cc: Mingkai.Hu mingkai...@freescale.com
   Cc: David Woodhouse dw...@infradead.org
   Cc: Brian Norris computersforpe...@gmail.com
   ---
drivers/mtd/spi-nor/spi-nor.c | 35
   +++---
  -
include/linux/mtd/spi-nor.h   |  9 +
2 files changed, 40 insertions(+), 4 deletions(-)
  
   diff --git a/drivers/mtd/spi-nor/spi-nor.c
   b/drivers/mtd/spi-nor/spi- nor.c index f954d03..c5c472d5 100644
   --- a/drivers/mtd/spi-nor/spi-nor.c
   +++ b/drivers/mtd/spi-nor/spi-nor.c
   @@ -100,6 +100,28 @@ static int read_fsr(struct spi_nor *nor)  }
  
/*
   + * Read the clear flag status register.
   + * The clear flag status register operation was required by
   +Micron
   + * SPI-NOR chips, which support FSR. And if an error bit of FSR
   + * have been set like protection, voltage, erase, and program,
   + * it must be cleared by the clear FSR operation.
   + * Returns zero for FSR bits cleared and negative if error
 occurred.
   + */
   +static int read_cfsr(struct spi_nor *nor) {
   + int ret;
   + u8 val;
   +
   + ret = nor-read_reg(nor, SPINOR_OP_RDCFSR, val, 1);
  
   There should be a write_reg instead of read_reg.
   There isn’t a register named CFSR, and the command SPINOR_OP_RDCFSR
   is used to clear the FSR, another words reset FSR to default value.
 
  Yes, SPINOR_OP_RDCFSR is clear flag status register, for clearing
  errors bits on fsr we need to read cfsr once.
 
 
  Sorry, I'm not clear for this operation. Please correct me if I'm wrong.
  As far as I understand, this command is used to reset the FSR. Does a
  value Will be read back? And there is not the register CFSR, so I
  don't know which register will be read by SPINOR_OP_RDCFSR?
 
 Sorry for the confusion in previous email.
 
 If there is any error bits set during FSR operation, those will reset
 back to original values by reading CFSR ie means the bits on flag status
 register revert back to original state, so-that the flag status register
 is ready for next FSR operation.
 
 I have defined this, SPINOR_OP_RDCFSR on the patch
 
 diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
 index c5a58c4..36c1681 100644
 --- a/include/linux/mtd/spi-nor.h
 +++ b/include/linux/mtd/spi-nor.h
 @@ -35,6 +35,7 @@
  #define SPINOR_OP_RDID 0x9f/* Read JEDEC ID */
  #define SPINOR_OP_RDCR 0x35/* Read configuration register */
  #define SPINOR_OP_RDFSR0x70/* Read flag status
 register */
 +#define SPINOR_OP_RDCFSR   0x50/* Read clear flag status
 register */
 
 For more information pls- refer flash datasheet[1]
 
 Page, 29: about fsr
 Page, 41: about cfsr

Upon page 41, I think, it is a CMD which is used to clear the FSR instead of
a CFSR Register. This section is to expound the CLEAR FLAG STATUS REGISTER
Command, and it says execute this CMD to clear the error bits, rather than
read the CFSR to clear those bits.

 
 [1]
 https://www.google.co.in/url?sa=trct=jq=esrc=ssource=webcd=2cad=rja
 uact=8ved=0CCIQFjABahUKEwjTwY3zzbnHAhXVj44KHdiWDVUurl=https%3A%2F%2Fww
 w.micron.com%2F~%2Fmedia%2Fdocuments%2Fproducts%2Fdata-sheet%2Fnor-
 flash%2Fserial-
 nor%2Fn25q%2Fn25q_512mb_1ce_3v_65nm.pdfei=Uc3WVZPVCNWfugTYrbaoBQusg=AFQ
 jCNEN4dLie4U9OTSbNxN-h9jyN9InDQsig2=vRQTvlkbgsgJw1Fy9z1K8A
 
Thanks!
Zhiqiang
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z�

RE: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram

[Zhao Qiang]

 -Original Message-
 From: Laura Abbott [mailto:labb...@redhat.com]
 Sent: Tuesday, August 25, 2015 7:32 AM
 To: Zhao Qiang-B45475; Wood Scott-B07421
 Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
 lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
 Yang-Leo-R58472; pau...@samba.org
 Subject: Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage
 muram
 
 On 08/24/2015 02:31 AM, Zhao Qiang wrote:
 
 
  +out:
  +   of_node_put(np);
  +   return ret;
  +}
  +
  +/**
  + * qe_muram_alloc - allocate the requested size worth of multi-user
  +ram
  + * @size: number of bytes to allocate
  + * @align: requested alignment, in bytes
  + *
  + * This function returns an offset into the muram area.
  + * Use qe_dpram_addr() to get the virtual address of the area.
  + * Use qe_muram_free() to free the allocation.
  + */
  +unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
  +{
  +   unsigned long start;
  +   unsigned long flags;
  +   struct muram_block *entry;
  +
  +   spin_lock_irqsave(qe_muram_lock, flags);
  +   muram_pool_data.align = align;
  +   start = gen_pool_alloc(muram_pool, size);
 
 The advantage of creating gen_pool_alloc_data was so that you could pass
 in the align automatically without having to modify the structure.
 Is there a reason you aren't using that?
 
  +   memset(qe_muram_addr(start), 0, size);
 
 There doesn't seem to be a check for allocation failure from the
 gen_alloc.

gen_pool_alloc will return 0 if there is error, but if the address returned is 
just 0x0, it can't distinguish it is address or error.

 
  +   entry = kmalloc(sizeof(*entry), GFP_KERNEL);
  +   if (!entry)
  +   goto out;
  +   entry-start = start;
  +   entry-size = size;
  +   list_add(entry-head, muram_block_list);
 
 What's the point of keeping the block list anyway? It's used only in this
 file and it only seems to duplicate what gen_alloc is doing internally.
 Is there some lookup functionality you still need? Could you use a
 gen_alloc API to do so?

I need to record the size when allocation, so when free the block, I can get 
The right size for the block, and pass the right size to 
gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size).

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

Re: [PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations

[Viresh Kumar]

On Tue, Aug 25, 2015 at 8:35 AM, Olof Johansson o...@lixom.net wrote:
 That's OK, others surely capitalize their platform names too in
 documentation. Some of them even have funkier capitalization than
 that, such as SPEAr.

That's how the company projected it :(

www.st.com/spear
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] drm/crtc: Add a helper func to get a registered crtc from its index

[Xinliang Liu]

This patch add a helper func to get a registered crtc from its index.
In some case, where we know the crtc's index and we want to know the
crtc too.

For example, the enable_vblank func of struct drm_driver:
In the implementation of this func, we know the index of the crtc but
we want to know the crtc. This helper func can get the crtc easily.
A sample impelmentation of enable_vblank is as shown as bellow:

int hisi_drm_crtc_enable_vblank(struct drm_device *dev, int c)
{
struct drm_crtc *crtc = drm_get_crtc_from_index(dev, c);
struct hisi_crtc *hcrtc = to_hisi_crtc(crtc);
struct hisi_crtc_ops *ops = hcrtc-ops;
int ret = 0;

if (ops-enable_vblank)
ret = ops-enable_vblank(hcrtc);

return ret;
}

Signed-off-by: Xinliang Liu xinliang@linaro.org
---
 drivers/gpu/drm/drm_crtc.c | 25 +
 include/drm/drm_crtc.h |  2 ++
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b9ba061..8764765 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -747,6 +747,31 @@ unsigned int drm_crtc_index(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_index);
 
+/**
+ * drm_get_crtc_from_index - find a registered CRTC from the index
+ * @dev: DRM device
+ * @index: index of a registered CRTC
+ *
+ * Given a index, return the registered CRTC within a DRM
+ * device's list of CRTCs.
+ */
+struct drm_crtc *drm_get_crtc_from_index(struct drm_device *dev,
+unsigned int index)
+{
+   unsigned int index_tmp = 0;
+   struct drm_crtc *crtc;
+
+   list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
+   if (index_tmp == index)
+   return crtc;
+
+   index_tmp++;
+   }
+
+   BUG();
+}
+EXPORT_SYMBOL(drm_get_crtc_from_index);
+
 /*
  * drm_mode_remove - remove and free a mode
  * @connector: connector list to modify
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 57ca8cc..3a46d39d 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1225,6 +1225,8 @@ extern int drm_crtc_init_with_planes(struct drm_device 
*dev,
 const struct drm_crtc_funcs *funcs);
 extern void drm_crtc_cleanup(struct drm_crtc *crtc);
 extern unsigned int drm_crtc_index(struct drm_crtc *crtc);
+extern struct drm_crtc *drm_get_crtc_from_index(struct drm_device *dev,
+   unsigned int index);
 
 /**
  * drm_crtc_mask - find the mask of a registered CRTC
-- 
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: [BUG] arm: kgdb: patch_text() in kgdb_arch_set_breakpoint() may sleep

[Kees Cook]

On Mon, Aug 24, 2015 at 4:56 PM, Doug Anderson diand...@chromium.org wrote:
 Kees,

 On Mon, Aug 24, 2015 at 10:46 AM, Kees Cook keesc...@chromium.org wrote:
 On Sun, Aug 23, 2015 at 7:45 PM, Doug Anderson diand...@chromium.org wrote:
 On Wed, Aug 5, 2015 at 8:50 AM, Aapo Vienamo avien...@nvidia.com wrote:
 Hi,

 The breakpoint setting code in arch/arm/kernel/kgdb.c calls
 patch_text(), which ends up trying to sleep while in interrupt context.
 The bug was introduced by commit: 23a4e40 arm: kgdb: Handle read-only
 text / modules. The resulting behavior is BUG: scheduling while
 atomic... when setting a breakpoint in kgdb. This was tested on an
 Nvidia Jetson TK1 board with 4.2.0-rc5-next-20150805 kernel.

 Regards,
 Aapo Vienamo

 Aapo,

 Including the stack trace with this would have been helpful, though
 it's not too hard to reproduce.  Here it is:

 [  416.510559] BUG: scheduling while atomic: swapper/0/0/0x00010007
 [  416.516554] Modules linked in:
 [  416.519614] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
 4.2.0-rc7-00133-geb63b34 #1073
 [  416.527341] Hardware name: Rockchip (Device Tree)
 [  416.532042] [c0017a4c] (unwind_backtrace) from [c00133d4]
 (show_stack+0x20/0x24)
 [  416.539772] [c00133d4] (show_stack) from [c05400e8]
 (dump_stack+0x84/0xb8)
 [  416.546983] [c05400e8] (dump_stack) from [c004913c]
 (__schedule_bug+0x54/0x6c)
 [  416.554540] [c004913c] (__schedule_bug) from [c054065c]
 (__schedule+0x80/0x668)
 [  416.562183] [c054065c] (__schedule) from [c0540cfc] 
 (schedule+0xb8/0xd4)
 [  416.569219] [c0540cfc] (schedule) from [c0543a3c]
 (schedule_timeout+0x2c/0x234)
 [  416.576861] [c0543a3c] (schedule_timeout) from [c05417c0]
 (wait_for_common+0xf4/0x188)
 [  416.585109] [c05417c0] (wait_for_common) from [c0541874]
 (wait_for_completion+0x20/0x24)
 [  416.593531] [c0541874] (wait_for_completion) from [c00a0104]
 (__stop_cpus+0x58/0x70)
 [  416.601608] [c00a0104] (__stop_cpus) from [c00a0580]
 (stop_cpus+0x3c/0x54)
 [  416.608817] [c00a0580] (stop_cpus) from [c00a06c4]
 (__stop_machine+0xcc/0xe8)
 [  416.616286] [c00a06c4] (__stop_machine) from [c00a0714]
 (stop_machine+0x34/0x44)
 [  416.624016] [c00a0714] (stop_machine) from [c00173e8]
 (patch_text+0x28/0x34)
 [  416.631399] [c00173e8] (patch_text) from [c001733c]
 (kgdb_arch_set_breakpoint+0x40/0x4c)
 [  416.639823] [c001733c] (kgdb_arch_set_breakpoint) from
 [c00a0d68] (kgdb_validate_break_address+0x2c/0x60)
 [  416.649719] [c00a0d68] (kgdb_validate_break_address) from
 [c00a0e90] (dbg_set_sw_break+0x1c/0xdc)
 [  416.658922] [c00a0e90] (dbg_set_sw_break) from [c00a2e88]
 (gdb_serial_stub+0x9c4/0xba4)
 [  416.667259] [c00a2e88] (gdb_serial_stub) from [c00a11cc]
 (kgdb_cpu_enter+0x1f8/0x60c)
 [  416.675423] [c00a11cc] (kgdb_cpu_enter) from [c00a18cc]
 (kgdb_handle_exception+0x19c/0x1d0)
 [  416.684106] [c00a18cc] (kgdb_handle_exception) from [c0016f7c]
 (kgdb_compiled_brk_fn+0x30/0x3c)
 [  416.693135] [c0016f7c] (kgdb_compiled_brk_fn) from [c00091a4]
 (do_undefinstr+0x1a4/0x20c)
 [  416.701643] [c00091a4] (do_undefinstr) from [c001400c]
 (__und_svc_finish+0x0/0x34)
 [  416.709543] Exception stack(0xc07c1ce8 to 0xc07c1d30)
 [  416.714584] 1ce0:    c07c6504 c086e290
 c086e294 c086e294 c086e290
 [  416.722745] 1d00: c07c6504 0067 0001 c07c2100 0027
 c07c1d4c c07c1d50 c07c1d30
 [  416.730905] 1d20: c00a0990 c00a08d0 6193 
 [  416.735947] [c001400c] (__und_svc_finish) from [c00a08d0]
 (kgdb_breakpoint+0x58/0x94)
 [  416.744110] [c00a08d0] (kgdb_breakpoint) from [c00a0990]
 (sysrq_handle_dbg+0x58/0x6c)
 [  416.752273] [c00a0990] (sysrq_handle_dbg) from [c02c230c]
 (__handle_sysrq+0xac/0x15c)
 [  416.760437] [c02c230c] (__handle_sysrq) from [c02c23ec]
 (handle_sysrq+0x30/0x34)


 Kees: I think you've dealt with a lot more of these types of issues
 than I have.  Any quick thoughts?  If not I can put it on my long-term
 list of things to do, but until then we could always just post a
 Revert...

 I don't think a revert is in order here. CONFIG_DEBUG_RODATA could be
 turned off for builds where you need kgdb while this bug gets found.

 I don't think that's right.  In my testing I don't have
 CONFIG_DEBUG_RODATA.  I think I did the right grep:

 $ grep ARM_KERNMEM_PERMS .config
 # CONFIG_ARM_KERNMEM_PERMS is not set

 Basically no matter what we'll call:
 - kgdb_arch_set_breakpoint
 -- patch_text
 --- stop_machine

 ...no dependencies on RODATA.

I said DEBUG_RODATA since that's the stricter of the options (it
requires KERNMEM_PERMS). But yes, I see now that patch.c doesn't test
for this feature at all (which probably makes sense).

 I
 don't actually see where we've gone wrong, though. Looks like
 scheduling happened while waiting for CPUs to stop? Where did we enter
 atomic?

 We're in kdb.  That's a stop mode debugger.  No sleeping allowed while
 in the debugger.


 Perhaps we need to test if we're already atomic in patch_text, and
 only call stop_machine if we need to?

 Untested (and likely 

[PATCH 2/3] tools/liblockdep: correct macro for WARN

[Sasha Levin]

As Peter Zijlstra pointed out, the varargs for WARN() are optional, so we
need to correctly handle the case where they don't exist.

This would cause a compilation error.

Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
 tools/lib/lockdep/uinclude/linux/kernel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/lockdep/uinclude/linux/kernel.h 
b/tools/lib/lockdep/uinclude/linux/kernel.h
index cd2cc59..276c7a8 100644
--- a/tools/lib/lockdep/uinclude/linux/kernel.h
+++ b/tools/lib/lockdep/uinclude/linux/kernel.h
@@ -23,7 +23,7 @@
 #define WARN_ON(x) (x)
 #define WARN_ON_ONCE(x) (x)
 #define likely(x) (x)
-#define WARN(x, y, z) (x)
+#define WARN(x, y...) (x)
 #define uninitialized_var(x) x
 #define __init
 #define noinline
-- 
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 3/3] tools/liblockdep: use the rbtree header provided by common tools headers

[Sasha Levin]

Recent changes to rbtree.h may break compilation. There is no reason to use
a liblockdep specific header to begin with, so we'll use the one shared
with all other tools/.

Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
 tools/lib/lockdep/preload.c   | 2 +-
 tools/lib/lockdep/uinclude/linux/rbtree.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)
 delete mode 100644 tools/lib/lockdep/uinclude/linux/rbtree.h

diff --git a/tools/lib/lockdep/preload.c b/tools/lib/lockdep/preload.c
index 0b0112c..21cdf86 100644
--- a/tools/lib/lockdep/preload.c
+++ b/tools/lib/lockdep/preload.c
@@ -5,7 +5,7 @@
 #include stdlib.h
 #include sysexits.h
 #include include/liblockdep/mutex.h
-#include ../../../include/linux/rbtree.h
+#include ../../include/linux/rbtree.h
 
 /**
  * struct lock_lookup - liblockdep's view of a single unique lock
diff --git a/tools/lib/lockdep/uinclude/linux/rbtree.h 
b/tools/lib/lockdep/uinclude/linux/rbtree.h
deleted file mode 100644
index 965901d..000
--- a/tools/lib/lockdep/uinclude/linux/rbtree.h
+++ /dev/null
@@ -1 +0,0 @@
-#include ../../../include/linux/rbtree.h
-- 
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/

linux-next: manual merge of the kvm-ppc tree with the tip tree

[Stephen Rothwell]

Hi Alexander,

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

  arch/powerpc/kvm/book3s_hv.c

between commit:

  c56dadf39761 ("sched/preempt, powerpc, kvm: Use need_resched() instead of 
should_resched()")

from the tip tree and commit:

  ec2571650826 ("KVM: PPC: Book3S HV: Make use of unused threads when running 
guests")

from the kvm-ppc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/powerpc/kvm/book3s_hv.c
index a9f753fb73a8,fad52f226c12..
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@@ -2178,11 -2670,12 +2670,13 @@@ static int kvmppc_run_vcpu(struct kvm_r
vc->runner = vcpu;
if (n_ceded == vc->n_runnable) {
kvmppc_vcore_blocked(vc);
 -  } else if (should_resched()) {
 +  } else if (need_resched()) {
 +  vc->vcore_state = VCORE_PREEMPT;
+   kvmppc_vcore_preempt(vc);
/* Let something else run */
cond_resched_lock(>lock);
-   vc->vcore_state = VCORE_INACTIVE;
+   if (vc->vcore_state == VCORE_PREEMPT)
+   kvmppc_vcore_end_preempt(vc);
} else {
kvmppc_run_core(vc);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-v5 RESEND 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa

[Vaibhav Hiremath]

Driver will now supports enable/disable across msg xfer, which user
can control it by new DT property -

i2c-disable-after-xfer : If set, driver will disable I2C module after msg
 xfer and enable it back before xfer.

Signed-off-by: Vaibhav Hiremath 
---
 Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt 
b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..9657db5 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -18,6 +18,11 @@ Recommended properties :
status register of i2c controller instead.
  - mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
 
+Optional properties :
+
+ - i2c-disable-after-xfer : If set, driver will disable I2C module
+   after msg xfer and enable it again before xfer.
+
 Examples:
twsi1: i2c@d4011000 {
compatible = "mrvl,mmp-twsi";
-- 
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-v5 RESEND 0/5] i2c: pxa: Add support for PXA910 family of device

[Vaibhav Hiremath]

Sorry for not following up on this aggressively, was quit busy with some
other stuff. Resending this patch with Robert's Tested-By.


This patch-series is subset of the original patch-series, submitted
on 14 Jul 2015.
Link to Original Patch-series - https://lkml.org/lkml/2015/7/14/80

The first six patches have been already queued up for upstream. So this
patch-series is respin of remaining 5 patches.

Testing:
  - Basic testing on PMIC device on I2C-0 interface
  - Boot tested on platform based on PXA1928
  - Read few registers of PMIC (RTC, ID, etc...) during boot

V4 => V5
===
Link to V3: https://lkml.org/lkml/2015/7/14/80
  - Dropped First 6 patches as they are already accepted, queued for upstream
  - Fixed a bug in PATCH [5/5], where for non PXA910 devices it as resulting 
into
NULL pointer dereference.


For the record, pasting all the details from original patch-series -

V3 => V4
===
Link to V3: http://www.spinics.net/lists/devicetree/msg85904.html
  - [PATCH 06/11] Removed unnecessary dev_err on devm_kzalloc() check
  - [PATCH 06/11] Removed return check on platform_get_resource(), as 
devm_ioremap_resource() does it for us.
Also, brought up the devm_ioremap_resource() function call in the execution
sequence, as no point in delaying it if we do not have resource.
It make sense, after this change.
  - [PATCH 04/11] Typecast changed to 'enum pxa_i2c_types'
Also updated the subject line "Removed ==> Fix"

V2 => V3
===
Link to V2: http://www.spinics.net/lists/linux-i2c/msg20059.html
  - Removed PATCH [4/12] related to reset of I2C module.
Suggested by "Robert Jarzmik"
  - Updated commit description for,
  PATCH [11/12]: Mentioned reasoning about moment of clk_get code.
  PATCH [12/12]: for DT property node.
  - Added Acked by "Robert Jarzmik" to patched which he acked.

V1 => V2:

Link to V1 - 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/347012.html
  - Fixed all comments from "Robert Jarzmik" and "Wolfram Sang"
 - Dropped Patch
 05/12: using core bus reset implementation - under work.
 08/12: NAKed and dropped
 - Separated DT binding patch from driver changes, for easy merge


Vaibhav Hiremath (4):
  Documentation: binding: add new property 'disable_after_xfer' to
i2c-pxa
  i2c: pxa: Add support for pxa910/988 & new configuration features
  Documentation: binding: add sclk adjustment properties to i2c-pxa
  i2c: pxa: Add ILCR (tLow & tHigh) configuration support

Yi Zhang (1):
  i2c: pxa: enable/disable i2c module across msg xfer

 Documentation/devicetree/bindings/i2c/i2c-pxa.txt |  18 +++
 drivers/i2c/busses/i2c-pxa.c  | 154 --
 2 files changed, 163 insertions(+), 9 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-v5 RESEND 2/5] i2c: pxa: enable/disable i2c module across msg xfer

[Vaibhav Hiremath]

From: Yi Zhang 

Enable i2c module/unit before transmission and disable when it
finishes.

why?
It's because the i2c bus may be disturbed if the slave device,
typically a touch, powers on.

As we do not want to break slave mode support, this patch introduces
DT property to control disable of the I2C module after xfer in master
mode of operation.

i2c-disable-after-xfer : If set, driver will disable I2C module after
msg xfer

Signed-off-by: Yi Zhang 
Signed-off-by: Vaibhav Hiremath 
---
 drivers/i2c/busses/i2c-pxa.c | 43 +--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 66cf437..abf04f2 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -161,6 +161,7 @@ struct pxa_i2c {
unsigned char   master_code;
unsigned long   rate;
boolhighmode_enter;
+   booldisable_after_xfer;
 };
 
 #define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -284,6 +285,24 @@ static void i2c_pxa_scream_blue_murder(struct pxa_i2c 
*i2c, const char *why)
 static void i2c_pxa_master_complete(struct pxa_i2c *i2c, int ret);
 static irqreturn_t i2c_pxa_handler(int this_irq, void *dev_id);
 
+/* enable/disable i2c unit */
+static inline int i2c_pxa_is_enabled(struct pxa_i2c *i2c)
+{
+   return (readl(_ICR(i2c)) & ICR_IUE);
+}
+
+static inline void i2c_pxa_enable(struct pxa_i2c *i2c, bool enable)
+{
+   if (enable) {
+   if (!i2c_pxa_is_enabled(i2c)) {
+   writel(readl(_ICR(i2c)) | ICR_IUE, _ICR(i2c));
+   udelay(100);
+   }
+   } else {
+   writel(readl(_ICR(i2c)) & ~ICR_IUE, _ICR(i2c));
+   }
+}
+
 static inline int i2c_pxa_is_slavemode(struct pxa_i2c *i2c)
 {
return !(readl(_ICR(i2c)) & ICR_SCLE);
@@ -480,8 +499,7 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
i2c_pxa_set_slave(i2c, 0);
 
/* enable unit */
-   writel(readl(_ICR(i2c)) | ICR_IUE, _ICR(i2c));
-   udelay(100);
+   i2c_pxa_enable(i2c, true);
 }
 
 
@@ -832,6 +850,9 @@ static int i2c_pxa_pio_xfer(struct i2c_adapter *adap,
struct pxa_i2c *i2c = adap->algo_data;
int ret, i;
 
+   /* Enable i2c unit */
+   i2c_pxa_enable(i2c, true);
+
/* If the I2C controller is disabled we need to reset it
  (probably due to a suspend/resume destroying state). We do
  this here as we can then avoid worrying about resuming the
@@ -852,6 +873,11 @@ static int i2c_pxa_pio_xfer(struct i2c_adapter *adap,
ret = -EREMOTEIO;
  out:
i2c_pxa_set_slave(i2c, ret);
+
+   /* disable i2c unit */
+   if (i2c->disable_after_xfer)
+   i2c_pxa_enable(i2c, false);
+
return ret;
 }
 
@@ -1067,6 +1093,9 @@ static int i2c_pxa_xfer(struct i2c_adapter *adap, struct 
i2c_msg msgs[], int num
struct pxa_i2c *i2c = adap->algo_data;
int ret, i;
 
+   /* Enable i2c unit */
+   i2c_pxa_enable(i2c, true);
+
for (i = adap->retries; i >= 0; i--) {
ret = i2c_pxa_do_xfer(i2c, msgs, num);
if (ret != I2C_RETRY)
@@ -1080,6 +1109,10 @@ static int i2c_pxa_xfer(struct i2c_adapter *adap, struct 
i2c_msg msgs[], int num
ret = -EREMOTEIO;
  out:
i2c_pxa_set_slave(i2c, ret);
+   /* disable i2c unit */
+   if (i2c->disable_after_xfer)
+   i2c_pxa_enable(i2c, false);
+
return ret;
 }
 
@@ -1120,6 +1153,9 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, 
struct pxa_i2c *i2c,
/* For device tree we always use the dynamic or alias-assigned ID */
i2c->adap.nr = -1;
 
+   i2c->disable_after_xfer = of_property_read_bool(np,
+   "i2c-disable-after-xfer");
+
if (of_get_property(np, "mrvl,i2c-polling", NULL))
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
@@ -1264,6 +1300,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
 
platform_set_drvdata(dev, i2c);
 
+   if (i2c->disable_after_xfer)
+   i2c_pxa_enable(i2c, false);
+
 #ifdef CONFIG_I2C_PXA_SLAVE
dev_info(>adap.dev, " PXA I2C adapter, slave address %d\n",
i2c->slave_addr);
-- 
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-v5 RESEND 4/5] Documentation: binding: add sclk adjustment properties to i2c-pxa

[Vaibhav Hiremath]

With addition of PXA910 family of devices, the TWSI module supports
new feature which allows us to adjust SCLK. i2c-pxa driver takes input
configuration in nsec and converts it to respective bit-fields,

 - i2c-sclk-low-time-ns : SCLK low time (tlow)
   This property is used along with mode selection.
 - i2c-sclk-high-time-ns : SCLK high time (thigh)
 - i2c-start-hold-time-ns : Used in case of high speed mode for start bit
   hold/setup wait counter.
 - i2c-stop-hold-time-ns : Used in case of high speed mode for stop bit
   hold/setup wait counter.
 - i2c-sda-hold-time-ns : Used to calculate hold/setup wait counter for
   standard and fast mode.

Signed-off-by: Vaibhav Hiremath 
---
 Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 13 +
 1 file changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt 
b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 9657db5..bb4df60 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -23,12 +23,25 @@ Optional properties :
  - i2c-disable-after-xfer : If set, driver will disable I2C module
after msg xfer and enable it again before xfer.
 
+   (Applicable to PXA910 family):
+
+ - i2c-sclk-low-time-ns : SCLK low time (tlow), for standard/fast/high
+   speed mode.
+   This property is used along with mode selection. Driver uses this property
+   to set low/high time for standard and fast speed mode, as HW counter
+   bit-field is same for both.
+ - i2c-sclk-high-time-ns : SCLK high time (thigh), Used in case of high speed
+   mode only.
+
 Examples:
twsi1: i2c@d4011000 {
compatible = "mrvl,mmp-twsi";
reg = <0xd4011000 0x1000>;
interrupts = <7>;
mrvl,i2c-fast-mode;
+
+   i2c-sclk-low-time-ns = <988>;
+   i2c-sclk-high-time-ns = <988>;
};

twsi2: i2c@d4025000 {
-- 
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-v5 RESEND 5/5] i2c: pxa: Add ILCR (tLow & tHigh) configuration support

[Vaibhav Hiremath]

With addition of PXA910 family of devices, the TWSI module supports
SCL clock adjustment using ILCR register.

This patch enables the control and configuration of ICLR through DT
properties,

i2c-sclk-high-time-ns:
  SCLK high time (tHigh), for standard/fast/high speed mode
i2c-sclk-low-time-ns:
  SCLK low time (tLow), for standard/fast/high speed mode

Note that in case of standard and fast mod, the tLow and tHigh counters
are same, and software will use tLow value.

Also, brought up devm_clk_get() fn above i2c_pxa_probe_dt(), as it
uses clk rate for timing calculations.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Jett.Zhou 
Signed-off-by: Yi Zhang 
Tested-by: Robert Jarzmik 
---
 drivers/i2c/busses/i2c-pxa.c | 69 
 1 file changed, 63 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 8d76197..6012ae5 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -195,6 +195,9 @@ struct pxa_i2c {
unsigned long   rate;
boolhighmode_enter;
booldisable_after_xfer;
+
+   unsigned intsclk_thigh_load_cnt;
+   unsigned intsclk_tlow_load_cnt;
 };
 
 #define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -507,6 +510,36 @@ static void i2c_pxa_set_slave(struct pxa_i2c *i2c, int 
errcode)
 #define i2c_pxa_set_slave(i2c, err)do { } while (0)
 #endif
 
+static void i2c_pxa_do_sclk_adj(struct pxa_i2c *i2c)
+{
+   unsigned int reg_ilcr;
+
+   if (!i2c->reg_ilcr)
+   return;
+
+   reg_ilcr = readl(_ILCR(i2c));
+
+   /* For standard/fast mode tlow and thigh counters are same */
+   if (i2c->sclk_tlow_load_cnt) {
+   unsigned int mask, shift;
+
+   mask = i2c->high_mode ? ILCR_HLVL_MASK :
+   i2c->fast_mode ? ILCR_FLV_MASK : ILCR_SLV_MASK;
+   shift = i2c->high_mode ? ILCR_HLVL_SHIFT :
+   i2c->fast_mode ? ILCR_FLV_SHIFT : ILCR_SLV_SHIFT;
+
+   reg_ilcr &= ~mask;
+   reg_ilcr |= i2c->sclk_tlow_load_cnt << shift;
+   }
+
+   if (i2c->high_mode && i2c->sclk_thigh_load_cnt) {
+   reg_ilcr &= ~ILCR_HLVH_MASK;
+   reg_ilcr |= i2c->sclk_thigh_load_cnt << ILCR_HLVH_SHIFT;
+   }
+
+   writel(reg_ilcr, _ILCR(i2c));
+}
+
 static void i2c_pxa_reset(struct pxa_i2c *i2c)
 {
pr_debug("Resetting I2C Controller Unit\n");
@@ -526,6 +559,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
 
+   i2c_pxa_do_sclk_adj(i2c);
+
 #ifdef CONFIG_I2C_PXA_SLAVE
dev_info(>adap.dev, "Enabling slave mode\n");
writel(readl(_ICR(i2c)) | ICR_SADIE | ICR_ALDIE | ICR_SSDIE, _ICR(i2c));
@@ -1198,6 +1233,26 @@ static int i2c_pxa_probe_dt(struct platform_device 
*pdev, struct pxa_i2c *i2c,
 
*i2c_types = (enum pxa_i2c_types)(of_id->data);
 
+   /* optional properties */
+   if (of_device_is_compatible(np, "mrvl,mmp-twsi")) {
+   unsigned int tlow = 0, thigh = 0;
+   unsigned int clk_ns;
+
+   /* clock time in nsec */
+   clk_ns = 100 / (i2c->rate / 1000);
+
+   of_property_read_u32(np, "i2c-sclk-high-time-ns", );
+   i2c->sclk_thigh_load_cnt = thigh / clk_ns;
+
+   of_property_read_u32(np, "i2c-sclk-low-time-ns", );
+   i2c->sclk_tlow_load_cnt = tlow / clk_ns;
+
+   /* For std/fast mode tlow & thigh have same bit-fields */
+   if (!i2c->high_mode &&
+   (i2c->sclk_tlow_load_cnt != i2c->sclk_thigh_load_cnt))
+   dev_warn(>adap.dev,
+   "mismatch of tLow & tHigh values, using 
tLow\n");
+   }
return 0;
 }
 
@@ -1248,6 +1303,14 @@ static int i2c_pxa_probe(struct platform_device *dev)
return irq;
}
 
+   i2c->clk = devm_clk_get(>dev, NULL);
+   if (IS_ERR(i2c->clk)) {
+   dev_err(>dev, "failed to get the clk: %ld\n", 
PTR_ERR(i2c->clk));
+   return PTR_ERR(i2c->clk);
+   }
+
+   i2c->rate = clk_get_rate(i2c->clk);
+
/* Default adapter num to device id; i2c_pxa_probe_dt can override. */
i2c->adap.nr = dev->id;
 
@@ -1265,12 +1328,6 @@ static int i2c_pxa_probe(struct platform_device *dev)
 
strlcpy(i2c->adap.name, "pxa_i2c-i2c", sizeof(i2c->adap.name));
 
-   i2c->clk = devm_clk_get(>dev, NULL);
-   if (IS_ERR(i2c->clk)) {
-   dev_err(>dev, "failed to get the clk: %ld\n", 
PTR_ERR(i2c->clk));
-   return PTR_ERR(i2c->clk);
-   }
-
i2c->reg_ibmr = i2c->reg_base + pxa_reg_layout[i2c_type].ibmr;
i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
 

[PATCH-v5 RESEND 3/5] i2c: pxa: Add support for pxa910/988 & new configuration features

[Vaibhav Hiremath]

TWSI_ILCR & TWSI_IWCR registers are used to adjust clock rate
of standard & fast mode in pxa910/988; so this patch adds these two new
entries to "struct pxa_reg_layout" and "struct pxa_i2c".

As discussed in the previous patch-series, the idea here is to add standard
DT properties for ilcr and iwcr configuration fields.
In case of Master ilcr is used for low/high time and in case of slave mode
of operation iwcr is used for setup/hold time.

Signed-off-by: Jett.Zhou 
Signed-off-by: Yi Zhang 
Signed-off-by: Vaibhav Hiremath 
Tested-by: Robert Jarzmik 
---
 drivers/i2c/busses/i2c-pxa.c | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index abf04f2..8d76197 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -46,12 +46,15 @@ struct pxa_reg_layout {
u32 icr;
u32 isr;
u32 isar;
+   u32 ilcr;
+   u32 iwcr;
 };
 
 enum pxa_i2c_types {
REGS_PXA2XX,
REGS_PXA3XX,
REGS_CE4100,
+   REGS_PXA910,
 };
 
 /*
@@ -79,12 +82,22 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.isr =  0x04,
/* no isar register */
},
+   [REGS_PXA910] = {
+   .ibmr = 0x00,
+   .idbr = 0x08,
+   .icr =  0x10,
+   .isr =  0x18,
+   .isar = 0x20,
+   .ilcr = 0x28,
+   .iwcr = 0x30,
+   },
 };
 
 static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa2xx-i2c", REGS_PXA2XX },
{ "pxa3xx-pwri2c",  REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
+   { "pxa910-i2c", REGS_PXA910 },
{ },
 };
 MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -124,6 +137,24 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
 #define ISR_SAD(1 << 9)   /* slave address detected */
 #define ISR_BED(1 << 10)  /* bus error no ACK/NAK */
 
+/* bit field shift & mask */
+#define ILCR_SLV_SHIFT 0
+#define ILCR_SLV_MASK  (0x1FF << ILCR_SLV_SHIFT)
+#define ILCR_FLV_SHIFT 9
+#define ILCR_FLV_MASK  (0x1FF << ILCR_FLV_SHIFT)
+#define ILCR_HLVL_SHIFT18
+#define ILCR_HLVL_MASK (0x1FF << ILCR_HLVL_SHIFT)
+#define ILCR_HLVH_SHIFT27
+#define ILCR_HLVH_MASK (0x1F << ILCR_HLVH_SHIFT)
+
+#define IWCR_CNT_SHIFT 0
+#define IWCR_CNT_MASK  (0x1F << IWCR_CNT_SHIFT)
+#define IWCR_HS_CNT1_SHIFT 5
+#define IWCR_HS_CNT1_MASK  (0x1F << IWCR_HS_CNT1_SHIFT)
+#define IWCR_HS_CNT2_SHIFT 10
+#define IWCR_HS_CNT2_MASK  (0x1F << IWCR_HS_CNT2_SHIFT)
+
+
 struct pxa_i2c {
spinlock_t  lock;
wait_queue_head_t   wait;
@@ -150,6 +181,8 @@ struct pxa_i2c {
void __iomem*reg_icr;
void __iomem*reg_isr;
void __iomem*reg_isar;
+   void __iomem*reg_ilcr;
+   void __iomem*reg_iwcr;
 
unsigned long   iobase;
unsigned long   iosize;
@@ -169,6 +202,8 @@ struct pxa_i2c {
 #define _ICR(i2c)  ((i2c)->reg_icr)
 #define _ISR(i2c)  ((i2c)->reg_isr)
 #define _ISAR(i2c) ((i2c)->reg_isar)
+#define _ILCR(i2c) ((i2c)->reg_ilcr)
+#define _IWCR(i2c) ((i2c)->reg_iwcr)
 
 /*
  * I2C Slave mode address
@@ -1135,7 +1170,7 @@ static const struct i2c_algorithm i2c_pxa_pio_algorithm = 
{
 static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
-   { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA2XX },
+   { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
{}
 };
 MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1243,6 +1278,11 @@ static int i2c_pxa_probe(struct platform_device *dev)
if (i2c_type != REGS_CE4100)
i2c->reg_isar = i2c->reg_base + pxa_reg_layout[i2c_type].isar;
 
+   if (i2c_type == REGS_PXA910) {
+   i2c->reg_ilcr = i2c->reg_base + pxa_reg_layout[i2c_type].ilcr;
+   i2c->reg_iwcr = i2c->reg_base + pxa_reg_layout[i2c_type].iwcr;
+   }
+
i2c->iobase = res->start;
i2c->iosize = resource_size(res);
 
-- 
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 3/8][v3]usb:fsl:otg: Add support to add/remove usb host driver

[Ramneek Mehresh]

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Thursday, August 20, 2015 7:40 PM
> To: Mehresh Ramneek-B31383 
> Cc: linux-kernel@vger.kernel.org; ba...@ti.com;
> gre...@linuxfoundation.org; linux-...@vger.kernel.org; Li Yang-Leo-R58472
> 
> Subject: RE: [PATCH 3/8][v3]usb:fsl:otg: Add support to add/remove usb
> host driver
> 
> On Thu, 20 Aug 2015, Ramneek Mehresh wrote:
> 
> > > > --- a/drivers/usb/host/ehci-fsl.h
> > > > +++ b/drivers/usb/host/ehci-fsl.h
> > > > @@ -63,4 +63,22 @@
> > > >  #define UTMI_PHY_EN (1<<9)
> > > >  #define ULPI_PHY_CLK_SEL(1<<10)
> > > >  #define PHY_CLK_VALID  (1<<17)
> > > > +
> > > > +struct ehci_fsl {
> > > > +#ifdef CONFIG_PM
> > > > +   /* Saved USB PHY settings, need to restore after deep sleep. */
> > > > +   u32 usb_ctrl;
> > > > +#endif
> > >
> > > Do you need this #ifdef?
> > >
> > Yes, this is required for deep-sleep support...we need to save/restore
> controller
> > registers during deep-sleep when usb controller power is shut-off. Don't
> need this
> > during normal usb operation...saving/restoring usb controller registers in
> non deep-sleep
> > scenario will add unnecessary delays
> 
> What I meant was, can you keep the "u32 usb_ctrl;" line but get rid of
> the "#ifdef CONFIG_PM" and "#endif" lines?
> 
> Alan Stern
I do understand that. However, USB suspend/resume functionality work in context 
of
PM. Only in this context, we need to save/restore usb controller register
for deep-sleep functionality. If you see usage of this in ehci-fsl.c file, it's 
used in 
ehci_fsl_drv_suspend() under CONFIG_PM to save USB CNTL register.
If I remove CONFIG_PM from struct ehci_fsl{}, I'll need to change the entire 
driver
also to make suspend and resume functionalities compile by default.
   
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/18] ARM: sunxi: use const and __initconst for smp_operations

[Maxime Ripard]

On Mon, Aug 24, 2015 at 01:36:14PM +0900, Masahiro Yamada wrote:
> The smp_operations structure is not over-written, so add const
> qualifier and replace __initdata with __initconst.
> 
> Also, add static to sun8i_smp_ops.
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Maxime Ripard 

Thanks!
Maxime

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


signature.asc
Description: Digital signature

Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes

[Dave Chinner]

On Mon, Aug 24, 2015 at 11:18:16AM +0800, Eryu Guan wrote:
> On Mon, Aug 24, 2015 at 11:11:23AM +1000, Dave Chinner wrote:
> > 
> > Eryu, can you change the way you run the event trace to be:
> > 
> > $ sudo trace-cmd  -o  ./check 
> > 
> > rather than running the trace as a background operation elsewhere?
> > Maybe that will give better results.
> 
> The results are here
> 
> http://128.199.137.77/writeback-v3/

OK, the trace is still missing a few events, but it's much more
complete, and contains the events that tell more of the story:

$ ls -li /mnt/scr
total 51196
15688955 -rw--- 1 root root 10481664 Aug 24 13:06 985
15688959 -rw--- 1 root root0 Aug 24 13:06 989
15688961 -rw--- 1 root root0 Aug 24 13:06 991
15688964 -rw--- 1 root root0 Aug 24 13:06 994
15688966 -rw--- 1 root root0 Aug 24 13:06 996
$


 Inode #  Sizeblock count  flushiter
   dec  hex   inode loginode   log  inode  log
15688955  0xef64fb  0x9ff000  0x9ff000 0x9ff  0xa00  1  0
15688959  0xef64ff  00 0xa00  0xa00  0  0
15688961  0xef6501  00 0xa00  0xa00  0  0
15688964  0xef6504  00 0xa00  0xa00  0  0
15688966  0xef6506  00 0xa00  0xa00  0  0


Ok, that tallies with the previous symptoms. However, the trace
tells us something different. the xfs_setfilesize events. here's the
last 12 xfs_setfilesize events delivered in the trace (trimmed for
brevity and focus):

ino 0xef64fa isize 0xa0 disize 0x0 offset 0x0 count 10481664
ino 0xef64fa isize 0xa0 disize 0x9ff000 offset 0x9ff000 count 409
ino 0xef64fb isize 0xa0 disize 0x0 offset 0x0 count 10481664
ino 0xef64fb isize 0xa0 disize 0x9ff000 offset 0x9ff000 count 4096
ino 0xef64ff isize 0xa0 disize 0x0 offset 0x0 count 10481664
ino 0xef64ff isize 0xa0 disize 0x9ff000 offset 0x9ff000 count 4096
ino 0xef6501 isize 0xa0 disize 0x0 offset 0x0 count 10481664
ino 0xef6501 isize 0xa0 disize 0x9ff000 offset 0x9ff000 count 4096
ino 0xef6504 isize 0xa0 disize 0x0 offset 0x0 count 10481664
ino 0xef6504 isize 0xa0 disize 0x9ff000 offset 0x9ff000 count 4096
ino 0xef6506 isize 0xa0 disize 0x0 offset 0x0 count 10481664
ino 0xef6506 isize 0xa0 disize 0x9ff000 offset 0x9ff000 count 4096

Yeah, the last 9 transactions corresponding to these events are not
in the log.  Which means, most likely, that they occurred after
->sync_fs forced the log out. THe next thing that happens is the fs
is shut down, and that's preventing the dirty log from being written
to disk.

Eryu, this can be confirmed by add the xfs_log_force event to the
trace.

What I can't see in the traces is where sync is doing a blocking
sync pass on the fileystem. The wbc control structure being passed
to XFS is:

wbc_writepage:bdi 253:0: towrt=45569 skip=0 mode=0 kupd=0 bgrd=0 
reclm=0 cyclic=0 start=0x0 end=0x7fff

Which is not coming from sync_inodes_sb() as the sync mode is
incorrect (i.e. not WB_SYNC_ALL). It looks to me that writeback is
coming from a generic bdi flusher command rather than a directed
superblock sync. i.e. through wakeup_flusher_threads() which sets:

work->sync_mode = WB_SYNC_NONE;
work->nr_pages  = nr_pages;
work->range_cyclic = range_cyclic;
work->reason= reason;
work->auto_free = 1;

as the reason is "sync":

sync-18849  writeback_queue:  bdi 253:0: sb_dev 0:0 
nr_pages=308986 sync_mode=0 kupdate=0 range_cyclic=0 background=0 reason=sync
sync-18849  writeback_queue:  bdi 253:0: sb_dev 253:1 
nr_pages=9223372036854775807 sync_mode=1 kupdate=0 range_cyclic=0 background=0 
reason=sync

kworker/u8:1-1563   writeback_exec:   bdi 253:0: sb_dev 0:0 
nr_pages=308986 sync_mode=0 kupdate=0 range_cyclic=0 background=0 reason=sync
kworker/u8:1-1563   writeback_start:  bdi 253:0: sb_dev 0:0 
nr_pages=308986 sync_mode=0 kupdate=0 range_cyclic=0 background=0 reason=sync

The next writeback_queue/writeback_exec tracepoint pair are:


 kworker/2:1-17163  xfs_setfilesize:  dev 253:6 ino 0xef6506 isize 
0xa0 disize 0x0 offset 0x0 count 10481664
 kworker/2:1-17163  xfs_setfilesize:  dev 253:6 ino 0xef6506 isize 
0xa0 disize 0x9ff000 offset 0x9ff000 count 4096
sync-18849  wbc_writepage:bdi 253:0: 
towrt=9223372036854775798 skip=0 mode=1 kupd=0 bgrd=0 reclm=0 cyclic=0 
start=0x0 end=0x7fff
sync-18849  wbc_writepage:bdi 253:0: 
towrt=9223372036854775797 skip=0 mode=1 kupd=0 bgrd=0 reclm=0 cyclic=0 
start=0x0 end=0x7fff
sync-18849  wbc_writepage:bdi 253:0: 
towrt=9223372036854775796 skip=0 mode=1 kupd=0 bgrd=0 reclm=0 cyclic=0 
start=0x0 end=0x7fff
sync-18849  wbc_writepage:bdi 253:0: 
towrt=9223372036854775795 skip=0 mode=1 kupd=0 bgrd=0 reclm=0 

[PATCH] Fix bug in iommu_context_addr: Always get pointer to lower extended-context-table

[Xiao, Nan (Nan@HPS Performance, Beijing)]

Hi David & joerg,

In iommu_context_addr() function, we always use lower extended-context-table
even though upper-half of the extended root-entry is present.

Signed-off-by: Nan Xiao 
---
 drivers/iommu/intel-iommu.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0649b94..4213598 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -759,10 +759,11 @@ static inline struct context_entry 
*iommu_context_addr(struct intel_iommu *iommu
if (devfn >= 0x80) {
devfn -= 0x80;
entry = >hi;
-   }
+   } else
+   entry = >lo;
devfn *= 2;
-   }
-   entry = >lo;
+   } else
+   entry = >lo;
if (*entry & 1)
context = phys_to_virt(*entry & VTD_PAGE_MASK);
else {
-- 
2.4.3

Best Regards
Nan Xiao

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] doc: dt: Add interrupt parent to Xilinx AXI DMA instantation example.

[Michal Simek]

On 08/21/2015 06:32 PM, Moritz Fischer wrote:
> This patch adds 'interrupt-parent' properties to the instantation example in
> the docs for the devicetree bindings of the Xilinx AXI DMA driver.
> 
> Signed-off-by: Moritz Fischer 
> ---
>  Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt 
> b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> index 2291c40..7c956e9 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> @@ -19,6 +19,7 @@ Required child node properties:
>  - compatible: It should be either "xlnx,axi-dma-mm2s-channel" or
>   "xlnx,axi-dma-s2mm-channel".
>  - interrupts: Should contain per channel DMA interrupts.
> +- interrupt-parent: Should contain interrupt parent.
>  - xlnx,datawidth: Should contain the stream data width, take values
>   {32,64...1024}.
>  
> @@ -36,11 +37,13 @@ axi_dma_0: axidma@4040 {
>   dma-channel@4040 {
>   compatible = "xlnx,axi-dma-mm2s-channel";
>   interrupts = < 0 59 4 >;
> + interrupt-parent = <>;
>   xlnx,datawidth = <0x40>;
>   } ;
>   dma-channel@40400030 {
>   compatible = "xlnx,axi-dma-s2mm-channel";
>   interrupts = < 0 58 4 >;
> + interrupt-parent = <>;
>   xlnx,datawidth = <0x40>;
>   } ;
>  } ;
> 

Acked-by: Michal Simek 

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-v6 0/6] mfd: 88pm800: Add Device tree support

[Vaibhav Hiremath]

On Tuesday 14 July 2015 12:27 AM, Vaibhav Hiremath wrote:



On Wednesday 08 July 2015 05:56 PM, Vaibhav Hiremath wrote:

This patch-series adds support for Device tree to 88PM800 mfd driver.
It also sets default configuration of irq clear method if board file
doesn't exist.

Testing::
  - Boot tested on PXA1928 based platform.
  - probe of mfd, rtc and regulator function passing successfully.
  - Basic read operations on registers
  - irq clear configuration

V5 => V6
===


I hope this will be queued for 4.2




Lee,

This patch-series is pending since long time, reviewed and acked.
Request to queue it up for next merge window.

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] sched/nohz: Affine unpinned timers to housekeepers

[Ingo Molnar]

* Paul E. McKenney  wrote:

> > here it's fully set - triggering the bug I'm worried about. So what am I 
> > missing, what prevents CONFIG_NO_HZ_FULL_ALL from crashing?
> 
> The boot CPU is excluded from tick_nohz_full_mask in tick_nohz_init(), which 
> is 
> called from tick_init() which is called from start_kernel() shortly after 
> rcu_init():
> 
>   cpu = smp_processor_id();
> 
>   if (cpumask_test_cpu(cpu, tick_nohz_full_mask)) {
>   pr_warning("NO_HZ: Clearing %d from nohz_full range for 
> timekeeping\n", cpu);
>   cpumask_clear_cpu(cpu, tick_nohz_full_mask);
>   }
> 
> This happens after the call to tick_nohz_init_all() that does the 
> cpumask_setall() that you called out above.

Ah, indeed - I somehow missed that.

This brings up two other questions:

1)

the 'housekeeping CPU' is essentially the boot CPU. Yet we dedicate a full mask 
to 
it (housekeeping_mask - a variable mask to begin with) and recover the 
housekeeping CPU via:

+   return cpumask_any_and(housekeeping_mask, cpu_online_mask);

which can be pretty expensive, and which gets executed in two hotpaths:

kernel/time/hrtimer.c:  return _cpu(hrtimer_bases, get_nohz_timer_target());
kernel/time/timer.c:return per_cpu_ptr(_bases, 
get_nohz_timer_target());

... why not just use a single housekeeping_cpu which would be way faster to 
pass 
down to the timer code?

2)

What happens if the boot CPU is offlined? (under 
CONFIG_BOOTPARAM_HOTPLUG_CPU0=y)

I don't see CPU hotplug callbacks fixing up the housekeeping_mask if the boot 
CPU 
is offlined.

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] x86/math-emu: Add support for FCMOVcc and F[U]COMI[P] insns

[Ingo Molnar]

* Denys Vlasenko  wrote:

> I propose the table to be commented like shown below:
> 
> /*Opcode: d8  d9da  db   dc  dd  de  df */
> /*c0..f*/ fadd__, fld_i_,   fcmovb, fcmovnb, fadd_i, ffree_, faddp_, _df_c0_,
> /*c8..f*/ fmul__, fxch_i,   fcmove, fcmovne, fmul_i, _dd_c8_,fmulp_, _df_c8_,
> /*d0..7*/ fcom_st,fp_nop,   fcmovbe,fcmovnbe,_dc_d0_,fst_i_, _de_d0_,_df_d0_,
> /*d8..f*/ fcompst,_d9_d8_,  fcmovu, fcmovnu, _dc_d8_,fstp_i, fcompp, _df_d8_,
> /*e0..7*/ fsub__, FPU_etc,  __BAD__,finit_,  fsubri, fucom_, fsubrp, fstsw_,
> /*e8..f*/ fsubr_, fconst,   fucompp,fucomi_, fsub_i, fucomp, fsubp_, fucomip,
> /*f0..7*/ fdiv__, FPU_triga,__BAD__,fcomi_,  fdivri, __BAD__,fdivrp, fcomip,
> /*f8..f*/ fdivr_, FPU_trigb,__BAD__,__BAD__, fdiv_i, __BAD__,fdivp_, __BAD__,

I agree with that, but please fix the vertical alignment (like my patch did), 
as 
the table is pretty hard to navigate in this form.

Also, the first patch in the series should remove the 'undocumented' #ifdef. 
That 
define was fully justified ~20 years ago but let's not complicate new code with 
it.

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 v2] x86/entry/32: Remove duplicate initialization of tss.ss1

[Ingo Molnar]

* Andy Lutomirski  wrote:

> On Sun, Aug 23, 2015 at 4:26 AM, Ingo Molnar  wrote:
> >
> > * Andy Lutomirski  wrote:
> >
> >> It's statically initialized, so we don't need to dynamically
> >> initialize it too.
> >>
> >> Reported-by: Brian Gerst 
> >> Signed-off-by: Andy Lutomirski 
> >> ---
> >>
> >> Changes since v1: Delete the code :)
> >>
> >> arch/x86/kernel/cpu/common.c | 8 
> >>  1 file changed, 8 deletions(-)
> >>
> >> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> >> index e2ed2513a51e..e08eee98a5f8 100644
> >> --- a/arch/x86/kernel/cpu/common.c
> >> +++ b/arch/x86/kernel/cpu/common.c
> >> @@ -1005,14 +1005,6 @@ void enable_sep_cpu(void)
> >>   if (IS_ENABLED(CONFIG_X86_32) && !boot_cpu_has(X86_FEATURE_SEP))
> >>   goto out;
> >>
> >> -#ifdef CONFIG_X86_32
> >> - /*
> >> -  * We cache MSR_IA32_SYSENTER_CS's value in the TSS's ss1 field --
> >> -  * see the big comment in struct x86_hw_tss's definition.
> >> -  */
> >> - tss->x86_tss.ss1 = __KERNEL_CS;
> >> -#endif
> >> -
> >>   wrmsrl_safe(MSR_IA32_SYSENTER_CS, __KERNEL_CS);
> >>   wrmsrl_safe(MSR_IA32_SYSENTER_ESP,
> >>   (unsigned long)tss +
> >
> > So this code changed substantially in tip:x86/asm - do we still need this 
> > patch?
> >
> 
> Yes, although I think it's actually the other way around -- I think
> this patch may have applied on top of something that never made it
> into tip/x86/asm.  I can re-check or I could just rebase the patch (or
> you could apply it with the obvious fixup).

Yeah, so I noticed that it fell amongst the cracks - please incorporate it into 
your next (v4.4 targeted) series once we get to that, so it doesn't get lost.

> It's obviously not a critical fix.

Yeah.

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] x86/math-emu: Add support for FCMOVcc and F[U]COMI[P] insns

[Ingo Molnar]

* Ingo Molnar  wrote:

> 
> * Denys Vlasenko  wrote:
> 
> > I propose the table to be commented like shown below:
> > 
> > /*Opcode: d8  d9da  db   dc  dd  de  df */
> > /*c0..f*/ fadd__, fld_i_,   fcmovb, fcmovnb, fadd_i, ffree_, faddp_, 
> > _df_c0_,
> > /*c8..f*/ fmul__, fxch_i,   fcmove, fcmovne, fmul_i, _dd_c8_,fmulp_, 
> > _df_c8_,
> > /*d0..7*/ fcom_st,fp_nop,   fcmovbe,fcmovnbe,_dc_d0_,fst_i_, 
> > _de_d0_,_df_d0_,
> > /*d8..f*/ fcompst,_d9_d8_,  fcmovu, fcmovnu, _dc_d8_,fstp_i, fcompp, 
> > _df_d8_,
> > /*e0..7*/ fsub__, FPU_etc,  __BAD__,finit_,  fsubri, fucom_, fsubrp, fstsw_,
> > /*e8..f*/ fsubr_, fconst,   fucompp,fucomi_, fsub_i, fucomp, fsubp_, 
> > fucomip,
> > /*f0..7*/ fdiv__, FPU_triga,__BAD__,fcomi_,  fdivri, __BAD__,fdivrp, fcomip,
> > /*f8..f*/ fdivr_, FPU_trigb,__BAD__,__BAD__, fdiv_i, __BAD__,fdivp_, 
> > __BAD__,
> 
> I agree with that, but please fix the vertical alignment (like my patch did), 
> as 
> the table is pretty hard to navigate in this form.

and by that I mean to split each line into two, to have groups of 4 
instructions 
and enough tabs between them.

> Also, the first patch in the series should remove the 'undocumented' #ifdef. 
> That define was fully justified ~20 years ago but let's not complicate new 
> code 
> with it.

The formerly undocumented opcodes could also grow real names.

All in nicely separate patches.

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: linux-next: build failure after merge of the slave-dma tree

[Maxime Ripard]

Hi Vinod,

On Thu, Aug 06, 2015 at 08:30:27AM +0530, Vinod Koul wrote:
> On Thu, Aug 06, 2015 at 12:22:03PM +1000, Stephen Rothwell wrote:
> > Hi Vinod,
> > 
> > After merging the slave-dma tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> > 
> > drivers/dma/at_hdmac.c: In function 'atc_prep_dma_memset':
> > drivers/dma/at_hdmac.c:960:6: error: 'struct at_desc' has no member named 
> > 'tx_width'
> >   desc->tx_width = 2;
> >   ^
> > 
> > Caused by commit
> > 
> >   25fed8c2fff1 ("dmaengine: hdmac: Add memset capabilities")
> > 
> > interacting with commit
> > 
> >   93dce3a6434f ("dmaengine: at_hdmac: fix residue computation")
> Thanks Stephen,
> 
> I am dropping this commit now, it need to be fixed to take into account
> Cyrille work on remove tx_width and this patch should be updated to reflect
> that

I'll send an updated version today, is there some time left for this
to be part of 4.3?

Thanks,
Maxime

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


signature.asc
Description: Digital signature

Re: [PATCH] of: add vendor prefix for Socionext Inc.

[Lee Jones]

On Wed, 29 Jul 2015, Masahiro Yamada wrote:

> Signed-off-by: Masahiro Yamada 
> ---
> 
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Patch has been around for nearly a month and is pretty trivial, so I'm
just going to go ahead an apply it.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3 v3] mm/vmalloc: Cache the vmalloc memory info

[Ingo Molnar]

* Rasmus Villemoes  wrote:

> On Sun, Aug 23 2015, Ingo Molnar  wrote:
> 
> > Ok, fair enough - so how about the attached approach instead, which
> > uses a 64-bit generation counter to track changes to the vmalloc
> > state.
> 
> How does this invalidation approach compare to the jiffies approach? In
> other words, how often does the vmalloc info actually change (or rather,
> in this approximation, how often is vmap_area_lock taken)? In
> particular, does it also solve the problem with git's test suite and
> similar situations with lots of short-lived processes?

The two approaches are pretty similar, and in a typical distro with typical 
workload vmalloc() is mostly a boot time affair.

But vmalloc() can be used more often in certain corner cases - neither of the 
patches makes that in any way slower, just the optimization won't trigger that 
often.

Since vmalloc() use is suboptimal for several reasons (it does not use large 
pages 
for kernel space allocations, etc.), this is all pretty OK IMHO.

> > ==>
> > From f9fd770e75e2edb4143f32ced0b53d7a77969c94 Mon Sep 17 00:00:00 2001
> > From: Ingo Molnar 
> > Date: Sat, 22 Aug 2015 12:28:01 +0200
> > Subject: [PATCH] mm/vmalloc: Cache the vmalloc memory info
> >
> > Linus reported that glibc (rather stupidly) reads /proc/meminfo
> > for every sysinfo() call,
> 
> Not quite: It is done by the two functions get_{av,}phys_pages
> functions; and get_phys_pages is called (once per process) by glibc's
> qsort implementation. In fact, sysinfo() is (at least part of) the cure,
> not the disease. Whether qsort should care about the total amount of
> memory is another discussion.
> 
> 

Thanks, is the fixed up changelog below better?

Ingo

===>

mm/vmalloc: Cache the vmalloc memory info

Linus reported that for scripting-intense workloads such as the
Git build, glibc's qsort will read /proc/meminfo for every process
created (by way of get_phys_pages()), which causes the Git build 
to generate a surprising amount of kernel overhead.

A fair chunk of the overhead is due to get_vmalloc_info() - which 
walks a potentially long list to do its statistics.

Modify Linus's jiffies based patch to use generation counters
to cache the vmalloc info: vmap_unlock() increases the generation
counter, and the get_vmalloc_info() reads it and compares it
against a cached generation counter.

Also use a seqlock to make sure we always print a consistent
set of vmalloc statistics.

Reported-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Rik van Riel 
Cc: linux...@kvack.org
Signed-off-by: Ingo Molnar 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] mfd: update Intel soc PMIC header file to support Broxton WC PMIC

[Lee Jones]

Why have you sent this set 3 times?

> IRQ control registers of Intel Broxton Whisky Cove PMIC are
> separated in two parts, so add secondary IRQ chip.
> And the new member of device will be used in PMC IPC regmap APIs.
> 
> Signed-off-by: Qipeng Zha 
> ---
>  include/linux/mfd/intel_soc_pmic.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/mfd/intel_soc_pmic.h 
> b/include/linux/mfd/intel_soc_pmic.h
> index abcbfcf..a730f14 100644
> --- a/include/linux/mfd/intel_soc_pmic.h
> +++ b/include/linux/mfd/intel_soc_pmic.h
> @@ -21,10 +21,15 @@
>  
>  #include 
>  
> +#define INIT_REGMAP_IRQ(_irq, _off, _mask)   \
> + [_irq] = { .reg_offset = (_off), .mask = (_mask) }
> +
>  struct intel_soc_pmic {
>   int irq;
>   struct regmap *regmap;
>   struct regmap_irq_chip_data *irq_chip_data;
> + struct regmap_irq_chip_data *irq_chip_data_level2;
> + struct device *dev;
>  };
>  
>  #endif   /* __INTEL_SOC_PMIC_H__ */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3 v3] mm/vmalloc: Cache the vmalloc memory info

[Ingo Molnar]

* Rasmus Villemoes  wrote:

> I was curious why these fields were ever added to /proc/meminfo, and dug
> up this:
> 
> commit d262ee3ee6ba4f5f6125571d93d9d63191d2ef76
> Author: Andrew Morton 
> Date:   Sat Apr 12 12:59:04 2003 -0700
> 
> [PATCH] vmalloc stats in /proc/meminfo
> 
> From: Matt Porter 
> 
> There was a thread a while back on lkml where Dave Hansen proposed this
> simple vmalloc usage reporting patch.  The thread pretty much died out as
> most people seemed focused on what VM loading type bugs it could solve.  I
> had posted that this type of information was really valuable in debugging
> embedded Linux board ports.  A common example is where people do arch
> specific setup that limits there vmalloc space and then they find modules
> won't load.  ;) Having the Vmalloc* info readily available is real useful 
> in
> helping folks to fix their kernel ports.
> 
> That thread is at .
> 
> [Maybe one could just remove the fields and see if anybody actually
> notices/cares any longer. Or, if they are only used by kernel
> developers, put them in their own file.]

So instead of removing the fields (which I'm quite sure is an ABI breaker as it 
could break less robust /proc/meminfo parsers and scripts), we could just 
report 
'0' all the time - and have the real info somewhere else?

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-v3] mfd: 88pm80x: Add 88pm860 chip type support

[Vaibhav Hiremath]

On Monday 20 July 2015 05:22 PM, Vaibhav Hiremath wrote:

Add chip identification support for 88PM860 device
to the pm80x_chip_mapping table.

Signed-off-by: Vaibhav Hiremath 
Reviewed-by: Krzysztof Kozlowski 
---
  drivers/mfd/88pm80x.c   | 2 ++
  include/linux/mfd/88pm80x.h | 1 +
  2 files changed, 3 insertions(+)



Mark,

Last update/understanding which I have on this patch is,

Lee is OK with taking this patch from regulator tree.
Lee please let me know if you think otherwise.

With this patch in, the build dependency will go away.

Request to pick this patch into your topic/88pm800 branch and run build
test.

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

Re: [PATCH V8 10/25] perf tools: Add example call-graph script

[Adrian Hunter]

On 21/08/15 18:28, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 21, 2015 at 12:21:25PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Aug 21, 2015 at 12:11:33PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> [acme@zoo ~]$ perf script -s 
>>> ~/libexec/perf-core/scripts/python/export-to-postgresql.py bts_example 
>>> branches calls
>>> 2015-08-21 12:10:00.504126 Creating database...
>>> QSqlDatabase: QPSQL driver not loaded
>>> QSqlDatabase: available drivers: QSQLITE
>>> QSqlDatabase: an instance of QCoreApplication is required for loading 
>>> driver plugins
>>> QSqlQuery::exec: database not open
>>> Traceback (most recent call last):
>>>   File 
>>> "/home/acme/libexec/perf-core/scripts/python/export-to-postgresql.py", line 
>>> 87, in 
>>> do_query(query, 'CREATE DATABASE ' + dbname)
>>>   File 
>>> "/home/acme/libexec/perf-core/scripts/python/export-to-postgresql.py", line 
>>> 78, in do_query
>>> raise Exception("Query failed: " + q.lastError().text())
>>> Exception: Query failed: Driver not loaded Driver not loaded
>>> Error running python script 
>>> /home/acme/libexec/perf-core/scripts/python/export-to-postgresql.py
>>> [acme@zoo ~]$ 
>>
>> A-ha, this was missing:
>>
>> [root@zoo ~]# rpm -ql qt-postgresql 
>> /usr/lib64/qt4/plugins/sqldrivers/libqsqlpsql.so
>> [root@zoo ~]#
>>
>> [acme@zoo ~]$ perf script -s 
>> ~/libexec/perf-core/scripts/python/export-to-postgresql.py bts_example 
>> branches calls
>> 2015-08-21 12:20:01.841677 Creating database...
>> 2015-08-21 12:20:02.556853 Writing to intermediate files...
>> 2015-08-21 12:20:03.262814 Copying to database...
>> 2015-08-21 12:20:03.783109 Removing intermediate files...
>> 2015-08-21 12:20:03.790282 Adding primary keys
>> 2015-08-21 12:20:04.294342 Adding foreign keys
>> 2015-08-21 12:20:04.718238 Done
>> [acme@zoo ~]$ 
>>
>> Now to the next steps... Lets see how this looks like with BTS...
> 
> So, after running:
> 
>   [acme@zoo linux]$ python
>   tools/perf/scripts/python/call-graph-from-postgresql.py bts_example
> 
> I got a GUI and after expanding some callchains I took this screenshot:
> 
>   http://vger.kernel.org/~acme/perf/call_graph_example_intel_bts.png
> 
> Cool stuff! But it seems the COMM got messed up? I.e. that "1380:1380"
> first level after "ls".

That is, in fact, correct.  The top-level is the process (comm).  The next
level is the threads (pid/tid) for that process.  Currently, each thread is
reported separately.

For the future, there ought to be an option to combine the data for all
threads of a process, or all processes with the same comm.  Also presently
it is not tracking if a thread sets it's own comm (e.g. some multi-threaded
applications name each thread).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/SDIO: enable SDIO device to suspend/resume asynchronously

[Fu, Zhonghui]

On 2015/8/17 14:48, Adrian Hunter wrote:
> On 17/08/15 06:26, Fu, Zhonghui wrote:
>> Hi,
>>
>> Any comments are welcome.
>>
>>
>> Thanks,
>> Zhonghui
>>
>> On 2015/7/30 15:40, Fu, Zhonghui wrote:
>>> Enable SDIO card and function device to suspend/resume asynchronously.
>>> This can improve system suspend/resume speed.
> For me, it needs more explanation.
>
> For example, why is this worth doing?  Can you give an example where it does
> significantly improve suspend/resume speed?  Are there any cases where it
> could be worse?
>
> Why is it safe?  Presumably it is safe if there are no dependencies on the
> device outside the device hierarchy. Is that so?  Are there any other
> potential pitfalls to enabling async_suspend?

Now, PM core support asynchronous device suspend/resume mode. If one device has 
been set to support asynchronous PM mode, it's suspend/resume operation can be 
performed in a separate kernel thread and take advantage of multicore feature 
to improve overall system suspend/resume speed. The worst case is that all 
device suspend/resume threads will be scheduled to the same CPU, it hardly 
occur.

PM core ensure all the suspend/resume dependency related to one device. 
Actually, async suspend/resume mode is one feature of PM core, every device 
subsystem may use it or not use it. Once one device subsystem choose to use 
this feature, its safety is up to PM core as long as device subsystem has 
initialized fully this device.


Thanks,
Zhonghui  
>
>>> Signed-off-by: Zhonghui Fu 
>>> ---
>>>  drivers/mmc/core/sdio.c |4 
>>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
>>> index b91abed..6719b77 100644
>>> --- a/drivers/mmc/core/sdio.c
>>> +++ b/drivers/mmc/core/sdio.c
>>> @@ -1106,6 +1106,8 @@ int mmc_attach_sdio(struct mmc_host *host)
>>> pm_runtime_enable(>dev);
>>> }
>>>  
>>> +   device_enable_async_suspend(>dev);
>>> +
>>> /*
>>>  * The number of functions on the card is encoded inside
>>>  * the ocr.
>>> @@ -1126,6 +1128,8 @@ int mmc_attach_sdio(struct mmc_host *host)
>>>  */
>>> if (host->caps & MMC_CAP_POWER_OFF_CARD)
>>> pm_runtime_enable(>sdio_func[i]->dev);
>>> +
>>> +   device_enable_async_suspend(>sdio_func[i]->dev);
>>> }
>>>  
>>> /*
>>> -- 1.7.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/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ubifs: Allow O_DIRECT

[Artem Bityutskiy]

On Thu, 2015-08-20 at 13:49 -0700, Brian Norris wrote:
> Pardon the innocent bystander's comment, but:
> 
> On Thu, Aug 20, 2015 at 01:40:02PM +0200, Richard Weinberger wrote:
> > Am 20.08.2015 um 13:31 schrieb Artem Bityutskiy:
> > > On Thu, 2015-08-20 at 11:00 +0800, Dongsheng Yang wrote:
> > > > On 08/20/2015 04:35 AM, Richard Weinberger wrote:
> > > > > Currently UBIFS does not support direct IO, but some
> > > > > applications
> > > > > blindly use the O_DIRECT flag.
> > > > > Instead of failing upon open() we can do better and fall back
> > > > > to buffered IO.
> > > > 
> > > > H, to be honest, I am not sure we have to do it as Dave
> > > > suggested. I think that's just a work-around for current
> > > > fstests.
> > > > 
> > > > IMHO, perform a buffered IO when user request direct IO without
> > > > any warning sounds not a good idea. Maybe adding a warning
> > > > would
> > > > make it better.
> > > > 
> > > > I think we need more discussion about AIO in ubifs, and
> > > > actually
> > > > I have a plan for it. But I have not listed the all cons and
> > > > pros of
> > > > it so far.
> > > > 
> > > > Artem, what's your opinion?
> > > 
> > > Yes, this is my worry too.
> > > 
> > > Basically, we need to see what is the "common practice" here, and
> > > follow it. This requires a small research. What would be the most
> > > popular Linux FS which does not support direct I/O? Can we check
> > > what
> > > it does?
> > 
> > All popular filesystems seem to support direct IO.
> > That's the problem, application do not expect O_DIRECT to fail.
> 
> Why can't we just suggest fixing the applications? The man pages for
> O_DIRECT clearly document the EINVAL return code:
> 
>   EINVAL The filesystem does not support the O_DIRECT flag. See NOTES
>   for more information.
> 
> and under NOTES:
> 
>   O_DIRECT  support  was added under Linux in kernel version 2.4.10.
>   Older Linux kernels simply ignore this flag.  Some filesystems may
> not
>   implement the flag and open() will fail with EINVAL if it is used.

That's an option.

When writing the code, we were defensive and preferred to error out for
everything we do not support. This is generally a good SW engineering
practice.

Now, some user-space fails when direct I/O is not supported. We can
chose to fake direct I/O or fix user-space. The latter seems to be the
preferred course of actions, and you are correctly pointing the man
page.

However, if

1. we are the only FS erroring out on O_DIRECT
2. other file-systems not supporting direct IO just fake it

we may just follow the crowd and fake it too.

I am kind of trusting Richard here - I assume he did the research and
the above is the case, this is why I am fine with his patch.

Does this logic seem acceptable to you? Other folk's opinion would be
great to hear.

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

Re: [PATCH 0/7] Exynos4412-based Trats2 USB gadget (DWC2) fixes

[Krzysztof Kozlowski]

On 21.08.2015 21:38, Marek Szyprowski wrote:
> Dear All,
> 
> Since v3.19 s3c-hsotg (DWC2) USB controller stopped working on
> Exynos4412-based Trats2 platform. However on Odroid-U3 (which is also
> Exynos4412-based) it worked fine all the time. After long investigation
> it turned out that this was caused by 2 independent issues.
> 
> First issue was caused by patch 7eec1266751bd3a25e35ce88686634c768fedc24
> ("ARM: dts: Add Maxim 77693 PMIC to exynos4412-trats2") added support
> for Maxim 77693 regulators, but without defining consumers for them.
> This causes regulator core to disable them. However SAFEOUT1 regulator
> provides power supply to VBUS signal, which also power some USB phy
> related parts of Exynos SoC core. This has been fixed by patches 1-3,
> which adds support for VBUS regulator, defines them in DTS for all
> Exynos platforms and changes probe sequence of the drivers to ensure no
> deferred probe occurs (USB gadget subsystem doesn't support deferred
> probe yet).
> 
> Second issue is related to DWC2 driver rewrite and host/gadget/dual-role
> integration code. DWC2 module on some platforms needs three additional
> hardware resources: phy, clock and power supply. All of them must be
> enabled/activated to properly initialize and operate. This was initially
> handled in s3c-hsotg driver, which has been converted to 'gadget' part
> of dwc2 driver. Unfortunately, not all of this code got moved to common
> platform code, what resulted in accessing DWC2 registers without
> enabling power supply regulators and clock. This caused initialization
> failure on Exynos4412-based Trats2. Odroid U3 board worked fine, because
> power supplies used by DWC2 module are marked there as 'always-on',
> because they are also used by other modules (USB hub) and clock was
> shared with USB2 PHY, so it was already enabled. This initialization
> issue has been fixed by the last patch. While preparing it I've also
> fixed a few minor issues found in nearby code (patches 4-6).
> 
> I would like to get those patches merged separately to respective
> subsystem trees:
> patch 1: phy subsystem tree
> patch 2: Samsung Exynos tree
> patch 3: regulator subsystem tree
> patch 4-7: USB gadget subsystem tree
> 
> Patches have been prepared on top of linux-next from 20150821.

Entire patchset tested on Trats2 board:
Tested-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH 07/18] ARM: EXYNOS: use const and __initconst for smp_operations

[Krzysztof Kozlowski]

On 24.08.2015 13:36, Masahiro Yamada wrote:
> The smp_operations structure is not over-written, so add const
> qualifier and replace __initdata with __initconst.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/arm/mach-exynos/common.h  | 2 +-
>  arch/arm/mach-exynos/platsmp.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH v2] rtc: s5m: fix to update ctrl register

[Alexandre Belloni]

On 21/08/2015 at 18:43:41 +0900, Joonyoung Shim wrote :
> According to datasheet, the S2MPS13X and S2MPS14X should update write
> buffer via setting WUDR bit to high after ctrl register is written.
> 
> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
> tools/testing/selftests/timers/rtctest.c test program and hour format is
> used to 12 hour mode in Odroid-XU3 board.
> 
> One more issue is the RTC doesn't keep time on Odroid-XU3 board when i
> turn on board after power off even if RTC battery is connected. It can
> be solved as setting WUDR & RUDR bits to high at the same time after
> RTC_CTRL register is written. It's same with condition of only writing
> ALARM registers, so this is for only S2MPS14 and we should set WUDR &
> A_UDR bits to high on S2MPS13.
> 
> I can't find any reasonable description about this like fix from
> datasheet, but can find similar codes from rtc driver source of
> hardkernel kernel and vender kernel.
> 
> Signed-off-by: Joonyoung Shim 
> Cc:  # v3.16
> ---
> Changelog for v2:
> - update commit description and code to fix time keeping problem
> - update the stable tag with the kernel version
> 
>  drivers/rtc/rtc-s5m.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
Applied, thanks. I fixed the small typo.

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

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

[Artem Bityutskiy]

On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote:
> On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote:
> > > Basically, we need to see what is the "common practice" here, and
> > > follow it. This requires a small research. What would be the most
> > > popular Linux FS which does not support direct I/O? Can we check 
> > > what
> > > it does?
> > 
> > All popular filesystems seem to support direct IO.
> > That's the problem, application do not expect O_DIRECT to fail.
> > 
> > My intention was to do it like exofs:
> 
> Fair enough, thanks!
> 
> Signed-off-by: Artem Bityutskiy 

Richard, you mention this was suggested by Dave, could you please pint
to the discussion, if possible?

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

Re: [PATCH 13/18] iio: adc: mcp320x: Set struct spi_driver .of_match_table

[Javier Martinez Canillas]

Hello Rob and Jonathan,

On 08/24/2015 12:10 AM, Rob Herring wrote:
> On Sat, Aug 22, 2015 at 12:48 PM, Jonathan Cameron  wrote:
>> On 20/08/15 23:48, Javier Martinez Canillas wrote:
>>> Hello Michael,
>>>
>>> On 08/21/2015 12:29 AM, Michael Welling wrote:
 On Fri, Aug 21, 2015 at 12:02:40AM +0200, Javier Martinez Canillas wrote:
> Hello Michael,
>
> On 08/20/2015 10:09 PM, Michael Welling wrote:
>> On Thu, Aug 20, 2015 at 09:07:26AM +0200, Javier Martinez Canillas wrote:
>>> The driver has an OF id table but the .of_match_table is not set so
>>> the SPI core can't do an OF style match and the table was unused.
>>>
>>
>> Is an OF style match necessary?
>>
>
> Did you read the cover letter [0] on which I explain why is needed to
> avoid breaking module autoloading in the future? Once the SPI core is
> changed by RFC patch 18/18? (you were cc'ed in the cover letter BTW).

 Well I have read it now. :)

>>>
>>> Great :)
>>>
>
>> I have been using devicetree and it matches based on the .id_table.
>>
>
> Yes it fallbacks to the .id_table or the driver name but the correct
> thing to do for devices registered by OF, is to match using the
> compatible string.
>
>> Couldn't we just remove the mcp320x_dt_ids table instead?
>>
>
> No, that is the wrong thing to do IMHO since the compatible string
> contains both vendor and device name whle the .id_table only contains
> a device name.
>
> So it makes sense to match using the compatible string and also report
> the OF modalias information to user-space.
>
> Otherwise what's the point of the vendor in the compatible string for
> SPI devices? You can just use "bar" instead of "foo,bar" as a string.
>

 Well then shouldn't the patch include adding the vendor to the compatible
 string?

>>>
>>> Well, I was talking in general. You are right that this specific driver does
>>> not have a vendor prefix for the compatible strings. This is incorrect
>>> according to the ePAPR document [0].
>>>
>>> However, these compatible strings are already documented as a DT binding doc
>>> in Documentation/devicetree/bindings/iio/adc/mcp320x.txt so I don't know
>>> what is the correct thing to do in this situation.
>> Take the view the old version is wrong but needs to be supported and add also
>> the corrected strings + document them.
>>
>> cc'd The device tree list for any more comments on this.
> 
> Agreed. Document both and mark the old one deprecated.
>

Thanks a lot for your comments. I'll do that as a follow up then.
 
> Rob
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/11] ARM: DTS: dra7-evm: Add fixed regulator to be used by aic3106's DVDD

[Peter Ujfalusi]

TPS77018DBVT is used to create 1.8V from avm_3v3_sw's 3.3V connected to
aic3106's DVDD.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/dra7-evm.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index de02cf5853a9..add77ac4f302 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -35,6 +35,15 @@
regulator-max-microvolt = <330>;
};
 
+   aic_dvdd: fixedregulator-aic_dvdd {
+   /* TPS77018DBVT */
+   compatible = "regulator-fixed";
+   regulator-name = "aic_dvdd";
+   vin-supply = <_3v3_sw>;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
extcon_usb1: extcon_usb1 {
compatible = "linux,extcon-usb-gpio";
id-gpio = <_gpio_21 1 GPIO_ACTIVE_HIGH>;
-- 
2.5.0

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

[PATCH 07/11] ARM: DTS: dra72-evm: Add fixed regulator representing DVDD supply for aic3106

[Peter Ujfalusi]

The DVDD is supplied via TPS77018DBVT fixed regulator from evm_3v3

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Darren Etheridge 
---
 arch/arm/boot/dts/dra72-evm.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 6f6bd98c98df..ac3a29483791 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -30,6 +30,15 @@
regulator-max-microvolt = <330>;
};
 
+   aic_dvdd: fixedregulator-aic_dvdd {
+   /* TPS77018DBVT */
+   compatible = "regulator-fixed";
+   regulator-name = "aic_dvdd";
+   vin-supply = <_3v3>;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
evm_3v3_sd: fixedregulator-sd {
compatible = "regulator-fixed";
regulator-name = "evm_3v3_sd";
-- 
2.5.0

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

[PATCH 06/11] ARM: DTS: dra7-evm: Audio support

[Peter Ujfalusi]

The board uses tlv320aic3106 codec connected to McASP3. The master clock
for the codec and McASP3 is coming from ATL2.
McASP3 is the master on the I2S bus.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/dra7-evm.dts | 113 +
 1 file changed, 113 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 3694046c29eb..1a66d359f3e3 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -9,6 +9,7 @@
 
 #include "dra74x.dtsi"
 #include 
+#include 
 
 / {
model = "TI DRA742";
@@ -64,6 +65,40 @@
enable-active-high;
gpio = < 11 GPIO_ACTIVE_HIGH>;
};
+
+   sound0: sound@0 {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "DRA7xx-EVM";
+   simple-audio-card,widgets =
+   "Headphone", "Headphone Jack",
+   "Line", "Line Out",
+   "Microphone", "Mic Jack",
+   "Line", "Line In";
+   simple-audio-card,routing =
+   "Headphone Jack",   "HPLOUT",
+   "Headphone Jack",   "HPROUT",
+   "Line Out", "LLOUT",
+   "Line Out", "RLOUT",
+   "MIC3L","Mic Jack",
+   "MIC3R","Mic Jack",
+   "Mic Jack", "Mic Bias",
+   "LINE1L",   "Line In",
+   "LINE1R",   "Line In";
+   simple-audio-card,format = "dsp_b";
+   simple-audio-card,bitclock-master = <_master>;
+   simple-audio-card,frame-master = <_master>;
+   simple-audio-card,bitclock-inversion;
+
+   sound0_master: simple-audio-card,cpu {
+   sound-dai = <>;
+   system-clock-frequency = <5644800>;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <>;
+   clocks = <_clkin2_ck>;
+   };
+   };
 };
 
 _pmx_core {
@@ -292,6 +327,31 @@
0x418   (MUX_MODE15 | PULL_UP)  /* wakeup0.off */
>;
};
+
+   atl_pins: pinmux_atl_pins {
+   pinctrl-single,pins = <
+   0x298 (PIN_OUTPUT | MUX_MODE5)  /* xref_clk1.atl_clk1 */
+   0x29c (PIN_OUTPUT | MUX_MODE5)  /* xref_clk2.atl_clk2 */
+   >;
+   };
+
+   mcasp3_pins: pinmux_mcasp3_pins {
+   pinctrl-single,pins = <
+   0x324 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_aclkx 
*/
+   0x328 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_fsx */
+   0x32c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr0 
*/
+   0x330 (PIN_INPUT_PULLDOWN | MUX_MODE0)  /* mcasp3_axr1 
*/
+   >;
+   };
+
+   mcasp3_sleep_pins: pinmux_mcasp3_sleep_pins {
+   pinctrl-single,pins = <
+   0x324 (MUX_MODE15)
+   0x328 (MUX_MODE15)
+   0x32c (MUX_MODE15)
+   0x330 (MUX_MODE15)
+   >;
+   };
 };
 
  {
@@ -431,6 +491,20 @@
#interrupt-cells = <2>;
};
 
+   tlv320aic3106: tlv320aic3106@19 {
+   #sound-dai-cells = <0>;
+   compatible = "ti,tlv320aic3106";
+   reg = <0x19>;
+   adc-settle-ms = <40>;
+   ai3x-micbias-vg = <1>;  /* 2.0V */
+   status = "okay";
+
+   /* Regulators */
+   AVDD-supply = <_3v3_sw>;
+   IOVDD-supply = <_3v3_sw>;
+   DRVDD-supply = <_3v3_sw>;
+   DVDD-supply = <_dvdd>;
+   };
 };
 
  {
@@ -730,3 +804,42 @@
pinctrl-1 = <_pins_sleep>;
pinctrl-2 = <_pins_default>;
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   assigned-clocks = <_dpll_sys_clk_mux>,
+ <_gfclk_mux>,
+ <_abe_ck>,
+ <_abe_m2x2_ck>,
+ <_clkin2_ck>;
+   assigned-clock-parents = <_clkin2>, <_abe_m2_ck>;
+   assigned-clock-rates = <0>, <0>, <180633600>, <361267200>, <5644800>;
+
+   status = "okay";
+
+   atl2 {
+   bws = ;
+   aws = ;
+   };
+};
+
+ {
+   #sound-dai-cells = <0>;
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_sleep_pins>;
+
+   assigned-clocks = <_ahclkx_mux>;
+   assigned-clock-parents = <_clkin2_ck>;
+
+   status = "okay";
+
+   op-mode = <0>;  /* MCASP_IIS_MODE */
+   tdm-slots = <2>;
+   /* 4 serializer */
+   serial-dir = <  /* 0: INACTIVE, 

[PATCH 08/11] ARM: DTS: dra72-evm: Add gpio hog for vin6_sel_s0 to select audio

[Peter Ujfalusi]

The GPIO expander's p1 on i2c5 bus 0x26 address is used for selecting
between audio and VIN6 functionality. For VIN6 use an add on card is
needed while audio is present on the board itself.
Select the audio functionality over the VIN6 in the dts file.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/dra72-evm.dts | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index ac3a29483791..33be5c64bda3 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -119,6 +119,13 @@
>;
};
 
+   i2c5_pins: pinmux_i2c5_pins {
+   pinctrl-single,pins = <
+   0x2b4 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda 
*/
+   0x2b8 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl 
*/
+   >;
+   };
+
nand_default: nand_default {
pinctrl-single,pins = <
0x0 (PIN_INPUT  | MUX_MODE0) /* gpmc_ad0 */
@@ -389,6 +396,14 @@
 * VIN6_SEL_S0 is low, thus selecting McASP3 over VIN6
 */
lines-initial-states = <0x0f2b>;
+
+   p1 {
+   /* vin6_sel_s0: high: VIN6, low: audio */
+   gpio-hog;
+   gpios = <1 GPIO_ACTIVE_HIGH>;
+   output-low;
+   line-name = "vin6_sel_s0";
+   };
};
 };
 
-- 
2.5.0

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

[PATCH 10/11] ARM: DTS: am57xx-beagle-x15: Add fixed regulator for aic3104's DVDD

[Peter Ujfalusi]

The DVDD is supplied via TPS77018DBVT fixed regulator from vdd_3v3

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 3a05b94f59ed..485be19822f7 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -35,6 +35,14 @@
regulator-max-microvolt = <330>;
};
 
+   aic_dvdd: fixedregulator-aic_dvdd {
+   compatible = "regulator-fixed";
+   regulator-name = "aic_dvdd_fixed";
+   vin-supply = <_3v3>;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
vtt_fixed: fixedregulator-vtt {
/* TPS51200 */
compatible = "regulator-fixed";
-- 
2.5.0

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

[PATCH 11/11] ARM: DTS: am57xx-beagle-x15: Enable analog audio support

[Peter Ujfalusi]

The analog audio setup consists of:
McASP3 <-> tlv320aic3104 codec

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 87 +
 1 file changed, 87 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 485be19822f7..fd4c96ca8728 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -157,6 +157,32 @@
};
};
};
+
+   sound0: sound@0 {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "BeagleBoard-X15";
+   simple-audio-card,widgets =
+   "Line", "Line Out",
+   "Line", "Line In";
+   simple-audio-card,routing =
+   "Line Out", "LLOUT",
+   "Line Out", "RLOUT",
+   "MIC2L","Line In",
+   "MIC2R","Line In";
+   simple-audio-card,format = "dsp_b";
+   simple-audio-card,bitclock-master = <_master>;
+   simple-audio-card,frame-master = <_master>;
+   simple-audio-card,bitclock-inversion;
+
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   };
+
+   sound0_master: simple-audio-card,codec {
+   sound-dai = <>;
+   clocks = <_clk>;
+   };
+   };
 };
 
 _pmx_core {
@@ -347,6 +373,36 @@
0x370 (PIN_OUTPUT | MUX_MODE14) /* gpio6_28 
LS_OE */
>;
};
+
+   clkout2_pins_default: clkout2_pins_default {
+   pinctrl-single,pins = <
+   0x294 (PIN_OUTPUT_PULLDOWN | MUX_MODE9) /* 
xref_clk0.clkout2 */
+   >;
+   };
+
+   clkout2_pins_sleep: clkout2_pins_sleep {
+   pinctrl-single,pins = <
+   0x294 (PIN_INPUT | MUX_MODE15)  /* xref_clk0.clkout2 */
+   >;
+   };
+
+   mcasp3_pins_default: mcasp3_pins_default {
+   pinctrl-single,pins = <
+   0x324 (PIN_INPUT_PULLDOWN | MUX_MODE0) /* 
mcasp3_aclkx.mcasp3_aclkx */
+   0x328 (PIN_INPUT_PULLDOWN | MUX_MODE0) /* 
mcasp3_fsx.mcasp3_fsx */
+   0x32c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
mcasp3_axr0.mcasp3_axr0 */
+   0x330 (PIN_INPUT_PULLDOWN | MUX_MODE0) /* 
mcasp3_axr1.mcasp3_axr1 */
+   >;
+   };
+
+   mcasp3_pins_sleep: mcasp3_pins_sleep {
+   pinctrl-single,pins = <
+   0x324 (PIN_INPUT | MUX_MODE15)
+   0x328 (PIN_INPUT | MUX_MODE15)
+   0x32c (PIN_INPUT | MUX_MODE15)
+   0x330 (PIN_INPUT | MUX_MODE15)
+   >;
+   };
 };
 
  {
@@ -514,6 +570,22 @@
interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
#thermal-sensor-cells = <1>;
};
+
+   tlv320aic3104: tlv320aic3104@18 {
+   #sound-dai-cells = <0>;
+   compatible = "ti,tlv320aic3104";
+   reg = <0x18>;
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_sleep>;
+   status = "okay";
+   adc-settle-ms = <40>;
+
+   AVDD-supply = <_3v3>;
+   IOVDD-supply = <_3v3>;
+   DRVDD-supply = <_3v3>;
+   DVDD-supply = <_dvdd>;
+   };
 };
 
  {
@@ -704,3 +776,18 @@
  {
gpios = < 8 GPIO_ACTIVE_LOW>;
 };
+
+ {
+   #sound-dai-cells = <0>;
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_sleep>;
+   status = "okay";
+
+   op-mode = <0>;  /* MCASP_IIS_MODE */
+   tdm-slots = <2>;
+   /* 4 serializers */
+   serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
+   1 2 0 0
+   >;
+};
-- 
2.5.0

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

[PATCH 03/11] ARM: DTS: dra7-evm: Rename mmc2_3v3 supply to evm_3v3_sw

[Peter Ujfalusi]

Use the name for the supply as it is in the schematics since the same
supply is used for other peripherals than MMC2, like audio.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/dra7-evm.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index a6c82e5b64fe..de02cf5853a9 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -28,9 +28,9 @@
gpio = <_gpio_21 5 GPIO_ACTIVE_HIGH>;
};
 
-   mmc2_3v3: fixedregulator-mmc2 {
+   evm_3v3_sw: fixedregulator-evm_3v3_sw {
compatible = "regulator-fixed";
-   regulator-name = "mmc2_3v3";
+   regulator-name = "evm_3v3_sw";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
@@ -484,7 +484,7 @@
 
  {
status = "okay";
-   vmmc-supply = <_3v3>;
+   vmmc-supply = <_3v3_sw>;
bus-width = <8>;
 };
 
-- 
2.5.0

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

[PATCH 09/11] ARM: DTS: dra72-evm: Audio support

[Peter Ujfalusi]

The board uses tlv320aic3106 codec connected to McASP3. The master clock
for the codec and McASP3 is coming from ATL2.
McASP3 is the master on the I2S bus.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/dra72-evm.dts | 114 
 1 file changed, 114 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 33be5c64bda3..249000d50090 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -9,6 +9,7 @@
 
 #include "dra72x.dtsi"
 #include 
+#include 
 
 / {
model = "TI DRA722";
@@ -102,6 +103,40 @@
};
};
};
+
+   sound0: sound@0 {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "DRA7xx-EVM";
+   simple-audio-card,widgets =
+   "Headphone", "Headphone Jack",
+   "Line", "Line Out",
+   "Microphone", "Mic Jack",
+   "Line", "Line In";
+   simple-audio-card,routing =
+   "Headphone Jack",   "HPLOUT",
+   "Headphone Jack",   "HPROUT",
+   "Line Out", "LLOUT",
+   "Line Out", "RLOUT",
+   "MIC3L","Mic Jack",
+   "MIC3R","Mic Jack",
+   "Mic Jack", "Mic Bias",
+   "LINE1L",   "Line In",
+   "LINE1R",   "Line In";
+   simple-audio-card,format = "dsp_b";
+   simple-audio-card,bitclock-master = <_master>;
+   simple-audio-card,frame-master = <_master>;
+   simple-audio-card,bitclock-inversion;
+
+   sound0_master: simple-audio-card,cpu {
+   sound-dai = <>;
+   system-clock-frequency = <5644800>;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <>;
+   clocks = <_clkin2_ck>;
+   };
+   };
 };
 
 _pmx_core {
@@ -236,6 +271,31 @@
0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD 
*/
>;
};
+
+   atl_pins: pinmux_atl_pins {
+   pinctrl-single,pins = <
+   0x298 (PIN_OUTPUT | MUX_MODE5)  /* xref_clk1.atl_clk1 */
+   0x29c (PIN_OUTPUT | MUX_MODE5)  /* xref_clk2.atl_clk2 */
+   >;
+   };
+
+   mcasp3_pins: pinmux_mcasp3_pins {
+   pinctrl-single,pins = <
+   0x324 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_aclkx 
*/
+   0x328 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_fsx */
+   0x32c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr0 
*/
+   0x330 (PIN_INPUT_PULLDOWN | MUX_MODE0)  /* mcasp3_axr1 
*/
+   >;
+   };
+
+   mcasp3_sleep_pins: pinmux_mcasp3_sleep_pins {
+   pinctrl-single,pins = <
+   0x324 (PIN_INPUT_PULLDOWN | MUX_MODE15)
+   0x328 (PIN_INPUT_PULLDOWN | MUX_MODE15)
+   0x32c (PIN_INPUT_PULLDOWN | MUX_MODE15)
+   0x330 (PIN_INPUT_PULLDOWN | MUX_MODE15)
+   >;
+   };
 };
 
  {
@@ -376,6 +436,21 @@
output-low;
};
};
+
+   tlv320aic3106: tlv320aic3106@19 {
+   #sound-dai-cells = <0>;
+   compatible = "ti,tlv320aic3106";
+   reg = <0x19>;
+   adc-settle-ms = <40>;
+   ai3x-micbias-vg = <1>;  /* 2.0V */
+   status = "okay";
+
+   /* Regulators */
+   AVDD-supply = <_3v3>;
+   IOVDD-supply = <_3v3>;
+   DRVDD-supply = <_3v3>;
+   DVDD-supply = <_dvdd>;
+   };
 };
 
  {
@@ -719,3 +794,42 @@
};
};
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   assigned-clocks = <_dpll_sys_clk_mux>,
+ <_gfclk_mux>,
+ <_abe_ck>,
+ <_abe_m2x2_ck>,
+ <_clkin2_ck>;
+   assigned-clock-parents = <_clkin2>, <_abe_m2_ck>;
+   assigned-clock-rates = <0>, <0>, <180633600>, <361267200>, <5644800>;
+
+   status = "okay";
+
+   atl2 {
+   bws = ;
+   aws = ;
+   };
+};
+
+ {
+   #sound-dai-cells = <0>;
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_sleep_pins>;
+
+   assigned-clocks = <_ahclkx_mux>;
+   assigned-clock-parents = <_clkin2_ck>;
+
+   status = "okay";
+
+   op-mode = <0>;  /* MCASP_IIS_MODE */
+   tdm-slots = <2>;
+   /* 4 serializer */
+   

[PATCH 01/11] ARM: OMAP: DRA7: hwmod: Add data for McASP3

[Peter Ujfalusi]

McASP3 is used by default on DRA7x based boards for audio.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247bced49..c38b7fa30c27 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1298,6 +1298,38 @@ static struct omap_hwmod dra7xx_mcspi4_hwmod = {
 };
 
 /*
+ * 'mcasp' class
+ *
+ */
+static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = {
+   .sysc_offs  = 0x0004,
+   .sysc_flags = SYSC_HAS_SIDLEMODE,
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= _hwmod_sysc_type3,
+};
+
+static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
+   .name   = "mcasp",
+   .sysc   = _mcasp_sysc,
+};
+
+/* mcasp3 */
+static struct omap_hwmod dra7xx_mcasp3_hwmod = {
+   .name   = "mcasp3",
+   .class  = _mcasp_hwmod_class,
+   .clkdm_name = "l4per2_clkdm",
+   .main_clk   = "mcasp3_ahclkx_mux",
+   .flags  = HWMOD_SWSUP_SIDLE,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4PER2_MCASP3_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4PER2_MCASP3_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/*
  * 'mmc' class
  *
  */
@@ -2566,6 +2598,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi = 
{
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_per2 -> mcasp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp3 = {
+   .master = _l4_per2_hwmod,
+   .slave  = _mcasp3_hwmod,
+   .clk= "l3_iclk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
{
.pa_start   = 0x48078000,
@@ -3338,6 +3378,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
_l4_wkup__dcan1,
_l4_per2__dcan2,
_l4_per2__cpgmac0,
+   _l4_per2__mcasp3,
_gmac__mdio,
_l4_cfg__dma_system,
_l3_main_1__dss,
-- 
2.5.0

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

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

[Dongsheng Yang]

On 08/24/2015 03:18 PM, Artem Bityutskiy wrote:

On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote:

On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote:

Basically, we need to see what is the "common practice" here, and
follow it. This requires a small research. What would be the most
popular Linux FS which does not support direct I/O? Can we check
what
it does?


All popular filesystems seem to support direct IO.
That's the problem, application do not expect O_DIRECT to fail.

My intention was to do it like exofs:


Fair enough, thanks!

Signed-off-by: Artem Bityutskiy 


Richard, you mention this was suggested by Dave, could you please pint
to the discussion, if possible?


http://lists.infradead.org/pipermail/linux-mtd/2015-August/060702.html

That's in a discussion I want to introduce ubifs into xfstests.

Yang


Artem.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support

[Peter Ujfalusi]

Hi,

this series will enable analog audio (via onboard aic310x codec) for dra7-evm,
dra72-evm and am57xx-beagle-x15 boards.
In these board McASP3 is connected to the codec and for the McASP3 we needed to
have the DMA crossbar in place since the request lines are not mapped by
default.

Regars,
Peter
---
Peter Ujfalusi (11):
  ARM: OMAP: DRA7: hwmod: Add data for McASP3
  ARM: DTS: dra7: Add McASP3 node
  ARM: DTS: dra7-evm: Rename mmc2_3v3 supply to evm_3v3_sw
  ARM: DTS: dra7-evm: Add fixed regulator to be used by aic3106's DVDD
  ARM: DTS: dra7-evm: Enable pcf8575 (0x26 address) on i2c2 bus
  ARM: DTS: dra7-evm: Audio support
  ARM: DTS: dra72-evm: Add fixed regulator representing DVDD supply for
aic3106
  ARM: DTS: dra72-evm: Add gpio hog for vin6_sel_s0 to select audio
  ARM: DTS: dra72-evm: Audio support
  ARM: DTS: am57xx-beagle-x15: Add fixed regulator for aic3104's DVDD
  ARM: DTS: am57xx-beagle-x15: Enable analog audio support

 arch/arm/boot/dts/am57xx-beagle-x15.dts   |  95 
 arch/arm/boot/dts/dra7-evm.dts| 142 +-
 arch/arm/boot/dts/dra7.dtsi   |  15 
 arch/arm/boot/dts/dra72-evm.dts   | 138 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  41 +
 5 files changed, 428 insertions(+), 3 deletions(-)

-- 
2.5.0

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

[PATCH 05/11] ARM: DTS: dra7-evm: Enable pcf8575 (0x26 address) on i2c2 bus

[Peter Ujfalusi]

This GPIO expander is used for controlling various muxes on the board.
By default select audio functionality over VIN6 by setting the P1
(vin6_sel_s0) pin to low.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/dra7-evm.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index add77ac4f302..3694046c29eb 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -438,6 +438,20 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
clock-frequency = <40>;
+
+   pcf_hdmi: gpio@26 {
+   compatible = "nxp,pcf8575";
+   reg = <0x26>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   p1 {
+   /* vin6_sel_s0: high: VIN6, low: audio */
+   gpio-hog;
+   gpios = <1 GPIO_ACTIVE_HIGH>;
+   output-low;
+   line-name = "vin6_sel_s0";
+   };
+   };
 };
 
  {
-- 
2.5.0

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

Re: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers

[Mike Galbraith]

On Mon, 2015-08-24 at 08:44 +0200, Ingo Molnar wrote:

> the 'housekeeping CPU' is essentially the boot CPU. Yet we dedicate a full 
> mask to 
> it (housekeeping_mask - a variable mask to begin with) and recover the 
> housekeeping CPU via:
> 
> +   return cpumask_any_and(housekeeping_mask, cpu_online_mask);

There can be, and had better be if box is big, multiple housekeepers.

Imagine a NO_HZ_FULL_ALL kernel on an SGI beast from hell.  Offloading
8191 CPUs onto poor little CPU0 probably wouldn't work out well :)

-Mike

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

[PATCH 02/11] ARM: DTS: dra7: Add McASP3 node

[Peter Ujfalusi]

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/dra7.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5d65db9ebc2b..07fa4ea5521a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1403,6 +1403,21 @@
status = "disabled";
};
 
+   mcasp3: mcasp@48468000 {
+   compatible = "ti,dra7-mcasp-audio";
+   ti,hwmods = "mcasp3";
+   reg = <0x48468000 0x2000>;
+   reg-names = "mpu";
+   interrupts = ,
+;
+   interrupt-names = "tx", "rx";
+   dmas = <_xbar 133>, <_xbar 132>;
+   dma-names = "tx", "rx";
+   clocks = <_ahclkx_mux>;
+   clock-names = "fck";
+   status = "disabled";
+   };
+
crossbar_mpu: crossbar@4a002a48 {
compatible = "ti,irq-crossbar";
reg = <0x4a002a48 0x130>;
-- 
2.5.0

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

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

[Dongsheng Yang]

On 08/24/2015 03:17 PM, Dongsheng Yang wrote:

On 08/24/2015 03:18 PM, Artem Bityutskiy wrote:

On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote:

On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote:

Basically, we need to see what is the "common practice" here, and
follow it. This requires a small research. What would be the most
popular Linux FS which does not support direct I/O? Can we check
what
it does?


All popular filesystems seem to support direct IO.
That's the problem, application do not expect O_DIRECT to fail.

My intention was to do it like exofs:


Fair enough, thanks!

Signed-off-by: Artem Bityutskiy 


Richard, you mention this was suggested by Dave, could you please pint
to the discussion, if possible?


http://lists.infradead.org/pipermail/linux-mtd/2015-August/060702.html

That's in a discussion I want to introduce ubifs into xfstests.


And Artem, I cc-ed that discussion to you, maybe you can find it in your
Inbox.


Yang


Artem.
--
To unsubscribe from this list: send the line "unsubscribe
linux-fsdevel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3 1/1] USB:option:add ZTE PIDs

[Johan Hovold]

On Wed, Aug 19, 2015 at 08:51:17AM -0700, Liu.Zhao wrote:
> 
> This is intended to add ZTE device PIDs on kernel.
> 
> 
> 
> Signed-off-by: Liu.Zhao 
> ---
>  drivers/usb/serial/option.c | 36 
>  1 file changed, 28 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index 876423b..e26db28 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -278,13 +278,17 @@ static void option_instat_callback(struct urb *urb);
>  #define ZTE_PRODUCT_MF6220x0001
>  #define ZTE_PRODUCT_MF6280x0015
>  #define ZTE_PRODUCT_MF6260x0031
> -#define ZTE_PRODUCT_AC2726   0xfff1
> -#define ZTE_PRODUCT_MG8800xfffd
> -#define ZTE_PRODUCT_CDMA_TECH0xfffe
> -#define ZTE_PRODUCT_AC8710T  0x
> +#define ZTE_PRODUCT_ZM8620_X 0x0396
> +#define ZTE_PRODUCT_ME3620_MBIM  0x0426
> +#define ZTE_PRODUCT_ME3620_X 0x1432
> +#define ZTE_PRODUCT_ME3620_L 0x1433
>  #define ZTE_PRODUCT_MC2718   0xffe8
>  #define ZTE_PRODUCT_AD3812   0xffeb
>  #define ZTE_PRODUCT_MC2716   0xffed
> +#define ZTE_PRODUCT_AC2726   0xfff1
> +#define ZTE_PRODUCT_MG8800xfffd
> +#define ZTE_PRODUCT_CDMA_TECH0xfffe
> +#define ZTE_PRODUCT_AC8710T  0x

Reordering the current entries is not needed, but if you do it then you
must mention it in the commit message above.

Also make sure to not change any formatting; checkpatch is now
complaining about whitespace issues (always run checkpatch before
submitting).

>  #define BENQ_VENDOR_ID   0x04a5
>  #define BENQ_PRODUCT_H10 0x4068
> @@ -544,6 +548,14 @@ static const struct option_blacklist_info 
> zte_mc2716_z_blacklist = {
>   .sendsetup = BIT(1) | BIT(2) | BIT(3),
>  };
>  
> +static const struct option_blacklist_info zte_me3620andzm8620_xl_blacklist = 
> {
> + .reserved = BIT(3) | BIT(4) | BIT(5),
> +};

Use two structs for this: zte_me3620_blacklist and zm8620_xl_blacklist
even if they reserve the same ports.

> +
> +static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
> + .reserved = BIT(2) | BIT(3) | BIT(4),
> +};
> +
>  static const struct option_blacklist_info huawei_cdc12_blacklist = {
>   .reserved = BIT(1) | BIT(2),
>  };
> @@ -1581,16 +1593,24 @@ static const struct usb_device_id option_ids[] = {
>   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfff9, 0xff, 0xff, 
> 0xff) },
>   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffb, 0xff, 0xff, 
> 0xff) },
>   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffc, 0xff, 0xff, 
> 0xff) },
> - { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MG880, 0xff, 
> 0xff, 0xff) },
> - { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_CDMA_TECH, 
> 0xff, 0xff, 0xff) },
>   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC2726, 
> 0xff, 0xff, 0xff) },
>   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC8710T, 
> 0xff, 0xff, 0xff) },
> - { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718, 
> 0xff, 0xff, 0xff),
> -  .driver_info = (kernel_ulong_t)_mc2718_z_blacklist },
>   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AD3812, 
> 0xff, 0xff, 0xff),
>.driver_info = (kernel_ulong_t)_ad3812_z_blacklist },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_CDMA_TECH, 
> 0xff, 0xff, 0xff) },
>   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2716, 
> 0xff, 0xff, 0xff),
>.driver_info = (kernel_ulong_t)_mc2716_z_blacklist },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718, 
> 0xff, 0xff, 0xff),
> +  .driver_info = (kernel_ulong_t)_mc2718_z_blacklist },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MG880, 0xff, 
> 0xff, 0xff) },
> + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L),
> +  .driver_info = (kernel_ulong_t)_me3620andzm8620_xl_blacklist },
> + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X),
> +  .driver_info = (kernel_ulong_t)_me3620andzm8620_xl_blacklist },
> + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X),
> +  .driver_info = (kernel_ulong_t)_me3620andzm8620_xl_blacklist },
> + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM),
> +  .driver_info = (kernel_ulong_t)_me3620_mbim_blacklist },

If really want to reorder the current entries, then at least make sure
the end result is indeed sorted.

>   { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) },
>   { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
>   { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 

[PATCH 3/3 v4] mm/vmalloc: Cache the vmalloc memory info

[Ingo Molnar]

* George Spelvin  wrote:

> First, an actual, albeit minor, bug: initializing both vmap_info_gen
> and vmap_info_cache_gen to 0 marks the cache as valid, which it's not.

Ha! :-) Fixed.

> vmap_info_gen should be initialized to 1 to force an initial
> cache update.

Yeah.

> Second, I don't see why you need a 64-bit counter.  Seqlocks consider
> 32 bits (31 bits, actually, the lsbit means "update in progress") quite
> a strong enough guarantee.

Just out of general paranoia - but you are right, and this would lower the 
overhead on 32-bit SMP platforms a bit, plus it avoids 64-bit word tearing 
artifacts on 32 bit platforms as well.

I modified it to u32.

> Third, it seems as though vmap_info_cache_gen is basically a duplicate
> of vmap_info_lock.sequence.  It should be possible to make one variable
> serve both purposes.

Correct, I alluded to that in my description:

> > Note that there's an even simpler variant possible I think: we could use 
> > just 
> > the two generation counters and barriers to remove the seqlock.

> You just need a kludge to handle the case of multiple vamp_info updates
> between cache updates.
> 
> There are two simple ones:
> 
> 1) Avoid bumping vmap_info_gen unnecessarily.  In vmap_unlock(), do
>   vmap_info_gen = (vmap_info_lock.sequence | 1) + 1;
> 2) - Make vmap_info_gen a seqcount_t
>- In vmap_unlock(), do write_seqcount_barrier(_info_gen)
>- In get_vmalloc_info, inside the seqlock critical section, do
>  vmap_info_lock.seqcount.sequence = vmap_info_gen.sequence - 1;
>  (Using the vmap_info_gen.sequence read while validating the
>  cache in the first place.)
> 
> I should try to write an actual patch illustrating this.

So I think something like the patch below is even simpler than trying to kludge 
generation counter semantics into seqcounts.

I used two generation counters and a spinlock. The fast path is completely 
lockless and lightweight on modern SMP platforms. (where smp_rmb() is a no-op 
or 
very cheap.)

There's not even a seqlock retry loop, instead an invalid cache causes us to 
fall 
back to the old behavior - and the freshest result is guaranteed to end up in 
the 
cache.

The linecount got a bit larger: but half of it is comments.

Note that the generation counters are signed integers so that this comparison 
can 
be done:

+   if (gen-vmap_info_cache_gen > 0) {

Thanks,

Ingo

==>
>From 1a4c168a22cc302282cbd1bf503ecfc4dc52b74f Mon Sep 17 00:00:00 2001
From: Ingo Molnar 
Date: Sat, 22 Aug 2015 12:28:01 +0200
Subject: [PATCH] mm/vmalloc: Cache the vmalloc memory info

Linus reported that for scripting-intense workloads such as the
Git build, glibc's qsort will read /proc/meminfo for every process
created (by way of get_phys_pages()), which causes the Git build
to generate a surprising amount of kernel overhead.

A fair chunk of the overhead is due to get_vmalloc_info() - which
walks a potentially long list to do its statistics.

Modify Linus's jiffies based patch to use generation counters
to cache the vmalloc info: vmap_unlock() increases the generation
counter, and the get_vmalloc_info() reads it and compares it
against a cached generation counter.

Also use a seqlock to make sure we always print a consistent
set of vmalloc statistics.

Reported-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Rik van Riel 
Cc: linux...@kvack.org
Signed-off-by: Ingo Molnar 
---
 mm/vmalloc.c | 83 +---
 1 file changed, 80 insertions(+), 3 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 605138083880..23df06ebb48a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -276,7 +276,21 @@ EXPORT_SYMBOL(vmalloc_to_pfn);
 #define VM_LAZY_FREEING0x02
 #define VM_VM_AREA 0x04
 
-static DEFINE_SPINLOCK(vmap_area_lock);
+static __cacheline_aligned_in_smp DEFINE_SPINLOCK(vmap_area_lock);
+
+#ifdef CONFIG_PROC_FS
+/*
+ * A seqlock and two generation counters for a simple cache of the
+ * vmalloc allocation statistics info printed in /proc/meminfo.
+ *
+ * ( The assumption of the optimization is that it's read frequently, but
+ *   modified infrequently. )
+ */
+static DEFINE_SPINLOCK(vmap_info_lock);
+static int vmap_info_gen = 1;
+static int vmap_info_cache_gen;
+static struct vmalloc_info vmap_info_cache;
+#endif
 
 static inline void vmap_lock(void)
 {
@@ -285,6 +299,9 @@ static inline void vmap_lock(void)
 
 static inline void vmap_unlock(void)
 {
+#ifdef CONFIG_PROC_FS
+   WRITE_ONCE(vmap_info_gen, vmap_info_gen+1);
+#endif
spin_unlock(_area_lock);
 }
 
@@ -2699,7 +2716,7 @@ static int __init proc_vmalloc_init(void)
 }
 module_init(proc_vmalloc_init);
 
-void get_vmalloc_info(struct vmalloc_info *vmi)
+static void calc_vmalloc_info(struct vmalloc_info *vmi)
 {
struct vmap_area *va;
unsigned long free_area_size;
@@ -2746,5 +2763,65 @@ void get_vmalloc_info(struct vmalloc_info *vmi)
 out:
rcu_read_unlock();
 }
-#endif
 
+/*
+ 

[PATCH] clk: ti: clk-7xx: Remove hardwired ABE clock configuration

[Peter Ujfalusi]

The ABE related clocks should be configured via DT and not have it wired
inside of the kernel.

Signed-off-by: Peter Ujfalusi 
---
Hi Tero,

the ABE PLL configuration can, and will be done for dra7xx in DT with the
assigned-clocks/rate/parent feature so no need to have this anymore.

Regards,
Peter

 drivers/clk/ti/clk-7xx.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 9b5b289e6334..a911d7de3377 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -18,7 +18,6 @@
 
 #include "clock.h"
 
-#define DRA7_DPLL_ABE_DEFFREQ  180633600
 #define DRA7_DPLL_GMAC_DEFFREQ 10
 #define DRA7_DPLL_USB_DEFFREQ  96000
 
@@ -313,27 +312,12 @@ static struct ti_dt_clk dra7xx_clks[] = {
 int __init dra7xx_dt_clk_init(void)
 {
int rc;
-   struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
+   struct clk *dpll_ck, *hdcp_ck;
 
ti_dt_clocks_register(dra7xx_clks);
 
omap2_clk_disable_autoidle_all();
 
-   abe_dpll_mux = clk_get_sys(NULL, "abe_dpll_sys_clk_mux");
-   sys_clkin2 = clk_get_sys(NULL, "sys_clkin2");
-   dpll_ck = clk_get_sys(NULL, "dpll_abe_ck");
-
-   rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
-   if (!rc)
-   rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
-   if (rc)
-   pr_err("%s: failed to configure ABE DPLL!\n", __func__);
-
-   dpll_ck = clk_get_sys(NULL, "dpll_abe_m2x2_ck");
-   rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2);
-   if (rc)
-   pr_err("%s: failed to configure ABE DPLL m2x2!\n", __func__);
-
dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
if (rc)
-- 
2.5.0

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

Re: [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously

[Johannes Berg]

On Mon, 2015-08-24 at 11:45 +0800, Fu, Zhonghui wrote:
> 
> On 2015/8/17 16:46, Arend van Spriel wrote:
> > + Rafael
> > 
> > On 08/17/2015 09:29 AM, Johannes Berg wrote:
> > > On Mon, 2015-08-17 at 09:48 +0800, Fu, Zhonghui wrote:
> > > > 
> > > > The suspend/resume timing of wiphy device and related devices 
> > > > will be
> > > > ensured by their parent/child relationship. So, enabling wiphy 
> > > > device
> > > > to suspend/resume asynchronously does not change any 
> > > >  dependency. It
> > > > can only take advantage of multicore and improve system
> > > > suspend/resume speed.
> > > > 
> > > 
> > > You're going to have to explain that to me, because I don't see 
> > > that.
> > > All I see is that when looking at a device, if async is possible, 
> > > it
> > > gets added to an async work, and if async is not possible then it 
> > > gets
> > > done immediately. Even putting aside the question of whether or 
> > > not
> > > async is ordered or not (I don't know), if the wiphy is async and 
> > > the
> > > PCI (or other bus) device isn't, then it seems they could get 
> > > handled
> > > out of order, no? Or is there some magic code somewhere that I'm
> > > missing that explicitly waits for the async of the parent/child
> > > relationship?
> > 
> > This patch got me worried as well. Can't find the magic either. 
> > Maybe Rafael can give some hints here.
> 
> "dpm_wait_for_children" function will be invoked in 
> "__device_suspend", "__device_suspend_late", and 
> "__device_suspend_noirq" functions to synchronize the child 
> relationship. "dpm_wait" function will be invoked in 
> "device_resume_noirq", "device_resume_early", and "device_resume" 
> functions to synchronize the parent relationship. If two devices have 
> parent/child relationship, but different suspend/resume mode(sync or 
> async), this will have no impact to PM timing order between them. 
> Because all devices will use "__device_suspend", 
> "__device_suspend_late" ... functions to complete their PM 
> transition.
> 

Ok, good point. For the unaware here, can you please resend with a
commit message amended with some of this information?

thanks,
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/14] Documentation: drm/bridge: add document for analogix_dp

[Jingoo Han]

On 2015. 8. 24., at AM 9:43, Krzysztof Kozlowski  
wrote:
> 
> 2015-08-24 8:23 GMT+09:00 Rob Herring :
>>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang  wrote:
>>> Analogix dp driver is split from exynos dp driver, so we just
>>> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
>>> 
>>> Beside update some exynos dtsi file with the latest change
>>> according to the devicetree binding documents.
>> 
>> You can't just change the exynos bindings and break compatibility. Is
>> there some agreement with exynos folks to do this?
> 
> No, there is no agreement. This wasn't even sent to Exynos maintainers.
> Additionally the patchset did not look interesting to me because of
> misleading subject - Documentation instead of "ARM: dts:".
> 
> Yakir, please:
> 1. Provide backward compatibility. Mark old properties as deprecated
> but still support them.
> 2. Separate all DTS changes to a separate patch, unless bisectability
> would be hurt. Anyway you should prepare it in a such way that
> separation would be possible without breaking bisectability.
> 3. Use proper subject for the patch changing DTS. This is not
> documentation change!
> 4. Please use script get_maintainers to obtain list of valid
> maintainers and CC-them with at least cover letter and patches
> requiring their attention.

To Yakir Yang,

Please be careful when you CC people.

I don't find the reason why you CC'ed the following people. Of course, they
look to be one of the talented developers. However, they look to be
unrelated to your patchset.

 Takashi Iwai
 Vincent Palatin
 Fabio Estevam
 Philipp Zabel


Also, please add Exynos Architecture maintainers to CC list. I don't understand
why you removed them from CC list.
 Kukjin Kim
 Krzysztof Kozlowski

Without their Ack, you will not change the codes of ARM Exynos Architecture.

Best regards,
Jingoo Han

> 
> Best regards,
> Krzysztof
> 
> 
>> 
>> 
>>> Signed-off-by: Yakir Yang 
>>> ---
>>> Changes in v3:
>>> - Take Heiko suggest, add devicetree binding documents.
>>> - Take Thierry Reding suggest, remove sync pol & colorimetry properies
>>>  from the new analogix dp driver devicetree binding.
>>> - Update the exist exynos dtsi file with the latest DP DT properies.
>>> 
>>> Changes in v2: None
>>> 
>>> .../devicetree/bindings/drm/bridge/analogix_dp.txt | 70 
>>> ++
>>> .../devicetree/bindings/video/exynos_dp.txt| 50 ++--
>>> arch/arm/boot/dts/exynos5250-arndale.dts   | 10 ++--
>>> arch/arm/boot/dts/exynos5250-smdk5250.dts  | 10 ++--
>>> arch/arm/boot/dts/exynos5250-snow.dts  | 12 ++--
>>> arch/arm/boot/dts/exynos5250-spring.dts| 12 ++--
>>> arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++--
>>> arch/arm/boot/dts/exynos5420-smdk5420.dts  | 10 ++--
>>> arch/arm/boot/dts/exynos5800-peach-pi.dts  | 12 ++--
>>> 9 files changed, 119 insertions(+), 79 deletions(-)
>>> create mode 100644 
>>> Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
>>> 
>>> diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt 
>>> b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
>>> new file mode 100644
>>> index 000..6127018
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
>>> @@ -0,0 +1,70 @@
>>> +Analogix Display Port bridge bindings
>>> +
>>> +Required properties for dp-controller:
>>> +   -compatible:
>>> +   platform specific such as:
>>> +* "samsung,exynos5-dp"
>>> +* "rockchip,rk3288-dp"
>>> +   -reg:
>>> +   physical base address of the controller and length
>>> +   of memory mapped region.
>>> +   -interrupts:
>>> +   interrupt combiner values.
>>> +   -clocks:
>>> +   from common clock binding: handle to dp clock.
>>> +   -clock-names:
>>> +   from common clock binding: Shall be "dp".
>>> +   -interrupt-parent:
>>> +   phandle to Interrupt combiner node.
>>> +   -phys:
>>> +   from general PHY binding: the phandle for the PHY device.
>>> +   -phy-names:
>>> +   from general PHY binding: Should be "dp".
>>> +   -analogix,color-space:
>>> +   input video data format.
>>> +   COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 
>>> 2
>>> +   -analogix,color-depth:
>>> +   number of bits per colour component.
>>> +   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
>> 
>> This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
>> drop the vendor prefix.
>> 
>>> +   -analogix,link-rate:
>>> +   max link rate supported by the eDP controller.
>>> +   LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A,
>>> +   LINK_RATE_5_40GBPS = 0x14
>> 
>> Same here. I'd rather see something like "link-rate-mbps" and use 

Re: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers

[Ingo Molnar]

* Mike Galbraith  wrote:

> On Mon, 2015-08-24 at 08:44 +0200, Ingo Molnar wrote:
> 
> > the 'housekeeping CPU' is essentially the boot CPU. Yet we dedicate a full 
> > mask to 
> > it (housekeeping_mask - a variable mask to begin with) and recover the 
> > housekeeping CPU via:
> > 
> > +   return cpumask_any_and(housekeeping_mask, cpu_online_mask);
> 
> There can be, and had better be if box is big, multiple housekeepers.

Yes - but that does not seem to be possible via the code right now AFAICS, so 
at 
minimum it's incomplete.

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 v3 2/2] drivers: rtc: add xilinx zynqmp rtc driver

[Alexandre Belloni]

On 19/08/2015 at 15:23:22 +0530, Suneel Garapati wrote :
> adds support for RTC controller found on
> Xilinx Zynq Ultrascale+ MPSoC platform.
> 
> Signed-off-by: Suneel Garapati 
> ---
> Changes v3 
> - fix checkpatch errors 
> - check time in secs arg against max sec val 
> - order header files 
> - use ptr_err_or_zero macro 
> - use time64 variants 
> Changes v2 
> - change alm to alarm 
> ---
>  drivers/rtc/Kconfig  |   7 ++
>  drivers/rtc/Makefile |   1 +
>  drivers/rtc/rtc-zynqmp.c | 279 
> +++
>  3 files changed, 287 insertions(+)
>  create mode 100644 drivers/rtc/rtc-zynqmp.c
> 
Applied, thanks.

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

Re: [PATCH v3 1/2] devicetree: bindings: rtc: add bindings for xilinx zynqmp rtc

[Alexandre Belloni]

On 19/08/2015 at 15:23:21 +0530, Suneel Garapati wrote :
> adds file for description on device node bindings for RTC
> found on Xilinx Zynq Ultrascale+ MPSoC.
> 
> Signed-off-by: Suneel Garapati 
> ---
> Changes v3 
> - none 
> Changes v2 
> - add examples for interrupt-names 
> - change alm to alarm 
> ---
>  Documentation/devicetree/bindings/rtc/xlnx-rtc.txt | 25 
> ++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rtc/xlnx-rtc.txt
> 
Applied, thanks.

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

Re: [PATCH 3/3 v4] mm/vmalloc: Cache the vmalloc memory info

[Ingo Molnar]

* Ingo Molnar  wrote:

> +/*
> + * Return a consistent snapshot of the current vmalloc allocation
> + * statistics, for /proc/meminfo:
> + */
> +void get_vmalloc_info(struct vmalloc_info *vmi)
> +{
> + int gen = READ_ONCE(vmap_info_gen);
> +
> + /*
> +  * If the generation counter of the cache matches that of
> +  * the vmalloc generation counter then return the cache:
> +  */
> + if (READ_ONCE(vmap_info_cache_gen) == gen) {
> + int gen_after;
> +
> + /*
> +  * The two read barriers make sure that we read
> +  * 'gen', 'vmap_info_cache' and 'gen_after' in
> +  * precisely that order:
> +  */
> + smp_rmb();
> + *vmi = vmap_info_cache;
> +
> + smp_rmb();
> + gen_after = READ_ONCE(vmap_info_gen);
> +
> + /* The cache is still valid: */
> + if (gen == gen_after)
> + return;
> +
> + /* Ok, the cache got invalidated just now, regenerate it */
> + gen = gen_after;
> + }

One more detail: I just realized that with the read barriers, the READ_ONCE() 
accesses are not needed anymore - the barriers and the control dependencies are 
enough.

This will further simplify the code.

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 v3 2/2] drivers: rtc: add xilinx zynqmp rtc driver

[Michal Simek]

On 08/24/2015 09:43 AM, Alexandre Belloni wrote:
> On 19/08/2015 at 15:23:22 +0530, Suneel Garapati wrote :
>> adds support for RTC controller found on
>> Xilinx Zynq Ultrascale+ MPSoC platform.
>>
>> Signed-off-by: Suneel Garapati 
>> ---
>> Changes v3 
>> - fix checkpatch errors 
>> - check time in secs arg against max sec val 
>> - order header files 
>> - use ptr_err_or_zero macro 
>> - use time64 variants 
>> Changes v2 
>> - change alm to alarm 
>> ---
>>  drivers/rtc/Kconfig  |   7 ++
>>  drivers/rtc/Makefile |   1 +
>>  drivers/rtc/rtc-zynqmp.c | 279 
>> +++
>>  3 files changed, 287 insertions(+)
>>  create mode 100644 drivers/rtc/rtc-zynqmp.c
>>
> Applied, thanks.
> 

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/

[PATCH 3/3 v5] mm/vmalloc: Cache the vmalloc memory info

[Ingo Molnar]

* Ingo Molnar  wrote:

> One more detail: I just realized that with the read barriers, the READ_ONCE() 
> accesses are not needed anymore - the barriers and the control dependencies 
> are 
> enough.
> 
> This will further simplify the code.

I.e. something like the updated patch below. (We still need the WRITE_ONCE() 
for 
vmap_info_gen update.)

Thanks,

Ingo

>
>From 46a0507e0a395a7bc2fe4b46a4766e7457ac0140 Mon Sep 17 00:00:00 2001
From: Ingo Molnar 
Date: Sat, 22 Aug 2015 12:28:01 +0200
Subject: [PATCH] mm/vmalloc: Cache the vmalloc memory info

Linus reported that for scripting-intense workloads such as the
Git build, glibc's qsort will read /proc/meminfo for every process
created (by way of get_phys_pages()), which causes the Git build
to generate a surprising amount of kernel overhead.

A fair chunk of the overhead is due to get_vmalloc_info() - which
walks a potentially long list to do its statistics.

Modify Linus's jiffies based patch to use generation counters
to cache the vmalloc info: vmap_unlock() increases the generation
counter, and the get_vmalloc_info() reads it and compares it
against a cached generation counter.

Also use a seqlock to make sure we always print a consistent
set of vmalloc statistics.

Reported-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Rik van Riel 
Cc: linux...@kvack.org
Signed-off-by: Ingo Molnar 
---
 mm/vmalloc.c | 82 +---
 1 file changed, 79 insertions(+), 3 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 605138083880..2f8d9660e007 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -276,7 +276,21 @@ EXPORT_SYMBOL(vmalloc_to_pfn);
 #define VM_LAZY_FREEING0x02
 #define VM_VM_AREA 0x04
 
-static DEFINE_SPINLOCK(vmap_area_lock);
+static __cacheline_aligned_in_smp DEFINE_SPINLOCK(vmap_area_lock);
+
+#ifdef CONFIG_PROC_FS
+/*
+ * A seqlock and two generation counters for a simple cache of the
+ * vmalloc allocation statistics info printed in /proc/meminfo.
+ *
+ * ( The assumption of the optimization is that it's read frequently, but
+ *   modified infrequently. )
+ */
+static DEFINE_SPINLOCK(vmap_info_lock);
+static int vmap_info_gen = 1;
+static int vmap_info_cache_gen;
+static struct vmalloc_info vmap_info_cache;
+#endif
 
 static inline void vmap_lock(void)
 {
@@ -285,6 +299,9 @@ static inline void vmap_lock(void)
 
 static inline void vmap_unlock(void)
 {
+#ifdef CONFIG_PROC_FS
+   WRITE_ONCE(vmap_info_gen, vmap_info_gen+1);
+#endif
spin_unlock(_area_lock);
 }
 
@@ -2699,7 +2716,7 @@ static int __init proc_vmalloc_init(void)
 }
 module_init(proc_vmalloc_init);
 
-void get_vmalloc_info(struct vmalloc_info *vmi)
+static void calc_vmalloc_info(struct vmalloc_info *vmi)
 {
struct vmap_area *va;
unsigned long free_area_size;
@@ -2746,5 +2763,64 @@ void get_vmalloc_info(struct vmalloc_info *vmi)
 out:
rcu_read_unlock();
 }
-#endif
 
+/*
+ * Return a consistent snapshot of the current vmalloc allocation
+ * statistics, for /proc/meminfo:
+ */
+void get_vmalloc_info(struct vmalloc_info *vmi)
+{
+   int gen = vmap_info_gen;
+
+   /*
+* If the generation counter of the cache matches that of
+* the vmalloc generation counter then return the cache:
+*/
+   if (vmap_info_cache_gen == gen) {
+   int gen_after;
+
+   /*
+* The two read barriers make sure that we read
+* 'gen', 'vmap_info_cache' and 'gen_after' in
+* precisely that order:
+*/
+   smp_rmb();
+   *vmi = vmap_info_cache;
+
+   smp_rmb();
+   gen_after = vmap_info_gen;
+
+   /* The cache is still valid: */
+   if (gen == gen_after)
+   return;
+
+   /* Ok, the cache got invalidated just now, regenerate it */
+   gen = gen_after;
+   }
+
+   /* Make sure 'gen' is read before the vmalloc info */
+   smp_rmb();
+
+   calc_vmalloc_info(vmi);
+
+   /*
+* All updates to vmap_info_cache_gen go through this spinlock,
+* so when the cache got invalidated, we'll only mark it valid
+* again if we first fully write the new vmap_info_cache.
+*
+* This ensures that partial results won't be used.
+*/
+   spin_lock(_info_lock);
+   if (gen-vmap_info_cache_gen > 0) {
+   vmap_info_cache = *vmi;
+   /*
+* Make sure the new cached data is visible before
+* the generation counter update:
+*/
+   smp_wmb();
+   vmap_info_cache_gen = gen;
+   }
+   spin_unlock(_info_lock);
+}
+
+#endif /* CONFIG_PROC_FS */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH v2 1/5] clocksource: mediatek: do not enable GPT_CLK_EVT when setup

[Daniel Lezcano]

On 08/21/2015 04:39 PM, Yingjoe Chen wrote:

[ ... ]


   - Does the spurious interrupt occurs *every* time ? at each boot ?


Yes. If you applied this series to enable mtk timer without this fix on
mt8173 or mt8135 you can reproduce it. It occurs for every boot.

It crash before uart driver is ready, so you'll have to use earlycon to
see the crash log.


Can you give me the earlycon params ?

Thanks.

 -- Daniel

--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [x86] copy_from{to}_user question

[yalin wang]

> On Aug 22, 2015, at 17:05, Borislav Petkov  wrote:
> 
> On Fri, Aug 21, 2015 at 02:06:16PM -0700, H. Peter Anvin wrote:
>> What I'm saying is that we do do STAC, which *disables* SMAP.  We have
>> to do that because one pointer is known to be a user space pointer.
>> 
>> However, we currently don't verify that the *other* pointer is kernel
>> space, which it is supposed to be (if not, we should be using
>> copy_in_user).  We have to do this manually since we have to STAC which
>> means SMAP doesn't do anything at all.  I believe it would be a good
>> idea to add such checks (and they would even benefit non-SMAP hardware.)
> 
> Ah, ok, so we're on the same page.
> 
> And yep, Linus gave the probe_kernel_read() suggestion in another mail.
> 
i am not clear about what is STAC / SMAP ?
could you give me a link for understanding ?

Linus suggest to use probe_kernel_read() , but also said it is 
not efficient to use it, because we need copy the data 2 times by this method.

my patch suggests to use copy_in_user() ,
but seems not a generic(portable) function on all architectures.

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/

Re: [PATCH v3 1/1] USB:option:add ZTE PIDs

[Bjørn Mork]

Johan Hovold  writes:
> On Wed, Aug 19, 2015 at 08:51:17AM -0700, Liu.Zhao wrote:
>> 
>>  #define BENQ_VENDOR_ID  0x04a5
>>  #define BENQ_PRODUCT_H100x4068
>> @@ -544,6 +548,14 @@ static const struct option_blacklist_info 
>> zte_mc2716_z_blacklist = {
>>  .sendsetup = BIT(1) | BIT(2) | BIT(3),
>>  };
>>  
>> +static const struct option_blacklist_info zte_me3620andzm8620_xl_blacklist 
>> = {
>> +.reserved = BIT(3) | BIT(4) | BIT(5),
>> +};
>
> Use two structs for this: zte_me3620_blacklist and zm8620_xl_blacklist
> even if they reserve the same ports.

Why?  Wouldn't it be better to merge all identical lists and give them
structured names describing their contents instead?  E.g.

 static const struct option_blacklist_info bi_s0001_r = {
.sendsetup = BIT(0) | BIT(1),
 };

 static const struct option_blacklist_info bi_s0001_r04 = {
.sendsetup = BIT(0) | BIT(1),
.reserved = BIT(4),
 };

 static const struct option_blacklist_info bi_s_r030405 =  {
.reserved = BIT(3) | BIT(4) | BIT(5),
 };


etc.  Or some other naming scheme.

I don't see the point of having lots of identical structs just to be
able to name them after some rarely meaningful marketing name.  Many
vendors recycle their pids, making this completely futile.


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ubifs: Allow O_DIRECT

[Christoph Hellwig]

On Mon, Aug 24, 2015 at 10:13:25AM +0300, Artem Bityutskiy wrote:
> 1. we are the only FS erroring out on O_DIRECT
> 2. other file-systems not supporting direct IO just fake it

There are lots of file systems not supporting O_DIRECT, but ubifs might
be the most common one.  Given that O_DIRECT implementations aren't
hard, so what's holding back a real implementation?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] sched/nohz: Affine unpinned timers to housekeepers

[Mike Galbraith]

On Mon, 2015-08-24 at 09:41 +0200, Ingo Molnar wrote:
> * Mike Galbraith  wrote:
> 
> > On Mon, 2015-08-24 at 08:44 +0200, Ingo Molnar wrote:
> > 
> > > the 'housekeeping CPU' is essentially the boot CPU. Yet we dedicate a 
> > > full mask to 
> > > it (housekeeping_mask - a variable mask to begin with) and recover the 
> > > housekeeping CPU via:
> > > 
> > > +   return cpumask_any_and(housekeeping_mask, cpu_online_mask);
> > 
> > There can be, and had better be if box is big, multiple housekeepers.
> 
> Yes - but that does not seem to be possible via the code right now AFAICS, so 
> at 
> minimum it's incomplete.

In master housekeepers are set up in tick_nohz_init().  Everybody who's
not a nohz_full CPU is a housekeeper.

-Mike

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

Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device

[Ard Biesheuvel]

On 21 August 2015 at 05:47, Gabriel L. Somlo  wrote:
> On Thu, Aug 20, 2015 at 07:21:48AM +0200, Ard Biesheuvel wrote:
>> On 19 August 2015 at 22:49, Gabriel L. Somlo  wrote:
>> >> > From: "Gabriel L. Somlo" 
>> >> >> Several different architectures supported by QEMU are set up with a
>> >> >> "firmware configuration" (fw_cfg) device, used to pass configuration
>> >> >> "blobs" into the guest by the host running QEMU.
>> >> >>
>> >> >> Historically, these config blobs were mostly of interest to the guest
>> >> >> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
>> >> >> the command line, which makes them potentially interesting to userspace
>> >> >> (e.g. for passing early boot environment variables, etc.).
>> >> >>
>> >> >
>> >> > Does 'potentially interesting' mean you have a use case? Could you 
>> >> > elaborate?
>> >
>> > My personal one would be something like:
>> >
>> > cat > guestinfo.txt << EOT
>> >   KEY1="val1"
>> >   KEY2="val2"
>> >   ...
>> > EOT
>> >
>> > qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt 
>> > ...
>> >
>> > Then, from inside the guest:
>> >
>> >   . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
>> >
>> >   do_something_with $KEY1 $KEY2
>> >   ...
>> >
>> > But I'm thinking this is only one of the many positive things one
>> > could do with the ability to access random host-supplied blobs from
>> > guest userspace :)
>> >
>>
>> 'random host-supplied blobs' sounds awfully like files in a file
>> system to me, and that is already supported by QEMU and works with any
>> guest OS unmodified. If you are in control of the command line, surely
>> you can add a -drive xxx,fat:path/to/blobs -device xxx pair that
>> simply turns up as a volume.
>
> That did come up, here's the start of original thread on the qemu mailing
> list from a while back:
>
> https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg00371.html
>
> To recap, the main advantages to transfering data this way are:
>
> 1. Asynchronous
>
>The host can simply pass data via the qemu command line, and
>not have to care if/when the guest is ready to accept the
>data (i.e. has made it far enough to e.g. start a guest agent)
>

How does that not apply to a file system?

> 2. Out-of-band
>
>I don't have to take over a user-visible element such as a
>disk drive. Same reason VSOCK (or VMWare VMCI for that matter)
>exist and are NOT actual Ethernet/TCP-IP network interfaces :)
>

OK that makes sense. Note that I am not the one you need to convince
that this is a good idea, but I would still like to understand better
why your use case requires this. Could you explain?

-- 
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

[Javier Martinez Canillas]

Hello Mark,

On 08/21/2015 07:29 PM, Mark Brown wrote:
> On Fri, Aug 21, 2015 at 01:47:00AM +0200, Javier Martinez Canillas wrote:
>> On 08/21/2015 01:25 AM, Mark Brown wrote:
>>> On Thu, Aug 20, 2015 at 11:45:09PM +0200, Javier Martinez Canillas wrote:
> 
> IOW, it's labeled as such mostly for safety, since it has quite a few
> distributed dependencies.
> 
>>> Are there really only 17 drivers that are missing an explict of_table?
>>> That seems like a low number.
> 
>> In fact the 17 patches are the combination of the SPI drivers that:
> 
>> a) Have a .id_table but not a MODULE_DEVICE_TABLE(spi,...)
>> b) Have a .of_match_table but no a MODULE_DEVICE_TABLE(of,...)
>> c) Don't have a .of_match_table but have a DT binding document
> 
>> Maybe there are more SPI drivers out there that only have a .id_table
>> and don't have a .of_match_table nor a DT binding doc. But in that case
>> there isn't too much I can do since I've no information that these are
>> drivers are actually used in systems booted with OF.
> 
> We could at the very least scan through the in tree DTs.  There does
> seem to be a substantial overlap between systems that often don't use
> modular kernels but could and systems where people are using the I2C
> and SPI ID mapping shims.
> 

My script does this but didn't find any matches.

Basically what I do is for drivers with no OF table, to take the name field
from the spi_device_id in the SPI id table and see if one of these are used
as a compatible string either in a DTS or mentioned in a DT binding.

I found some matches in DT bindings which are the type c) issue but none
used in an in tree DTS.

But that doesn't mean that there could be drivers with no OF table, no DT
binding and with out-of-tree DTS that are using compatible = "bar" instead
compatible = "foo,bar" and relying on SPI matching using the SPI device id
table as a fallback. But I guess these should be fixed for module autoload.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] sched/nohz: Affine unpinned timers to housekeepers

[Ingo Molnar]

* Mike Galbraith  wrote:

> On Mon, 2015-08-24 at 09:41 +0200, Ingo Molnar wrote:
> > * Mike Galbraith  wrote:
> > 
> > > On Mon, 2015-08-24 at 08:44 +0200, Ingo Molnar wrote:
> > > 
> > > > the 'housekeeping CPU' is essentially the boot CPU. Yet we dedicate a 
> > > > full mask to 
> > > > it (housekeeping_mask - a variable mask to begin with) and recover the 
> > > > housekeeping CPU via:
> > > > 
> > > > +   return cpumask_any_and(housekeeping_mask, cpu_online_mask);
> > > 
> > > There can be, and had better be if box is big, multiple housekeepers.
> > 
> > Yes - but that does not seem to be possible via the code right now AFAICS, 
> > so 
> > at minimum it's incomplete.
> 
> In master housekeepers are set up in tick_nohz_init().  Everybody who's not a 
> nohz_full CPU is a housekeeper.

Ah, indeed, I missed the nohz_full= boot option:

static int __init tick_nohz_full_setup(char *str)
{
alloc_bootmem_cpumask_var(_nohz_full_mask);
if (cpulist_parse(str, tick_nohz_full_mask) < 0) {


Ok, first question is resolved - but the second one, behavior on boot CPU 
unplug 
still holds.

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 2/2] ubifs: Allow O_DIRECT

[Artem Bityutskiy]

On Mon, 2015-08-24 at 00:53 -0700, Christoph Hellwig wrote:
> On Mon, Aug 24, 2015 at 10:13:25AM +0300, Artem Bityutskiy wrote:
> > 1. we are the only FS erroring out on O_DIRECT
> > 2. other file-systems not supporting direct IO just fake it
> 
> There are lots of file systems not supporting O_DIRECT, but ubifs
> might
> be the most common one.  Given that O_DIRECT implementations aren't
> hard, so what's holding back a real implementation?

Back when we were writing UBIFS, we did not need direct IO, so we did
not implement it. But yes, probably someone who cares could just try
implementing this feature.

Artem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] Add support for Exynos SROM Controller driver

[Pankaj Dubey]

This patch set adds support for Exynos SROM controller DT based driver.
Currently SROM register sets are used only during S2R, so driver
basically added for taking care of S2R. It will help us in removing
static mapping from exynos.c and other extra code handline during S2R.

This patch set also updated exynos4 and exynos5 dtsi files for with device
node for srom, and added binding documentation for the same.

First two patches are some minor cleanup in mach-exynos.

Patchset v1 was posted here[1]
[1]: https://lkml.org/lkml/2015/4/29/98

Changes since v1:
 - Rebased to latest kgene tree.
 - Addressed review comments from Krzysztof Kozlowski.
 - Add two new patches for minor cleanup in exynos.c and map.h

Pankaj Dubey (7):
  ARM: EXYNOS: remove unused static mapping of CMU for exynos5
  ARM: EXYNOS: code cleanup in map.h
  drivers: soc: add support for exynos SROM driver
  ARM: EXYNOS: Remove SROM related register settings from mach-exynos
  ARM: dts: add SROM device node for exynos4
  ARM: dts: add SROM device node for exynos5
  Documentation: dt-bindings: add exynos-srom binding information

 .../bindings/arm/samsung/exynos-srom.txt   |  12 ++
 arch/arm/boot/dts/exynos4.dtsi |   5 +
 arch/arm/boot/dts/exynos5.dtsi |   5 +
 arch/arm/mach-exynos/Kconfig   |   2 +
 arch/arm/mach-exynos/common.h  |   2 -
 arch/arm/mach-exynos/exynos.c  |  22 
 arch/arm/mach-exynos/include/mach/map.h|   8 --
 arch/arm/mach-exynos/regs-srom.h   |  53 
 arch/arm/mach-exynos/suspend.c |  20 +--
 arch/arm/plat-samsung/include/plat/map-s5p.h   |   1 -
 drivers/soc/Kconfig|   1 +
 drivers/soc/Makefile   |   1 +
 drivers/soc/samsung/Kconfig|  13 ++
 drivers/soc/samsung/Makefile   |   1 +
 drivers/soc/samsung/exynos-srom.c  | 143 +
 drivers/soc/samsung/exynos-srom.h  |  51 
 16 files changed, 236 insertions(+), 104 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
 delete mode 100644 arch/arm/mach-exynos/regs-srom.h
 create mode 100644 drivers/soc/samsung/Kconfig
 create mode 100644 drivers/soc/samsung/Makefile
 create mode 100644 drivers/soc/samsung/exynos-srom.c
 create mode 100644 drivers/soc/samsung/exynos-srom.h

-- 
2.4.5

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

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

[Christoph Hellwig]

On Mon, Aug 24, 2015 at 11:02:42AM +0300, Artem Bityutskiy wrote:
> Back when we were writing UBIFS, we did not need direct IO, so we did
> not implement it. But yes, probably someone who cares could just try
> implementing this feature.

So I think the answer here is to implement a real version insted of
adding hacks to pretend it is supported.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] ARM: EXYNOS: remove unused static mapping of CMU for exynos5

[Pankaj Dubey]

Remove unused static mapping of exynos5 CMU and related code.

Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-exynos/exynos.c   | 5 -
 arch/arm/mach-exynos/include/mach/map.h | 1 -
 2 files changed, 6 deletions(-)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 1c47aee..524aa6f 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -70,11 +70,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_SROMC),
.length = SZ_4K,
.type   = MT_DEVICE,
-   }, {
-   .virtual= (unsigned long)S5P_VA_CMU,
-   .pfn= __phys_to_pfn(EXYNOS5_PA_CMU),
-   .length = 144 * SZ_1K,
-   .type   = MT_DEVICE,
},
 };
 
diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index de3ae59..a2acba3 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -25,7 +25,6 @@
 #define EXYNOS_PA_CHIPID   0x1000
 
 #define EXYNOS4_PA_CMU 0x1003
-#define EXYNOS5_PA_CMU 0x1001
 
 #define EXYNOS4_PA_DMC00x1040
 #define EXYNOS4_PA_DMC10x1041
-- 
2.4.5

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

[PATCH v2 2/7] ARM: EXYNOS: code cleanup in map.h

[Pankaj Dubey]

Remove unused exynos5440 uart offset macro.

Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-exynos/include/mach/map.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index a2acba3..86d8085 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -35,8 +35,4 @@
 #define EXYNOS4_PA_SROMC   0x1257
 #define EXYNOS5_PA_SROMC   0x1225
 
-/* Compatibility UART */
-
-#define EXYNOS5440_PA_UART00x000B
-
 #endif /* __ASM_ARCH_MAP_H */
-- 
2.4.5

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

[PATCH v2 3/7] drivers: soc: add support for exynos SROM driver

[Pankaj Dubey]

This patch adds Exynos SROM controller driver which will handle
save restore of SROM registers during S2R.

Signed-off-by: Pankaj Dubey 
---
 drivers/soc/Kconfig   |   1 +
 drivers/soc/Makefile  |   1 +
 drivers/soc/samsung/Kconfig   |  13 
 drivers/soc/samsung/Makefile  |   1 +
 drivers/soc/samsung/exynos-srom.c | 143 ++
 drivers/soc/samsung/exynos-srom.h |  51 ++
 6 files changed, 210 insertions(+)
 create mode 100644 drivers/soc/samsung/Kconfig
 create mode 100644 drivers/soc/samsung/Makefile
 create mode 100644 drivers/soc/samsung/exynos-srom.c
 create mode 100644 drivers/soc/samsung/exynos-srom.h

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 96ddecb..69107c9 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
 
 source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/samsung/Kconfig"
 source "drivers/soc/sunxi/Kconfig"
 source "drivers/soc/ti/Kconfig"
 source "drivers/soc/versatile/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 7dc7c0d..34c4398 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
 obj-$(CONFIG_ARCH_QCOM)+= qcom/
+obj-$(CONFIG_SOC_SAMSUNG)  += samsung/
 obj-$(CONFIG_ARCH_SUNXI)   += sunxi/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
 obj-$(CONFIG_SOC_TI)   += ti/
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
new file mode 100644
index 000..ea4bc2a
--- /dev/null
+++ b/drivers/soc/samsung/Kconfig
@@ -0,0 +1,13 @@
+#
+# SAMSUNG SoC drivers
+#
+menu "Samsung SOC driver support"
+
+config SOC_SAMSUNG
+   bool
+
+config EXYNOS_SROM
+   bool
+   depends on ARM && ARCH_EXYNOS
+
+endmenu
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
new file mode 100644
index 000..9c554d5
--- /dev/null
+++ b/drivers/soc/samsung/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EXYNOS_SROM)  += exynos-srom.o
diff --git a/drivers/soc/samsung/exynos-srom.c 
b/drivers/soc/samsung/exynos-srom.c
new file mode 100644
index 000..d7c4aa7
--- /dev/null
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -0,0 +1,143 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ *   http://www.samsung.com/
+ *
+ * EXYNOS - SROM Controller support
+ * Author: Pankaj Dubey 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "exynos-srom.h"
+
+static void __iomem *exynos_srom_base;
+
+static const unsigned long exynos_srom_offsets[] = {
+   /* SROM side */
+   EXYNOS_SROM_BW,
+   EXYNOS_SROM_BC0,
+   EXYNOS_SROM_BC1,
+   EXYNOS_SROM_BC2,
+   EXYNOS_SROM_BC3,
+};
+
+/**
+ * struct exynos_srom_reg_dump: register dump of SROM Controller registers.
+ * @offset: srom register offset from the controller base address.
+ * @value: the value of register under the offset.
+ */
+struct exynos_srom_reg_dump {
+   u32 offset;
+   u32 value;
+};
+
+static struct exynos_srom_reg_dump *exynos_srom_regs;
+
+static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump(
+   const unsigned long *rdump,
+   unsigned long nr_rdump)
+{
+   struct exynos_srom_reg_dump *rd;
+   unsigned int i;
+
+   rd = kcalloc(nr_rdump, sizeof(*rd), GFP_KERNEL);
+   if (!rd)
+   return NULL;
+
+   for (i = 0; i < nr_rdump; ++i)
+   rd[i].offset = rdump[i];
+
+   return rd;
+}
+
+static const struct of_device_id of_exynos_srom_ids[] = {
+   {
+   .compatible = "samsung,exynos-srom",
+   },
+   {},
+};
+
+static int exynos_srom_probe(struct platform_device *pdev)
+{
+   struct device_node *np;
+   struct device *dev = >dev;
+
+   np = dev->of_node;
+   exynos_srom_base = of_iomap(np, 0);
+
+   if (!exynos_srom_base) {
+   pr_err("iomap of exynos srom controller failed\n");
+   return -ENOMEM;
+   }
+
+   exynos_srom_regs = exynos_srom_alloc_reg_dump(exynos_srom_offsets,
+   sizeof(exynos_srom_offsets));
+
+   if (!exynos_srom_regs) {
+   iounmap(exynos_srom_regs);
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static void exynos_srom_save(void __iomem *base,
+   struct exynos_srom_reg_dump *rd,
+   unsigned int num_regs)
+{
+   for (; num_regs > 0; --num_regs, ++rd)
+   rd->value = readl(base + rd->offset);
+
+}
+
+static void exynos_srom_restore(void __iomem *base,
+ 

[PATCH v2 4/7] ARM: EXYNOS: Remove SROM related register settings from mach-exynos

[Pankaj Dubey]

As now we have dedicated driver for SROM controller, it will take care
of saving register banks during S2R so we can safely remove these
settings from mach-exynos.

Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-exynos/Kconfig |  2 ++
 arch/arm/mach-exynos/common.h|  2 --
 arch/arm/mach-exynos/exynos.c| 17 -
 arch/arm/mach-exynos/include/mach/map.h  |  3 --
 arch/arm/mach-exynos/regs-srom.h | 53 
 arch/arm/mach-exynos/suspend.c   | 20 ++-
 arch/arm/plat-samsung/include/plat/map-s5p.h |  1 -
 7 files changed, 4 insertions(+), 94 deletions(-)
 delete mode 100644 arch/arm/mach-exynos/regs-srom.h

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 3a10f1a..7c917ef 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -27,6 +27,8 @@ menuconfig ARCH_EXYNOS
select SRAM
select THERMAL
select MFD_SYSCON
+   select SOC_SAMSUNG
+   select EXYNOS_SROM
help
  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
 
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 1534925..1c04741 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -108,8 +108,6 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, 
EXYNOS5_SOC_MASK)
 
 #define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \
  soc_is_exynos4412())
-#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410() || \
- soc_is_exynos5420() || soc_is_exynos5800())
 
 extern u32 cp15_save_diag;
 extern u32 cp15_save_power;
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 524aa6f..4ffb90e 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -37,11 +37,6 @@ void __iomem *pmu_base_addr;
 
 static struct map_desc exynos4_iodesc[] __initdata = {
{
-   .virtual= (unsigned long)S5P_VA_SROMC,
-   .pfn= __phys_to_pfn(EXYNOS4_PA_SROMC),
-   .length = SZ_4K,
-   .type   = MT_DEVICE,
-   }, {
.virtual= (unsigned long)S5P_VA_CMU,
.pfn= __phys_to_pfn(EXYNOS4_PA_CMU),
.length = SZ_128K,
@@ -64,15 +59,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
},
 };
 
-static struct map_desc exynos5_iodesc[] __initdata = {
-   {
-   .virtual= (unsigned long)S5P_VA_SROMC,
-   .pfn= __phys_to_pfn(EXYNOS5_PA_SROMC),
-   .length = SZ_4K,
-   .type   = MT_DEVICE,
-   },
-};
-
 static struct platform_device exynos_cpuidle = {
.name  = "exynos_cpuidle",
 #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
@@ -144,9 +130,6 @@ static void __init exynos_map_io(void)
 {
if (soc_is_exynos4())
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-
-   if (soc_is_exynos5())
-   iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
 }
 
 static void __init exynos_init_io(void)
diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index 86d8085..351e839 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -32,7 +32,4 @@
 #define EXYNOS4_PA_COREPERI0x1050
 #define EXYNOS4_PA_L2CC0x10502000
 
-#define EXYNOS4_PA_SROMC   0x1257
-#define EXYNOS5_PA_SROMC   0x1225
-
 #endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-exynos/regs-srom.h b/arch/arm/mach-exynos/regs-srom.h
deleted file mode 100644
index 5c4d442..000
--- a/arch/arm/mach-exynos/regs-srom.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * Copyright (c) 2010 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * S5P SROMC register definitions
- *
- * 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.
-*/
-
-#ifndef __PLAT_SAMSUNG_REGS_SROM_H
-#define __PLAT_SAMSUNG_REGS_SROM_H __FILE__
-
-#include 
-
-#define S5P_SROMREG(x) (S5P_VA_SROMC + (x))
-
-#define S5P_SROM_BWS5P_SROMREG(0x0)
-#define S5P_SROM_BC0   S5P_SROMREG(0x4)
-#define S5P_SROM_BC1   S5P_SROMREG(0x8)
-#define S5P_SROM_BC2   S5P_SROMREG(0xc)
-#define S5P_SROM_BC3   S5P_SROMREG(0x10)
-#define S5P_SROM_BC4   S5P_SROMREG(0x14)
-#define S5P_SROM_BC5   S5P_SROMREG(0x18)
-
-/* one register BW holds 4 x 4-bit packed settings for NCS0 - NCS3 */
-
-#define S5P_SROM_BW__DATAWIDTH__SHIFT  0
-#define S5P_SROM_BW__ADDRMODE__SHIFT   1
-#define S5P_SROM_BW__WAITENABLE__SHIFT 2
-#define 

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

[Christoph Hellwig]

On Mon, Aug 24, 2015 at 03:17:10PM +0800, Dongsheng Yang wrote:
> >Richard, you mention this was suggested by Dave, could you please pint
> >to the discussion, if possible?
> 
> http://lists.infradead.org/pipermail/linux-mtd/2015-August/060702.html
> 
> That's in a discussion I want to introduce ubifs into xfstests.

FYI, xfstests is a test suite, _not_ an application.  Adding O_DIRECT
just for xfstests is utterly dumb and suggeting that is even dumber.

xfstests should check for supported features, and skip tests that use
it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ubifs: Allow O_DIRECT

[Dongsheng Yang]

On 08/24/2015 04:03 PM, Christoph Hellwig wrote:

On Mon, Aug 24, 2015 at 11:02:42AM +0300, Artem Bityutskiy wrote:

Back when we were writing UBIFS, we did not need direct IO, so we did
not implement it. But yes, probably someone who cares could just try
implementing this feature.


So I think the answer here is to implement a real version insted of
adding hacks to pretend it is supported.


Actually, I had a plan for it. But it's for 4.4 or 4.5 in my plan.

Yang

.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] ARM: dts: add SROM device node for exynos4

[Pankaj Dubey]

Add device node of SROM controller for exynos4.

CC: Rob Herring 
CC: Mark Rutland 
CC: Ian Campbell 
Signed-off-by: Pankaj Dubey 
---
 arch/arm/boot/dts/exynos4.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 98c0a36..b0732d7 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -76,6 +76,11 @@
reg = <0x1000 0x100>;
};
 
+   sromc@1257 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1257 0x10>;
+   };
+
mipi_phy: video-phy@10020710 {
compatible = "samsung,s5pv210-mipi-video-phy";
#phy-cells = <1>;
-- 
2.4.5

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