[PATCH 1/2] perf: fix build error on MUSL libc

2020-12-10 Thread Chanho Park 
__always_inline can cause build error on musl libc. The fix patch has
submitted but not merged yet[1]. To build perf tool with musl libc,
 inclusion is necessary and it should be included before
asm/byteorder.h.

from /usr/include/linux/byteorder/little_endian.h:13,
from /usr/include/asm/byteorder.h:23,
from tools/include/uapi/linux/perf_event.h:20,
from arch/arm64/util/../../arm/util/pmu.c:9:

/usr/include/linux/swab.h:171:8: error: unknown type name '__always_inline'
  171 | static __always_inline __u16 __swab16p(const __u16 *p)
  |^~~

[1]: https://lkml.org/lkml/2018/9/13/78
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Cc: Mike Leach 
Cc: Leo Yan 
Cc: John Garry 
Cc: Will Deacon 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Mark Rutland 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Khem Raj 
Signed-off-by: Chanho Park 
---
 include/uapi/linux/perf_event.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index bb7b271397a6..af5e80dc7d54 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -17,6 +17,9 @@
 
 #include 
 #include 
+#if !defined(__GLIBC__)
+#include 
+#endif
 #include 
 
 /*
-- 
2.23.0

[PATCH 0/2] fix perf tool build error on MUSL libc

2020-12-10 Thread Chanho Park 
__always_inline can cause build error on musl libc because it's not
defined. We need to include  before asm/byteorder.h.
tools/include/uapi/linux/perf_event.h is copied version from
include/uapi/linux/perf_event.h. To fix this, we need to apply this
change both header files.

Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Cc: Mike Leach 
Cc: Leo Yan 
Cc: John Garry 
Cc: Will Deacon 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Mark Rutland 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Khem Raj 

Chanho Park (2):
  perf: fix build error on MUSL libc
  perf: tool: fix build error on MUSL libc

 include/uapi/linux/perf_event.h   | 3 +++
 tools/include/uapi/linux/perf_event.h | 3 +++
 2 files changed, 6 insertions(+)

-- 
2.23.0

[PATCH 2/2] perf: tool: fix build error on MUSL libc

2020-12-10 Thread Chanho Park 
__always_inline can cause build error on musl libc. The fix patch has
submitted but not merged yet[1]. To build perf tool with musl libc,
 inclusion is necessary and it should be included before
asm/byteorder.h.

from /usr/include/linux/byteorder/little_endian.h:13,
from /usr/include/asm/byteorder.h:23,
from tools/include/uapi/linux/perf_event.h:20,
from arch/arm64/util/../../arm/util/pmu.c:9:

/usr/include/linux/swab.h:171:8: error: unknown type name '__always_inline'
  171 | static __always_inline __u16 __swab16p(const __u16 *p)
  |^~~

[1]: https://lkml.org/lkml/2018/9/13/78
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Cc: Mike Leach 
Cc: Leo Yan 
Cc: John Garry 
Cc: Will Deacon 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Mark Rutland 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Khem Raj 
Signed-off-by: Chanho Park 
---
 tools/include/uapi/linux/perf_event.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/include/uapi/linux/perf_event.h 
b/tools/include/uapi/linux/perf_event.h
index bb7b271397a6..af5e80dc7d54 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -17,6 +17,9 @@
 
 #include 
 #include 
+#if !defined(__GLIBC__)
+#include 
+#endif
 #include 
 
 /*
-- 
2.23.0

RE: [PATCH] perf arm pmu: fix build error on MUSL libc

2020-12-08 Thread Chanho Park 
Hi Namhyung and Jiri,

> -Original Message-
> From: Jiri Olsa 
> Sent: Monday, December 7, 2020 10:29 PM
> To: Namhyung Kim 
> Cc: Chanho Park ; Will Deacon
;
> Chanho Park ; mathieu.poir...@linaro.org;
> suzuki.poul...@arm.com; coresi...@lists.linaro.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel ;
> Mike Leach ; Leo Yan ; John
> Garry ; Peter Zijlstra ; Ingo
> Molnar ; Arnaldo Carvalho de Melo ;
> Mark Rutland ; Khem Raj 
> Subject: Re: [PATCH] perf arm pmu: fix build error on MUSL libc
> 
> On Mon, Dec 07, 2020 at 09:31:06PM +0900, Namhyung Kim wrote:
> > Hi Chanho,
> >
> > On Mon, Dec 7, 2020 at 8:58 PM Chanho Park 
> wrote:
> > >
> > > Hi Will,
> > >
> > > > Looks like other files just include this unconditionally, but have
> > > > a comment explaining why. See util/branch.h and util/event.h.
> > > > Maybe we should do the same for util/pmu.h, which is already
> included here?
> > >
> > > I found below files which perf includes .
> > > Instead of doing same for all, we'd better put this only for
> > > tools/include/uapi/linux/perf_event.h.
> >
> > It's a copy of the kernel header, I'm not sure we want to add something
> there.
> 
> right, we want to copy that directly from kernel uapi so let's not do any
> changes in here
> 

I tried to modify it from include/uapi/linux/perf_event.h but it didn't
work. And then, I found perf tool tried to refer the header from
tools/include/ directory. I should go include/uapi first and sync the change
to tools/ directory. I'll re-spin this patch.

Best Regard,
Chanho Park

RE: [PATCH] perf arm pmu: fix build error on MUSL libc

2020-12-07 Thread Chanho Park 
Hi Will,
 
> Looks like other files just include this unconditionally, but have a
> comment explaining why. See util/branch.h and util/event.h. Maybe we
> should do the same for util/pmu.h, which is already included here?

I found below files which perf includes . Instead of
doing same for all, we'd better put this only for
tools/include/uapi/linux/perf_event.h.

--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -17,6 +17,9 @@
 
 #include 
 #include 
+#if !defined(__GLIBC__)
+#include 
+#endif
 #include 
 
 /*

tools/perf/arch/arm/util/pmu.c:#include 
tools/perf/arch/x86/util/pmu.c:#include 
tools/perf/arch/x86/util/tsc.c:#include 
tools/perf/lib/include/internal/evsel.h:#include 
tools/perf/lib/include/perf/event.h:#include 
tools/perf/lib/tests/test-evlist.c:#include 
tools/perf/lib/tests/test-evsel.c:#include 
tools/perf/tests/hists_common.c:#include 
tools/perf/util/auxtrace.c:#include 
tools/perf/util/auxtrace.h:#include 
tools/perf/util/branch.h:#include 
tools/perf/util/event.c:#include 
tools/perf/util/evsel.c:#include 
tools/perf/util/evsel.h:#include 
tools/perf/util/header.h:#include 
tools/perf/util/mem-events.h:#include 
tools/perf/util/namespaces.h:#include 
tools/perf/util/record.h:#include 
tools/perf/util/session.h:#include 
tools/perf/util/pmu.h:#include 
tools/perf/util/synthetic-events.c:#include 
tools/perf/util/parse-events.h:#include 
tools/perf/util/perf_event_attr_fprintf.c:#include 

Best Regards,
Chanho Park

[PATCH] perf arm pmu: fix build error on MUSL libc

2020-12-06 Thread Chanho Park 
__always_inline can cause build error on musl libc. The fix patch has
submitted but not merged yet[1]. To build perf tool with musl libc,
 inclusion is necessary and it should be included before
perf_event.h.

from /usr/include/linux/byteorder/little_endian.h:13,
from /usr/include/asm/byteorder.h:23,
from tools/include/uapi/linux/perf_event.h:20,
from arch/arm64/util/../../arm/util/pmu.c:9:

/usr/include/linux/swab.h:171:8: error: unknown type name '__always_inline'
  171 | static __always_inline __u16 __swab16p(const __u16 *p)
  |^~~

[1]: https://lkml.org/lkml/2018/9/13/78
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Cc: Mike Leach 
Cc: Leo Yan 
Cc: John Garry 
Cc: Will Deacon 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Mark Rutland 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Khem Raj 
Signed-off-by: Chanho Park 
---
 tools/perf/arch/arm/util/pmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/arch/arm/util/pmu.c b/tools/perf/arch/arm/util/pmu.c
index bbc297a7e2e3..4c0357e8c0ab 100644
--- a/tools/perf/arch/arm/util/pmu.c
+++ b/tools/perf/arch/arm/util/pmu.c
@@ -6,6 +6,9 @@
 
 #include 
 #include 
+#if !defined(__GLIBC__)
+#include 
+#endif
 #include 
 #include 
 
-- 
2.23.0

[PATCH] drivers core: export symbols for device hotplug

2020-11-26 Thread Chanho Park 
To support module build for cpu hotplug driver on type-1 hypervisor
such as drivers/xen/cpu_hotplug.c, we need to export below four symbols.

lock_device_hotplug / unlock_device_hotplug
device_online / device_offline

Signed-off-by: Chanho Park 
---
 drivers/base/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index d661ada1518f..1bfd0c54a778 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1586,11 +1586,13 @@ void lock_device_hotplug(void)
 {
mutex_lock(_hotplug_lock);
 }
+EXPORT_SYMBOL_GPL(lock_device_hotplug);
 
 void unlock_device_hotplug(void)
 {
mutex_unlock(_hotplug_lock);
 }
+EXPORT_SYMBOL_GPL(unlock_device_hotplug);
 
 int lock_device_hotplug_sysfs(void)
 {
@@ -3419,6 +3421,7 @@ int device_offline(struct device *dev)
 
return ret;
 }
+EXPORT_SYMBOL_GPL(device_offline);
 
 /**
  * device_online - Put the device back online after successful 
device_offline().
@@ -3450,6 +3453,7 @@ int device_online(struct device *dev)
 
return ret;
 }
+EXPORT_SYMBOL_GPL(device_online);
 
 struct root_device {
struct device dev;
-- 
2.23.0

RE: [PATCH] scsi: ufs: make sure scan sequence for multiple hosts

2020-10-26 Thread Chanho Park 
> In case you'll convince Bart that this code is needed, maybe use a IDA
> handle for that?

Thanks for your suggestion.
IDA is useful to maintain unique IDs with bitmap structure but the patch 
assumes host_no is the unique number and can be used in the bitmap for making 
sequential order.

Best Regards,
Chanho Park

RE: [PATCH] scsi: ufs: make sure scan sequence for multiple hosts

2020-10-21 Thread Chanho Park 
> > Did you mean /dev/disk/by-[part]label/ symlink? It's quite reasonable to
> > use them by udev in userspace such as initramfs but some cases does not
> use
> > initramfs or initrd. In that case, we need to load the root
> > device(/dev/sda[N]) directly from kernel.
> 
> Please use udev or systemd instead of adding code in the UFS driver that
> is
> not necessary when udev or systemd is used.
>

What I mentioned was how it can be handled when we mount rootfs directly from 
kernel.

1) kernel -> initramfs (mount root) -> systemd
2) kernel (mount root) -> systemd
 -> In this case, we normally use root=/dev/sda1 from kernel commandline to 
mount the rootfs.

Like fstab can support legacy node mount, ufs driver also needs to provide an 
option for using the permanent legacy node. If you're really worry about adding 
a new codes for all UFS driver, we can put this as controller specific or 
optional feature.

Best Regards,
Chanho Park

[PATCH] scsi: ufs: make sure scan sequence for multiple hosts

2020-10-20 Thread Chanho Park 
By doing scan as asynchronous way, scsi device scannning can be out of
order execution. It is no problem if there is a ufs host but the scsi
device name of each host can be changed according to the scan sequences.

Ideal Case) host0 scan first
host0 will be started from /dev/sda
 -> /dev/sdb (BootLUN0 of host0)
 -> /dev/sdc (BootLUN1 of host1)
host1 will be started from /dev/sdd

This might be an ideal case and we can easily find the host device by
this mappinng.

However, Abnormal Case) host1 scan first,
host1 will be started from /dev/sda and host0 will be followed later.

To make sure the scan sequences according to the host, we can use a
bitmap which hosts are scanned and wait until previous hosts are
finished to scan.

Signed-off-by: Chanho Park 
---
 drivers/scsi/ufs/ufshcd.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b8f573a02713..1ced5996e988 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -214,6 +215,10 @@ static struct ufs_dev_fix ufs_fixups[] = {
END_FIX
 };
 
+/* Ordered scan host */
+static unsigned long scanned_hosts = 0;
+static wait_queue_head_t scan_wq = __WAIT_QUEUE_HEAD_INITIALIZER(scan_wq);
+
 static irqreturn_t ufshcd_tmc_handler(struct ufs_hba *hba);
 static void ufshcd_async_scan(void *data, async_cookie_t cookie);
 static int ufshcd_reset_and_restore(struct ufs_hba *hba);
@@ -7709,8 +7714,13 @@ static void ufshcd_async_scan(void *data, async_cookie_t 
cookie)
if (ret)
goto out;
 
-   /* Probe and add UFS logical units  */
+   /* Probe and add UFS logical units. Sequential scan by host_no */
+   wait_event(scan_wq,
+  find_first_zero_bit(_hosts, hba->host->max_id) ==
+  hba->host->host_no);
ret = ufshcd_add_lus(hba);
+   set_bit(hba->host->host_no, _hosts);
+   wake_up(_wq);
 out:
/*
 * If we failed to initialize the device or the device is not
-- 
2.28.0

[PATCH] scsi: ufs: make sure scan sequence for multiple hosts

2020-10-20 Thread Chanho Park 
By doing scan as asynchronous way, scsi device scannning can be out of
order execution. It is no problem if there is a ufs host but the scsi
device name of each host can be changed according to the scan sequences.

Ideal Case) host0 scan first
host0 will be started from /dev/sda
 -> /dev/sdb (BootLUN0 of host0)
 -> /dev/sdc (BootLUN1 of host1)
host1 will be started from /dev/sdd

This might be an ideal case and we can easily find the host device by
this mappinng.

However, Abnormal Case) host1 scan first,
host1 will be started from /dev/sda and host0 will be followed later.

To make sure the scan sequences according to the host, we can use a
bitmap which hosts are scanned and wait until previous hosts are
finished to scan.

Signed-off-by: Chanho Park 
---
 drivers/scsi/ufs/ufshcd.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b8f573a02713..1ced5996e988 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -214,6 +215,10 @@ static struct ufs_dev_fix ufs_fixups[] = {
END_FIX
 };
 
+/* Ordered scan host */
+static unsigned long scanned_hosts = 0;
+static wait_queue_head_t scan_wq = __WAIT_QUEUE_HEAD_INITIALIZER(scan_wq);
+
 static irqreturn_t ufshcd_tmc_handler(struct ufs_hba *hba);
 static void ufshcd_async_scan(void *data, async_cookie_t cookie);
 static int ufshcd_reset_and_restore(struct ufs_hba *hba);
@@ -7709,8 +7714,13 @@ static void ufshcd_async_scan(void *data, async_cookie_t 
cookie)
if (ret)
goto out;
 
-   /* Probe and add UFS logical units  */
+   /* Probe and add UFS logical units. Sequential scan by host_no */
+   wait_event(scan_wq,
+  find_first_zero_bit(_hosts, hba->host->max_id) ==
+  hba->host->host_no);
ret = ufshcd_add_lus(hba);
+   set_bit(hba->host->host_no, _hosts);
+   wake_up(_wq);
 out:
/*
 * If we failed to initialize the device or the device is not
-- 
2.28.0

[PATCH] tty: do not set TTY_IO_ERROR flag if console port

2018-11-22 Thread Chanho Park 
Since Commit 761ed4a94582 ('tty: serial_core: convert uart_close to use
tty_port_close') and Commit 4dda864d7307 ('tty: serial_core: Fix serial
console crash on port shutdown), a serial port which is used as
console can be stuck when logging out if there is a remained process.
After logged out, agetty will try to grab the serial port but it will
be failed because the previous process did not release the port
correctly. To fix this, TTY_IO_ERROR bit should not be enabled of
tty_port_close if the port is console port.

Reproduce step:
- Run background processes from serial console
$ while true; do sleep 10; done &

- Log out
$ logout
-> Stuck

- Read journal log by journalctl | tail
Jan 28 16:07:01 ubuntu systemd[1]: Stopped Serial Getty on ttyAMA0.
Jan 28 16:07:01 ubuntu systemd[1]: Started Serial Getty on ttyAMA0.
Jan 28 16:07:02 ubuntu agetty[1643]: /dev/ttyAMA0: not a tty

Fixes: 761ed4a94582ab29 ("tty: serial_core: convert uart_close to use 
tty_port_close")

Cc: Geert Uytterhoeven 
Cc: Rob Herring 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Chanho Park 
---
 drivers/tty/tty_port.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index cb60750..044c3cb 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -633,7 +633,8 @@ void tty_port_close(struct tty_port *port, struct 
tty_struct *tty,
if (tty_port_close_start(port, tty, filp) == 0)
return;
tty_port_shutdown(port, tty);
-   set_bit(TTY_IO_ERROR, >flags);
+   if (!port->console)
+   set_bit(TTY_IO_ERROR, >flags);
tty_port_close_end(port, tty);
tty_port_tty_set(port, NULL);
 }
-- 
1.9.1

[PATCH] tty: do not set TTY_IO_ERROR flag if console port

2018-11-22 Thread Chanho Park 
Since Commit 761ed4a94582 ('tty: serial_core: convert uart_close to use
tty_port_close') and Commit 4dda864d7307 ('tty: serial_core: Fix serial
console crash on port shutdown), a serial port which is used as
console can be stuck when logging out if there is a remained process.
After logged out, agetty will try to grab the serial port but it will
be failed because the previous process did not release the port
correctly. To fix this, TTY_IO_ERROR bit should not be enabled of
tty_port_close if the port is console port.

Reproduce step:
- Run background processes from serial console
$ while true; do sleep 10; done &

- Log out
$ logout
-> Stuck

- Read journal log by journalctl | tail
Jan 28 16:07:01 ubuntu systemd[1]: Stopped Serial Getty on ttyAMA0.
Jan 28 16:07:01 ubuntu systemd[1]: Started Serial Getty on ttyAMA0.
Jan 28 16:07:02 ubuntu agetty[1643]: /dev/ttyAMA0: not a tty

Fixes: 761ed4a94582ab29 ("tty: serial_core: convert uart_close to use 
tty_port_close")

Cc: Geert Uytterhoeven 
Cc: Rob Herring 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Chanho Park 
---
 drivers/tty/tty_port.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index cb60750..044c3cb 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -633,7 +633,8 @@ void tty_port_close(struct tty_port *port, struct 
tty_struct *tty,
if (tty_port_close_start(port, tty, filp) == 0)
return;
tty_port_shutdown(port, tty);
-   set_bit(TTY_IO_ERROR, >flags);
+   if (!port->console)
+   set_bit(TTY_IO_ERROR, >flags);
tty_port_close_end(port, tty);
tty_port_tty_set(port, NULL);
 }
-- 
1.9.1

Re: [PATCH] ARM: dts: Make CPU configuration more readable for exynos542x/5800

2015-12-17 Thread Chanho Park 
ol-port = <_control1>;
> -};
> +   cpu3: cpu@103 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a7";
> +   reg = <0x103>;
> +   clock-frequency = <10>;
> +   cci-control-port = <_control0>;
> +   };
>
> - {
> -   device_type = "cpu";
> -   compatible = "arm,cortex-a15";
> -   reg = <0x1>;
> -   clock-frequency = <18>;
> -   cci-control-port = <_control1>;
> -};
> +   cpu4: cpu@0 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a15";
> +   reg = <0x0>;
> +   clock-frequency = <18>;
> +   cci-control-port = <_control1>;
> +   };
>
> - {
> -   device_type = "cpu";
> -   compatible = "arm,cortex-a15";
> -   reg = <0x2>;
> -   clock-frequency = <18>;
> -   cci-control-port = <_control1>;
> -};
> +   cpu5: cpu@1 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a15";
> +   reg = <0x1>;
> +   clock-frequency = <18>;
> +   cci-control-port = <_control1>;
> +   };
> +
> +   cpu6: cpu@2 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a15";
> +   reg = <0x2>;
> +   clock-frequency = <18>;
> +   cci-control-port = <_control1>;
> +   };
>
> - {
> -   device_type = "cpu";
> -   compatible = "arm,cortex-a15";
> -   reg = <0x3>;
> -   clock-frequency = <18>;
> -   cci-control-port = <_control1>;
> +   cpu7: cpu@3 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a15";
> +   reg = <0x3>;
> +   clock-frequency = <18>;
> +   cci-control-port = <_control1>;
> +   };
> +   };
>  };
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 064176f201e7..279322b83351 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include "exynos5800.dtsi"
> +#include "exynos5420-cpus.dtsi"
>
>  / {
> model = "Google Peach Pi Rev 10+";
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Good clean-up.
Reviewed-by: Chanho Park 

-- 
Best Regards,
Chanho Park
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: dts: Make CPU configuration more readable for exynos542x/5800

2015-12-17 Thread Chanho Park 
eg = <0x0>;
> -   clock-frequency = <18>;
> -   cci-control-port = <_control1>;
> -};
> +   cpu3: cpu@103 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a7";
> +   reg = <0x103>;
> +   clock-frequency = <10>;
> +   cci-control-port = <_control0>;
> +   };
>
> - {
> -   device_type = "cpu";
> -   compatible = "arm,cortex-a15";
> -   reg = <0x1>;
> -   clock-frequency = <18>;
> -   cci-control-port = <_control1>;
> -};
> +   cpu4: cpu@0 {
> +   device_type = "cpu";
> +       compatible = "arm,cortex-a15";
> +   reg = <0x0>;
> +   clock-frequency = <18>;
> +   cci-control-port = <_control1>;
> +   };
>
> - {
> -   device_type = "cpu";
> -   compatible = "arm,cortex-a15";
> -   reg = <0x2>;
> -   clock-frequency = <18>;
> -   cci-control-port = <_control1>;
> -};
> +   cpu5: cpu@1 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a15";
> +   reg = <0x1>;
> +   clock-frequency = <18>;
> +   cci-control-port = <_control1>;
> +   };
> +
> +   cpu6: cpu@2 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a15";
> +   reg = <0x2>;
> +   clock-frequency = <18>;
> +   cci-control-port = <_control1>;
> +   };
>
> - {
> -   device_type = "cpu";
> -   compatible = "arm,cortex-a15";
> -   reg = <0x3>;
> -   clock-frequency = <18>;
> -   cci-control-port = <_control1>;
> +   cpu7: cpu@3 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a15";
> +   reg = <0x3>;
> +   clock-frequency = <18>;
> +   cci-control-port = <_control1>;
> +   };
> +   };
>  };
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 064176f201e7..279322b83351 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include "exynos5800.dtsi"
> +#include "exynos5420-cpus.dtsi"
>
>  / {
> model = "Google Peach Pi Rev 10+";
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Good clean-up.
Reviewed-by: Chanho Park <parkc...@gmail.com>

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

Re: [PATCH 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

2015-06-10 Thread Chanho Park 
Hi,

On Wed, Jun 10, 2015 at 10:10 PM, Javier Martinez Canillas
 wrote:
> The Exynos interrupt combiner IP looses its state when the SoC enters
> into a low power state during a Suspend-to-RAM. This means that if a
> IRQ is used as a source, the interrupts for the devices are disabled
> when the system is resumed from a sleep state so are not triggered.
>
> Save the interrupt enable set register for each combiner group and
> restore it after resume to make sure that the interrupts are enabled.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>
> Hello,
>
> I noticed this issue because after a S2R, IRQs for some devices didn't
> trigger anymore but others continued working and all of them had lines
> from a GPIO chip as their interrupt source.
>
> The only difference was that the GPIO pins that were not working after
> a resume, were the ones that had the interrupt combiner as interrupt
> parent.
>
> With this patch now all perhiperals are working correctly after a resume.
> Tested on an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi
> Chromebooks.
>
> Best regards,
> Javier
>
>  drivers/irqchip/exynos-combiner.c | 61 
> +++
>  1 file changed, 56 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/irqchip/exynos-combiner.c 
> b/drivers/irqchip/exynos-combiner.c
> index 5945223b73fa..69c710641bfa 100644
> --- a/drivers/irqchip/exynos-combiner.c
> +++ b/drivers/irqchip/exynos-combiner.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -34,9 +35,14 @@ struct combiner_chip_data {
> unsigned int irq_mask;
> void __iomem *base;
> unsigned int parent_irq;
> +#ifdef CONFIG_PM
> +   u32 pm_save;
> +#endif
>  };
>
> +static struct combiner_chip_data *combiner_data;
>  static struct irq_domain *combiner_irq_domain;
> +static unsigned int max_nr = 20;
>
>  static inline void __iomem *combiner_base(struct irq_data *data)
>  {
> @@ -170,12 +176,10 @@ static struct irq_domain_ops combiner_irq_domain_ops = {
>  };
>
>  static void __init combiner_init(void __iomem *combiner_base,
> -struct device_node *np,
> -unsigned int max_nr)
> +struct device_node *np)
>  {
> int i, irq;
> unsigned int nr_irq;
> -   struct combiner_chip_data *combiner_data;
>
> nr_irq = max_nr * IRQ_IN_COMBINER;
>
> @@ -201,11 +205,56 @@ static void __init combiner_init(void __iomem 
> *combiner_base,
> }
>  }
>
> +#ifdef CONFIG_PM
> +
> +/**
> + * combiner_suspend - save interrupt combiner state before suspend
> + *
> + * Save the interrupt enable set register for all combiner groups since
> + * the state is lost when the system enters into a sleep state.
> + *
> + */
> +static int combiner_suspend(void)
> +{
> +   int i;
> +
> +   for (i = 0; i < max_nr; i++)
> +   combiner_data[i].pm_save =
> +   __raw_readl(combiner_data[i].base + 
> COMBINER_ENABLE_SET);
> +
> +   return 0;
> +}
> +
> +/**
> + * combiner_resume - restore interrupt combiner state after resume
> + *
> + * Restore the interrupt enable set register for all combiner groups since
> + * the state is lost when the system enters into a sleep state on suspend.
> + *
> + */
> +static void combiner_resume(void)
> +{
> +   int i;
> +
> +   for (i = 0; i < max_nr; i++)

Don't you need to clear masking bits of the COMBINER_ENABLE_CLEAR
before enabling the bits?

> +   __raw_writel(combiner_data[i].pm_save,
> +combiner_data[i].base + COMBINER_ENABLE_SET);
> +}
> +
> +#else
> +#define combiner_suspend   NULL
> +#define combiner_resumeNULL
> +#endif
> +
> +static struct syscore_ops combiner_syscore_ops = {
> +   .suspend= combiner_suspend,
> +   .resume = combiner_resume,
> +};
> +
>  static int __init combiner_of_init(struct device_node *np,
>struct device_node *parent)
>  {
> void __iomem *combiner_base;
> -   unsigned int max_nr = 20;
>
> combiner_base = of_iomap(np, 0);
> if (!combiner_base) {
> @@ -219,7 +268,9 @@ static int __init combiner_of_init(struct device_node *np,
> __func__, max_nr);
> }
>
> -   combiner_init(combiner_base, np, max_nr);
> +   combiner_init(combiner_base, np);
> +
> +   register_syscore_ops(_syscore_ops);
>
&g

Re: [PATCH 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

2015-06-10 Thread Chanho Park 
Hi,

On Wed, Jun 10, 2015 at 10:10 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The Exynos interrupt combiner IP looses its state when the SoC enters
 into a low power state during a Suspend-to-RAM. This means that if a
 IRQ is used as a source, the interrupts for the devices are disabled
 when the system is resumed from a sleep state so are not triggered.

 Save the interrupt enable set register for each combiner group and
 restore it after resume to make sure that the interrupts are enabled.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---

 Hello,

 I noticed this issue because after a S2R, IRQs for some devices didn't
 trigger anymore but others continued working and all of them had lines
 from a GPIO chip as their interrupt source.

 The only difference was that the GPIO pins that were not working after
 a resume, were the ones that had the interrupt combiner as interrupt
 parent.

 With this patch now all perhiperals are working correctly after a resume.
 Tested on an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi
 Chromebooks.

 Best regards,
 Javier

  drivers/irqchip/exynos-combiner.c | 61 
 +++
  1 file changed, 56 insertions(+), 5 deletions(-)

 diff --git a/drivers/irqchip/exynos-combiner.c 
 b/drivers/irqchip/exynos-combiner.c
 index 5945223b73fa..69c710641bfa 100644
 --- a/drivers/irqchip/exynos-combiner.c
 +++ b/drivers/irqchip/exynos-combiner.c
 @@ -13,6 +13,7 @@
  #include linux/init.h
  #include linux/io.h
  #include linux/slab.h
 +#include linux/syscore_ops.h
  #include linux/irqdomain.h
  #include linux/irqchip/chained_irq.h
  #include linux/interrupt.h
 @@ -34,9 +35,14 @@ struct combiner_chip_data {
 unsigned int irq_mask;
 void __iomem *base;
 unsigned int parent_irq;
 +#ifdef CONFIG_PM
 +   u32 pm_save;
 +#endif
  };

 +static struct combiner_chip_data *combiner_data;
  static struct irq_domain *combiner_irq_domain;
 +static unsigned int max_nr = 20;

  static inline void __iomem *combiner_base(struct irq_data *data)
  {
 @@ -170,12 +176,10 @@ static struct irq_domain_ops combiner_irq_domain_ops = {
  };

  static void __init combiner_init(void __iomem *combiner_base,
 -struct device_node *np,
 -unsigned int max_nr)
 +struct device_node *np)
  {
 int i, irq;
 unsigned int nr_irq;
 -   struct combiner_chip_data *combiner_data;

 nr_irq = max_nr * IRQ_IN_COMBINER;

 @@ -201,11 +205,56 @@ static void __init combiner_init(void __iomem 
 *combiner_base,
 }
  }

 +#ifdef CONFIG_PM
 +
 +/**
 + * combiner_suspend - save interrupt combiner state before suspend
 + *
 + * Save the interrupt enable set register for all combiner groups since
 + * the state is lost when the system enters into a sleep state.
 + *
 + */
 +static int combiner_suspend(void)
 +{
 +   int i;
 +
 +   for (i = 0; i  max_nr; i++)
 +   combiner_data[i].pm_save =
 +   __raw_readl(combiner_data[i].base + 
 COMBINER_ENABLE_SET);
 +
 +   return 0;
 +}
 +
 +/**
 + * combiner_resume - restore interrupt combiner state after resume
 + *
 + * Restore the interrupt enable set register for all combiner groups since
 + * the state is lost when the system enters into a sleep state on suspend.
 + *
 + */
 +static void combiner_resume(void)
 +{
 +   int i;
 +
 +   for (i = 0; i  max_nr; i++)

Don't you need to clear masking bits of the COMBINER_ENABLE_CLEAR
before enabling the bits?

 +   __raw_writel(combiner_data[i].pm_save,
 +combiner_data[i].base + COMBINER_ENABLE_SET);
 +}
 +
 +#else
 +#define combiner_suspend   NULL
 +#define combiner_resumeNULL
 +#endif
 +
 +static struct syscore_ops combiner_syscore_ops = {
 +   .suspend= combiner_suspend,
 +   .resume = combiner_resume,
 +};
 +
  static int __init combiner_of_init(struct device_node *np,
struct device_node *parent)
  {
 void __iomem *combiner_base;
 -   unsigned int max_nr = 20;

 combiner_base = of_iomap(np, 0);
 if (!combiner_base) {
 @@ -219,7 +268,9 @@ static int __init combiner_of_init(struct device_node *np,
 __func__, max_nr);
 }

 -   combiner_init(combiner_base, np, max_nr);
 +   combiner_init(combiner_base, np);
 +
 +   register_syscore_ops(combiner_syscore_ops);

 return 0;
  }
 --
 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/



-- 
Best Regards,
Chanho Park
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message

Re: [PATCH v1 1/1] ARM: EXYNOS: fix DEBUG_LL on Cortex-A7.

2015-05-17 Thread Chanho Park 
Hi Tarek,

On Sun, May 17, 2015 at 3:42 PM, Tarek Dakhran  wrote:
> Cortex-A7 has EXYNOS5_PA_UART base address for UART.
> If system boots from Cortex-A7 CPU addruart loads wrong
> address. This patch fixex this.
>
> Signed-off-by: Tarek Dakhran 
> ---
>  arch/arm/include/debug/exynos.S | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/include/debug/exynos.S b/arch/arm/include/debug/exynos.S
> index b17fdb7..a61b3ea 100644
> --- a/arch/arm/include/debug/exynos.S
> +++ b/arch/arm/include/debug/exynos.S
> @@ -24,6 +24,7 @@
> mrc p15, 0, \tmp, c0, c0, 0
> and \tmp, \tmp, #0xf0
> teq \tmp, #0xf0 @@ A15
> +   teqne   \tmp, #0x70 @@ A7
> ldreq   \rp, =EXYNOS5_PA_UART
> movne   \rp, #EXYNOS4_PA_UART   @@ EXYNOS4
> ldr \rv, =S3C_VA_UART
> --
> 1.9.1
>

Please see previous Joonyoung's patch. Your patch could break
exynos3250 because it has not only two cortex-a7 cpus but also uses
EXYOS4_PA_UART.

http://www.spinics.net/lists/linux-samsung-soc/msg37318.html

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

Re: [PATCH v1 1/1] ARM: EXYNOS: fix DEBUG_LL on Cortex-A7.

2015-05-17 Thread Chanho Park 
Hi Tarek,

On Sun, May 17, 2015 at 3:42 PM, Tarek Dakhran t.dakh...@gmail.com wrote:
 Cortex-A7 has EXYNOS5_PA_UART base address for UART.
 If system boots from Cortex-A7 CPU addruart loads wrong
 address. This patch fixex this.

 Signed-off-by: Tarek Dakhran t.dakh...@gmail.com
 ---
  arch/arm/include/debug/exynos.S | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/arch/arm/include/debug/exynos.S b/arch/arm/include/debug/exynos.S
 index b17fdb7..a61b3ea 100644
 --- a/arch/arm/include/debug/exynos.S
 +++ b/arch/arm/include/debug/exynos.S
 @@ -24,6 +24,7 @@
 mrc p15, 0, \tmp, c0, c0, 0
 and \tmp, \tmp, #0xf0
 teq \tmp, #0xf0 @@ A15
 +   teqne   \tmp, #0x70 @@ A7
 ldreq   \rp, =EXYNOS5_PA_UART
 movne   \rp, #EXYNOS4_PA_UART   @@ EXYNOS4
 ldr \rv, =S3C_VA_UART
 --
 1.9.1


Please see previous Joonyoung's patch. Your patch could break
exynos3250 because it has not only two cortex-a7 cpus but also uses
EXYOS4_PA_UART.

http://www.spinics.net/lists/linux-samsung-soc/msg37318.html

-- 
Best Regards,
Chanho Park
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] ext4 crypto: remove duplicated encryption mode definitions

2015-04-23 Thread Chanho Park 
This patch removes duplicated encryption modes which were already in
ext4.h. They were duplicated from commit 3edc18d and commit f542fb.

Cc: Theodore Ts'o 
Cc: Michael Halcrow 
Cc: Andreas Dilger 
Signed-off-by: Chanho Park 
---
 fs/ext4/ext4.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index ef267ad..07378a4 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1066,12 +1066,6 @@ extern void ext4_set_bits(void *bm, int cur, int len);
 /* Metadata checksum algorithm codes */
 #define EXT4_CRC32C_CHKSUM 1
 
-/* Encryption algorithms */
-#define EXT4_ENCRYPTION_MODE_INVALID   0
-#define EXT4_ENCRYPTION_MODE_AES_256_XTS   1
-#define EXT4_ENCRYPTION_MODE_AES_256_GCM   2
-#define EXT4_ENCRYPTION_MODE_AES_256_CBC   3
-
 /*
  * Structure of the super block
  */
-- 
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] ext4 crypto: remove duplicated encryption mode definitions

2015-04-23 Thread Chanho Park 
This patch removes duplicated encryption modes which were already in
ext4.h. They were duplicated from commit 3edc18d and commit f542fb.

Cc: Theodore Ts'o ty...@mit.edu
Cc: Michael Halcrow mhalc...@google.com
Cc: Andreas Dilger adilger.ker...@dilger.ca
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
 fs/ext4/ext4.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index ef267ad..07378a4 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1066,12 +1066,6 @@ extern void ext4_set_bits(void *bm, int cur, int len);
 /* Metadata checksum algorithm codes */
 #define EXT4_CRC32C_CHKSUM 1
 
-/* Encryption algorithms */
-#define EXT4_ENCRYPTION_MODE_INVALID   0
-#define EXT4_ENCRYPTION_MODE_AES_256_XTS   1
-#define EXT4_ENCRYPTION_MODE_AES_256_GCM   2
-#define EXT4_ENCRYPTION_MODE_AES_256_CBC   3
-
 /*
  * Structure of the super block
  */
-- 
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 v3] pinctrl: exynos: Add support for Exynos5433

2015-02-11 Thread Chanho Park 
Hi Linus,

We're looking forward to merging it on the v3.20.
Could you pick this patch up before merge-window is closed?

Best Regards,
Chanho Park

> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Chanwoo Choi
> Sent: Thursday, February 12, 2015 3:18 PM
> To: Linus Walleij
> Cc: linux-samsung-soc; Tomasz Figa; linux-kernel@vger.kernel.org; Inki
> Dae; Kukjin Kim; Thomas Abraham; Chanho Park; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3] pinctrl: exynos: Add support for Exynos5433
> 
> Hi Linus,
> 
> On 02/08/2015 11:59 PM, Tomasz Figa wrote:
> > Hi,
> >
> > 2015-01-29 18:48 GMT+09:00 Linus Walleij :
> >> On Wed, Jan 21, 2015 at 7:43 AM, Chanwoo Choi 
> wrote:
> >>
> >>> This patch adds driver data for Exynos5433 SoC. Exynos5433 includes
> 228 multi-
> >>> functional input/output port pins and 135 memory port pins. There
> are 41 general
> >>> port groups and 2 memory port groups.
> >>>
> >>> Cc: Tomasz Figa 
> >>> Cc: Thomas Abraham 
> >>> Cc: Linus Walleij 
> >>> Signed-off-by: Chanwoo Choi 
> >>> Acked-by: Inki Dae 
> >>> ---
> >>> Changes from v2:
> >>> - Rebase it on v3.19-rc5
> >>
> >> Waiting for Tomasz to review this.
> >
> > Thanks Linus. Looks good to me.
> >
> > Acked-by: Tomasz Figa 
> 
> Could you please pick this patch?
> 
> Best Regards,
> Chanwoo Choi
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

RE: [PATCH v3] pinctrl: exynos: Add support for Exynos5433

2015-02-11 Thread Chanho Park 
Hi Linus,

We're looking forward to merging it on the v3.20.
Could you pick this patch up before merge-window is closed?

Best Regards,
Chanho Park

 -Original Message-
 From: linux-arm-kernel [mailto:linux-arm-kernel-
 boun...@lists.infradead.org] On Behalf Of Chanwoo Choi
 Sent: Thursday, February 12, 2015 3:18 PM
 To: Linus Walleij
 Cc: linux-samsung-soc; Tomasz Figa; linux-kernel@vger.kernel.org; Inki
 Dae; Kukjin Kim; Thomas Abraham; Chanho Park; linux-arm-
 ker...@lists.infradead.org
 Subject: Re: [PATCH v3] pinctrl: exynos: Add support for Exynos5433
 
 Hi Linus,
 
 On 02/08/2015 11:59 PM, Tomasz Figa wrote:
  Hi,
 
  2015-01-29 18:48 GMT+09:00 Linus Walleij linus.wall...@linaro.org:
  On Wed, Jan 21, 2015 at 7:43 AM, Chanwoo Choi cw00.c...@samsung.com
 wrote:
 
  This patch adds driver data for Exynos5433 SoC. Exynos5433 includes
 228 multi-
  functional input/output port pins and 135 memory port pins. There
 are 41 general
  port groups and 2 memory port groups.
 
  Cc: Tomasz Figa tomasz.f...@gmail.com
  Cc: Thomas Abraham thomas.abra...@linaro.org
  Cc: Linus Walleij linus.wall...@linaro.org
  Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
  Acked-by: Inki Dae inki@samsung.com
  ---
  Changes from v2:
  - Rebase it on v3.19-rc5
 
  Waiting for Tomasz to review this.
 
  Thanks Linus. Looks good to me.
 
  Acked-by: Tomasz Figa tomasz.f...@gmail.com
 
 Could you please pick this patch?
 
 Best Regards,
 Chanwoo Choi
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[tip:perf/core] perf tools: define _DEFAULT_SOURCE for glibc_2.20

2014-09-18 Thread tip-bot for Chanho Park 
Commit-ID:  512fe365373b9c95a70b4b6357503ee74d27214f
Gitweb: http://git.kernel.org/tip/512fe365373b9c95a70b4b6357503ee74d27214f
Author: Chanho Park 
AuthorDate: Fri, 12 Sep 2014 11:10:17 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 17 Sep 2014 17:08:10 -0300

perf tools: define _DEFAULT_SOURCE for glibc_2.20

_BSD_SOURCE was deprecated in favour of _DEFAULT_SOURCE since glibc
2.20[1]. To avoid build warning on glibc2.20, _DEFAULT_SOURCE should
also be defined.

[1]: https://sourceware.org/glibc/wiki/Release/2.20

Signed-off-by: Chanho Park 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1410487817-13403-1-git-send-email-chanho61.p...@samsung.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/util.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 6ad2b5e..80bfdaa 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -39,6 +39,8 @@
 
 #define _ALL_SOURCE 1
 #define _BSD_SOURCE 1
+/* glibc 2.20 deprecates _BSD_SOURCE in favour of _DEFAULT_SOURCE */
+#define _DEFAULT_SOURCE 1
 #define HAS_BOOL
 
 #include 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: define _DEFAULT_SOURCE for glibc_2.20

2014-09-18 Thread tip-bot for Chanho Park 
Commit-ID:  512fe365373b9c95a70b4b6357503ee74d27214f
Gitweb: http://git.kernel.org/tip/512fe365373b9c95a70b4b6357503ee74d27214f
Author: Chanho Park chanho61.p...@samsung.com
AuthorDate: Fri, 12 Sep 2014 11:10:17 +0900
Committer:  Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Wed, 17 Sep 2014 17:08:10 -0300

perf tools: define _DEFAULT_SOURCE for glibc_2.20

_BSD_SOURCE was deprecated in favour of _DEFAULT_SOURCE since glibc
2.20[1]. To avoid build warning on glibc2.20, _DEFAULT_SOURCE should
also be defined.

[1]: https://sourceware.org/glibc/wiki/Release/2.20

Signed-off-by: Chanho Park chanho61.p...@samsung.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link: 
http://lkml.kernel.org/r/1410487817-13403-1-git-send-email-chanho61.p...@samsung.com
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/util.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 6ad2b5e..80bfdaa 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -39,6 +39,8 @@
 
 #define _ALL_SOURCE 1
 #define _BSD_SOURCE 1
+/* glibc 2.20 deprecates _BSD_SOURCE in favour of _DEFAULT_SOURCE */
+#define _DEFAULT_SOURCE 1
 #define HAS_BOOL
 
 #include unistd.h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] perf tools: define _DEFAULT_SOURCE for glibc_2.20

2014-09-11 Thread Chanho Park 
_BSD_SOURCE was deprecated in favour of _DEFAULT_SOURCE since glibc
2.20[1]. To avoid build warning on glibc2.20, _DEFAULT_SOURCE should
also be defined.

[1]: https://sourceware.org/glibc/wiki/Release/2.20

Signed-off-by: Chanho Park 
---
 tools/perf/util/util.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 6686436..333d9d1 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -39,6 +39,8 @@
 
 #define _ALL_SOURCE 1
 #define _BSD_SOURCE 1
+/* glibc 2.20 deprecates _BSD_SOURCE in favour of _DEFAULT_SOURCE */
+#define _DEFAULT_SOURCE 1
 #define HAS_BOOL
 
 #include 
-- 
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] perf tools: define _DEFAULT_SOURCE for glibc_2.20

2014-09-11 Thread Chanho Park 
_BSD_SOURCE was deprecated in favour of _DEFAULT_SOURCE since glibc
2.20[1]. To avoid build warning on glibc2.20, _DEFAULT_SOURCE should
also be defined.

[1]: https://sourceware.org/glibc/wiki/Release/2.20

Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
 tools/perf/util/util.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 6686436..333d9d1 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -39,6 +39,8 @@
 
 #define _ALL_SOURCE 1
 #define _BSD_SOURCE 1
+/* glibc 2.20 deprecates _BSD_SOURCE in favour of _DEFAULT_SOURCE */
+#define _DEFAULT_SOURCE 1
 #define HAS_BOOL
 
 #include unistd.h
-- 
1.9.1

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

RE: [PATCH] Smack: separate smackfstransmute and smackfsroot

2014-06-18 Thread Chanho Park 
Hi,

> -Original Message-
> From: Casey Schaufler [mailto:ca...@schaufler-ca.com]
> Sent: Wednesday, June 18, 2014 10:26 PM
> To: Chanho Park
> Cc: james.l.mor...@oracle.com; linux-security-mod...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Casey Schaufler
> Subject: Re: [PATCH] Smack: separate smackfstransmute and smackfsroot
> 
> On 6/18/2014 5:41 AM, Chanho Park wrote:
> > According to previous commit(e830b39: Smack: Add smkfstransmute mount
> option),
> > the smackfstransmute option is the smackfsroot option + transmute
> option.
> > I think it can be confused because the transmute option can only have
> "TRUE".
> > Before the patch, you cannot use the smackfsroot and the
> smackfstransmute at
> > the same time. If you use the options simultaenously, the previous
> option will
> > be omitted. In the below example, the smackfsroot option will be
> omitted.
> > mount -t tmpfs -o size=128M,smackfsroot=*,smackfstransmute=_ tmpfs
> /tmp
> >
> > After the patch, now you can use the smackfstransmute option like
> below:
> > mount -t tmpfs -o size=128M,smackfsroot=*,smackfstransmute=TRUE tmpfs
> /tmp
> >
> > Signed-off-by: Chanho Park 
> 
> Nacked-by: Casey Schaufler 
> 
> The smackfsroot option behaves as intended.
> The smackfstransmute option behaves as intended.
> There is no case where you want to mark the root inode
> transmuting where you do not also want to set the
> Smack label of that inode. Making the smackfstransmute
> option require the smackfsroot option as well would be
> unnecessary and inconvenient.

If the smackfstransmute option was like that, we should prevent the two
options at the same time to avoid confusing.
At least, I think we need to provide a documentation for that.

Best Regards,
Chanho Park

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Smack: separate smackfstransmute and smackfsroot

2014-06-18 Thread Chanho Park 
According to previous commit(e830b39: Smack: Add smkfstransmute mount option),
the smackfstransmute option is the smackfsroot option + transmute option.
I think it can be confused because the transmute option can only have "TRUE".
Before the patch, you cannot use the smackfsroot and the smackfstransmute at
the same time. If you use the options simultaenously, the previous option will
be omitted. In the below example, the smackfsroot option will be omitted.
mount -t tmpfs -o size=128M,smackfsroot=*,smackfstransmute=_ tmpfs /tmp

After the patch, now you can use the smackfstransmute option like below:
mount -t tmpfs -o size=128M,smackfsroot=*,smackfstransmute=TRUE tmpfs /tmp

Signed-off-by: Chanho Park 
---
 Documentation/security/Smack.txt | 3 +++
 security/smack/smack.h   | 2 ++
 security/smack/smack_lsm.c   | 5 ++---
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt
index b6ef7e9..27290d8 100644
--- a/Documentation/security/Smack.txt
+++ b/Documentation/security/Smack.txt
@@ -669,6 +669,9 @@ Smack supports some mount options:
smackfsfloor=label: specifies a label to which all labels set on the
filesystem must have read access. Not yet enforced.
 
+   smackfstransmute=TRUE: assign a transmute option for the root of the
+   file system if it lacks the Smack extended attribute.
+
 These mount options apply to all file system types.
 
 Smack auditing
diff --git a/security/smack/smack.h b/security/smack/smack.h
index 020307e..d4f75e6 100644
--- a/security/smack/smack.h
+++ b/security/smack/smack.h
@@ -146,6 +146,8 @@ struct smk_port_label {
 #define SMK_FSROOT "smackfsroot="
 #define SMK_FSTRANS"smackfstransmute="
 
+#define SMK_FSTRANS_ON "TRUE"
+
 #define SMACK_CIPSO_OPTION "-CIPSO"
 
 /*
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index f2c3080..7d3f40d 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -450,9 +450,8 @@ static int smack_sb_kern_mount(struct super_block *sb, int 
flags, void *data)
}
} else if (strncmp(op, SMK_FSTRANS, strlen(SMK_FSTRANS)) == 0) {
op += strlen(SMK_FSTRANS);
-   nsp = smk_import(op, 0);
-   if (nsp != NULL) {
-   sp->smk_root = nsp;
+   if (strncmp(op, SMK_FSTRANS_ON,
+   strlen(SMK_FSTRANS_ON)) == 0) {
transmute = 1;
specified = 1;
}
-- 
1.9.1

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

[PATCH] Smack: separate smackfstransmute and smackfsroot

2014-06-18 Thread Chanho Park 
According to previous commit(e830b39: Smack: Add smkfstransmute mount option),
the smackfstransmute option is the smackfsroot option + transmute option.
I think it can be confused because the transmute option can only have TRUE.
Before the patch, you cannot use the smackfsroot and the smackfstransmute at
the same time. If you use the options simultaenously, the previous option will
be omitted. In the below example, the smackfsroot option will be omitted.
mount -t tmpfs -o size=128M,smackfsroot=*,smackfstransmute=_ tmpfs /tmp

After the patch, now you can use the smackfstransmute option like below:
mount -t tmpfs -o size=128M,smackfsroot=*,smackfstransmute=TRUE tmpfs /tmp

Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
 Documentation/security/Smack.txt | 3 +++
 security/smack/smack.h   | 2 ++
 security/smack/smack_lsm.c   | 5 ++---
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt
index b6ef7e9..27290d8 100644
--- a/Documentation/security/Smack.txt
+++ b/Documentation/security/Smack.txt
@@ -669,6 +669,9 @@ Smack supports some mount options:
smackfsfloor=label: specifies a label to which all labels set on the
filesystem must have read access. Not yet enforced.
 
+   smackfstransmute=TRUE: assign a transmute option for the root of the
+   file system if it lacks the Smack extended attribute.
+
 These mount options apply to all file system types.
 
 Smack auditing
diff --git a/security/smack/smack.h b/security/smack/smack.h
index 020307e..d4f75e6 100644
--- a/security/smack/smack.h
+++ b/security/smack/smack.h
@@ -146,6 +146,8 @@ struct smk_port_label {
 #define SMK_FSROOT smackfsroot=
 #define SMK_FSTRANSsmackfstransmute=
 
+#define SMK_FSTRANS_ON TRUE
+
 #define SMACK_CIPSO_OPTION -CIPSO
 
 /*
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index f2c3080..7d3f40d 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -450,9 +450,8 @@ static int smack_sb_kern_mount(struct super_block *sb, int 
flags, void *data)
}
} else if (strncmp(op, SMK_FSTRANS, strlen(SMK_FSTRANS)) == 0) {
op += strlen(SMK_FSTRANS);
-   nsp = smk_import(op, 0);
-   if (nsp != NULL) {
-   sp-smk_root = nsp;
+   if (strncmp(op, SMK_FSTRANS_ON,
+   strlen(SMK_FSTRANS_ON)) == 0) {
transmute = 1;
specified = 1;
}
-- 
1.9.1

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

RE: [PATCH] Smack: separate smackfstransmute and smackfsroot

2014-06-18 Thread Chanho Park 
Hi,

 -Original Message-
 From: Casey Schaufler [mailto:ca...@schaufler-ca.com]
 Sent: Wednesday, June 18, 2014 10:26 PM
 To: Chanho Park
 Cc: james.l.mor...@oracle.com; linux-security-mod...@vger.kernel.org;
 linux-kernel@vger.kernel.org; Casey Schaufler
 Subject: Re: [PATCH] Smack: separate smackfstransmute and smackfsroot
 
 On 6/18/2014 5:41 AM, Chanho Park wrote:
  According to previous commit(e830b39: Smack: Add smkfstransmute mount
 option),
  the smackfstransmute option is the smackfsroot option + transmute
 option.
  I think it can be confused because the transmute option can only have
 TRUE.
  Before the patch, you cannot use the smackfsroot and the
 smackfstransmute at
  the same time. If you use the options simultaenously, the previous
 option will
  be omitted. In the below example, the smackfsroot option will be
 omitted.
  mount -t tmpfs -o size=128M,smackfsroot=*,smackfstransmute=_ tmpfs
 /tmp
 
  After the patch, now you can use the smackfstransmute option like
 below:
  mount -t tmpfs -o size=128M,smackfsroot=*,smackfstransmute=TRUE tmpfs
 /tmp
 
  Signed-off-by: Chanho Park chanho61.p...@samsung.com
 
 Nacked-by: Casey Schaufler ca...@schaufler-ca.com
 
 The smackfsroot option behaves as intended.
 The smackfstransmute option behaves as intended.
 There is no case where you want to mark the root inode
 transmuting where you do not also want to set the
 Smack label of that inode. Making the smackfstransmute
 option require the smackfsroot option as well would be
 unnecessary and inconvenient.

If the smackfstransmute option was like that, we should prevent the two
options at the same time to avoid confusing.
At least, I think we need to provide a documentation for that.

Best Regards,
Chanho Park

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/27] irqchip: Declare cortex-a7's irqchip to initialize gic from dt

2014-04-10 Thread Chanho Park 
Hi,

> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Marc Zyngier
> Sent: Thursday, April 10, 2014 7:05 PM
> To: Chanwoo Choi
> Cc: mark.rutl...@arm.com; linux-samsung-...@vger.kernel.org;
> t.f...@samsung.com; hyunhee@samsung.com; sw0312@samsung.com;
> linux-kernel@vger.kernel.org; yj44@samsung.com; inki@samsung.com;
> kyungmin.p...@samsung.com; kgene@samsung.com; Thomas Gleixner;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 07/27] irqchip: Declare cortex-a7's irqchip to
> initialize gic from dt
> 
> On Thu, Apr 10 2014 at 10:28:24 am BST, Chanwoo Choi
>  wrote:
> > This patch declare coretex-a7's irqchip to initialze gic from dt
> > with "arm,cortex-a7-gic" data.
> >
> > Cc: Thomas Gleixner 
> > Signed-off-by: Chanwoo Choi 
> > Signed-off-by: Kyungmin Park 
> > ---
> >  drivers/irqchip/irq-gic.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > index 4300b66..8e906e4 100644
> > --- a/drivers/irqchip/irq-gic.c
> > +++ b/drivers/irqchip/irq-gic.c
> > @@ -1069,6 +1069,7 @@ gic_of_init(struct device_node *node, struct
> device_node *parent)
> >  }
> >  IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
> >  IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
> > +IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
> >  IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
> >  IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
> 
> Frankly, this patch adds no value. Are we going to add
> "arm,cortex-a12-gic", "arm,cortex-a17-gic", "arm,cortex-a53-gic",
> "arm,cortex-a57-gic"? And that's just to mention the ARM Ltd cores...
> 
> Instead, how about defining a generic "arm,gic" property, and mandate
> that new DT files are using that? We can always use a more precise
> compatible for quirks.

I prefer it would be arm,gicv2 instead arm-gic.
In case of GICv3 of arm64, it can be arm,gicv3.

Best Regards,
Chanho Park

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 21/27] ARM: dts: exynos3250: Add PMU dt data

2014-04-10 Thread Chanho Park 
Hi,

> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Chanwoo Choi
> Sent: Thursday, April 10, 2014 7:06 PM
> To: kgene@samsung.com; t.f...@samsung.com; linux-samsung-
> s...@vger.kernel.org
> Cc: hyunhee@samsung.com; sw0312@samsung.com; linux-
> ker...@vger.kernel.org; yj44@samsung.com; inki@samsung.com;
> cw00.c...@samsung.com; kyungmin.p...@samsung.com; linux-arm-
> ker...@lists.infradead.org
> Subject: [PATCH 21/27] ARM: dts: exynos3250: Add PMU dt data
> 
> From: Hyunhee Kim 
> 
> ARM CPU has its own PMU (Performance Monitoring Unit). This patch add
> PMU dt
> data to support PMU for CPU. Exynos3250 has four PMU interrupts.
> 
> Signed-off-by: Hyunhee Kim 
> Signed-off-by: Kyungmin Park 
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index ceed761..2f0ca32 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -280,4 +280,9 @@
>   pinctrl-0 = <_bus>;
>   status = "disabled";
>   };
> +
> + pmu {
> + compatible = "arm,cortex-a7-pmu";
> + interrupts = <0 18 0>, <0 19 0>, <0 20 0>, <0 21 0>;
> +     };

As I know, the exynos3250 has two CPU cores. Why does it have four pmu
interrupts?
IMO it is sufficient it has only two interrupts.

Best Regards,
Chanho Park 

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

RE: [PATCH 02/27] ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250

2014-04-10 Thread Chanho Park 
Hi Arnd,

> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Arnd Bergmann
> Sent: Thursday, April 10, 2014 6:45 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: kgene@samsung.com; t.f...@samsung.com; hyunhee@samsung.com;
> sw0312@samsung.com; linux-kernel@vger.kernel.org;
> yj44@samsung.com; inki@samsung.com; Chanwoo Choi;
> kyungmin.p...@samsung.com; linux-samsung-...@vger.kernel.org
> Subject: Re: [PATCH 02/27] ARM: EXYNOS: Add IO mapping for non-secure
> SYSRAM of Exynos3250
> 
> On Thursday 10 April 2014 18:28:19 Chanwoo Choi wrote:
> >
> > The non-secure SYSRAM is used for secondary CPU bring-up. This patch
> add
> > IO mapping for non-scure SYSRAM.
> >
> > Signed-off-by: Chanwoo Choi 
> > Signed-off-by: Kyungmin Park 
> 
> I really don't want to see any further static mappings here. We had the
> same discussion for the previous Exynos chip that was submitted, so
> please
> describe the SYSRAM in DT, and start thinking about the other static
> mappings
> that can be removed.

Sachin already submitted the DT support[1] for SYSRAM area.

[1] : http://www.spinics.net/lists/linux-samsung-soc/msg27647.html

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

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

RE: [PATCH 02/27] ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250

2014-04-10 Thread Chanho Park 
Hi Arnd,

 -Original Message-
 From: linux-arm-kernel [mailto:linux-arm-kernel-
 boun...@lists.infradead.org] On Behalf Of Arnd Bergmann
 Sent: Thursday, April 10, 2014 6:45 PM
 To: linux-arm-ker...@lists.infradead.org
 Cc: kgene@samsung.com; t.f...@samsung.com; hyunhee@samsung.com;
 sw0312@samsung.com; linux-kernel@vger.kernel.org;
 yj44@samsung.com; inki@samsung.com; Chanwoo Choi;
 kyungmin.p...@samsung.com; linux-samsung-...@vger.kernel.org
 Subject: Re: [PATCH 02/27] ARM: EXYNOS: Add IO mapping for non-secure
 SYSRAM of Exynos3250
 
 On Thursday 10 April 2014 18:28:19 Chanwoo Choi wrote:
 
  The non-secure SYSRAM is used for secondary CPU bring-up. This patch
 add
  IO mapping for non-scure SYSRAM.
 
  Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 
 I really don't want to see any further static mappings here. We had the
 same discussion for the previous Exynos chip that was submitted, so
 please
 describe the SYSRAM in DT, and start thinking about the other static
 mappings
 that can be removed.

Sachin already submitted the DT support[1] for SYSRAM area.

[1] : http://www.spinics.net/lists/linux-samsung-soc/msg27647.html

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

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

RE: [PATCH 21/27] ARM: dts: exynos3250: Add PMU dt data

2014-04-10 Thread Chanho Park 
Hi,

 -Original Message-
 From: linux-arm-kernel [mailto:linux-arm-kernel-
 boun...@lists.infradead.org] On Behalf Of Chanwoo Choi
 Sent: Thursday, April 10, 2014 7:06 PM
 To: kgene@samsung.com; t.f...@samsung.com; linux-samsung-
 s...@vger.kernel.org
 Cc: hyunhee@samsung.com; sw0312@samsung.com; linux-
 ker...@vger.kernel.org; yj44@samsung.com; inki@samsung.com;
 cw00.c...@samsung.com; kyungmin.p...@samsung.com; linux-arm-
 ker...@lists.infradead.org
 Subject: [PATCH 21/27] ARM: dts: exynos3250: Add PMU dt data
 
 From: Hyunhee Kim hyunhee@samsung.com
 
 ARM CPU has its own PMU (Performance Monitoring Unit). This patch add
 PMU dt
 data to support PMU for CPU. Exynos3250 has four PMU interrupts.
 
 Signed-off-by: Hyunhee Kim hyunhee@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/boot/dts/exynos3250.dtsi | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos3250.dtsi
 b/arch/arm/boot/dts/exynos3250.dtsi
 index ceed761..2f0ca32 100644
 --- a/arch/arm/boot/dts/exynos3250.dtsi
 +++ b/arch/arm/boot/dts/exynos3250.dtsi
 @@ -280,4 +280,9 @@
   pinctrl-0 = i2c7_bus;
   status = disabled;
   };
 +
 + pmu {
 + compatible = arm,cortex-a7-pmu;
 + interrupts = 0 18 0, 0 19 0, 0 20 0, 0 21 0;
 + };

As I know, the exynos3250 has two CPU cores. Why does it have four pmu
interrupts?
IMO it is sufficient it has only two interrupts.

Best Regards,
Chanho Park 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/27] irqchip: Declare cortex-a7's irqchip to initialize gic from dt

2014-04-10 Thread Chanho Park 
Hi,

 -Original Message-
 From: linux-arm-kernel [mailto:linux-arm-kernel-
 boun...@lists.infradead.org] On Behalf Of Marc Zyngier
 Sent: Thursday, April 10, 2014 7:05 PM
 To: Chanwoo Choi
 Cc: mark.rutl...@arm.com; linux-samsung-...@vger.kernel.org;
 t.f...@samsung.com; hyunhee@samsung.com; sw0312@samsung.com;
 linux-kernel@vger.kernel.org; yj44@samsung.com; inki@samsung.com;
 kyungmin.p...@samsung.com; kgene@samsung.com; Thomas Gleixner;
 linux-arm-ker...@lists.infradead.org
 Subject: Re: [PATCH 07/27] irqchip: Declare cortex-a7's irqchip to
 initialize gic from dt
 
 On Thu, Apr 10 2014 at 10:28:24 am BST, Chanwoo Choi
 cw00.c...@samsung.com wrote:
  This patch declare coretex-a7's irqchip to initialze gic from dt
  with arm,cortex-a7-gic data.
 
  Cc: Thomas Gleixner t...@linutronix.de
  Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
   drivers/irqchip/irq-gic.c | 1 +
   1 file changed, 1 insertion(+)
 
  diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
  index 4300b66..8e906e4 100644
  --- a/drivers/irqchip/irq-gic.c
  +++ b/drivers/irqchip/irq-gic.c
  @@ -1069,6 +1069,7 @@ gic_of_init(struct device_node *node, struct
 device_node *parent)
   }
   IRQCHIP_DECLARE(cortex_a15_gic, arm,cortex-a15-gic, gic_of_init);
   IRQCHIP_DECLARE(cortex_a9_gic, arm,cortex-a9-gic, gic_of_init);
  +IRQCHIP_DECLARE(cortex_a7_gic, arm,cortex-a7-gic, gic_of_init);
   IRQCHIP_DECLARE(msm_8660_qgic, qcom,msm-8660-qgic, gic_of_init);
   IRQCHIP_DECLARE(msm_qgic2, qcom,msm-qgic2, gic_of_init);
 
 Frankly, this patch adds no value. Are we going to add
 arm,cortex-a12-gic, arm,cortex-a17-gic, arm,cortex-a53-gic,
 arm,cortex-a57-gic? And that's just to mention the ARM Ltd cores...
 
 Instead, how about defining a generic arm,gic property, and mandate
 that new DT files are using that? We can always use a more precise
 compatible for quirks.

I prefer it would be arm,gicv2 instead arm-gic.
In case of GICv3 of arm64, it can be arm,gicv3.

Best Regards,
Chanho Park

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

[PATCHv2] dma: pl330: add pl330_prep_dma_sg to transfer from sglist to sglist

2013-09-13 Thread Chanho Park 
This patch adds prep_dma_sg function to transfer memory to memory which
mapped in scatter/gather list. The patch move get_burst_len to upwards to
call in the __pl330_prep_dma_mecpy. Some duplicated code was splitted off
from prep_dma_memcpy.
This patch also included previous Boojon Kim's patch[1] which fixes burst_size
calculation. The burst_size should be aligned not only length but also source
and destionation addresses.

[1] : http://lkml.indiana.edu/hypermail/linux/kernel/1201.1/00246.html

Cc: Boojin Kim 
Signed-off-by: Chanho Park 
Acked-by: Jassi Brar 
Signed-off-by: Kyungmin Park 
---
 drivers/dma/pl330.c |  179 +++
 1 file changed, 138 insertions(+), 41 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a562d24..b272ee6 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2602,9 +2602,33 @@ static inline void fill_px(struct pl330_xfer *px,
px->src_addr = src;
 }
 
+/* Call after fixing burst size */
+static inline int get_burst_len(struct dma_pl330_desc *desc, size_t len)
+{
+   struct dma_pl330_chan *pch = desc->pchan;
+   struct pl330_info *pi = >dmac->pif;
+   int burst_len;
+
+   burst_len = pi->pcfg.data_bus_width / 8;
+   burst_len *= pi->pcfg.data_buf_dep;
+   burst_len >>= desc->rqcfg.brst_size;
+
+   /* src/dst_burst_len can't be more than 16 */
+   if (burst_len > 16)
+   burst_len = 16;
+
+   while (burst_len > 1) {
+   if (!(len % (burst_len << desc->rqcfg.brst_size)))
+   break;
+   burst_len--;
+   }
+
+   return burst_len;
+}
+
 static struct dma_pl330_desc *
 __pl330_prep_dma_memcpy(struct dma_pl330_chan *pch, dma_addr_t dst,
-   dma_addr_t src, size_t len)
+   dma_addr_t src, size_t len, int burst)
 {
struct dma_pl330_desc *desc = pl330_get_desc(pch);
 
@@ -2626,31 +2650,23 @@ __pl330_prep_dma_memcpy(struct dma_pl330_chan *pch, 
dma_addr_t dst,
 */
fill_px(>px, dst, src, len);
 
-   return desc;
-}
-
-/* Call after fixing burst size */
-static inline int get_burst_len(struct dma_pl330_desc *desc, size_t len)
-{
-   struct dma_pl330_chan *pch = desc->pchan;
-   struct pl330_info *pi = >dmac->pif;
-   int burst_len;
-
-   burst_len = pi->pcfg.data_bus_width / 8;
-   burst_len *= pi->pcfg.data_buf_dep;
-   burst_len >>= desc->rqcfg.brst_size;
-
-   /* src/dst_burst_len can't be more than 16 */
-   if (burst_len > 16)
-   burst_len = 16;
+   desc->rqcfg.src_inc = 1;
+   desc->rqcfg.dst_inc = 1;
+   desc->req.rqtype = MEMTOMEM;
 
-   while (burst_len > 1) {
-   if (!(len % (burst_len << desc->rqcfg.brst_size)))
+   while (burst > 1) {
+   if (!(len % burst) && !(len % dst) && !(len % src))
break;
-   burst_len--;
+   burst /= 2;
}
 
-   return burst_len;
+   desc->rqcfg.brst_size = 0;
+   while (burst != (1 << desc->rqcfg.brst_size))
+   desc->rqcfg.brst_size++;
+
+   desc->rqcfg.brst_len = get_burst_len(desc, len);
+
+   return desc;
 }
 
 static struct dma_async_tx_descriptor *pl330_prep_dma_cyclic(
@@ -2752,28 +2768,12 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t 
dst,
 
pi = >dmac->pif;
 
-   desc = __pl330_prep_dma_memcpy(pch, dst, src, len);
-   if (!desc)
-   return NULL;
-
-   desc->rqcfg.src_inc = 1;
-   desc->rqcfg.dst_inc = 1;
-   desc->req.rqtype = MEMTOMEM;
-
/* Select max possible burst size */
burst = pi->pcfg.data_bus_width / 8;
 
-   while (burst > 1) {
-   if (!(len % burst))
-   break;
-   burst /= 2;
-   }
-
-   desc->rqcfg.brst_size = 0;
-   while (burst != (1 << desc->rqcfg.brst_size))
-   desc->rqcfg.brst_size++;
-
-   desc->rqcfg.brst_len = get_burst_len(desc, len);
+   desc = __pl330_prep_dma_memcpy(pch, dst, src, len, burst);
+   if (!desc)
+   return NULL;
 
desc->txd.flags = flags;
 
@@ -2803,6 +2803,102 @@ static void __pl330_giveback_desc(struct dma_pl330_dmac 
*pdmac,
 }
 
 static struct dma_async_tx_descriptor *
+pl330_prep_dma_sg(struct dma_chan *chan,
+   struct scatterlist *dst_sg, unsigned int dst_nents,
+   struct scatterlist *src_sg, unsigned int src_nents,
+   unsigned long flags)
+{
+   struct dma_pl330_desc *first, *desc = NULL;
+   struct dma_pl330_chan *pch = to_pchan(chan);
+   struct pl330_info *pi;
+   dma_addr_t src, dst;
+   size_t len, dst_len = 0, src_len = 0;
+   int burst;
+
+   if (unlikely(!pch))
+   return NULL;
+
+   pi

[PATCHv2] dma: pl330: add pl330_prep_dma_sg to transfer from sglist to sglist

2013-09-13 Thread Chanho Park 
This patch adds prep_dma_sg function to transfer memory to memory which
mapped in scatter/gather list. The patch move get_burst_len to upwards to
call in the __pl330_prep_dma_mecpy. Some duplicated code was splitted off
from prep_dma_memcpy.
This patch also included previous Boojon Kim's patch[1] which fixes burst_size
calculation. The burst_size should be aligned not only length but also source
and destionation addresses.

[1] : http://lkml.indiana.edu/hypermail/linux/kernel/1201.1/00246.html

Cc: Boojin Kim boojin@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Acked-by: Jassi Brar jassisinghb...@gmail.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/dma/pl330.c |  179 +++
 1 file changed, 138 insertions(+), 41 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a562d24..b272ee6 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2602,9 +2602,33 @@ static inline void fill_px(struct pl330_xfer *px,
px-src_addr = src;
 }
 
+/* Call after fixing burst size */
+static inline int get_burst_len(struct dma_pl330_desc *desc, size_t len)
+{
+   struct dma_pl330_chan *pch = desc-pchan;
+   struct pl330_info *pi = pch-dmac-pif;
+   int burst_len;
+
+   burst_len = pi-pcfg.data_bus_width / 8;
+   burst_len *= pi-pcfg.data_buf_dep;
+   burst_len = desc-rqcfg.brst_size;
+
+   /* src/dst_burst_len can't be more than 16 */
+   if (burst_len  16)
+   burst_len = 16;
+
+   while (burst_len  1) {
+   if (!(len % (burst_len  desc-rqcfg.brst_size)))
+   break;
+   burst_len--;
+   }
+
+   return burst_len;
+}
+
 static struct dma_pl330_desc *
 __pl330_prep_dma_memcpy(struct dma_pl330_chan *pch, dma_addr_t dst,
-   dma_addr_t src, size_t len)
+   dma_addr_t src, size_t len, int burst)
 {
struct dma_pl330_desc *desc = pl330_get_desc(pch);
 
@@ -2626,31 +2650,23 @@ __pl330_prep_dma_memcpy(struct dma_pl330_chan *pch, 
dma_addr_t dst,
 */
fill_px(desc-px, dst, src, len);
 
-   return desc;
-}
-
-/* Call after fixing burst size */
-static inline int get_burst_len(struct dma_pl330_desc *desc, size_t len)
-{
-   struct dma_pl330_chan *pch = desc-pchan;
-   struct pl330_info *pi = pch-dmac-pif;
-   int burst_len;
-
-   burst_len = pi-pcfg.data_bus_width / 8;
-   burst_len *= pi-pcfg.data_buf_dep;
-   burst_len = desc-rqcfg.brst_size;
-
-   /* src/dst_burst_len can't be more than 16 */
-   if (burst_len  16)
-   burst_len = 16;
+   desc-rqcfg.src_inc = 1;
+   desc-rqcfg.dst_inc = 1;
+   desc-req.rqtype = MEMTOMEM;
 
-   while (burst_len  1) {
-   if (!(len % (burst_len  desc-rqcfg.brst_size)))
+   while (burst  1) {
+   if (!(len % burst)  !(len % dst)  !(len % src))
break;
-   burst_len--;
+   burst /= 2;
}
 
-   return burst_len;
+   desc-rqcfg.brst_size = 0;
+   while (burst != (1  desc-rqcfg.brst_size))
+   desc-rqcfg.brst_size++;
+
+   desc-rqcfg.brst_len = get_burst_len(desc, len);
+
+   return desc;
 }
 
 static struct dma_async_tx_descriptor *pl330_prep_dma_cyclic(
@@ -2752,28 +2768,12 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t 
dst,
 
pi = pch-dmac-pif;
 
-   desc = __pl330_prep_dma_memcpy(pch, dst, src, len);
-   if (!desc)
-   return NULL;
-
-   desc-rqcfg.src_inc = 1;
-   desc-rqcfg.dst_inc = 1;
-   desc-req.rqtype = MEMTOMEM;
-
/* Select max possible burst size */
burst = pi-pcfg.data_bus_width / 8;
 
-   while (burst  1) {
-   if (!(len % burst))
-   break;
-   burst /= 2;
-   }
-
-   desc-rqcfg.brst_size = 0;
-   while (burst != (1  desc-rqcfg.brst_size))
-   desc-rqcfg.brst_size++;
-
-   desc-rqcfg.brst_len = get_burst_len(desc, len);
+   desc = __pl330_prep_dma_memcpy(pch, dst, src, len, burst);
+   if (!desc)
+   return NULL;
 
desc-txd.flags = flags;
 
@@ -2803,6 +2803,102 @@ static void __pl330_giveback_desc(struct dma_pl330_dmac 
*pdmac,
 }
 
 static struct dma_async_tx_descriptor *
+pl330_prep_dma_sg(struct dma_chan *chan,
+   struct scatterlist *dst_sg, unsigned int dst_nents,
+   struct scatterlist *src_sg, unsigned int src_nents,
+   unsigned long flags)
+{
+   struct dma_pl330_desc *first, *desc = NULL;
+   struct dma_pl330_chan *pch = to_pchan(chan);
+   struct pl330_info *pi;
+   dma_addr_t src, dst;
+   size_t len, dst_len = 0, src_len = 0;
+   int burst;
+
+   if (unlikely(!pch))
+   return NULL;
+
+   pi = pch-dmac-pif;
+
+   /* basic sanity checks */
+   if (dst_nents == 0 || src_nents == 0)
+   return