date:20170121

Re: [PATCH 3/5] s390/pci: Move three assignments for the variable "rc" in clp_normal_command()

2017-01-21 Thread Christophe JAILLET


Le 21/01/2017 à 19:12, SF Markus Elfring a écrit :

@@ -541,9 +543,8 @@ static int clp_normal_command(struct clp_req *req)
if (rc)
goto out_free;
  
-	rc = -EFAULT;

if (copy_to_user(uptr, lpcb, PAGE_SIZE) != 0)
-   goto out_free;
+   rc = -EFAULT;
  
  	rc = 0;
  


With this, we return 0 (success) on error.

CJ

Re: [PATCH 3/5] s390/pci: Move three assignments for the variable "rc" in clp_normal_command()

2017-01-21 Thread Christophe JAILLET


Le 21/01/2017 à 19:12, SF Markus Elfring a écrit :

@@ -541,9 +543,8 @@ static int clp_normal_command(struct clp_req *req)
if (rc)
goto out_free;
  
-	rc = -EFAULT;

if (copy_to_user(uptr, lpcb, PAGE_SIZE) != 0)
-   goto out_free;
+   rc = -EFAULT;
  
  	rc = 0;
  


With this, we return 0 (success) on error.

CJ

Re: [PATCH] net/mlx4: use rb_entry()

2017-01-21 Thread Leon Romanovsky

On Fri, Jan 20, 2017 at 10:36:57PM +0800, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang 
> ---
>  drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

I don't understand completely the rationale behind this conversion.
rb_entry == container_of, why do we need another name for it?

>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c 
> b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> index 1822382..6da6e01 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> @@ -236,8 +236,8 @@ static void *res_tracker_lookup(struct rb_root *root, u64 
> res_id)
>   struct rb_node *node = root->rb_node;
>
>   while (node) {
> - struct res_common *res = container_of(node, struct res_common,
> -   node);
> + struct res_common *res = rb_entry(node, struct res_common,
> +   node);
>
>   if (res_id < res->res_id)
>   node = node->rb_left;
> @@ -255,8 +255,8 @@ static int res_tracker_insert(struct rb_root *root, 
> struct res_common *res)
>
>   /* Figure out where to put new node */
>   while (*new) {
> - struct res_common *this = container_of(*new, struct res_common,
> -node);
> + struct res_common *this = rb_entry(*new, struct res_common,
> +node);
>
>   parent = *new;
>   if (res->res_id < this->res_id)
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Re: [PATCH] net/mlx4: use rb_entry()

2017-01-21 Thread Leon Romanovsky

On Fri, Jan 20, 2017 at 10:36:57PM +0800, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang 
> ---
>  drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

I don't understand completely the rationale behind this conversion.
rb_entry == container_of, why do we need another name for it?

>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c 
> b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> index 1822382..6da6e01 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> @@ -236,8 +236,8 @@ static void *res_tracker_lookup(struct rb_root *root, u64 
> res_id)
>   struct rb_node *node = root->rb_node;
>
>   while (node) {
> - struct res_common *res = container_of(node, struct res_common,
> -   node);
> + struct res_common *res = rb_entry(node, struct res_common,
> +   node);
>
>   if (res_id < res->res_id)
>   node = node->rb_left;
> @@ -255,8 +255,8 @@ static int res_tracker_insert(struct rb_root *root, 
> struct res_common *res)
>
>   /* Figure out where to put new node */
>   while (*new) {
> - struct res_common *this = container_of(*new, struct res_common,
> -node);
> + struct res_common *this = rb_entry(*new, struct res_common,
> +node);
>
>   parent = *new;
>   if (res->res_id < this->res_id)
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Re: [PATCH] PCI: rockchip: mark PM functions as __maybe_unused

2017-01-21 Thread Shawn Lin


Hi Arnd,

On 2017/1/21 0:24, Arnd Bergmann wrote:

When CONFIG_PM_SLEEP is disabled, we get harmless build warnings:

host/pcie-rockchip.c:1267:12: error: 'rockchip_pcie_resume_noirq' defined but 
not used [-Werror=unused-function]
host/pcie-rockchip.c:1240:12: error: 'rockchip_pcie_suspend_noirq' defined but 
not used [-Werror=unused-function]

Marking both functions as __maybe_unused avoids the warning without
the need for #ifdef around them.


Sorry for introducing this warning, and thanks for fixing it.

Acked-by: Shawn Lin 



Fixes: 013dd3d5e183 ("PCI: rockchip: Add system PM support")
Signed-off-by: Arnd Bergmann 
---
 drivers/pci/host/pcie-rockchip.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 0d6e8ee5b017..b975116d2b03 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -1237,7 +1237,7 @@ static int rockchip_pcie_wait_l2(struct rockchip_pcie 
*rockchip)
return 0;
 }

-static int rockchip_pcie_suspend_noirq(struct device *dev)
+static int __maybe_unused rockchip_pcie_suspend_noirq(struct device *dev)
 {
struct rockchip_pcie *rockchip = dev_get_drvdata(dev);
int ret;
@@ -1264,7 +1264,7 @@ static int rockchip_pcie_suspend_noirq(struct device *dev)
return ret;
 }

-static int rockchip_pcie_resume_noirq(struct device *dev)
+static int __maybe_unused rockchip_pcie_resume_noirq(struct device *dev)
 {
struct rockchip_pcie *rockchip = dev_get_drvdata(dev);
int err;




--
Best Regards
Shawn Lin

Re: [PATCH] PCI: rockchip: mark PM functions as __maybe_unused

2017-01-21 Thread Shawn Lin


Hi Arnd,

On 2017/1/21 0:24, Arnd Bergmann wrote:

When CONFIG_PM_SLEEP is disabled, we get harmless build warnings:

host/pcie-rockchip.c:1267:12: error: 'rockchip_pcie_resume_noirq' defined but 
not used [-Werror=unused-function]
host/pcie-rockchip.c:1240:12: error: 'rockchip_pcie_suspend_noirq' defined but 
not used [-Werror=unused-function]

Marking both functions as __maybe_unused avoids the warning without
the need for #ifdef around them.


Sorry for introducing this warning, and thanks for fixing it.

Acked-by: Shawn Lin 



Fixes: 013dd3d5e183 ("PCI: rockchip: Add system PM support")
Signed-off-by: Arnd Bergmann 
---
 drivers/pci/host/pcie-rockchip.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 0d6e8ee5b017..b975116d2b03 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -1237,7 +1237,7 @@ static int rockchip_pcie_wait_l2(struct rockchip_pcie 
*rockchip)
return 0;
 }

-static int rockchip_pcie_suspend_noirq(struct device *dev)
+static int __maybe_unused rockchip_pcie_suspend_noirq(struct device *dev)
 {
struct rockchip_pcie *rockchip = dev_get_drvdata(dev);
int ret;
@@ -1264,7 +1264,7 @@ static int rockchip_pcie_suspend_noirq(struct device *dev)
return ret;
 }

-static int rockchip_pcie_resume_noirq(struct device *dev)
+static int __maybe_unused rockchip_pcie_resume_noirq(struct device *dev)
 {
struct rockchip_pcie *rockchip = dev_get_drvdata(dev);
int err;




--
Best Regards
Shawn Lin

[PATCH v3] vfio error recovery: kernel support

2017-01-21 Thread Michael S. Tsirkin

This is a design and an initial patch for kernel side for AER
support in VFIO.

0. What happens now (PCIE AER only)
   Fatal errors cause a link reset.
   Non fatal errors don't.
   All errors stop the VM eventually, but not immediately
   because it's detected and reported asynchronously.
   Interrupts are forwarded as usual.
   Correctable errors are not reported to guest at all.
   Note: PPC EEH is different. This focuses on AER.

1. Correctable errors
   I don't see a need to report these to guest. So let's not.

2. Fatal errors
   It's not easy to handle them gracefully since link reset
   is needed. As a first step, let's use the existing mechanism
   in that case.

2. Non-fatal errors
   Here we could make progress by reporting them to guest
   and have guest handle them.
   Issues:
a. this behaviour should only be enabled with new userspace
   old userspace should work without changes
Suggestion: One way to address this would be to add a new eventfd
non_fatal_err_trigger. If not set, invoke err_trigger.

b. drivers are supposed to stop MMIO when error is reported
if vm keeps going, we will keep doing MMIO/config
Suggestion 1: ignore this. vm stop happens much later when
userspace runs anyway, so we are not making things much worse
Suggestion 2: try to stop MMIO/config, resume on resume call

Patch below implements Suggestion 1.

Note that although this is really against the documentation, which states
error_detected() is the point at which the driver should quiesce the
device and not touch it further (until diagnostic poking at
mmio_enabled or full access at resume callback).
Fixing this won't be easy.
However, this is not a regression.

Also note this does nothing about interrupts, documentation
suggests returning IRQ_NONE until reset.
Again, not a regression.

c. PF driver might detect that function is completely broken,
if vm keeps going, we will keep doing MMIO/config
Suggestion 1: ignore this. vm stop happens much later when
userspace runs anyway, so we are not making things much worse
Suggestion 2: detect this and invoke err_trigger to stop VM

Patch below implements Suggestion 2.

Aside: what should we return if driver is e.g. being unbound?
For slot_reset, this implements Alex's suggestion to
return PCI_ERS_RESULT_NONE. It's worth considering whether
same should happen in error_report.

Signed-off-by: Michael S. Tsirkin 
---

Completely untested by myself. Will be build-tested by 0-day :)

changes from v2:
- fix build error reported by 0 day testing
changes from v1:
- more detailed commit log
- fixed a couple of bugs

Alex, pls review but don't apply until we get
- userspace updated to use the new interface
- testing reports

Cao jin, could you pls look into integrating this
with your userspace patches?


 drivers/vfio/pci/vfio_pci.c | 34 +-
 drivers/vfio/pci/vfio_pci_intrs.c   | 19 +++
 drivers/vfio/pci/vfio_pci_private.h |  1 +
 include/linux/virtio_config.h   | 12 +++-
 include/uapi/linux/vfio.h   |  1 +
 5 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 0e33278..7d58b8f 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1296,7 +1296,9 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct 
pci_dev *pdev,
 
mutex_lock(>igate);
 
-   if (vdev->err_trigger)
+   if (state == pci_channel_io_normal && vdev->non_fatal_err_trigger)
+   eventfd_signal(vdev->non_fatal_err_trigger, 1);
+   else if (vdev->err_trigger)
eventfd_signal(vdev->err_trigger, 1);
 
mutex_unlock(>igate);
@@ -1306,8 +1308,38 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct 
pci_dev *pdev,
return PCI_ERS_RESULT_CAN_RECOVER;
 }
 
+static pci_ers_result_t vfio_pci_aer_slot_reset(struct pci_dev *pdev)
+{
+   struct vfio_pci_device *vdev;
+   struct vfio_device *device;
+   static pci_ers_result_t err = PCI_ERS_RESULT_NONE;
+
+   device = vfio_device_get_from_dev(>dev);
+   if (!device)
+   goto err_dev;
+
+   vdev = vfio_device_data(device);
+   if (!vdev)
+   goto err_data;
+
+   mutex_lock(>igate);
+
+   if (vdev->err_trigger)
+   eventfd_signal(vdev->err_trigger, 1);
+
+   mutex_unlock(>igate);
+
+   err = PCI_ERS_RESULT_RECOVERED;
+
+err_data:
+   vfio_device_put(device);
+err_dev:
+   return err;
+}
+
 static const struct pci_error_handlers vfio_err_handlers = {
.error_detected = vfio_pci_aer_err_detected,
+   .slot_reset = vfio_pci_aer_slot_reset,
 };
 
 static struct pci_driver vfio_pci_driver = {
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
b/drivers/vfio/pci/vfio_pci_intrs.c
index 1c46045..e883db5 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++

[PATCH v3] vfio error recovery: kernel support

2017-01-21 Thread Michael S. Tsirkin

This is a design and an initial patch for kernel side for AER
support in VFIO.

0. What happens now (PCIE AER only)
   Fatal errors cause a link reset.
   Non fatal errors don't.
   All errors stop the VM eventually, but not immediately
   because it's detected and reported asynchronously.
   Interrupts are forwarded as usual.
   Correctable errors are not reported to guest at all.
   Note: PPC EEH is different. This focuses on AER.

1. Correctable errors
   I don't see a need to report these to guest. So let's not.

2. Fatal errors
   It's not easy to handle them gracefully since link reset
   is needed. As a first step, let's use the existing mechanism
   in that case.

2. Non-fatal errors
   Here we could make progress by reporting them to guest
   and have guest handle them.
   Issues:
a. this behaviour should only be enabled with new userspace
   old userspace should work without changes
Suggestion: One way to address this would be to add a new eventfd
non_fatal_err_trigger. If not set, invoke err_trigger.

b. drivers are supposed to stop MMIO when error is reported
if vm keeps going, we will keep doing MMIO/config
Suggestion 1: ignore this. vm stop happens much later when
userspace runs anyway, so we are not making things much worse
Suggestion 2: try to stop MMIO/config, resume on resume call

Patch below implements Suggestion 1.

Note that although this is really against the documentation, which states
error_detected() is the point at which the driver should quiesce the
device and not touch it further (until diagnostic poking at
mmio_enabled or full access at resume callback).
Fixing this won't be easy.
However, this is not a regression.

Also note this does nothing about interrupts, documentation
suggests returning IRQ_NONE until reset.
Again, not a regression.

c. PF driver might detect that function is completely broken,
if vm keeps going, we will keep doing MMIO/config
Suggestion 1: ignore this. vm stop happens much later when
userspace runs anyway, so we are not making things much worse
Suggestion 2: detect this and invoke err_trigger to stop VM

Patch below implements Suggestion 2.

Aside: what should we return if driver is e.g. being unbound?
For slot_reset, this implements Alex's suggestion to
return PCI_ERS_RESULT_NONE. It's worth considering whether
same should happen in error_report.

Signed-off-by: Michael S. Tsirkin 
---

Completely untested by myself. Will be build-tested by 0-day :)

changes from v2:
- fix build error reported by 0 day testing
changes from v1:
- more detailed commit log
- fixed a couple of bugs

Alex, pls review but don't apply until we get
- userspace updated to use the new interface
- testing reports

Cao jin, could you pls look into integrating this
with your userspace patches?


 drivers/vfio/pci/vfio_pci.c | 34 +-
 drivers/vfio/pci/vfio_pci_intrs.c   | 19 +++
 drivers/vfio/pci/vfio_pci_private.h |  1 +
 include/linux/virtio_config.h   | 12 +++-
 include/uapi/linux/vfio.h   |  1 +
 5 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 0e33278..7d58b8f 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1296,7 +1296,9 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct 
pci_dev *pdev,
 
mutex_lock(>igate);
 
-   if (vdev->err_trigger)
+   if (state == pci_channel_io_normal && vdev->non_fatal_err_trigger)
+   eventfd_signal(vdev->non_fatal_err_trigger, 1);
+   else if (vdev->err_trigger)
eventfd_signal(vdev->err_trigger, 1);
 
mutex_unlock(>igate);
@@ -1306,8 +1308,38 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct 
pci_dev *pdev,
return PCI_ERS_RESULT_CAN_RECOVER;
 }
 
+static pci_ers_result_t vfio_pci_aer_slot_reset(struct pci_dev *pdev)
+{
+   struct vfio_pci_device *vdev;
+   struct vfio_device *device;
+   static pci_ers_result_t err = PCI_ERS_RESULT_NONE;
+
+   device = vfio_device_get_from_dev(>dev);
+   if (!device)
+   goto err_dev;
+
+   vdev = vfio_device_data(device);
+   if (!vdev)
+   goto err_data;
+
+   mutex_lock(>igate);
+
+   if (vdev->err_trigger)
+   eventfd_signal(vdev->err_trigger, 1);
+
+   mutex_unlock(>igate);
+
+   err = PCI_ERS_RESULT_RECOVERED;
+
+err_data:
+   vfio_device_put(device);
+err_dev:
+   return err;
+}
+
 static const struct pci_error_handlers vfio_err_handlers = {
.error_detected = vfio_pci_aer_err_detected,
+   .slot_reset = vfio_pci_aer_slot_reset,
 };
 
 static struct pci_driver vfio_pci_driver = {
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
b/drivers/vfio/pci/vfio_pci_intrs.c
index 1c46045..e883db5 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c

[PATCH] Input: max11801_ts - drop call to input_set_drvdata()

2017-01-21 Thread Dmitry Torokhov

Nobody calls input_get_drvdata() so setting it is not required.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/max11801_ts.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/input/touchscreen/max11801_ts.c 
b/drivers/input/touchscreen/max11801_ts.c
index d87b89da114e..a595ae5284e3 100644
--- a/drivers/input/touchscreen/max11801_ts.c
+++ b/drivers/input/touchscreen/max11801_ts.c
@@ -199,7 +199,6 @@ static int max11801_ts_probe(struct i2c_client *client,
__set_bit(BTN_TOUCH, input_dev->keybit);
input_set_abs_params(input_dev, ABS_X, 0, MAX11801_MAX_X, 0, 0);
input_set_abs_params(input_dev, ABS_Y, 0, MAX11801_MAX_Y, 0, 0);
-   input_set_drvdata(input_dev, data);
 
max11801_ts_phy_init(data);
 
-- 
2.11.0.483.g087da7b7c-goog


-- 
Dmitry

[PATCH] Input: max11801_ts - drop call to input_set_drvdata()

2017-01-21 Thread Dmitry Torokhov

Nobody calls input_get_drvdata() so setting it is not required.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/max11801_ts.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/input/touchscreen/max11801_ts.c 
b/drivers/input/touchscreen/max11801_ts.c
index d87b89da114e..a595ae5284e3 100644
--- a/drivers/input/touchscreen/max11801_ts.c
+++ b/drivers/input/touchscreen/max11801_ts.c
@@ -199,7 +199,6 @@ static int max11801_ts_probe(struct i2c_client *client,
__set_bit(BTN_TOUCH, input_dev->keybit);
input_set_abs_params(input_dev, ABS_X, 0, MAX11801_MAX_X, 0, 0);
input_set_abs_params(input_dev, ABS_Y, 0, MAX11801_MAX_Y, 0, 0);
-   input_set_drvdata(input_dev, data);
 
max11801_ts_phy_init(data);
 
-- 
2.11.0.483.g087da7b7c-goog


-- 
Dmitry

[PULL] vhost/virtio: cleanups and fixes

2017-01-21 Thread Michael S. Tsirkin

The following changes since commit 49def1853334396f948dcb4cedb9347abb318df5:

  Linux 4.10-rc4 (2017-01-15 16:21:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus

for you to fetch changes up to 0db1dba5dfaf70fb3baf07973996db2078528cde:

  virtio/s390: virtio: constify virtio_config_ops structures (2017-01-19 
23:46:34 +0200)


virtio, vhost: fixes, cleanups

Random fixes and cleanups that accumulated over the time.

Signed-off-by: Michael S. Tsirkin 


Bhumika Goyal (2):
  vhost: scsi: constify target_core_fabric_ops structures
  virtio/s390: virtio: constify virtio_config_ops structures

Colin Ian King (1):
  virtio/s390: add missing \n to end of dev_err message

Dan Carpenter (1):
  vhost/scsi: silence uninitialized variable warning

G. Campana (1):
  virtio_console: fix a crash in config_work_handler

Halil Pasic (2):
  tools/virtio/ringtest: fix run-on-all.sh for offline cpus
  tools/virtio/ringtest: tweaks for s390

Pierre Morel (1):
  virtio/s390: support READ_STATUS command for virtio-ccw

 drivers/char/virtio_console.c   |  2 +-
 drivers/s390/virtio/virtio_ccw.c| 29 +++--
 drivers/vhost/scsi.c|  4 ++--
 tools/virtio/ringtest/main.h| 12 
 tools/virtio/ringtest/run-on-all.sh |  5 +++--
 5 files changed, 45 insertions(+), 7 deletions(-)

[PULL] vhost/virtio: cleanups and fixes

2017-01-21 Thread Michael S. Tsirkin

The following changes since commit 49def1853334396f948dcb4cedb9347abb318df5:

  Linux 4.10-rc4 (2017-01-15 16:21:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus

for you to fetch changes up to 0db1dba5dfaf70fb3baf07973996db2078528cde:

  virtio/s390: virtio: constify virtio_config_ops structures (2017-01-19 
23:46:34 +0200)


virtio, vhost: fixes, cleanups

Random fixes and cleanups that accumulated over the time.

Signed-off-by: Michael S. Tsirkin 


Bhumika Goyal (2):
  vhost: scsi: constify target_core_fabric_ops structures
  virtio/s390: virtio: constify virtio_config_ops structures

Colin Ian King (1):
  virtio/s390: add missing \n to end of dev_err message

Dan Carpenter (1):
  vhost/scsi: silence uninitialized variable warning

G. Campana (1):
  virtio_console: fix a crash in config_work_handler

Halil Pasic (2):
  tools/virtio/ringtest: fix run-on-all.sh for offline cpus
  tools/virtio/ringtest: tweaks for s390

Pierre Morel (1):
  virtio/s390: support READ_STATUS command for virtio-ccw

 drivers/char/virtio_console.c   |  2 +-
 drivers/s390/virtio/virtio_ccw.c| 29 +++--
 drivers/vhost/scsi.c|  4 ++--
 tools/virtio/ringtest/main.h| 12 
 tools/virtio/ringtest/run-on-all.sh |  5 +++--
 5 files changed, 45 insertions(+), 7 deletions(-)

[PATCH] sched: Documentation: sched-rt-group: fix example error

2017-01-21 Thread Zhou Chengming

I feel that the example given in the document to show the possibility
of task starvation of configurable period is wrong.

The example says group A and B both have 50% bandwidth, and a while (1)
loop in A will run for the full period of B and can starve B's tasks.

So I think the runtime of group A should be 5us, then the period and
runtime of group B should be 5us and 25000us.

Signed-off-by: Zhou Chengming 
---
 Documentation/scheduler/sched-rt-group.txt |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/scheduler/sched-rt-group.txt 
b/Documentation/scheduler/sched-rt-group.txt
index a03f0d9..d8fce3e 100644
--- a/Documentation/scheduler/sched-rt-group.txt
+++ b/Documentation/scheduler/sched-rt-group.txt
@@ -158,11 +158,11 @@ as its prone to starvation without deadline scheduling.
 Consider two sibling groups A and B; both have 50% bandwidth, but A's
 period is twice the length of B's.
 
-* group A: period=10us, runtime=1us
-   - this runs for 0.01s once every 0.1s
+* group A: period=10us, runtime=5us
+   - this runs for 0.05s once every 0.1s
 
-* group B: period= 5us, runtime=1us
-   - this runs for 0.01s twice every 0.1s (or once every 0.05 sec).
+* group B: period= 5us, runtime=25000us
+   - this runs for 0.025s twice every 0.1s (or once every 0.05 sec).
 
 This means that currently a while (1) loop in A will run for the full period of
 B and can starve B's tasks (assuming they are of lower priority) for a whole
-- 
1.7.7

[PATCH] sched: Documentation: sched-rt-group: fix example error

2017-01-21 Thread Zhou Chengming

I feel that the example given in the document to show the possibility
of task starvation of configurable period is wrong.

The example says group A and B both have 50% bandwidth, and a while (1)
loop in A will run for the full period of B and can starve B's tasks.

So I think the runtime of group A should be 5us, then the period and
runtime of group B should be 5us and 25000us.

Signed-off-by: Zhou Chengming 
---
 Documentation/scheduler/sched-rt-group.txt |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/scheduler/sched-rt-group.txt 
b/Documentation/scheduler/sched-rt-group.txt
index a03f0d9..d8fce3e 100644
--- a/Documentation/scheduler/sched-rt-group.txt
+++ b/Documentation/scheduler/sched-rt-group.txt
@@ -158,11 +158,11 @@ as its prone to starvation without deadline scheduling.
 Consider two sibling groups A and B; both have 50% bandwidth, but A's
 period is twice the length of B's.
 
-* group A: period=10us, runtime=1us
-   - this runs for 0.01s once every 0.1s
+* group A: period=10us, runtime=5us
+   - this runs for 0.05s once every 0.1s
 
-* group B: period= 5us, runtime=1us
-   - this runs for 0.01s twice every 0.1s (or once every 0.05 sec).
+* group B: period= 5us, runtime=25000us
+   - this runs for 0.025s twice every 0.1s (or once every 0.05 sec).
 
 This means that currently a while (1) loop in A will run for the full period of
 B and can starve B's tasks (assuming they are of lower priority) for a whole
-- 
1.7.7

Re: [PATCH v2] vfio error recovery: kernel support

2017-01-21 Thread kbuild test robot

Hi Michael,

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

url:
https://github.com/0day-ci/linux/commits/Michael-S-Tsirkin/vfio-error-recovery-kernel-support/20170122-133030
base:   https://github.com/awilliam/linux-vfio.git next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> /kbuild/src/lkp/drivers/vfio/pci/vfio_pci.c:1329:16: error: initialization 
>> from incompatible pointer type [-Werror=incompatible-pointer-types]
 .slot_reset = vfio_pci_aer_slot_reset,
   ^~~
   /kbuild/src/lkp/drivers/vfio/pci/vfio_pci.c:1329:16: note: (near 
initialization for 'vfio_err_handlers.slot_reset')
   cc1: some warnings being treated as errors

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


.config.gz
Description: application/gzip

Re: [PATCH v2] vfio error recovery: kernel support

2017-01-21 Thread kbuild test robot

Hi Michael,

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

url:
https://github.com/0day-ci/linux/commits/Michael-S-Tsirkin/vfio-error-recovery-kernel-support/20170122-133030
base:   https://github.com/awilliam/linux-vfio.git next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> /kbuild/src/lkp/drivers/vfio/pci/vfio_pci.c:1329:16: error: initialization 
>> from incompatible pointer type [-Werror=incompatible-pointer-types]
 .slot_reset = vfio_pci_aer_slot_reset,
   ^~~
   /kbuild/src/lkp/drivers/vfio/pci/vfio_pci.c:1329:16: note: (near 
initialization for 'vfio_err_handlers.slot_reset')
   cc1: some warnings being treated as errors

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


.config.gz
Description: application/gzip

Re: [PATCH v2 09/26] drm/rockchip: dw-mipi-dsi: respect message flags

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

Instead of always sending commands in LP mode, respect the
MIPI_DSI_MSG_USE_LPM flag to decide how to send each message.  Also
request acks if MIPI_DSI_MSG_REQ_ACK is set.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16 +++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 92dbc3e56603..15d33c3c8cb7 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -542,6 +542,19 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host 
*host,
return 0;
  }
  
+static void dw_mipi_message_config(struct dw_mipi_dsi *dsi,

+  const struct mipi_dsi_msg *msg)
+{
+   u32 val = 0;
+
+   if (msg->flags & MIPI_DSI_MSG_REQ_ACK)
+   val |= EN_ACK_RQST;
+   if (msg->flags & MIPI_DSI_MSG_USE_LPM)
+   val |= CMD_MODE_ALL_LP;
+
+   dsi_write(dsi, DSI_CMD_MODE_CFG, val);
+}
+
  static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
  {
int ret;
@@ -634,6 +647,8 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
mipi_dsi_host *host,
struct dw_mipi_dsi *dsi = host_to_dsi(host);
int ret;
  
+	dw_mipi_message_config(dsi, msg);

+
switch (msg->type) {
case MIPI_DSI_DCS_SHORT_WRITE:
case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
@@ -745,7 +760,6 @@ static void dw_mipi_dsi_command_mode_config(struct 
dw_mipi_dsi *dsi)
  {
dsi_write(dsi, DSI_TO_CNT_CFG, HSTX_TO_CNT(1000) | LPRX_TO_CNT(1000));
dsi_write(dsi, DSI_BTA_TO_CNT, 0xd00);
-   dsi_write(dsi, DSI_CMD_MODE_CFG, CMD_MODE_ALL_LP);
dsi_write(dsi, DSI_MODE_CFG, ENABLE_CMD_MODE);
  }

Re: [PATCH v2 09/26] drm/rockchip: dw-mipi-dsi: respect message flags

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

Instead of always sending commands in LP mode, respect the
MIPI_DSI_MSG_USE_LPM flag to decide how to send each message.  Also
request acks if MIPI_DSI_MSG_REQ_ACK is set.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16 +++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 92dbc3e56603..15d33c3c8cb7 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -542,6 +542,19 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host 
*host,
return 0;
  }
  
+static void dw_mipi_message_config(struct dw_mipi_dsi *dsi,

+  const struct mipi_dsi_msg *msg)
+{
+   u32 val = 0;
+
+   if (msg->flags & MIPI_DSI_MSG_REQ_ACK)
+   val |= EN_ACK_RQST;
+   if (msg->flags & MIPI_DSI_MSG_USE_LPM)
+   val |= CMD_MODE_ALL_LP;
+
+   dsi_write(dsi, DSI_CMD_MODE_CFG, val);
+}
+
  static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
  {
int ret;
@@ -634,6 +647,8 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
mipi_dsi_host *host,
struct dw_mipi_dsi *dsi = host_to_dsi(host);
int ret;
  
+	dw_mipi_message_config(dsi, msg);

+
switch (msg->type) {
case MIPI_DSI_DCS_SHORT_WRITE:
case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
@@ -745,7 +760,6 @@ static void dw_mipi_dsi_command_mode_config(struct 
dw_mipi_dsi *dsi)
  {
dsi_write(dsi, DSI_TO_CNT_CFG, HSTX_TO_CNT(1000) | LPRX_TO_CNT(1000));
dsi_write(dsi, DSI_BTA_TO_CNT, 0xd00);
-   dsi_write(dsi, DSI_CMD_MODE_CFG, CMD_MODE_ALL_LP);
dsi_write(dsi, DSI_MODE_CFG, ENABLE_CMD_MODE);
  }

Re: [PATCH v2 08/26] drm/rockchip: dw-mipi-dsi: include bad value in error message

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 


On 01/22/2017 12:31 AM, John Keeping wrote:

As an aid to debugging.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 2e6ad4591ebf..92dbc3e56603 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -644,7 +644,8 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
mipi_dsi_host *host,
ret = dw_mipi_dsi_dcs_long_write(dsi, msg);
break;
default:
-   dev_err(dsi->dev, "unsupported message type\n");
+   dev_err(dsi->dev, "unsupported message type 0x%02x\n",
+   msg->type);
ret = -EINVAL;
}

Re: [PATCH v2 08/26] drm/rockchip: dw-mipi-dsi: include bad value in error message

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 


On 01/22/2017 12:31 AM, John Keeping wrote:

As an aid to debugging.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 2e6ad4591ebf..92dbc3e56603 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -644,7 +644,8 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
mipi_dsi_host *host,
ret = dw_mipi_dsi_dcs_long_write(dsi, msg);
break;
default:
-   dev_err(dsi->dev, "unsupported message type\n");
+   dev_err(dsi->dev, "unsupported message type 0x%02x\n",
+   msg->type);
ret = -EINVAL;
}

Re: [PATCH v2 07/26] drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

As a side-effect of this, encode the endianness explicitly rather than
casting a u16.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 4be1ff3a42bb..2e6ad4591ebf 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -572,8 +572,13 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
dw_mipi_dsi *dsi, u32 hdr_val)
  static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
   const struct mipi_dsi_msg *msg)
  {
-   const u16 *tx_buf = msg->tx_buf;
-   u32 val = GEN_HDATA(*tx_buf) | GEN_HTYPE(msg->type);
+   const u8 *tx_buf = msg->tx_buf;
+   u32 val = GEN_HTYPE(msg->type);
+
+   if (msg->tx_len > 0)
+   val |= GEN_HDATA(tx_buf[0]);
+   if (msg->tx_len > 1)
+   val |= GEN_HDATA(tx_buf[1] << 8);
  
  	if (msg->tx_len > 2) {

dev_err(dsi->dev, "too long tx buf length %zu for short 
write\n",

Re: [PATCH v2 07/26] drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

As a side-effect of this, encode the endianness explicitly rather than
casting a u16.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 4be1ff3a42bb..2e6ad4591ebf 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -572,8 +572,13 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
dw_mipi_dsi *dsi, u32 hdr_val)
  static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
   const struct mipi_dsi_msg *msg)
  {
-   const u16 *tx_buf = msg->tx_buf;
-   u32 val = GEN_HDATA(*tx_buf) | GEN_HTYPE(msg->type);
+   const u8 *tx_buf = msg->tx_buf;
+   u32 val = GEN_HTYPE(msg->type);
+
+   if (msg->tx_len > 0)
+   val |= GEN_HDATA(tx_buf[0]);
+   if (msg->tx_len > 1)
+   val |= GEN_HDATA(tx_buf[1] << 8);
  
  	if (msg->tx_len > 2) {

dev_err(dsi->dev, "too long tx buf length %zu for short 
write\n",

Re: [PATCH v2 06/26] drm/rockchip: dw-mipi-dsi: fix generic packet status check

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits
are set so we can't just check "val & mask" because that will be true if
either bit is set.
According to DW mipi dsi controller databook, you are right. we should 
check both the 2 BIT.

gen_pld_w_empty:
This bit indicates the empty status of the generic write payload FIFO.
Dependency : DSI_GENERIC = 1. Otherwise, this bit is reserved.
Value after reset : 0x1


Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 4cbbbcb619b7..4be1ff3a42bb 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -545,7 +545,7 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host 
*host,
  static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
  {
int ret;
-   u32 val;
+   u32 val, mask;
  
  	ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,

 val, !(val & GEN_CMD_FULL), 1000,
@@ -557,8 +557,9 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi 
*dsi, u32 hdr_val)
  
  	dsi_write(dsi, DSI_GEN_HDR, hdr_val);
  
+	mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;

ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
-val, val & (GEN_CMD_EMPTY | GEN_PLD_W_EMPTY),
+val, (val & mask) == mask,
 1000, CMD_PKT_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev, "failed to write command FIFO\n");

Re: [PATCH v2 06/26] drm/rockchip: dw-mipi-dsi: fix generic packet status check

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits
are set so we can't just check "val & mask" because that will be true if
either bit is set.
According to DW mipi dsi controller databook, you are right. we should 
check both the 2 BIT.

gen_pld_w_empty:
This bit indicates the empty status of the generic write payload FIFO.
Dependency : DSI_GENERIC = 1. Otherwise, this bit is reserved.
Value after reset : 0x1


Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 4cbbbcb619b7..4be1ff3a42bb 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -545,7 +545,7 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host 
*host,
  static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
  {
int ret;
-   u32 val;
+   u32 val, mask;
  
  	ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,

 val, !(val & GEN_CMD_FULL), 1000,
@@ -557,8 +557,9 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi 
*dsi, u32 hdr_val)
  
  	dsi_write(dsi, DSI_GEN_HDR, hdr_val);
  
+	mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;

ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
-val, val & (GEN_CMD_EMPTY | GEN_PLD_W_EMPTY),
+val, (val & mask) == mask,
 1000, CMD_PKT_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev, "failed to write command FIFO\n");

[PATCH v6 1/4] usb: dbc: early driver for xhci debug capability

2017-01-21 Thread Lu Baolu

xHCI debug capability (DbC) is an optional but standalone
functionality provided by an xHCI host controller. Software
learns this capability by walking through the extended
capability list of the host. xHCI specification describes
DbC in section 7.6.

This patch introduces the code to probe and initialize the
debug capability hardware during early boot. With hardware
initialized, the debug target (system on which this code is
running) will present a debug device through the debug port
(normally the first USB3 port). The debug device is fully
compliant with the USB framework and provides the equivalent
of a very high performance (USB3) full-duplex serial link
between the debug host and target. The DbC functionality is
independent of xHCI host. There isn't any precondition from
xHCI host side for DbC to work.

This patch also includes bulk out and bulk in interfaces.
These interfaces could be used to implement early printk
bootconsole or hook to various system debuggers.

Cc: Mathias Nyman 
Signed-off-by: Lu Baolu 
---
 arch/x86/Kconfig.debug|   17 +
 drivers/usb/Kconfig   |3 +
 drivers/usb/Makefile  |2 +-
 drivers/usb/early/Makefile|1 +
 drivers/usb/early/xhci-dbc.c  | 1027 +
 drivers/usb/early/xhci-dbc.h  |  205 
 include/linux/usb/xhci-dbgp.h |   29 ++
 7 files changed, 1283 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/early/xhci-dbc.h
 create mode 100644 include/linux/usb/xhci-dbgp.h

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 67eec55..ab0178f 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -5,6 +5,9 @@ config TRACE_IRQFLAGS_SUPPORT
 
 source "lib/Kconfig.debug"
 
+config EARLY_PRINTK_USB
+   bool
+
 config X86_VERBOSE_BOOTUP
bool "Enable verbose x86 bootup info messages"
default y
@@ -29,6 +32,7 @@ config EARLY_PRINTK
 config EARLY_PRINTK_DBGP
bool "Early printk via EHCI debug port"
depends on EARLY_PRINTK && PCI
+   select EARLY_PRINTK_USB
---help---
  Write kernel log output directly into the EHCI debug port.
 
@@ -48,6 +52,19 @@ config EARLY_PRINTK_EFI
  This is useful for kernel debugging when your machine crashes very
  early before the console code is initialized.
 
+config EARLY_PRINTK_USB_XDBC
+   bool "Early printk via xHCI debug port"
+   depends on EARLY_PRINTK && PCI
+   select EARLY_PRINTK_USB
+   ---help---
+ Write kernel log output directly into the xHCI debug port.
+
+ This is useful for kernel debugging when your machine crashes very
+ early before the console code is initialized. For normal operation
+ it is not recommended because it looks ugly and doesn't cooperate
+ with klogd/syslogd or the X server. You should normally N here,
+ unless you want to debug such a crash.
+
 config X86_PTDUMP_CORE
def_bool n
 
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index fbe493d..9313fff 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -19,6 +19,9 @@ config USB_EHCI_BIG_ENDIAN_MMIO
 config USB_EHCI_BIG_ENDIAN_DESC
bool
 
+config USB_EARLY_PRINTK
+   bool
+
 menuconfig USB_SUPPORT
bool "USB support"
depends on HAS_IOMEM
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 7791af6..53d1356 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -49,7 +49,7 @@ obj-$(CONFIG_USB_MICROTEK)+= image/
 obj-$(CONFIG_USB_SERIAL)   += serial/
 
 obj-$(CONFIG_USB)  += misc/
-obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/
+obj-$(CONFIG_EARLY_PRINTK_USB) += early/
 
 obj-$(CONFIG_USB_ATM)  += atm/
 obj-$(CONFIG_USB_SPEEDTOUCH)   += atm/
diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile
index 24bbe51..fcde228 100644
--- a/drivers/usb/early/Makefile
+++ b/drivers/usb/early/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o
+obj-$(CONFIG_EARLY_PRINTK_USB_XDBC) += xhci-dbc.o
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
new file mode 100644
index 000..72480c4
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,1027 @@
+/**
+ * xhci-dbc.c - xHCI debug capability early driver
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Author: Lu Baolu 
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ":%s: " fmt, __func__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../host/xhci.h"
+#include "xhci-dbc.h"
+
+static struct xdbc_state xdbc;

[PATCH v6 1/4] usb: dbc: early driver for xhci debug capability

2017-01-21 Thread Lu Baolu

xHCI debug capability (DbC) is an optional but standalone
functionality provided by an xHCI host controller. Software
learns this capability by walking through the extended
capability list of the host. xHCI specification describes
DbC in section 7.6.

This patch introduces the code to probe and initialize the
debug capability hardware during early boot. With hardware
initialized, the debug target (system on which this code is
running) will present a debug device through the debug port
(normally the first USB3 port). The debug device is fully
compliant with the USB framework and provides the equivalent
of a very high performance (USB3) full-duplex serial link
between the debug host and target. The DbC functionality is
independent of xHCI host. There isn't any precondition from
xHCI host side for DbC to work.

This patch also includes bulk out and bulk in interfaces.
These interfaces could be used to implement early printk
bootconsole or hook to various system debuggers.

Cc: Mathias Nyman 
Signed-off-by: Lu Baolu 
---
 arch/x86/Kconfig.debug|   17 +
 drivers/usb/Kconfig   |3 +
 drivers/usb/Makefile  |2 +-
 drivers/usb/early/Makefile|1 +
 drivers/usb/early/xhci-dbc.c  | 1027 +
 drivers/usb/early/xhci-dbc.h  |  205 
 include/linux/usb/xhci-dbgp.h |   29 ++
 7 files changed, 1283 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/early/xhci-dbc.h
 create mode 100644 include/linux/usb/xhci-dbgp.h

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 67eec55..ab0178f 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -5,6 +5,9 @@ config TRACE_IRQFLAGS_SUPPORT
 
 source "lib/Kconfig.debug"
 
+config EARLY_PRINTK_USB
+   bool
+
 config X86_VERBOSE_BOOTUP
bool "Enable verbose x86 bootup info messages"
default y
@@ -29,6 +32,7 @@ config EARLY_PRINTK
 config EARLY_PRINTK_DBGP
bool "Early printk via EHCI debug port"
depends on EARLY_PRINTK && PCI
+   select EARLY_PRINTK_USB
---help---
  Write kernel log output directly into the EHCI debug port.
 
@@ -48,6 +52,19 @@ config EARLY_PRINTK_EFI
  This is useful for kernel debugging when your machine crashes very
  early before the console code is initialized.
 
+config EARLY_PRINTK_USB_XDBC
+   bool "Early printk via xHCI debug port"
+   depends on EARLY_PRINTK && PCI
+   select EARLY_PRINTK_USB
+   ---help---
+ Write kernel log output directly into the xHCI debug port.
+
+ This is useful for kernel debugging when your machine crashes very
+ early before the console code is initialized. For normal operation
+ it is not recommended because it looks ugly and doesn't cooperate
+ with klogd/syslogd or the X server. You should normally N here,
+ unless you want to debug such a crash.
+
 config X86_PTDUMP_CORE
def_bool n
 
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index fbe493d..9313fff 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -19,6 +19,9 @@ config USB_EHCI_BIG_ENDIAN_MMIO
 config USB_EHCI_BIG_ENDIAN_DESC
bool
 
+config USB_EARLY_PRINTK
+   bool
+
 menuconfig USB_SUPPORT
bool "USB support"
depends on HAS_IOMEM
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 7791af6..53d1356 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -49,7 +49,7 @@ obj-$(CONFIG_USB_MICROTEK)+= image/
 obj-$(CONFIG_USB_SERIAL)   += serial/
 
 obj-$(CONFIG_USB)  += misc/
-obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/
+obj-$(CONFIG_EARLY_PRINTK_USB) += early/
 
 obj-$(CONFIG_USB_ATM)  += atm/
 obj-$(CONFIG_USB_SPEEDTOUCH)   += atm/
diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile
index 24bbe51..fcde228 100644
--- a/drivers/usb/early/Makefile
+++ b/drivers/usb/early/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o
+obj-$(CONFIG_EARLY_PRINTK_USB_XDBC) += xhci-dbc.o
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
new file mode 100644
index 000..72480c4
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,1027 @@
+/**
+ * xhci-dbc.c - xHCI debug capability early driver
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Author: Lu Baolu 
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ":%s: " fmt, __func__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../host/xhci.h"
+#include "xhci-dbc.h"
+
+static struct xdbc_state xdbc;
+static int early_console_keep;
+
+#ifdef XDBC_TRACE
+#definexdbc_trace

[PATCH v6 3/4] usb: serial: add dbc debug device support to usb_debug

2017-01-21 Thread Lu Baolu

This patch adds dbc debug device support to the usb_debug driver.

Signed-off-by: Lu Baolu 
Acked-by: Johan Hovold 
---
 drivers/usb/serial/usb_debug.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
 };
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+   { USB_DEVICE(0x0525, 0x127a) },
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
 
 /* This HW really does not support a serial break, so one will be
  * emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
 };
 
+static struct usb_serial_driver dbc_device = {
+   .driver = {
+   .owner =THIS_MODULE,
+   .name = "xhci_dbc",
+   },
+   .id_table = dbc_id_table,
+   .num_ports =1,
+   .break_ctl =usb_debug_break_ctl,
+   .process_read_urb = usb_debug_process_read_urb,
+};
+
 static struct usb_serial_driver * const serial_drivers[] = {
-   _device, NULL
+   _device, _device, NULL
 };
 
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
 MODULE_LICENSE("GPL");
-- 
2.1.4

[PATCH v6 3/4] usb: serial: add dbc debug device support to usb_debug

2017-01-21 Thread Lu Baolu

This patch adds dbc debug device support to the usb_debug driver.

Signed-off-by: Lu Baolu 
Acked-by: Johan Hovold 
---
 drivers/usb/serial/usb_debug.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
 };
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+   { USB_DEVICE(0x0525, 0x127a) },
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
 
 /* This HW really does not support a serial break, so one will be
  * emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
 };
 
+static struct usb_serial_driver dbc_device = {
+   .driver = {
+   .owner =THIS_MODULE,
+   .name = "xhci_dbc",
+   },
+   .id_table = dbc_id_table,
+   .num_ports =1,
+   .break_ctl =usb_debug_break_ctl,
+   .process_read_urb = usb_debug_process_read_urb,
+};
+
 static struct usb_serial_driver * const serial_drivers[] = {
-   _device, NULL
+   _device, _device, NULL
 };
 
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
 MODULE_LICENSE("GPL");
-- 
2.1.4

[PATCH v6 4/4] usb: doc: add document for USB3 debug port usage

2017-01-21 Thread Lu Baolu

Add Documentation/usb/usb3-debug-port.rst. This document includes
the user guide for USB3 debug port.

Cc: linux-...@vger.kernel.org
Signed-off-by: Lu Baolu 
---
 Documentation/usb/usb3-debug-port.rst | 98 +++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/usb/usb3-debug-port.rst

diff --git a/Documentation/usb/usb3-debug-port.rst 
b/Documentation/usb/usb3-debug-port.rst
new file mode 100644
index 000..9eddb3a
--- /dev/null
+++ b/Documentation/usb/usb3-debug-port.rst
@@ -0,0 +1,98 @@
+===
+USB3 debug port
+===
+
+:Author: Lu Baolu 
+:Date: January 2017
+
+GENERAL
+===
+
+This is a HOWTO for using USB3 debug port on x86 systems.
+
+Before using any kernel debugging functionality based on USB3
+debug port, you need to check 1) whether debug port is supported
+by the xHCI host; 2) which port is used for debugging purposes
+(normally the first USB3 root port). You must have a USB 3.0
+super-speed A-to-A debugging cable to connect the debug target
+with a debug host. In this document, "debug target" stands for
+the system under debugging, and "debug host" stands for a
+stand-alone system that is able to talk to the debugging target
+through the USB3 debug port.
+
+EARLY PRINTK
+
+
+On the debug target system, you need to customize a debugging
+kernel with CONFIG_EARLY_PRINTK_USB_XDBC enabled. And, add
+below kernel boot parameter::
+
+   "earlyprintk=xdbc"
+
+If there are multiple xHCI controllers in the system, you can
+append a host contoller index to this kernel parameter. This
+index starts from 0.
+
+If you are going to use the "keep" option defined by the
+early printk framework to keep the boot console alive after
+early boot, you'd better add below kernel boot parameter::
+
+   "usbcore.autosuspend=-1"
+
+On the debug host side, you don't need to customize the kernel,
+but you'd better disable usb subsystem runtime power management
+by adding below kernel boot parameter::
+
+   "usbcore.autosuspend=-1"
+
+Before starting the debug target, you should connect the debug
+port on the debug target with a root port or port of any external
+hub on the debug host. The cable used to connect these two ports
+should be a USB 3.0 super-speed A-to-A debugging cable.
+
+During early boot of the debug target, DbC (xHCI debug engine for
+USB3 debug port) hardware will be detected and initialized. After
+initialization, the debug host should be able to enumerate the
+debug target as a debug device. The debug host will then bind the
+debug device with the usb_debug driver module and create the
+/dev/ttyUSB0 device.
+
+If the debug device enumeration goes smoothly, you should be able
+to see below kernel messages on the debug host::
+
+   # tail -f /var/log/kern.log
+   [ 1815.983374] usb 4-3: new SuperSpeed USB device number 4 using 
xhci_hcd
+   [ 1815.999595] usb 4-3: LPM exit latency is zeroed, disabling LPM.
+   [ 1815.999899] usb 4-3: New USB device found, idVendor=1d6b, 
idProduct=0004
+   [ 1815.02] usb 4-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
+   [ 1815.03] usb 4-3: Product: Remote GDB
+   [ 1815.04] usb 4-3: Manufacturer: Linux
+   [ 1815.05] usb 4-3: SerialNumber: 0001
+   [ 1816.000240] usb_debug 4-3:1.0: xhci_dbc converter detected
+   [ 1816.000360] usb 4-3: xhci_dbc converter now attached to ttyUSB0
+
+You can run below bash scripts on the debug host to read the kernel
+log sent from debug target.
+
+.. code-block:: sh
+
+   = start of bash scripts =
+   #!/bin/bash
+
+   while true ; do
+   while [ ! -d /sys/class/tty/ttyUSB0 ] ; do
+   :
+   done
+   cat /dev/ttyUSB0 >> xdbc.log
+   done
+   = end of bash scripts ===
+
+You should be able to see the early boot message in xdbc.log.
+
+If it doesn't work, please ask it on the 
+mailing list.
+
+Below USB hosts have been verified to work::
+
+   Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller
+   Intel Corporation Wildcat Point-LP USB xHCI Controller
-- 
2.1.4

[PATCH v6 4/4] usb: doc: add document for USB3 debug port usage

2017-01-21 Thread Lu Baolu

Add Documentation/usb/usb3-debug-port.rst. This document includes
the user guide for USB3 debug port.

Cc: linux-...@vger.kernel.org
Signed-off-by: Lu Baolu 
---
 Documentation/usb/usb3-debug-port.rst | 98 +++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/usb/usb3-debug-port.rst

diff --git a/Documentation/usb/usb3-debug-port.rst 
b/Documentation/usb/usb3-debug-port.rst
new file mode 100644
index 000..9eddb3a
--- /dev/null
+++ b/Documentation/usb/usb3-debug-port.rst
@@ -0,0 +1,98 @@
+===
+USB3 debug port
+===
+
+:Author: Lu Baolu 
+:Date: January 2017
+
+GENERAL
+===
+
+This is a HOWTO for using USB3 debug port on x86 systems.
+
+Before using any kernel debugging functionality based on USB3
+debug port, you need to check 1) whether debug port is supported
+by the xHCI host; 2) which port is used for debugging purposes
+(normally the first USB3 root port). You must have a USB 3.0
+super-speed A-to-A debugging cable to connect the debug target
+with a debug host. In this document, "debug target" stands for
+the system under debugging, and "debug host" stands for a
+stand-alone system that is able to talk to the debugging target
+through the USB3 debug port.
+
+EARLY PRINTK
+
+
+On the debug target system, you need to customize a debugging
+kernel with CONFIG_EARLY_PRINTK_USB_XDBC enabled. And, add
+below kernel boot parameter::
+
+   "earlyprintk=xdbc"
+
+If there are multiple xHCI controllers in the system, you can
+append a host contoller index to this kernel parameter. This
+index starts from 0.
+
+If you are going to use the "keep" option defined by the
+early printk framework to keep the boot console alive after
+early boot, you'd better add below kernel boot parameter::
+
+   "usbcore.autosuspend=-1"
+
+On the debug host side, you don't need to customize the kernel,
+but you'd better disable usb subsystem runtime power management
+by adding below kernel boot parameter::
+
+   "usbcore.autosuspend=-1"
+
+Before starting the debug target, you should connect the debug
+port on the debug target with a root port or port of any external
+hub on the debug host. The cable used to connect these two ports
+should be a USB 3.0 super-speed A-to-A debugging cable.
+
+During early boot of the debug target, DbC (xHCI debug engine for
+USB3 debug port) hardware will be detected and initialized. After
+initialization, the debug host should be able to enumerate the
+debug target as a debug device. The debug host will then bind the
+debug device with the usb_debug driver module and create the
+/dev/ttyUSB0 device.
+
+If the debug device enumeration goes smoothly, you should be able
+to see below kernel messages on the debug host::
+
+   # tail -f /var/log/kern.log
+   [ 1815.983374] usb 4-3: new SuperSpeed USB device number 4 using 
xhci_hcd
+   [ 1815.999595] usb 4-3: LPM exit latency is zeroed, disabling LPM.
+   [ 1815.999899] usb 4-3: New USB device found, idVendor=1d6b, 
idProduct=0004
+   [ 1815.02] usb 4-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
+   [ 1815.03] usb 4-3: Product: Remote GDB
+   [ 1815.04] usb 4-3: Manufacturer: Linux
+   [ 1815.05] usb 4-3: SerialNumber: 0001
+   [ 1816.000240] usb_debug 4-3:1.0: xhci_dbc converter detected
+   [ 1816.000360] usb 4-3: xhci_dbc converter now attached to ttyUSB0
+
+You can run below bash scripts on the debug host to read the kernel
+log sent from debug target.
+
+.. code-block:: sh
+
+   = start of bash scripts =
+   #!/bin/bash
+
+   while true ; do
+   while [ ! -d /sys/class/tty/ttyUSB0 ] ; do
+   :
+   done
+   cat /dev/ttyUSB0 >> xdbc.log
+   done
+   = end of bash scripts ===
+
+You should be able to see the early boot message in xdbc.log.
+
+If it doesn't work, please ask it on the 
+mailing list.
+
+Below USB hosts have been verified to work::
+
+   Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller
+   Intel Corporation Wildcat Point-LP USB xHCI Controller
-- 
2.1.4

[PATCH v6 2/4] x86: add support for earlyprintk via USB3 debug port

2017-01-21 Thread Lu Baolu

Add support for early printk by writing debug messages to the
USB3 debug port.   Users can use this type of early printk by
specifying kernel parameter of "earlyprintk=xdbc". This gives
users a chance of providing debug output.

The hardware for USB3 debug port requires DMA memory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.

Cc: Ingo Molnar 
Cc: x...@kernel.org
Signed-off-by: Lu Baolu 
---
 Documentation/admin-guide/kernel-parameters.txt | 1 +
 arch/x86/kernel/early_printk.c  | 5 +
 arch/x86/kernel/setup.c | 4 
 3 files changed, 10 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index be7c0d9..4bf6138 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -988,6 +988,7 @@
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+   earlyprintk=xdbc[xhciController#]
 
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 8a12199..0f08403 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -381,6 +382,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "efi", 3))
early_console_register(_efi_console, keep);
 #endif
+#ifdef CONFIG_EARLY_PRINTK_USB_XDBC
+   if (!strncmp(buf, "xdbc", 4))
+   early_xdbc_parse_parameter(buf + 4);
+#endif
 
buf++;
}
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4cfba94..1f27d91 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -70,6 +70,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -1120,6 +1121,9 @@ void __init setup_arch(char **cmdline_p)
memblock_set_current_limit(ISA_END_ADDRESS);
memblock_x86_fill();
 
+   if (!early_xdbc_setup_hardware())
+   early_xdbc_register_console();
+
reserve_bios_regions();
 
if (efi_enabled(EFI_MEMMAP)) {
-- 
2.1.4

[PATCH v6 2/4] x86: add support for earlyprintk via USB3 debug port

2017-01-21 Thread Lu Baolu

Add support for early printk by writing debug messages to the
USB3 debug port.   Users can use this type of early printk by
specifying kernel parameter of "earlyprintk=xdbc". This gives
users a chance of providing debug output.

The hardware for USB3 debug port requires DMA memory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.

Cc: Ingo Molnar 
Cc: x...@kernel.org
Signed-off-by: Lu Baolu 
---
 Documentation/admin-guide/kernel-parameters.txt | 1 +
 arch/x86/kernel/early_printk.c  | 5 +
 arch/x86/kernel/setup.c | 4 
 3 files changed, 10 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index be7c0d9..4bf6138 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -988,6 +988,7 @@
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+   earlyprintk=xdbc[xhciController#]
 
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 8a12199..0f08403 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -381,6 +382,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "efi", 3))
early_console_register(_efi_console, keep);
 #endif
+#ifdef CONFIG_EARLY_PRINTK_USB_XDBC
+   if (!strncmp(buf, "xdbc", 4))
+   early_xdbc_parse_parameter(buf + 4);
+#endif
 
buf++;
}
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4cfba94..1f27d91 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -70,6 +70,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -1120,6 +1121,9 @@ void __init setup_arch(char **cmdline_p)
memblock_set_current_limit(ISA_END_ADDRESS);
memblock_x86_fill();
 
+   if (!early_xdbc_setup_hardware())
+   early_xdbc_register_console();
+
reserve_bios_regions();
 
if (efi_enabled(EFI_MEMMAP)) {
-- 
2.1.4

[PATCH v6 0/4] usb: early: add support for early printk through USB3 debug port

2017-01-21 Thread Lu Baolu

xHCI debug capability (DbC) is an optional but standalone
functionality provided by an xHCI host controller. With DbC
hardware initialized, the system will present a debug device
through the USB3 debug port (normally the first USB3 port).
The debug device is fully compliant with the USB framework
and provides the equivalent of a very high performance (USB3)
full-duplex serial link between the debug host and target.
The DbC functionality is independent of xHCI host. There
isn't any precondition from xHCI host side for DbC to work.

This patch set adds support for early printk functionality
through a USB3 debug port by 1) initializing and enabling
the DbC hardware during early boot; 2) registering a boot
console to the system so that early printk messages can go
through the USB3 debug port. It also includes some lines
of changes in usb_debug driver so that it can be bound when
a USB3 debug device is enumerated.

---
Change log:
v5->v6:
  - rebase the patches on top of the latest 4.10-rc4
  - run successfully in a 32-bit kernel
  - [PATCH 1/4]
- remove ugly linebreaks to make code more readable
- rename config names to make them consistency
- move sleep-able ioremap() out of the lock area
- rename reserved fields of register structures
- make the vertical tabulation of struct fields consistent
  - [PATCH 2/4]
- remove "#ifdef" in the generic code by creating proper
  wrappers in header file
  - [PATCH 3/4]
- refine the title and commit message
  - [PATCH 4/4]
- fix several typos and grammar errors in the document

v4->v5:
  - add raw_spin_lock to make xdbc_bulk_write() reentrant.

v3->v4:
  - Rename the document with .dst suffix.
  - Add the list of hardware that has been succesfuly
tested on in the document.

v2->v3:
  - Removed spinlock usage.
  - Removed work queue usage.
  - Refined the user guide document.

v1->v2:
  - Refactor the duplicate code in xdbc_early_start() and
xdbc_handle_external_reset().
  - Free resources when hardware not used any more.
  - Refine the user guide document.

Lu Baolu (4):
  usb: dbc: early driver for xhci debug capability
  x86: add support for earlyprintk via USB3 debug port
  usb: serial: add dbc debug device support to usb_debug
  usb: doc: add document for USB3 debug port usage

 Documentation/admin-guide/kernel-parameters.txt |1 +
 Documentation/usb/usb3-debug-port.rst   |   98 +++
 arch/x86/Kconfig.debug  |   17 +
 arch/x86/kernel/early_printk.c  |5 +
 arch/x86/kernel/setup.c |4 +
 drivers/usb/Kconfig |3 +
 drivers/usb/Makefile|2 +-
 drivers/usb/early/Makefile  |1 +
 drivers/usb/early/xhci-dbc.c| 1027 +++
 drivers/usb/early/xhci-dbc.h|  205 +
 drivers/usb/serial/usb_debug.c  |   28 +-
 include/linux/usb/xhci-dbgp.h   |   29 +
 12 files changed, 1416 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/usb/usb3-debug-port.rst
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/early/xhci-dbc.h
 create mode 100644 include/linux/usb/xhci-dbgp.h

-- 
2.1.4

[PATCH v6 0/4] usb: early: add support for early printk through USB3 debug port

2017-01-21 Thread Lu Baolu

xHCI debug capability (DbC) is an optional but standalone
functionality provided by an xHCI host controller. With DbC
hardware initialized, the system will present a debug device
through the USB3 debug port (normally the first USB3 port).
The debug device is fully compliant with the USB framework
and provides the equivalent of a very high performance (USB3)
full-duplex serial link between the debug host and target.
The DbC functionality is independent of xHCI host. There
isn't any precondition from xHCI host side for DbC to work.

This patch set adds support for early printk functionality
through a USB3 debug port by 1) initializing and enabling
the DbC hardware during early boot; 2) registering a boot
console to the system so that early printk messages can go
through the USB3 debug port. It also includes some lines
of changes in usb_debug driver so that it can be bound when
a USB3 debug device is enumerated.

---
Change log:
v5->v6:
  - rebase the patches on top of the latest 4.10-rc4
  - run successfully in a 32-bit kernel
  - [PATCH 1/4]
- remove ugly linebreaks to make code more readable
- rename config names to make them consistency
- move sleep-able ioremap() out of the lock area
- rename reserved fields of register structures
- make the vertical tabulation of struct fields consistent
  - [PATCH 2/4]
- remove "#ifdef" in the generic code by creating proper
  wrappers in header file
  - [PATCH 3/4]
- refine the title and commit message
  - [PATCH 4/4]
- fix several typos and grammar errors in the document

v4->v5:
  - add raw_spin_lock to make xdbc_bulk_write() reentrant.

v3->v4:
  - Rename the document with .dst suffix.
  - Add the list of hardware that has been succesfuly
tested on in the document.

v2->v3:
  - Removed spinlock usage.
  - Removed work queue usage.
  - Refined the user guide document.

v1->v2:
  - Refactor the duplicate code in xdbc_early_start() and
xdbc_handle_external_reset().
  - Free resources when hardware not used any more.
  - Refine the user guide document.

Lu Baolu (4):
  usb: dbc: early driver for xhci debug capability
  x86: add support for earlyprintk via USB3 debug port
  usb: serial: add dbc debug device support to usb_debug
  usb: doc: add document for USB3 debug port usage

 Documentation/admin-guide/kernel-parameters.txt |1 +
 Documentation/usb/usb3-debug-port.rst   |   98 +++
 arch/x86/Kconfig.debug  |   17 +
 arch/x86/kernel/early_printk.c  |5 +
 arch/x86/kernel/setup.c |4 +
 drivers/usb/Kconfig |3 +
 drivers/usb/Makefile|2 +-
 drivers/usb/early/Makefile  |1 +
 drivers/usb/early/xhci-dbc.c| 1027 +++
 drivers/usb/early/xhci-dbc.h|  205 +
 drivers/usb/serial/usb_debug.c  |   28 +-
 include/linux/usb/xhci-dbgp.h   |   29 +
 12 files changed, 1416 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/usb/usb3-debug-port.rst
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/early/xhci-dbc.h
 create mode 100644 include/linux/usb/xhci-dbgp.h

-- 
2.1.4

Re: [PATCH v2 04/26] drm/rockchip: dw-mipi-dsi: remove mode_set hook

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 


On 01/22/2017 12:31 AM, John Keeping wrote:

This is not needed since we can access the mode via the CRTC from the
enable hook.  Also remove the "mode" field that is no longer used.

Signed-off-by: John Keeping 
---
New in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 13 +
  1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index cdbd25087e83..bd92e58b64f3 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -286,7 +286,6 @@ struct dw_mipi_dsi {
u32 format;
u16 input_div;
u16 feedback_div;
-   struct drm_display_mode *mode;
  
  	const struct dw_mipi_dsi_plat_data *pdata;

  };
@@ -816,15 +815,6 @@ static void dw_mipi_dsi_clear_err(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_INT_MSK1, 0);
  }
  
-static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,

-   struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
-{
-   struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
-
-   dsi->mode = adjusted_mode;
-}
-
  static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
  {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
@@ -854,7 +844,7 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder 
*encoder)
  static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
  {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
-   struct drm_display_mode *mode = dsi->mode;
+   struct drm_display_mode *mode = >crtc->state->adjusted_mode;
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
int ret;
@@ -930,7 +920,6 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder 
*encoder,
  static struct drm_encoder_helper_funcs
  dw_mipi_dsi_encoder_helper_funcs = {
.enable = dw_mipi_dsi_encoder_enable,
-   .mode_set = dw_mipi_dsi_encoder_mode_set,
.disable = dw_mipi_dsi_encoder_disable,
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
  };

Re: [PATCH v2 04/26] drm/rockchip: dw-mipi-dsi: remove mode_set hook

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 


On 01/22/2017 12:31 AM, John Keeping wrote:

This is not needed since we can access the mode via the CRTC from the
enable hook.  Also remove the "mode" field that is no longer used.

Signed-off-by: John Keeping 
---
New in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 13 +
  1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index cdbd25087e83..bd92e58b64f3 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -286,7 +286,6 @@ struct dw_mipi_dsi {
u32 format;
u16 input_div;
u16 feedback_div;
-   struct drm_display_mode *mode;
  
  	const struct dw_mipi_dsi_plat_data *pdata;

  };
@@ -816,15 +815,6 @@ static void dw_mipi_dsi_clear_err(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_INT_MSK1, 0);
  }
  
-static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,

-   struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
-{
-   struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
-
-   dsi->mode = adjusted_mode;
-}
-
  static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
  {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
@@ -854,7 +844,7 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder 
*encoder)
  static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
  {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
-   struct drm_display_mode *mode = dsi->mode;
+   struct drm_display_mode *mode = >crtc->state->adjusted_mode;
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
int ret;
@@ -930,7 +920,6 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder 
*encoder,
  static struct drm_encoder_helper_funcs
  dw_mipi_dsi_encoder_helper_funcs = {
.enable = dw_mipi_dsi_encoder_enable,
-   .mode_set = dw_mipi_dsi_encoder_mode_set,
.disable = dw_mipi_dsi_encoder_disable,
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
  };

make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.o'.

2017-01-21 Thread kbuild test robot

Hi Rich,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c497f8d17246720afe680ea1a8fa6e48e75af852
commit: 190fe191cfbead9fe089453dd092869c9469c6d4 sh: add support for linking a 
builtin device tree blob in the kernel
date:   6 months ago
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 190fe191cfbead9fe089453dd092869c9469c6d4
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

>> make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 
>> 'arch/sh/boot/dts/built-in.o'.
   make[2]: Target '__build' not remade because of errors.

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


.config.gz
Description: application/gzip

make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.o'.

2017-01-21 Thread kbuild test robot

Hi Rich,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c497f8d17246720afe680ea1a8fa6e48e75af852
commit: 190fe191cfbead9fe089453dd092869c9469c6d4 sh: add support for linking a 
builtin device tree blob in the kernel
date:   6 months ago
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 190fe191cfbead9fe089453dd092869c9469c6d4
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

>> make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 
>> 'arch/sh/boot/dts/built-in.o'.
   make[2]: Target '__build' not remade because of errors.

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


.config.gz
Description: application/gzip

[PATCH v2] vfio error recovery: kernel support

2017-01-21 Thread Michael S. Tsirkin

This is a design and an initial patch for kernel side for AER
support in VFIO.

0. What happens now (PCIE AER only)
   Fatal errors cause a link reset.
   Non fatal errors don't.
   All errors stop the VM eventually, but not immediately
   because it's detected and reported asynchronously.
   Interrupts are forwarded as usual.
   Correctable errors are not reported to guest at all.
   Note: PPC EEH is different. This focuses on AER.

1. Correctable errors
   I don't see a need to report these to guest. So let's not.

2. Fatal errors
   It's not easy to handle them gracefully since link reset
   is needed. As a first step, let's use the existing mechanism
   in that case.

2. Non-fatal errors
   Here we could make progress by reporting them to guest
   and have guest handle them.
   Issues:
a. this behaviour should only be enabled with new userspace
   old userspace should work without changes
Suggestion: One way to address this would be to add a new eventfd
non_fatal_err_trigger. If not set, invoke err_trigger.

b. drivers are supposed to stop MMIO when error is reported
if vm keeps going, we will keep doing MMIO/config
Suggestion 1: ignore this. vm stop happens much later when
userspace runs anyway, so we are not making things much worse
Suggestion 2: try to stop MMIO/config, resume on resume call

Patch below implements Suggestion 1.

Note that although this is really against the documentation, which states
error_detected() is the point at which the driver should quiesce the
device and not touch it further (until diagnostic poking at
mmio_enabled or full access at resume callback).
Fixing this won't be easy.
However, this is not a regression.

Also note this does nothing about interrupts, documentation
suggests returning IRQ_NONE until reset.
Again, not a regression.

c. PF driver might detect that function is completely broken,
if vm keeps going, we will keep doing MMIO/config
Suggestion 1: ignore this. vm stop happens much later when
userspace runs anyway, so we are not making things much worse
Suggestion 2: detect this and invoke err_trigger to stop VM

Patch below implements Suggestion 2.

Aside: what should we return if driver is e.g. being unbound?
For slot_reset, this implements Alex's suggestion to
return PCI_ERS_RESULT_NONE. It's worth considering whether
same should happen in error_report.

Signed-off-by: Michael S. Tsirkin 
---

changes from v1:
- more detailed commit log
- fixed a couple of bugs

Alex, pls review but don't apply until we get
- userspace updated to use the new interface
- testing reports


 drivers/vfio/pci/vfio_pci.c | 35 ++-
 drivers/vfio/pci/vfio_pci_intrs.c   | 19 +++
 drivers/vfio/pci/vfio_pci_private.h |  1 +
 include/linux/virtio_config.h   | 12 +++-
 include/uapi/linux/vfio.h   |  1 +
 5 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 0e33278..5d489b5 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1296,7 +1296,9 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct 
pci_dev *pdev,
 
mutex_lock(>igate);
 
-   if (vdev->err_trigger)
+   if (state == pci_channel_io_normal && vdev->non_fatal_err_trigger)
+   eventfd_signal(vdev->non_fatal_err_trigger, 1);
+   else if (vdev->err_trigger)
eventfd_signal(vdev->err_trigger, 1);
 
mutex_unlock(>igate);
@@ -1306,8 +1308,39 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct 
pci_dev *pdev,
return PCI_ERS_RESULT_CAN_RECOVER;
 }
 
+static pci_ers_result_t vfio_pci_aer_slot_reset(struct pci_dev *pdev,
+   pci_channel_state_t state)
+{
+   struct vfio_pci_device *vdev;
+   struct vfio_device *device;
+   static pci_ers_result_t err = PCI_ERS_RESULT_NONE;
+
+   device = vfio_device_get_from_dev(>dev);
+   if (!device)
+   goto err_dev;
+
+   vdev = vfio_device_data(device);
+   if (!vdev)
+   goto err_data;
+
+   mutex_lock(>igate);
+
+   if (vdev->err_trigger)
+   eventfd_signal(vdev->err_trigger, 1);
+
+   mutex_unlock(>igate);
+
+   err = PCI_ERS_RESULT_RECOVERED;
+
+err_data:
+   vfio_device_put(device);
+err_dev:
+   return err;
+}
+
 static const struct pci_error_handlers vfio_err_handlers = {
.error_detected = vfio_pci_aer_err_detected,
+   .slot_reset = vfio_pci_aer_slot_reset,
 };
 
 static struct pci_driver vfio_pci_driver = {
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
b/drivers/vfio/pci/vfio_pci_intrs.c
index 1c46045..e883db5 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -611,6 +611,17 @@ static int vfio_pci_set_err_trigger(struct vfio_pci_device 
*vdev,

[PATCH v2] vfio error recovery: kernel support

2017-01-21 Thread Michael S. Tsirkin

This is a design and an initial patch for kernel side for AER
support in VFIO.

0. What happens now (PCIE AER only)
   Fatal errors cause a link reset.
   Non fatal errors don't.
   All errors stop the VM eventually, but not immediately
   because it's detected and reported asynchronously.
   Interrupts are forwarded as usual.
   Correctable errors are not reported to guest at all.
   Note: PPC EEH is different. This focuses on AER.

1. Correctable errors
   I don't see a need to report these to guest. So let's not.

2. Fatal errors
   It's not easy to handle them gracefully since link reset
   is needed. As a first step, let's use the existing mechanism
   in that case.

2. Non-fatal errors
   Here we could make progress by reporting them to guest
   and have guest handle them.
   Issues:
a. this behaviour should only be enabled with new userspace
   old userspace should work without changes
Suggestion: One way to address this would be to add a new eventfd
non_fatal_err_trigger. If not set, invoke err_trigger.

b. drivers are supposed to stop MMIO when error is reported
if vm keeps going, we will keep doing MMIO/config
Suggestion 1: ignore this. vm stop happens much later when
userspace runs anyway, so we are not making things much worse
Suggestion 2: try to stop MMIO/config, resume on resume call

Patch below implements Suggestion 1.

Note that although this is really against the documentation, which states
error_detected() is the point at which the driver should quiesce the
device and not touch it further (until diagnostic poking at
mmio_enabled or full access at resume callback).
Fixing this won't be easy.
However, this is not a regression.

Also note this does nothing about interrupts, documentation
suggests returning IRQ_NONE until reset.
Again, not a regression.

c. PF driver might detect that function is completely broken,
if vm keeps going, we will keep doing MMIO/config
Suggestion 1: ignore this. vm stop happens much later when
userspace runs anyway, so we are not making things much worse
Suggestion 2: detect this and invoke err_trigger to stop VM

Patch below implements Suggestion 2.

Aside: what should we return if driver is e.g. being unbound?
For slot_reset, this implements Alex's suggestion to
return PCI_ERS_RESULT_NONE. It's worth considering whether
same should happen in error_report.

Signed-off-by: Michael S. Tsirkin 
---

changes from v1:
- more detailed commit log
- fixed a couple of bugs

Alex, pls review but don't apply until we get
- userspace updated to use the new interface
- testing reports


 drivers/vfio/pci/vfio_pci.c | 35 ++-
 drivers/vfio/pci/vfio_pci_intrs.c   | 19 +++
 drivers/vfio/pci/vfio_pci_private.h |  1 +
 include/linux/virtio_config.h   | 12 +++-
 include/uapi/linux/vfio.h   |  1 +
 5 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 0e33278..5d489b5 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1296,7 +1296,9 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct 
pci_dev *pdev,
 
mutex_lock(>igate);
 
-   if (vdev->err_trigger)
+   if (state == pci_channel_io_normal && vdev->non_fatal_err_trigger)
+   eventfd_signal(vdev->non_fatal_err_trigger, 1);
+   else if (vdev->err_trigger)
eventfd_signal(vdev->err_trigger, 1);
 
mutex_unlock(>igate);
@@ -1306,8 +1308,39 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct 
pci_dev *pdev,
return PCI_ERS_RESULT_CAN_RECOVER;
 }
 
+static pci_ers_result_t vfio_pci_aer_slot_reset(struct pci_dev *pdev,
+   pci_channel_state_t state)
+{
+   struct vfio_pci_device *vdev;
+   struct vfio_device *device;
+   static pci_ers_result_t err = PCI_ERS_RESULT_NONE;
+
+   device = vfio_device_get_from_dev(>dev);
+   if (!device)
+   goto err_dev;
+
+   vdev = vfio_device_data(device);
+   if (!vdev)
+   goto err_data;
+
+   mutex_lock(>igate);
+
+   if (vdev->err_trigger)
+   eventfd_signal(vdev->err_trigger, 1);
+
+   mutex_unlock(>igate);
+
+   err = PCI_ERS_RESULT_RECOVERED;
+
+err_data:
+   vfio_device_put(device);
+err_dev:
+   return err;
+}
+
 static const struct pci_error_handlers vfio_err_handlers = {
.error_detected = vfio_pci_aer_err_detected,
+   .slot_reset = vfio_pci_aer_slot_reset,
 };
 
 static struct pci_driver vfio_pci_driver = {
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
b/drivers/vfio/pci/vfio_pci_intrs.c
index 1c46045..e883db5 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -611,6 +611,17 @@ static int vfio_pci_set_err_trigger(struct vfio_pci_device 
*vdev,

Re: [PATCH v3 3/3] media: rc: add driver for IR remote receiver on MT7623 SoC

2017-01-21 Thread kbuild test robot

Hi Sean,

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

url:
https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/Documentation-devicetree-move-shared-property-used-by-rc-into-a-common-place/20170115-052257
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
>> drivers/media/rc/mtk-cir.c:220:11: error: too many arguments to function 
>> 'devm_rc_allocate_device'
 ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
  ^~~
   In file included from drivers/media/rc/mtk-cir.c:22:0:
   include/media/rc-core.h:213:16: note: declared here
struct rc_dev *devm_rc_allocate_device(struct device *dev);
   ^~~

vim +/devm_rc_allocate_device +220 drivers/media/rc/mtk-cir.c

   214  ir->base = devm_ioremap_resource(dev, res);
   215  if (IS_ERR(ir->base)) {
   216  dev_err(dev, "failed to map registers\n");
   217  return PTR_ERR(ir->base);
   218  }
   219  
 > 220  ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
   221  if (!ir->rc) {
   222  dev_err(dev, "failed to allocate device\n");
   223  return -ENOMEM;

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


.config.gz
Description: application/gzip

Re: [PATCH v3 3/3] media: rc: add driver for IR remote receiver on MT7623 SoC

2017-01-21 Thread kbuild test robot

Hi Sean,

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

url:
https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/Documentation-devicetree-move-shared-property-used-by-rc-into-a-common-place/20170115-052257
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
>> drivers/media/rc/mtk-cir.c:220:11: error: too many arguments to function 
>> 'devm_rc_allocate_device'
 ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
  ^~~
   In file included from drivers/media/rc/mtk-cir.c:22:0:
   include/media/rc-core.h:213:16: note: declared here
struct rc_dev *devm_rc_allocate_device(struct device *dev);
   ^~~

vim +/devm_rc_allocate_device +220 drivers/media/rc/mtk-cir.c

   214  ir->base = devm_ioremap_resource(dev, res);
   215  if (IS_ERR(ir->base)) {
   216  dev_err(dev, "failed to map registers\n");
   217  return PTR_ERR(ir->base);
   218  }
   219  
 > 220  ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
   221  if (!ir->rc) {
   222  dev_err(dev, "failed to allocate device\n");
   223  return -ENOMEM;

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


.config.gz
Description: application/gzip

[PATCH] Staging: rtl8188eu: os_dep: usb_ops_linux.c - style fix

2017-01-21 Thread Derek Robson

Fixed comparison, moved the constant to the right side of the test
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c 
b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
index e2dbe1b4afd3..41f7f3cb1779 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
@@ -471,7 +471,7 @@ u32 usb_read_port(struct adapter *adapter, u32 addr, struct 
recv_buf *precvbuf)
 
if ((!precvbuf->reuse) || (precvbuf->pskb == NULL)) {
precvbuf->pskb = skb_dequeue(>free_recv_skb_queue);
-   if (NULL != precvbuf->pskb)
+   if (precvbuf->pskb != NULL)
precvbuf->reuse = true;
}
 
-- 
2.11.0

[PATCH] Staging: rtl8188eu: os_dep: usb_ops_linux.c - style fix

2017-01-21 Thread Derek Robson

Fixed comparison, moved the constant to the right side of the test
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c 
b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
index e2dbe1b4afd3..41f7f3cb1779 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
@@ -471,7 +471,7 @@ u32 usb_read_port(struct adapter *adapter, u32 addr, struct 
recv_buf *precvbuf)
 
if ((!precvbuf->reuse) || (precvbuf->pskb == NULL)) {
precvbuf->pskb = skb_dequeue(>free_recv_skb_queue);
-   if (NULL != precvbuf->pskb)
+   if (precvbuf->pskb != NULL)
precvbuf->reuse = true;
}
 
-- 
2.11.0

Questions about process statistics

2017-01-21 Thread wy11



Hello,

Recently I noticed that in the early versions, the kernel scheduler  
suffers from such an attack,

http://static.usenix.org/event/sec07/tech/full_papers/tsafrir/tsafrir_html/
and it has already been fixed by introducing CFS and nanosecond  
granularity accounting.


However, as to the statistics exported from kernel to /proc/stat, it  
seems that the data is updated upon every tick by  
update_process_times, and the granularity is jiffies.


In my view, for applications which utilize such statistics in  
userspace, they would still suffer from a time accounting attack, for  
it is possible for a process to run between two ticks to evade from  
being accounted (please correct me if I'm wrong). Is there any special  
reason that /proc/stat only achieves a granularity of jiffies? Is it  
possible to update the statistics every time the CPU switches to  
another process instead of upon every tick, and to read TSC for a more  
accurate time value?


Also, I noticed that the acct_rss_mem1/acct_vm_mem1 area in  
task_struct is updated upon every tick, and a malicious process is  
able to occupy a large amount of memory between two ticks. Is it  
possible to update accumulate memory every time the memory size is  
modified (for example, insert_page) by adding previous memory times  
time interval? I'd like to know if it can help to avoid time  
accounting attack and achieve more accurate statistics.


I'd be appreciate if you can answer my questions. Thanks a lot.

Best Regards,

Wenqiu

Questions about process statistics

2017-01-21 Thread wy11



Hello,

Recently I noticed that in the early versions, the kernel scheduler  
suffers from such an attack,

http://static.usenix.org/event/sec07/tech/full_papers/tsafrir/tsafrir_html/
and it has already been fixed by introducing CFS and nanosecond  
granularity accounting.


However, as to the statistics exported from kernel to /proc/stat, it  
seems that the data is updated upon every tick by  
update_process_times, and the granularity is jiffies.


In my view, for applications which utilize such statistics in  
userspace, they would still suffer from a time accounting attack, for  
it is possible for a process to run between two ticks to evade from  
being accounted (please correct me if I'm wrong). Is there any special  
reason that /proc/stat only achieves a granularity of jiffies? Is it  
possible to update the statistics every time the CPU switches to  
another process instead of upon every tick, and to read TSC for a more  
accurate time value?


Also, I noticed that the acct_rss_mem1/acct_vm_mem1 area in  
task_struct is updated upon every tick, and a malicious process is  
able to occupy a large amount of memory between two ticks. Is it  
possible to update accumulate memory every time the memory size is  
modified (for example, insert_page) by adding previous memory times  
time interval? I'd like to know if it can help to avoid time  
accounting attack and achieve more accurate statistics.


I'd be appreciate if you can answer my questions. Thanks a lot.

Best Regards,

Wenqiu

Re: [PATCH] mm: extend zero pages to same element pages for zram

2017-01-21 Thread Sergey Senozhatsky

On (01/22/17 10:58), zhouxianrong wrote:
> 1. memset is just set a int value but i want to set a long value.

ah... ok. because you union it with the handle.

> 2. using clear_page rather than memset MAYBE due to in arm64 arch
>it is a 64-bytes operations.

clear_page() basically does memset(), which is quite well optimized.
except for arm64, yes.


> 6.6.4. Data Cache Zero
> 
> The ARMv8-A architecture introduces a Data Cache Zero by Virtual Address (DC 
> ZVA) instruction. This enables a block of 64
> bytes in memory, aligned to 64 bytes in size, to be set to zero. If the DC 
> ZVA instruction misses in the cache, it clears main
> memory, without causing an L1 or L2 cache allocation.
> 
> but i only consider the arm64 arch, other archs need to be reviewed.

thaks for the reply.

-ss

Re: [PATCH] mm: extend zero pages to same element pages for zram

2017-01-21 Thread Sergey Senozhatsky

On (01/22/17 10:58), zhouxianrong wrote:
> 1. memset is just set a int value but i want to set a long value.

ah... ok. because you union it with the handle.

> 2. using clear_page rather than memset MAYBE due to in arm64 arch
>it is a 64-bytes operations.

clear_page() basically does memset(), which is quite well optimized.
except for arm64, yes.


> 6.6.4. Data Cache Zero
> 
> The ARMv8-A architecture introduces a Data Cache Zero by Virtual Address (DC 
> ZVA) instruction. This enables a block of 64
> bytes in memory, aligned to 64 bytes in size, to be set to zero. If the DC 
> ZVA instruction misses in the cache, it clears main
> memory, without causing an L1 or L2 cache allocation.
> 
> but i only consider the arm64 arch, other archs need to be reviewed.

thaks for the reply.

-ss

[PATCH] Staging: greybus: gpio.c - style fix

2017-01-21 Thread Derek Robson

Fixed bare use of 'unsigned', Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/greybus/gpio.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c
index 250caa00de5e..e93710e6 100644
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -410,21 +410,21 @@ static int gb_gpio_request_handler(struct gb_operation 
*op)
return 0;
 }
 
-static int gb_gpio_request(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_request(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
return gb_gpio_activate_operation(ggc, (u8)offset);
 }
 
-static void gb_gpio_free(struct gpio_chip *chip, unsigned offset)
+static void gb_gpio_free(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
gb_gpio_deactivate_operation(ggc, (u8)offset);
 }
 
-static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u8 which;
@@ -438,14 +438,14 @@ static int gb_gpio_get_direction(struct gpio_chip *chip, 
unsigned offset)
return ggc->lines[which].direction ? 1 : 0;
 }
 
-static int gb_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
return gb_gpio_direction_in_operation(ggc, (u8)offset);
 }
 
-static int gb_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
+static int gb_gpio_direction_output(struct gpio_chip *chip, unsigned int 
offset,
int value)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
@@ -453,7 +453,7 @@ static int gb_gpio_direction_output(struct gpio_chip *chip, 
unsigned offset,
return gb_gpio_direction_out_operation(ggc, (u8)offset, !!value);
 }
 
-static int gb_gpio_get(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_get(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u8 which;
@@ -467,15 +467,15 @@ static int gb_gpio_get(struct gpio_chip *chip, unsigned 
offset)
return ggc->lines[which].value;
 }
 
-static void gb_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+static void gb_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
gb_gpio_set_value_operation(ggc, (u8)offset, !!value);
 }
 
-static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned offset,
-   unsigned debounce)
+static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
+   unsigned int debounce)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u16 usec;
@@ -593,7 +593,7 @@ static int gb_gpio_irqchip_add(struct gpio_chip *chip,
 {
struct gb_gpio_controller *ggc;
unsigned int offset;
-   unsigned irq_base;
+   unsigned int irq_base;
 
if (!chip || !irqchip)
return -EINVAL;
@@ -625,7 +625,7 @@ static int gb_gpio_irqchip_add(struct gpio_chip *chip,
return 0;
 }
 
-static int gb_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
-- 
2.11.0

[PATCH] Staging: greybus: gpio.c - style fix

2017-01-21 Thread Derek Robson

Fixed bare use of 'unsigned', Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/greybus/gpio.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c
index 250caa00de5e..e93710e6 100644
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -410,21 +410,21 @@ static int gb_gpio_request_handler(struct gb_operation 
*op)
return 0;
 }
 
-static int gb_gpio_request(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_request(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
return gb_gpio_activate_operation(ggc, (u8)offset);
 }
 
-static void gb_gpio_free(struct gpio_chip *chip, unsigned offset)
+static void gb_gpio_free(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
gb_gpio_deactivate_operation(ggc, (u8)offset);
 }
 
-static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u8 which;
@@ -438,14 +438,14 @@ static int gb_gpio_get_direction(struct gpio_chip *chip, 
unsigned offset)
return ggc->lines[which].direction ? 1 : 0;
 }
 
-static int gb_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
return gb_gpio_direction_in_operation(ggc, (u8)offset);
 }
 
-static int gb_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
+static int gb_gpio_direction_output(struct gpio_chip *chip, unsigned int 
offset,
int value)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
@@ -453,7 +453,7 @@ static int gb_gpio_direction_output(struct gpio_chip *chip, 
unsigned offset,
return gb_gpio_direction_out_operation(ggc, (u8)offset, !!value);
 }
 
-static int gb_gpio_get(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_get(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u8 which;
@@ -467,15 +467,15 @@ static int gb_gpio_get(struct gpio_chip *chip, unsigned 
offset)
return ggc->lines[which].value;
 }
 
-static void gb_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+static void gb_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
gb_gpio_set_value_operation(ggc, (u8)offset, !!value);
 }
 
-static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned offset,
-   unsigned debounce)
+static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
+   unsigned int debounce)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u16 usec;
@@ -593,7 +593,7 @@ static int gb_gpio_irqchip_add(struct gpio_chip *chip,
 {
struct gb_gpio_controller *ggc;
unsigned int offset;
-   unsigned irq_base;
+   unsigned int irq_base;
 
if (!chip || !irqchip)
return -EINVAL;
@@ -625,7 +625,7 @@ static int gb_gpio_irqchip_add(struct gpio_chip *chip,
return 0;
 }
 
-static int gb_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
-- 
2.11.0

Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

2017-01-21 Thread Michael S. Tsirkin

On Sun, Jan 22, 2017 at 10:41:22AM +0800, Jason Wang wrote:
> 
> 
> On 2017年01月21日 00:45, Michael S. Tsirkin wrote:
> > On Fri, Jan 20, 2017 at 02:32:42PM +0800, Jason Wang wrote:
> > > Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
> > > xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
> > > fixing this by adding a hint (has_data_valid) and set it only on the
> > > receiving path.
> > > 
> > > Cc: Rolf Neugebauer
> > > Signed-off-by: Jason Wang
> > > ---
> > >   drivers/net/macvtap.c  | 2 +-
> > >   drivers/net/tun.c  | 2 +-
> > >   drivers/net/virtio_net.c   | 2 +-
> > >   include/linux/virtio_net.h | 6 +-
> > >   net/packet/af_packet.c | 4 ++--
> > >   5 files changed, 10 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> > > index 5c26653..4026185 100644
> > > --- a/drivers/net/macvtap.c
> > > +++ b/drivers/net/macvtap.c
> > > @@ -825,7 +825,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue 
> > > *q,
> > >   return -EINVAL;
> > >   if (virtio_net_hdr_from_skb(skb, _hdr,
> > > - macvtap_is_little_endian(q)))
> > > + macvtap_is_little_endian(q), true))
> > >   BUG();
> > >   if (copy_to_iter(_hdr, sizeof(vnet_hdr), iter) !=
> > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > > index cd8e02c..2cd10b2 100644
> > > --- a/drivers/net/tun.c
> > > +++ b/drivers/net/tun.c
> > > @@ -1360,7 +1360,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> > >   return -EINVAL;
> > >   if (virtio_net_hdr_from_skb(skb, ,
> > > - tun_is_little_endian(tun))) {
> > > + tun_is_little_endian(tun), true)) {
> > >   struct skb_shared_info *sinfo = skb_shinfo(skb);
> > >   pr_err("unexpected GSO type: "
> > >  "0x%x, gso_size %d, hdr_len %d\n",
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index 4a10500..3474243 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -1104,7 +1104,7 @@ static int xmit_skb(struct send_queue *sq, struct 
> > > sk_buff *skb)
> > >   hdr = skb_vnet_hdr(skb);
> > >   if (virtio_net_hdr_from_skb(skb, >hdr,
> > > - virtio_is_little_endian(vi->vdev)))
> > > + virtio_is_little_endian(vi->vdev), false))
> > >   BUG();
> > >   if (vi->mergeable_rx_bufs)
> > > diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> > > index 5643647..5209b5e 100644
> > > --- a/include/linux/virtio_net.h
> > > +++ b/include/linux/virtio_net.h
> > > @@ -56,7 +56,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff 
> > > *skb,
> > >   static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> > > struct virtio_net_hdr *hdr,
> > > -   bool little_endian)
> > > +   bool little_endian,
> > > +   bool has_data_valid)
> > >   {
> > >   memset(hdr, 0, sizeof(*hdr));   /* no info leak */
> > I would prefer naming it is_rx. Callers should not know about
> > internal details like data valid, the issue we are trying to fix
> > here is that tx and tx headers are slightly different.
> > 
> 
> Actually, I've considered something like this, but the problem is:
> 
> - tun use this on xmit, so is_rx = true may cause some confusion here

tun is generally weird, yes. how about rx_format?

> - I believe we may want to support DATA_VALID (like xen-netback) on tx
> (probably with a feature) in the future.
> 
> Thanks

We'll put that knowledge within virtio_net_hdr_from_skb not
in the callers I think.

-- 
MST

Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

2017-01-21 Thread Michael S. Tsirkin

On Sun, Jan 22, 2017 at 10:41:22AM +0800, Jason Wang wrote:
> 
> 
> On 2017年01月21日 00:45, Michael S. Tsirkin wrote:
> > On Fri, Jan 20, 2017 at 02:32:42PM +0800, Jason Wang wrote:
> > > Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
> > > xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
> > > fixing this by adding a hint (has_data_valid) and set it only on the
> > > receiving path.
> > > 
> > > Cc: Rolf Neugebauer
> > > Signed-off-by: Jason Wang
> > > ---
> > >   drivers/net/macvtap.c  | 2 +-
> > >   drivers/net/tun.c  | 2 +-
> > >   drivers/net/virtio_net.c   | 2 +-
> > >   include/linux/virtio_net.h | 6 +-
> > >   net/packet/af_packet.c | 4 ++--
> > >   5 files changed, 10 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> > > index 5c26653..4026185 100644
> > > --- a/drivers/net/macvtap.c
> > > +++ b/drivers/net/macvtap.c
> > > @@ -825,7 +825,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue 
> > > *q,
> > >   return -EINVAL;
> > >   if (virtio_net_hdr_from_skb(skb, _hdr,
> > > - macvtap_is_little_endian(q)))
> > > + macvtap_is_little_endian(q), true))
> > >   BUG();
> > >   if (copy_to_iter(_hdr, sizeof(vnet_hdr), iter) !=
> > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > > index cd8e02c..2cd10b2 100644
> > > --- a/drivers/net/tun.c
> > > +++ b/drivers/net/tun.c
> > > @@ -1360,7 +1360,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> > >   return -EINVAL;
> > >   if (virtio_net_hdr_from_skb(skb, ,
> > > - tun_is_little_endian(tun))) {
> > > + tun_is_little_endian(tun), true)) {
> > >   struct skb_shared_info *sinfo = skb_shinfo(skb);
> > >   pr_err("unexpected GSO type: "
> > >  "0x%x, gso_size %d, hdr_len %d\n",
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index 4a10500..3474243 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -1104,7 +1104,7 @@ static int xmit_skb(struct send_queue *sq, struct 
> > > sk_buff *skb)
> > >   hdr = skb_vnet_hdr(skb);
> > >   if (virtio_net_hdr_from_skb(skb, >hdr,
> > > - virtio_is_little_endian(vi->vdev)))
> > > + virtio_is_little_endian(vi->vdev), false))
> > >   BUG();
> > >   if (vi->mergeable_rx_bufs)
> > > diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> > > index 5643647..5209b5e 100644
> > > --- a/include/linux/virtio_net.h
> > > +++ b/include/linux/virtio_net.h
> > > @@ -56,7 +56,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff 
> > > *skb,
> > >   static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> > > struct virtio_net_hdr *hdr,
> > > -   bool little_endian)
> > > +   bool little_endian,
> > > +   bool has_data_valid)
> > >   {
> > >   memset(hdr, 0, sizeof(*hdr));   /* no info leak */
> > I would prefer naming it is_rx. Callers should not know about
> > internal details like data valid, the issue we are trying to fix
> > here is that tx and tx headers are slightly different.
> > 
> 
> Actually, I've considered something like this, but the problem is:
> 
> - tun use this on xmit, so is_rx = true may cause some confusion here

tun is generally weird, yes. how about rx_format?

> - I believe we may want to support DATA_VALID (like xen-netback) on tx
> (probably with a feature) in the future.
> 
> Thanks

We'll put that knowledge within virtio_net_hdr_from_skb not
in the callers I think.

-- 
MST

Re: [PATCH v2 03/26] drm/rockchip: dw-mipi-dsi: pass mode in where needed

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

This shows that we only use the mode from the enable function and
prepares us to remove the "mode" field and the mode_set hook in the next
commit.

Signed-off-by: John Keeping 
---
New in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 41 ++
  1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index bbd992299f73..cdbd25087e83 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -330,11 +330,11 @@ static int max_mbps_to_testdin(unsigned int max_mbps)
   * The controller should generate 2 frames before
   * preparing the peripheral.
   */
-static void dw_mipi_dsi_wait_for_two_frames(struct dw_mipi_dsi *dsi)
+static void dw_mipi_dsi_wait_for_two_frames(struct drm_display_mode *mode)
  {
int refresh, two_frames;
  
-	refresh = drm_mode_vrefresh(dsi->mode);

+   refresh = drm_mode_vrefresh(mode);
two_frames = DIV_ROUND_UP(MSEC_PER_SEC, refresh) * 2;
msleep(two_frames);
  }
@@ -459,7 +459,8 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
return ret;
  }
  
-static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)

+static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
+   struct drm_display_mode *mode)
  {
unsigned int i, pre;
unsigned long mpclk, pllref, tmp;
@@ -474,7 +475,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
return bpp;
}
  
-	mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);

+   mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
if (mpclk) {
/* take 1 / 0.9, since mbps must big than bandwidth of RGB */
tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
@@ -742,43 +743,44 @@ static void dw_mipi_dsi_command_mode_config(struct 
dw_mipi_dsi *dsi)
  
  /* Get lane byte clock cycles. */

  static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
+  struct drm_display_mode *mode,
   u32 hcomponent)
  {
u32 frac, lbcc;
  
  	lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
  
-	frac = lbcc % dsi->mode->clock;

-   lbcc = lbcc / dsi->mode->clock;
+   frac = lbcc % mode->clock;
+   lbcc = lbcc / mode->clock;
if (frac)
lbcc++;
  
  	return lbcc;

  }
  
-static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)

+static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi,
+ struct drm_display_mode *mode)
  {
u32 htotal, hsa, hbp, lbcc;
-   struct drm_display_mode *mode = dsi->mode;
  
  	htotal = mode->htotal;

hsa = mode->hsync_end - mode->hsync_start;
hbp = mode->htotal - mode->hsync_end;
  
-	lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, htotal);

+   lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, mode, htotal);
dsi_write(dsi, DSI_VID_HLINE_TIME, lbcc);
  
-	lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, hsa);

+   lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, mode, hsa);
dsi_write(dsi, DSI_VID_HSA_TIME, lbcc);
  
-	lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, hbp);

+   lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, mode, hbp);
dsi_write(dsi, DSI_VID_HBP_TIME, lbcc);
  }
  
-static void dw_mipi_dsi_vertical_timing_config(struct dw_mipi_dsi *dsi)

+static void dw_mipi_dsi_vertical_timing_config(struct dw_mipi_dsi *dsi,
+  struct drm_display_mode *mode)
  {
u32 vactive, vsa, vfp, vbp;
-   struct drm_display_mode *mode = dsi->mode;
  
  	vactive = mode->vdisplay;

vsa = mode->vsync_end - mode->vsync_start;
@@ -852,11 +854,12 @@ static void dw_mipi_dsi_encoder_disable(struct 
drm_encoder *encoder)
  static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
  {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
+   struct drm_display_mode *mode = dsi->mode;
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
int ret;
  
-	ret = dw_mipi_dsi_get_lane_bps(dsi);

+   ret = dw_mipi_dsi_get_lane_bps(dsi, mode);
if (ret < 0)
return;
  
@@ -866,13 +869,13 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)

}
  
  	dw_mipi_dsi_init(dsi);

-   dw_mipi_dsi_dpi_config(dsi, dsi->mode);
+   dw_mipi_dsi_dpi_config(dsi, mode);
dw_mipi_dsi_packet_handler_config(dsi);
dw_mipi_dsi_video_mode_config(dsi);
-   dw_mipi_dsi_video_packet_config(dsi, dsi->mode);
+   dw_mipi_dsi_video_packet_config(dsi, mode);
dw_mipi_dsi_command_mode_config(dsi);
-

Re: [PATCH v2 03/26] drm/rockchip: dw-mipi-dsi: pass mode in where needed

2017-01-21 Thread Chris Zhong


Hi John

Reviewed-by: Chris Zhong 

On 01/22/2017 12:31 AM, John Keeping wrote:

This shows that we only use the mode from the enable function and
prepares us to remove the "mode" field and the mode_set hook in the next
commit.

Signed-off-by: John Keeping 
---
New in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 41 ++
  1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index bbd992299f73..cdbd25087e83 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -330,11 +330,11 @@ static int max_mbps_to_testdin(unsigned int max_mbps)
   * The controller should generate 2 frames before
   * preparing the peripheral.
   */
-static void dw_mipi_dsi_wait_for_two_frames(struct dw_mipi_dsi *dsi)
+static void dw_mipi_dsi_wait_for_two_frames(struct drm_display_mode *mode)
  {
int refresh, two_frames;
  
-	refresh = drm_mode_vrefresh(dsi->mode);

+   refresh = drm_mode_vrefresh(mode);
two_frames = DIV_ROUND_UP(MSEC_PER_SEC, refresh) * 2;
msleep(two_frames);
  }
@@ -459,7 +459,8 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
return ret;
  }
  
-static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)

+static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
+   struct drm_display_mode *mode)
  {
unsigned int i, pre;
unsigned long mpclk, pllref, tmp;
@@ -474,7 +475,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
return bpp;
}
  
-	mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);

+   mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
if (mpclk) {
/* take 1 / 0.9, since mbps must big than bandwidth of RGB */
tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
@@ -742,43 +743,44 @@ static void dw_mipi_dsi_command_mode_config(struct 
dw_mipi_dsi *dsi)
  
  /* Get lane byte clock cycles. */

  static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
+  struct drm_display_mode *mode,
   u32 hcomponent)
  {
u32 frac, lbcc;
  
  	lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
  
-	frac = lbcc % dsi->mode->clock;

-   lbcc = lbcc / dsi->mode->clock;
+   frac = lbcc % mode->clock;
+   lbcc = lbcc / mode->clock;
if (frac)
lbcc++;
  
  	return lbcc;

  }
  
-static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)

+static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi,
+ struct drm_display_mode *mode)
  {
u32 htotal, hsa, hbp, lbcc;
-   struct drm_display_mode *mode = dsi->mode;
  
  	htotal = mode->htotal;

hsa = mode->hsync_end - mode->hsync_start;
hbp = mode->htotal - mode->hsync_end;
  
-	lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, htotal);

+   lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, mode, htotal);
dsi_write(dsi, DSI_VID_HLINE_TIME, lbcc);
  
-	lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, hsa);

+   lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, mode, hsa);
dsi_write(dsi, DSI_VID_HSA_TIME, lbcc);
  
-	lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, hbp);

+   lbcc = dw_mipi_dsi_get_hcomponent_lbcc(dsi, mode, hbp);
dsi_write(dsi, DSI_VID_HBP_TIME, lbcc);
  }
  
-static void dw_mipi_dsi_vertical_timing_config(struct dw_mipi_dsi *dsi)

+static void dw_mipi_dsi_vertical_timing_config(struct dw_mipi_dsi *dsi,
+  struct drm_display_mode *mode)
  {
u32 vactive, vsa, vfp, vbp;
-   struct drm_display_mode *mode = dsi->mode;
  
  	vactive = mode->vdisplay;

vsa = mode->vsync_end - mode->vsync_start;
@@ -852,11 +854,12 @@ static void dw_mipi_dsi_encoder_disable(struct 
drm_encoder *encoder)
  static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
  {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
+   struct drm_display_mode *mode = dsi->mode;
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
int ret;
  
-	ret = dw_mipi_dsi_get_lane_bps(dsi);

+   ret = dw_mipi_dsi_get_lane_bps(dsi, mode);
if (ret < 0)
return;
  
@@ -866,13 +869,13 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)

}
  
  	dw_mipi_dsi_init(dsi);

-   dw_mipi_dsi_dpi_config(dsi, dsi->mode);
+   dw_mipi_dsi_dpi_config(dsi, mode);
dw_mipi_dsi_packet_handler_config(dsi);
dw_mipi_dsi_video_mode_config(dsi);
-   dw_mipi_dsi_video_packet_config(dsi, dsi->mode);
+   dw_mipi_dsi_video_packet_config(dsi, mode);
dw_mipi_dsi_command_mode_config(dsi);
-   dw_mipi_dsi_line_timer_config(dsi);
-

Re: [PATCH v2 01/26] drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for MIPI

2017-01-21 Thread Chris Zhong


Hi John


On 01/22/2017 12:31 AM, John Keeping wrote:

With atomic modesetting the hardware will be powered off when the
mode_set function is called.  We should configure the hardware in the
commit function (or even the enable function, but switching from commit
to enable is left for a future patch).


I tend to merge the 2 patches into one.



Signed-off-by: John Keeping 
---
v2:
- also move dw_mipi_dsi_get_lane_bps into the commit function
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 45 ++
  1 file changed, 19 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index d9aa382bb629..8b83ae50c8f3 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -819,34 +819,8 @@ static void dw_mipi_dsi_encoder_mode_set(struct 
drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
  {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
-   int ret;
  
  	dsi->mode = adjusted_mode;

-
-   ret = dw_mipi_dsi_get_lane_bps(dsi);
-   if (ret < 0)
-   return;
-
-   if (clk_prepare_enable(dsi->pclk)) {
-   dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
-   return;
-   }
-
-   dw_mipi_dsi_init(dsi);
-   dw_mipi_dsi_dpi_config(dsi, mode);
-   dw_mipi_dsi_packet_handler_config(dsi);
-   dw_mipi_dsi_video_mode_config(dsi);
-   dw_mipi_dsi_video_packet_config(dsi, mode);
-   dw_mipi_dsi_command_mode_config(dsi);
-   dw_mipi_dsi_line_timer_config(dsi);
-   dw_mipi_dsi_vertical_timing_config(dsi);
-   dw_mipi_dsi_dphy_timing_config(dsi);
-   dw_mipi_dsi_dphy_interface_config(dsi);
-   dw_mipi_dsi_clear_err(dsi);
-   if (drm_panel_prepare(dsi->panel))
-   dev_err(dsi->dev, "failed to prepare panel\n");
-
-   clk_disable_unprepare(dsi->pclk);
  }
  
  static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)

@@ -880,12 +854,31 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder 
*encoder)
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
+   int ret;
+
+   ret = dw_mipi_dsi_get_lane_bps(dsi);
+   if (ret < 0)
+   return;
  
  	if (clk_prepare_enable(dsi->pclk)) {

dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
return;
}
  
+	dw_mipi_dsi_init(dsi);

+   dw_mipi_dsi_dpi_config(dsi, dsi->mode);
+   dw_mipi_dsi_packet_handler_config(dsi);
+   dw_mipi_dsi_video_mode_config(dsi);
+   dw_mipi_dsi_video_packet_config(dsi, dsi->mode);
+   dw_mipi_dsi_command_mode_config(dsi);
+   dw_mipi_dsi_line_timer_config(dsi);
+   dw_mipi_dsi_vertical_timing_config(dsi);
+   dw_mipi_dsi_dphy_timing_config(dsi);
+   dw_mipi_dsi_dphy_interface_config(dsi);
+   dw_mipi_dsi_clear_err(dsi);
+   if (drm_panel_prepare(dsi->panel))
+   dev_err(dsi->dev, "failed to prepare panel\n");
+
dw_mipi_dsi_phy_init(dsi);
dw_mipi_dsi_wait_for_two_frames(dsi);

Re: [PATCH v2 01/26] drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for MIPI

2017-01-21 Thread Chris Zhong


Hi John


On 01/22/2017 12:31 AM, John Keeping wrote:

With atomic modesetting the hardware will be powered off when the
mode_set function is called.  We should configure the hardware in the
commit function (or even the enable function, but switching from commit
to enable is left for a future patch).


I tend to merge the 2 patches into one.



Signed-off-by: John Keeping 
---
v2:
- also move dw_mipi_dsi_get_lane_bps into the commit function
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 45 ++
  1 file changed, 19 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index d9aa382bb629..8b83ae50c8f3 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -819,34 +819,8 @@ static void dw_mipi_dsi_encoder_mode_set(struct 
drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
  {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
-   int ret;
  
  	dsi->mode = adjusted_mode;

-
-   ret = dw_mipi_dsi_get_lane_bps(dsi);
-   if (ret < 0)
-   return;
-
-   if (clk_prepare_enable(dsi->pclk)) {
-   dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
-   return;
-   }
-
-   dw_mipi_dsi_init(dsi);
-   dw_mipi_dsi_dpi_config(dsi, mode);
-   dw_mipi_dsi_packet_handler_config(dsi);
-   dw_mipi_dsi_video_mode_config(dsi);
-   dw_mipi_dsi_video_packet_config(dsi, mode);
-   dw_mipi_dsi_command_mode_config(dsi);
-   dw_mipi_dsi_line_timer_config(dsi);
-   dw_mipi_dsi_vertical_timing_config(dsi);
-   dw_mipi_dsi_dphy_timing_config(dsi);
-   dw_mipi_dsi_dphy_interface_config(dsi);
-   dw_mipi_dsi_clear_err(dsi);
-   if (drm_panel_prepare(dsi->panel))
-   dev_err(dsi->dev, "failed to prepare panel\n");
-
-   clk_disable_unprepare(dsi->pclk);
  }
  
  static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)

@@ -880,12 +854,31 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder 
*encoder)
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
+   int ret;
+
+   ret = dw_mipi_dsi_get_lane_bps(dsi);
+   if (ret < 0)
+   return;
  
  	if (clk_prepare_enable(dsi->pclk)) {

dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
return;
}
  
+	dw_mipi_dsi_init(dsi);

+   dw_mipi_dsi_dpi_config(dsi, dsi->mode);
+   dw_mipi_dsi_packet_handler_config(dsi);
+   dw_mipi_dsi_video_mode_config(dsi);
+   dw_mipi_dsi_video_packet_config(dsi, dsi->mode);
+   dw_mipi_dsi_command_mode_config(dsi);
+   dw_mipi_dsi_line_timer_config(dsi);
+   dw_mipi_dsi_vertical_timing_config(dsi);
+   dw_mipi_dsi_dphy_timing_config(dsi);
+   dw_mipi_dsi_dphy_interface_config(dsi);
+   dw_mipi_dsi_clear_err(dsi);
+   if (drm_panel_prepare(dsi->panel))
+   dev_err(dsi->dev, "failed to prepare panel\n");
+
dw_mipi_dsi_phy_init(dsi);
dw_mipi_dsi_wait_for_two_frames(dsi);

core.c:undefined reference to `fpu_save'

2017-01-21 Thread kbuild test robot

Hi Andrew,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   4c9eff7af69c61749b9eb09141f18f35edbf2210
commit: c60f169202c7643991a8b4bfeea60e06843d5b5a 
arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h
date:   10 months ago
config: mn10300-allnoconfig (attached as .config)
compiler: am33_2.0-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c60f169202c7643991a8b4bfeea60e06843d5b5a
# save the attached .config to linux build tree
make.cross ARCH=mn10300 

All errors (new ones prefixed by >>):

   kernel/built-in.o: In function `.L410':
>> core.c:(.sched.text+0x28a): undefined reference to `fpu_save'

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


.config.gz
Description: application/gzip

core.c:undefined reference to `fpu_save'

2017-01-21 Thread kbuild test robot

Hi Andrew,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   4c9eff7af69c61749b9eb09141f18f35edbf2210
commit: c60f169202c7643991a8b4bfeea60e06843d5b5a 
arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h
date:   10 months ago
config: mn10300-allnoconfig (attached as .config)
compiler: am33_2.0-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c60f169202c7643991a8b4bfeea60e06843d5b5a
# save the attached .config to linux build tree
make.cross ARCH=mn10300 

All errors (new ones prefixed by >>):

   kernel/built-in.o: In function `.L410':
>> core.c:(.sched.text+0x28a): undefined reference to `fpu_save'

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


.config.gz
Description: application/gzip

Re: [PATCH 2/4] ARM: nommu: dynamic exception base address setting

2017-01-21 Thread Afzal Mohammed

Hi,

On Fri, Jan 20, 2017 at 09:50:22PM +0530, Afzal Mohammed wrote:
> On Thu, Jan 19, 2017 at 01:59:09PM +, Vladimir Murzin wrote:

> > You can use
> > 
> > cpuid_feature_extract(CPUID_EXT_PFR1, 4)
> > 
> > and add a comment explaining what we are looking for and why.

W.r.t comments, tried to keep it concise, C tokens doing a part of it.

> Yes, that is better, was not aware of this, did saw CPUID_EXT_PFR1 as
> an unused macro.

> > > +#ifdef CONFIG_CPU_CP15
> > > + vectors_base = setup_vectors_base();
> > > +#endif
> > 
> > alternatively it can be
> > 
> > unsigned long vector_base = IS_ENABLED(CONFIG_CPU_CP15) ? setup_vbar() 
> > : 0;
> 
> Yes that certainly is better.

Have kept the function name as setup_vector_base() as in addition to
setting up VBAR, V bit also has to be configured by it - so that
function name remains true to it's name.

v2 with changes has been posted.

Regards
afzal

Re: [PATCH 2/4] ARM: nommu: dynamic exception base address setting

2017-01-21 Thread Afzal Mohammed

Hi,

On Fri, Jan 20, 2017 at 09:50:22PM +0530, Afzal Mohammed wrote:
> On Thu, Jan 19, 2017 at 01:59:09PM +, Vladimir Murzin wrote:

> > You can use
> > 
> > cpuid_feature_extract(CPUID_EXT_PFR1, 4)
> > 
> > and add a comment explaining what we are looking for and why.

W.r.t comments, tried to keep it concise, C tokens doing a part of it.

> Yes, that is better, was not aware of this, did saw CPUID_EXT_PFR1 as
> an unused macro.

> > > +#ifdef CONFIG_CPU_CP15
> > > + vectors_base = setup_vectors_base();
> > > +#endif
> > 
> > alternatively it can be
> > 
> > unsigned long vector_base = IS_ENABLED(CONFIG_CPU_CP15) ? setup_vbar() 
> > : 0;
> 
> Yes that certainly is better.

Have kept the function name as setup_vector_base() as in addition to
setting up VBAR, V bit also has to be configured by it - so that
function name remains true to it's name.

v2 with changes has been posted.

Regards
afzal

Re: [PATCH v2] PM / Domains: Keep the pd status during system PM phases

2017-01-21 Thread Elaine Zhang




On 01/20/2017 09:16 PM, Ulf Hansson wrote:

On 20 January 2017 at 03:21, Elaine Zhang  wrote:

If a PM domain is powered off before system suspend,
we hope do nothing in system runtime suspend noirq phase
and system runtime resume noirq phase.


One can hope, but that isn't good enough. :-)




This modify is to slove system resume issue for RK3399.
RK3399 SOC pd_gpu have voltage domain vdd_gpu,
so we must follow open vdd_gpu and power on pd_gpu,
power off pd_gpu and disable vdd_gpu.
Fix up in runtime resume noirq phase power on all PDs.


This doesn't make any sense to me. Can please try to explain this is
in great more detail, then I can try to help.


For example:
-->device suspend
   (mali gpu driver set pd_gpu off by pm_runtime_put_sync(),
and then disabled the vdd_gpu by regulator_disable().)
--> system suspend
-->prepare
-->suspend_noirq():
(power off all pds)
-->system resume
-->resume_noirq():
(power up all pds)
(in this case the vdd_gpu is still disabled,
 if power on the pd_gpu maybe make the system crash)
-->complete : power off the not used pd
-->device resuem
   (mali gpu driver enable vdd_gpu by regulator_enable(),
and then power up the pd_gpu by pm_runtime_get_sync())

So for RK3399 soc, if to set pd_gpu the vdd_gpu must be enabled, or else 
will can't get the ack back.

I hope the pd_gpu power up/off by the driver itself.

May be I solution is not the optimal solution,Do you have better suggestion?



Signed-off-by: Elaine Zhang 
---
  drivers/base/power/domain.c | 10 +++---
  include/linux/pm_domain.h   |  1 +
  2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 5711708532db..81351eec570f 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -842,8 +842,10 @@ static int pm_genpd_prepare(struct device *dev)

 genpd_lock(genpd);

-   if (genpd->prepared_count++ == 0)
+   if (genpd->prepared_count++ == 0) {
 genpd->suspended_count = 0;
+   genpd->suspend_power_off = genpd->status == GPD_STATE_POWER_OFF;
+   }

 genpd_unlock(genpd);

@@ -877,7 +879,8 @@ static int pm_genpd_suspend_noirq(struct device *dev)
 if (IS_ERR(genpd))
 return -EINVAL;

-   if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
+   if (genpd->suspend_power_off ||
+   (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev)))
 return 0;


This isn't going to work, because the PM domain might have been powered on.

There is simply no guarantee to that the PM domain remains powered off
during the system PM suspend phases. For example, any device in the PM
domain that get runtime resumed after the ->prepare() callback is
invoked this, will of course also trigger the PM domain to be powered
on.



 if (genpd->dev_ops.stop && genpd->dev_ops.start) {
@@ -914,7 +917,8 @@ static int pm_genpd_resume_noirq(struct device *dev)
 if (IS_ERR(genpd))
 return -EINVAL;

-   if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
+   if (genpd->suspend_power_off ||
+   (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev)))
 return 0;


Ditto, for the same reasons as above.



 /*
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 81ece61075df..9c0dc364f089 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -62,6 +62,7 @@ struct generic_pm_domain {
 unsigned int device_count;  /* Number of devices */
 unsigned int suspended_count;   /* System suspend device counter */
 unsigned int prepared_count;/* Suspend counter of prepared devices 
*/
+   bool suspend_power_off; /* Power status before system suspend */
 int (*power_off)(struct generic_pm_domain *domain);
 int (*power_on)(struct generic_pm_domain *domain);
 struct gpd_dev_ops dev_ops;
--
1.9.1




Kind regards
Uffe

Re: [PATCH v2] PM / Domains: Keep the pd status during system PM phases

2017-01-21 Thread Elaine Zhang




On 01/20/2017 09:16 PM, Ulf Hansson wrote:

On 20 January 2017 at 03:21, Elaine Zhang  wrote:

If a PM domain is powered off before system suspend,
we hope do nothing in system runtime suspend noirq phase
and system runtime resume noirq phase.


One can hope, but that isn't good enough. :-)




This modify is to slove system resume issue for RK3399.
RK3399 SOC pd_gpu have voltage domain vdd_gpu,
so we must follow open vdd_gpu and power on pd_gpu,
power off pd_gpu and disable vdd_gpu.
Fix up in runtime resume noirq phase power on all PDs.


This doesn't make any sense to me. Can please try to explain this is
in great more detail, then I can try to help.


For example:
-->device suspend
   (mali gpu driver set pd_gpu off by pm_runtime_put_sync(),
and then disabled the vdd_gpu by regulator_disable().)
--> system suspend
-->prepare
-->suspend_noirq():
(power off all pds)
-->system resume
-->resume_noirq():
(power up all pds)
(in this case the vdd_gpu is still disabled,
 if power on the pd_gpu maybe make the system crash)
-->complete : power off the not used pd
-->device resuem
   (mali gpu driver enable vdd_gpu by regulator_enable(),
and then power up the pd_gpu by pm_runtime_get_sync())

So for RK3399 soc, if to set pd_gpu the vdd_gpu must be enabled, or else 
will can't get the ack back.

I hope the pd_gpu power up/off by the driver itself.

May be I solution is not the optimal solution,Do you have better suggestion?



Signed-off-by: Elaine Zhang 
---
  drivers/base/power/domain.c | 10 +++---
  include/linux/pm_domain.h   |  1 +
  2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 5711708532db..81351eec570f 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -842,8 +842,10 @@ static int pm_genpd_prepare(struct device *dev)

 genpd_lock(genpd);

-   if (genpd->prepared_count++ == 0)
+   if (genpd->prepared_count++ == 0) {
 genpd->suspended_count = 0;
+   genpd->suspend_power_off = genpd->status == GPD_STATE_POWER_OFF;
+   }

 genpd_unlock(genpd);

@@ -877,7 +879,8 @@ static int pm_genpd_suspend_noirq(struct device *dev)
 if (IS_ERR(genpd))
 return -EINVAL;

-   if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
+   if (genpd->suspend_power_off ||
+   (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev)))
 return 0;


This isn't going to work, because the PM domain might have been powered on.

There is simply no guarantee to that the PM domain remains powered off
during the system PM suspend phases. For example, any device in the PM
domain that get runtime resumed after the ->prepare() callback is
invoked this, will of course also trigger the PM domain to be powered
on.



 if (genpd->dev_ops.stop && genpd->dev_ops.start) {
@@ -914,7 +917,8 @@ static int pm_genpd_resume_noirq(struct device *dev)
 if (IS_ERR(genpd))
 return -EINVAL;

-   if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
+   if (genpd->suspend_power_off ||
+   (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev)))
 return 0;


Ditto, for the same reasons as above.



 /*
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 81ece61075df..9c0dc364f089 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -62,6 +62,7 @@ struct generic_pm_domain {
 unsigned int device_count;  /* Number of devices */
 unsigned int suspended_count;   /* System suspend device counter */
 unsigned int prepared_count;/* Suspend counter of prepared devices 
*/
+   bool suspend_power_off; /* Power status before system suspend */
 int (*power_off)(struct generic_pm_domain *domain);
 int (*power_on)(struct generic_pm_domain *domain);
 struct gpd_dev_ops dev_ops;
--
1.9.1




Kind regards
Uffe

[PATCH] iio: trigger: close race condition in acquiring trigger reference

2017-01-21 Thread Alison Schofield

In iio_trigger_write_current() we find the trigger we want while
holding mutex on the list of triggers, but we don't actually do a
get on it while holding mutex.  We wait until further validations
are completed and we're sure it's the one we want.  Race condition
is that it could be freed by the time we do the get.

Solution is to grab the trigger (iio_trigger_get) as soon as we
find it while holding mutex on the list of triggers.  If later
we decide it's not the right one, put it back. (iio_trigger_put).


Signed-off-by: Alison Schofield 
Suggested-by: Lars-Peter Clausen 

---
Not directly related to this patch, but wondering about the
behavior when userspace tries to set an invalid current_trigger.

If the given trigger name is not found on the list, we don't
simply quit, we proceed.  Net result is the old trigger is
removed, the current trigger is set to NULL, and we return
success to userspace.  This looks like desired behavior 
since it is very intentionally coded.  Perhaps it is the
method used to remove a trigger?

Is that what we want?  


 drivers/iio/industrialio-trigger.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index 978729f..d0d869e 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -147,8 +147,7 @@ static struct iio_trigger *__iio_trigger_find_by_name(const 
char *name)
return NULL;
 }
 
-static struct iio_trigger *iio_trigger_find_by_name(const char *name,
-   size_t len)
+static struct iio_trigger *iio_trigger_acquire_by_name(const char *name)
 {
struct iio_trigger *trig = NULL, *iter;
 
@@ -156,6 +155,7 @@ static struct iio_trigger *iio_trigger_find_by_name(const 
char *name,
list_for_each_entry(iter, _trigger_list, list)
if (sysfs_streq(iter->name, name)) {
trig = iter;
+   iio_trigger_get(trig);
break;
}
mutex_unlock(_trigger_list_lock);
@@ -416,20 +416,22 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
}
mutex_unlock(_dev->mlock);
 
-   trig = iio_trigger_find_by_name(buf, len);
-   if (oldtrig == trig)
-   return len;
+   trig = iio_trigger_acquire_by_name(buf);
+   if (oldtrig == trig) {
+   ret = len;
+   goto out_trigger_put;
+   }
 
if (trig && indio_dev->info->validate_trigger) {
ret = indio_dev->info->validate_trigger(indio_dev, trig);
if (ret)
-   return ret;
+   goto out_trigger_put;
}
 
if (trig && trig->ops->validate_device) {
ret = trig->ops->validate_device(trig, indio_dev);
if (ret)
-   return ret;
+   goto out_trigger_put;
}
 
indio_dev->trig = trig;
@@ -441,13 +443,16 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
iio_trigger_put(oldtrig);
}
if (indio_dev->trig) {
-   iio_trigger_get(indio_dev->trig);
if (indio_dev->modes & INDIO_EVENT_TRIGGERED)
iio_trigger_attach_poll_func(indio_dev->trig,
 indio_dev->pollfunc_event);
}
 
return len;
+
+out_trigger_put:
+   iio_trigger_put(trig);
+   return ret;
 }
 
 static DEVICE_ATTR(current_trigger, S_IRUGO | S_IWUSR,
-- 
2.1.4

[PATCH] iio: trigger: close race condition in acquiring trigger reference

2017-01-21 Thread Alison Schofield

In iio_trigger_write_current() we find the trigger we want while
holding mutex on the list of triggers, but we don't actually do a
get on it while holding mutex.  We wait until further validations
are completed and we're sure it's the one we want.  Race condition
is that it could be freed by the time we do the get.

Solution is to grab the trigger (iio_trigger_get) as soon as we
find it while holding mutex on the list of triggers.  If later
we decide it's not the right one, put it back. (iio_trigger_put).


Signed-off-by: Alison Schofield 
Suggested-by: Lars-Peter Clausen 

---
Not directly related to this patch, but wondering about the
behavior when userspace tries to set an invalid current_trigger.

If the given trigger name is not found on the list, we don't
simply quit, we proceed.  Net result is the old trigger is
removed, the current trigger is set to NULL, and we return
success to userspace.  This looks like desired behavior 
since it is very intentionally coded.  Perhaps it is the
method used to remove a trigger?

Is that what we want?  


 drivers/iio/industrialio-trigger.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index 978729f..d0d869e 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -147,8 +147,7 @@ static struct iio_trigger *__iio_trigger_find_by_name(const 
char *name)
return NULL;
 }
 
-static struct iio_trigger *iio_trigger_find_by_name(const char *name,
-   size_t len)
+static struct iio_trigger *iio_trigger_acquire_by_name(const char *name)
 {
struct iio_trigger *trig = NULL, *iter;
 
@@ -156,6 +155,7 @@ static struct iio_trigger *iio_trigger_find_by_name(const 
char *name,
list_for_each_entry(iter, _trigger_list, list)
if (sysfs_streq(iter->name, name)) {
trig = iter;
+   iio_trigger_get(trig);
break;
}
mutex_unlock(_trigger_list_lock);
@@ -416,20 +416,22 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
}
mutex_unlock(_dev->mlock);
 
-   trig = iio_trigger_find_by_name(buf, len);
-   if (oldtrig == trig)
-   return len;
+   trig = iio_trigger_acquire_by_name(buf);
+   if (oldtrig == trig) {
+   ret = len;
+   goto out_trigger_put;
+   }
 
if (trig && indio_dev->info->validate_trigger) {
ret = indio_dev->info->validate_trigger(indio_dev, trig);
if (ret)
-   return ret;
+   goto out_trigger_put;
}
 
if (trig && trig->ops->validate_device) {
ret = trig->ops->validate_device(trig, indio_dev);
if (ret)
-   return ret;
+   goto out_trigger_put;
}
 
indio_dev->trig = trig;
@@ -441,13 +443,16 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
iio_trigger_put(oldtrig);
}
if (indio_dev->trig) {
-   iio_trigger_get(indio_dev->trig);
if (indio_dev->modes & INDIO_EVENT_TRIGGERED)
iio_trigger_attach_poll_func(indio_dev->trig,
 indio_dev->pollfunc_event);
}
 
return len;
+
+out_trigger_put:
+   iio_trigger_put(trig);
+   return ret;
 }
 
 static DEVICE_ATTR(current_trigger, S_IRUGO | S_IWUSR,
-- 
2.1.4

Re: [PATCH 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

2017-01-21 Thread Afzal Mohammed

Hi,

On Thu, Jan 19, 2017 at 02:24:24PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 19, 2017 at 02:07:39AM +0530, afzal mohammed wrote:

> > +#define VECTORS_BASE   0x
> 
> This should be UL(0x)

This has been taken care in v2.

Regards
afzal

Re: [PATCH 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

2017-01-21 Thread Afzal Mohammed

Hi,

On Thu, Jan 19, 2017 at 02:24:24PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 19, 2017 at 02:07:39AM +0530, afzal mohammed wrote:

> > +#define VECTORS_BASE   0x
> 
> This should be UL(0x)

This has been taken care in v2.

Regards
afzal

[PATCH v2 4/4] ARM: nommu: remove Hivecs configuration is asm

2017-01-21 Thread afzal mohammed

Now that exception based address is handled dynamically for
processors with CP15, remove Hivecs configuration in assembly.

Signed-off-by: afzal mohammed 
---
 arch/arm/kernel/head-nommu.S | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 6b4eb27b8758..2e21e08de747 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -152,11 +152,6 @@ __after_proc_init:
 #ifdef CONFIG_CPU_ICACHE_DISABLE
bic r0, r0, #CR_I
 #endif
-#ifdef CONFIG_CPU_HIGH_VECTOR
-   orr r0, r0, #CR_V
-#else
-   bic r0, r0, #CR_V
-#endif
mcr p15, 0, r0, c1, c0, 0   @ write control reg
 #elif defined (CONFIG_CPU_V7M)
/* For V7M systems we want to modify the CCR similarly to the SCTLR */
-- 
2.11.0

[PATCH v2 4/4] ARM: nommu: remove Hivecs configuration is asm

2017-01-21 Thread afzal mohammed

Now that exception based address is handled dynamically for
processors with CP15, remove Hivecs configuration in assembly.

Signed-off-by: afzal mohammed 
---
 arch/arm/kernel/head-nommu.S | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 6b4eb27b8758..2e21e08de747 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -152,11 +152,6 @@ __after_proc_init:
 #ifdef CONFIG_CPU_ICACHE_DISABLE
bic r0, r0, #CR_I
 #endif
-#ifdef CONFIG_CPU_HIGH_VECTOR
-   orr r0, r0, #CR_V
-#else
-   bic r0, r0, #CR_V
-#endif
mcr p15, 0, r0, c1, c0, 0   @ write control reg
 #elif defined (CONFIG_CPU_V7M)
/* For V7M systems we want to modify the CCR similarly to the SCTLR */
-- 
2.11.0

[PATCH v2 3/4] ARM: nommu: display vectors base

2017-01-21 Thread afzal mohammed

The exception base address is now dynamically estimated for no-MMU,
display it. As it is the case, now limit VECTORS_BASE usage to MMU
scenario.

Signed-off-by: afzal mohammed 
---

v2:
 A change to accomodate bisectability resolution on patch 1/4

 arch/arm/include/asm/memory.h | 4 ++--
 arch/arm/mm/init.c| 5 +
 arch/arm/mm/mm.h  | 5 +++--
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 0b5416fe7709..9ae474bf84fc 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -83,6 +83,8 @@
 #define IOREMAP_MAX_ORDER  24
 #endif
 
+#define VECTORS_BASE   UL(0x)
+
 #else /* CONFIG_MMU */
 
 /*
@@ -111,8 +113,6 @@
 
 #endif /* !CONFIG_MMU */
 
-#define VECTORS_BASE   UL(0x)
-
 /*
  * We fix the TCM memories max 32 KiB ITCM resp DTCM at these
  * locations
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 823e119a5daa..9c68e3aba87c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -522,7 +522,12 @@ void __init mem_init(void)
"  .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
"   .bss : 0x%p" " - 0x%p" "   (%4td kB)\n",
 
+#ifdef CONFIG_MMU
MLK(VECTORS_BASE, VECTORS_BASE + PAGE_SIZE),
+#else
+   MLK(vectors_base, vectors_base + PAGE_SIZE),
+#endif
+
 #ifdef CONFIG_HAVE_TCM
MLK(DTCM_OFFSET, (unsigned long) dtcm_end),
MLK(ITCM_OFFSET, (unsigned long) itcm_end),
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index ce727d47275c..546f09437fca 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -79,8 +79,9 @@ struct static_vm {
 extern struct list_head static_vmlist;
 extern struct static_vm *find_static_vm_vaddr(void *vaddr);
 extern __init void add_static_vm_early(struct static_vm *svm);
-
-#endif
+#else /* CONFIG_MMU */
+extern unsigned long vectors_base;
+#endif /* CONFIG_MMU */
 
 #ifdef CONFIG_ZONE_DMA
 extern phys_addr_t arm_dma_limit;
-- 
2.11.0

[PATCH v2 3/4] ARM: nommu: display vectors base

2017-01-21 Thread afzal mohammed

The exception base address is now dynamically estimated for no-MMU,
display it. As it is the case, now limit VECTORS_BASE usage to MMU
scenario.

Signed-off-by: afzal mohammed 
---

v2:
 A change to accomodate bisectability resolution on patch 1/4

 arch/arm/include/asm/memory.h | 4 ++--
 arch/arm/mm/init.c| 5 +
 arch/arm/mm/mm.h  | 5 +++--
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 0b5416fe7709..9ae474bf84fc 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -83,6 +83,8 @@
 #define IOREMAP_MAX_ORDER  24
 #endif
 
+#define VECTORS_BASE   UL(0x)
+
 #else /* CONFIG_MMU */
 
 /*
@@ -111,8 +113,6 @@
 
 #endif /* !CONFIG_MMU */
 
-#define VECTORS_BASE   UL(0x)
-
 /*
  * We fix the TCM memories max 32 KiB ITCM resp DTCM at these
  * locations
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 823e119a5daa..9c68e3aba87c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -522,7 +522,12 @@ void __init mem_init(void)
"  .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
"   .bss : 0x%p" " - 0x%p" "   (%4td kB)\n",
 
+#ifdef CONFIG_MMU
MLK(VECTORS_BASE, VECTORS_BASE + PAGE_SIZE),
+#else
+   MLK(vectors_base, vectors_base + PAGE_SIZE),
+#endif
+
 #ifdef CONFIG_HAVE_TCM
MLK(DTCM_OFFSET, (unsigned long) dtcm_end),
MLK(ITCM_OFFSET, (unsigned long) itcm_end),
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index ce727d47275c..546f09437fca 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -79,8 +79,9 @@ struct static_vm {
 extern struct list_head static_vmlist;
 extern struct static_vm *find_static_vm_vaddr(void *vaddr);
 extern __init void add_static_vm_early(struct static_vm *svm);
-
-#endif
+#else /* CONFIG_MMU */
+extern unsigned long vectors_base;
+#endif /* CONFIG_MMU */
 
 #ifdef CONFIG_ZONE_DMA
 extern phys_addr_t arm_dma_limit;
-- 
2.11.0

[PATCH v2 2/4] ARM: nommu: dynamic exception base address setting

2017-01-21 Thread afzal mohammed

No-MMU dynamic exception base address configuration on CP15
processors. In the case of low vectors, decision based on whether
security extensions are enabled & whether remap vectors to RAM
CONFIG option is selected.

For no-MMU without CP15, current default value of 0x0 is retained.

Signed-off-by: afzal mohammed 
---

v2:
 Use existing helpers to detect security extensions
 Rewrite a CPP step to C for readability

 arch/arm/mm/nommu.c | 52 ++--
 1 file changed, 50 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 2740967727e2..20ac52579952 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -11,6 +11,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,6 +23,8 @@
 
 #include "mm.h"
 
+unsigned long vectors_base;
+
 #ifdef CONFIG_ARM_MPU
 struct mpu_rgn_info mpu_rgn_info;
 
@@ -278,15 +281,60 @@ static void sanity_check_meminfo_mpu(void) {}
 static void __init mpu_setup(void) {}
 #endif /* CONFIG_ARM_MPU */
 
+#ifdef CONFIG_CPU_CP15
+#ifdef CONFIG_CPU_HIGH_VECTOR
+static unsigned long __init setup_vectors_base(void)
+{
+   unsigned long reg = get_cr();
+
+   set_cr(reg | CR_V);
+   return 0x;
+}
+#else /* CONFIG_CPU_HIGH_VECTOR */
+/* Write exception base address to VBAR */
+static inline void set_vbar(unsigned long val)
+{
+   asm("mcr p15, 0, %0, c12, c0, 0" : : "r" (val) : "cc");
+}
+
+/*
+ * Security extensions, bits[7:4], permitted values,
+ * 0b - not implemented, 0b0001/0b0010 - implemented
+ */
+static inline bool security_extensions_enabled(void)
+{
+   return !!cpuid_feature_extract(CPUID_EXT_PFR1, 4);
+}
+
+static unsigned long __init setup_vectors_base(void)
+{
+   unsigned long base = 0, reg = get_cr();
+
+   set_cr(reg & ~CR_V);
+   if (security_extensions_enabled()) {
+   if (IS_ENABLED(CONFIG_REMAP_VECTORS_TO_RAM))
+   base = CONFIG_DRAM_BASE;
+   set_vbar(base);
+   } else if (IS_ENABLED(CONFIG_REMAP_VECTORS_TO_RAM)) {
+   if (CONFIG_DRAM_BASE != 0)
+   pr_err("Security extensions not enabled, vectors cannot 
be remapped to RAM, vectors base will be 0x\n");
+   }
+
+   return base;
+}
+#endif /* CONFIG_CPU_HIGH_VECTOR */
+#endif /* CONFIG_CPU_CP15 */
+
 void __init arm_mm_memblock_reserve(void)
 {
 #ifndef CONFIG_CPU_V7M
+   vectors_base = IS_ENABLED(CONFIG_CPU_CP15) ? setup_vectors_base() : 0;
/*
 * Register the exception vector page.
 * some architectures which the DRAM is the exception vector to trap,
 * alloc_page breaks with error, although it is not NULL, but "0."
 */
-   memblock_reserve(CONFIG_VECTORS_BASE, 2 * PAGE_SIZE);
+   memblock_reserve(vectors_base, 2 * PAGE_SIZE);
 #else /* ifndef CONFIG_CPU_V7M */
/*
 * There is no dedicated vector page on V7-M. So nothing needs to be
@@ -310,7 +358,7 @@ void __init sanity_check_meminfo(void)
  */
 void __init paging_init(const struct machine_desc *mdesc)
 {
-   early_trap_init((void *)CONFIG_VECTORS_BASE);
+   early_trap_init((void *)vectors_base);
mpu_setup();
bootmem_init();
 }
-- 
2.11.0

[PATCH v2 2/4] ARM: nommu: dynamic exception base address setting

2017-01-21 Thread afzal mohammed

No-MMU dynamic exception base address configuration on CP15
processors. In the case of low vectors, decision based on whether
security extensions are enabled & whether remap vectors to RAM
CONFIG option is selected.

For no-MMU without CP15, current default value of 0x0 is retained.

Signed-off-by: afzal mohammed 
---

v2:
 Use existing helpers to detect security extensions
 Rewrite a CPP step to C for readability

 arch/arm/mm/nommu.c | 52 ++--
 1 file changed, 50 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 2740967727e2..20ac52579952 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -11,6 +11,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,6 +23,8 @@
 
 #include "mm.h"
 
+unsigned long vectors_base;
+
 #ifdef CONFIG_ARM_MPU
 struct mpu_rgn_info mpu_rgn_info;
 
@@ -278,15 +281,60 @@ static void sanity_check_meminfo_mpu(void) {}
 static void __init mpu_setup(void) {}
 #endif /* CONFIG_ARM_MPU */
 
+#ifdef CONFIG_CPU_CP15
+#ifdef CONFIG_CPU_HIGH_VECTOR
+static unsigned long __init setup_vectors_base(void)
+{
+   unsigned long reg = get_cr();
+
+   set_cr(reg | CR_V);
+   return 0x;
+}
+#else /* CONFIG_CPU_HIGH_VECTOR */
+/* Write exception base address to VBAR */
+static inline void set_vbar(unsigned long val)
+{
+   asm("mcr p15, 0, %0, c12, c0, 0" : : "r" (val) : "cc");
+}
+
+/*
+ * Security extensions, bits[7:4], permitted values,
+ * 0b - not implemented, 0b0001/0b0010 - implemented
+ */
+static inline bool security_extensions_enabled(void)
+{
+   return !!cpuid_feature_extract(CPUID_EXT_PFR1, 4);
+}
+
+static unsigned long __init setup_vectors_base(void)
+{
+   unsigned long base = 0, reg = get_cr();
+
+   set_cr(reg & ~CR_V);
+   if (security_extensions_enabled()) {
+   if (IS_ENABLED(CONFIG_REMAP_VECTORS_TO_RAM))
+   base = CONFIG_DRAM_BASE;
+   set_vbar(base);
+   } else if (IS_ENABLED(CONFIG_REMAP_VECTORS_TO_RAM)) {
+   if (CONFIG_DRAM_BASE != 0)
+   pr_err("Security extensions not enabled, vectors cannot 
be remapped to RAM, vectors base will be 0x\n");
+   }
+
+   return base;
+}
+#endif /* CONFIG_CPU_HIGH_VECTOR */
+#endif /* CONFIG_CPU_CP15 */
+
 void __init arm_mm_memblock_reserve(void)
 {
 #ifndef CONFIG_CPU_V7M
+   vectors_base = IS_ENABLED(CONFIG_CPU_CP15) ? setup_vectors_base() : 0;
/*
 * Register the exception vector page.
 * some architectures which the DRAM is the exception vector to trap,
 * alloc_page breaks with error, although it is not NULL, but "0."
 */
-   memblock_reserve(CONFIG_VECTORS_BASE, 2 * PAGE_SIZE);
+   memblock_reserve(vectors_base, 2 * PAGE_SIZE);
 #else /* ifndef CONFIG_CPU_V7M */
/*
 * There is no dedicated vector page on V7-M. So nothing needs to be
@@ -310,7 +358,7 @@ void __init sanity_check_meminfo(void)
  */
 void __init paging_init(const struct machine_desc *mdesc)
 {
-   early_trap_init((void *)CONFIG_VECTORS_BASE);
+   early_trap_init((void *)vectors_base);
mpu_setup();
bootmem_init();
 }
-- 
2.11.0

[PATCH v2 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

2017-01-21 Thread afzal mohammed

For MMU configurations, VECTORS_BASE is always 0x, a macro
definition will suffice.

For no-MMU, exception base address is dynamically determined in
subsequent patches. To preserve bisectability, now make the
macro applicable for no-MMU scenario too.

Thanks to 0-DAY kernel test infrastructure that found the
bisectability issue. This macro will be restricted to MMU case upon
dynamically determining exception base address for no-MMU.

Once exception address is handled dynamically for no-MMU,
VECTORS_BASE can be removed from Kconfig.

Suggested-by: Russell King 
Signed-off-by: afzal mohammed 
---

v2: 
 Fix bisectability issue on !MMU builds
 UL suffix on VECTORS_BASE definition

 arch/arm/include/asm/memory.h  | 2 ++
 arch/arm/mach-berlin/platsmp.c | 3 ++-
 arch/arm/mm/dump.c | 5 +++--
 arch/arm/mm/init.c | 4 ++--
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 76cbd9c674df..0b5416fe7709 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -111,6 +111,8 @@
 
 #endif /* !CONFIG_MMU */
 
+#define VECTORS_BASE   UL(0x)
+
 /*
  * We fix the TCM memories max 32 KiB ITCM resp DTCM at these
  * locations
diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
index 93f90688db18..578d41031abf 100644
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -15,6 +15,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -75,7 +76,7 @@ static void __init berlin_smp_prepare_cpus(unsigned int 
max_cpus)
if (!cpu_ctrl)
goto unmap_scu;
 
-   vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
+   vectors_base = ioremap(VECTORS_BASE, SZ_32K);
if (!vectors_base)
goto unmap_scu;
 
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index 9fe8e241335c..21192d6eda40 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -18,6 +18,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 struct addr_marker {
@@ -31,8 +32,8 @@ static struct addr_marker address_markers[] = {
{ 0,"vmalloc() Area" },
{ VMALLOC_END,  "vmalloc() End" },
{ FIXADDR_START,"Fixmap Area" },
-   { CONFIG_VECTORS_BASE,  "Vectors" },
-   { CONFIG_VECTORS_BASE + PAGE_SIZE * 2, "Vectors End" },
+   { VECTORS_BASE, "Vectors" },
+   { VECTORS_BASE + PAGE_SIZE * 2, "Vectors End" },
{ -1,   NULL },
 };
 
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..823e119a5daa 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -521,8 +522,7 @@ void __init mem_init(void)
"  .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
"   .bss : 0x%p" " - 0x%p" "   (%4td kB)\n",
 
-   MLK(UL(CONFIG_VECTORS_BASE), UL(CONFIG_VECTORS_BASE) +
-   (PAGE_SIZE)),
+   MLK(VECTORS_BASE, VECTORS_BASE + PAGE_SIZE),
 #ifdef CONFIG_HAVE_TCM
MLK(DTCM_OFFSET, (unsigned long) dtcm_end),
MLK(ITCM_OFFSET, (unsigned long) itcm_end),
-- 
2.11.0

[PATCH v2 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

2017-01-21 Thread afzal mohammed

For MMU configurations, VECTORS_BASE is always 0x, a macro
definition will suffice.

For no-MMU, exception base address is dynamically determined in
subsequent patches. To preserve bisectability, now make the
macro applicable for no-MMU scenario too.

Thanks to 0-DAY kernel test infrastructure that found the
bisectability issue. This macro will be restricted to MMU case upon
dynamically determining exception base address for no-MMU.

Once exception address is handled dynamically for no-MMU,
VECTORS_BASE can be removed from Kconfig.

Suggested-by: Russell King 
Signed-off-by: afzal mohammed 
---

v2: 
 Fix bisectability issue on !MMU builds
 UL suffix on VECTORS_BASE definition

 arch/arm/include/asm/memory.h  | 2 ++
 arch/arm/mach-berlin/platsmp.c | 3 ++-
 arch/arm/mm/dump.c | 5 +++--
 arch/arm/mm/init.c | 4 ++--
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 76cbd9c674df..0b5416fe7709 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -111,6 +111,8 @@
 
 #endif /* !CONFIG_MMU */
 
+#define VECTORS_BASE   UL(0x)
+
 /*
  * We fix the TCM memories max 32 KiB ITCM resp DTCM at these
  * locations
diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
index 93f90688db18..578d41031abf 100644
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -15,6 +15,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -75,7 +76,7 @@ static void __init berlin_smp_prepare_cpus(unsigned int 
max_cpus)
if (!cpu_ctrl)
goto unmap_scu;
 
-   vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
+   vectors_base = ioremap(VECTORS_BASE, SZ_32K);
if (!vectors_base)
goto unmap_scu;
 
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index 9fe8e241335c..21192d6eda40 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -18,6 +18,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 struct addr_marker {
@@ -31,8 +32,8 @@ static struct addr_marker address_markers[] = {
{ 0,"vmalloc() Area" },
{ VMALLOC_END,  "vmalloc() End" },
{ FIXADDR_START,"Fixmap Area" },
-   { CONFIG_VECTORS_BASE,  "Vectors" },
-   { CONFIG_VECTORS_BASE + PAGE_SIZE * 2, "Vectors End" },
+   { VECTORS_BASE, "Vectors" },
+   { VECTORS_BASE + PAGE_SIZE * 2, "Vectors End" },
{ -1,   NULL },
 };
 
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..823e119a5daa 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -521,8 +522,7 @@ void __init mem_init(void)
"  .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
"   .bss : 0x%p" " - 0x%p" "   (%4td kB)\n",
 
-   MLK(UL(CONFIG_VECTORS_BASE), UL(CONFIG_VECTORS_BASE) +
-   (PAGE_SIZE)),
+   MLK(VECTORS_BASE, VECTORS_BASE + PAGE_SIZE),
 #ifdef CONFIG_HAVE_TCM
MLK(DTCM_OFFSET, (unsigned long) dtcm_end),
MLK(ITCM_OFFSET, (unsigned long) itcm_end),
-- 
2.11.0

[PATCH v2 0/4] ARM: v7-A !MMU support, prepare CONFIG_VECTORS_BASE removal

2017-01-21 Thread afzal mohammed

Hi,

ARM core changes to support !MMU Kernel on v7-A MMU processors. This
series also does the preparation for CONFIG_VECTORS_BASE removal.

Based on the feedback from Russell, it was decided to handle vector
base dynamically in C for no-MMU & work towards the the goal of
removing VECTORS_BASE from Kconfig. MMU platform's always have
exception base address at 0x, hence a macro was defined and
it was decoupled from Kconfig. No-MMU CP15 scenario is handled
dynamically in C. Once vector region setup, used by Cortex-R, is
made devoid of VECTORS_BASE, it can be removed from Kconfig.

This series has been verified over current mainline plus [2] on
Vybrid Cosmic+, Cortex-M4 - !MMU Kernel and Cortex-A5 - MMU Kernel.

This series also has been verified over Vladimir's series plus [2] on
1. Vybrid Cosmic+
 a. Cortex-M4 !MMU Kernel
 b. Cortex-A5 MMU Kernel
 c. Cortex-A5 !MMU Kernel
2. AM437x IDK
 a. Cortex-A9 MMU Kernel
 b. Cortex-A9 !MMU Kernel

Regards
afzal


v2:
=> Fix bisectability issue on !MMU builds
=> UL suffix on VECTORS_BASE definition
=> Use existing helpers to detect security extensions
=> Rewrite a CPP step to C for readability

[1] "[RFC v2 PATCH 00/23] Allow NOMMU for MULTIPLATFORM",

http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470966.html
(git://linux-arm.org/linux-vm.git nommu-rfc-v2)

[2] "[PATCH 1/2] ARM: nommu: allow enabling REMAP_VECTORS_TO_RAM"

http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473593.html
(in -next)

afzal mohammed (4):
  ARM: mmu: decouple VECTORS_BASE from Kconfig
  ARM: nommu: dynamic exception base address setting
  ARM: nommu: display vectors base
  ARM: nommu: remove Hivecs configuration is asm

 arch/arm/include/asm/memory.h  |  2 ++
 arch/arm/kernel/head-nommu.S   |  5 
 arch/arm/mach-berlin/platsmp.c |  3 ++-
 arch/arm/mm/dump.c |  5 ++--
 arch/arm/mm/init.c |  9 ++--
 arch/arm/mm/mm.h   |  5 ++--
 arch/arm/mm/nommu.c| 52 --
 7 files changed, 67 insertions(+), 14 deletions(-)

-- 
2.11.0

[PATCH v2 0/4] ARM: v7-A !MMU support, prepare CONFIG_VECTORS_BASE removal

2017-01-21 Thread afzal mohammed

Hi,

ARM core changes to support !MMU Kernel on v7-A MMU processors. This
series also does the preparation for CONFIG_VECTORS_BASE removal.

Based on the feedback from Russell, it was decided to handle vector
base dynamically in C for no-MMU & work towards the the goal of
removing VECTORS_BASE from Kconfig. MMU platform's always have
exception base address at 0x, hence a macro was defined and
it was decoupled from Kconfig. No-MMU CP15 scenario is handled
dynamically in C. Once vector region setup, used by Cortex-R, is
made devoid of VECTORS_BASE, it can be removed from Kconfig.

This series has been verified over current mainline plus [2] on
Vybrid Cosmic+, Cortex-M4 - !MMU Kernel and Cortex-A5 - MMU Kernel.

This series also has been verified over Vladimir's series plus [2] on
1. Vybrid Cosmic+
 a. Cortex-M4 !MMU Kernel
 b. Cortex-A5 MMU Kernel
 c. Cortex-A5 !MMU Kernel
2. AM437x IDK
 a. Cortex-A9 MMU Kernel
 b. Cortex-A9 !MMU Kernel

Regards
afzal


v2:
=> Fix bisectability issue on !MMU builds
=> UL suffix on VECTORS_BASE definition
=> Use existing helpers to detect security extensions
=> Rewrite a CPP step to C for readability

[1] "[RFC v2 PATCH 00/23] Allow NOMMU for MULTIPLATFORM",

http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470966.html
(git://linux-arm.org/linux-vm.git nommu-rfc-v2)

[2] "[PATCH 1/2] ARM: nommu: allow enabling REMAP_VECTORS_TO_RAM"

http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473593.html
(in -next)

afzal mohammed (4):
  ARM: mmu: decouple VECTORS_BASE from Kconfig
  ARM: nommu: dynamic exception base address setting
  ARM: nommu: display vectors base
  ARM: nommu: remove Hivecs configuration is asm

 arch/arm/include/asm/memory.h  |  2 ++
 arch/arm/kernel/head-nommu.S   |  5 
 arch/arm/mach-berlin/platsmp.c |  3 ++-
 arch/arm/mm/dump.c |  5 ++--
 arch/arm/mm/init.c |  9 ++--
 arch/arm/mm/mm.h   |  5 ++--
 arch/arm/mm/nommu.c| 52 --
 7 files changed, 67 insertions(+), 14 deletions(-)

-- 
2.11.0

Re: [PATCH v2 26/26] drm/rockchip: dw-mipi-dsi: support read commands

2017-01-21 Thread Chris Zhong


Hi John

On 01/22/2017 12:31 AM, John Keeping wrote:

I haven't found any method for getting the length of a response, so this
just uses the requested rx_len

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 54 ++
  1 file changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f780401e8b5e..f0cb005c6d76 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -675,6 +675,54 @@ static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi 
*dsi,
return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
  }
  
+static int dw_mipi_dsi_dcs_read(struct dw_mipi_dsi *dsi,

+   const struct mipi_dsi_msg *msg)
+{
+   const u8 *tx_buf = msg->tx_buf;
+   u8 *rx_buf = msg->rx_buf;
+   size_t i;
+   int ret, val;
+
+   dsi_write(dsi, DSI_PCKHDL_CFG, EN_CRC_RX | EN_ECC_RX | EN_BTA);
+   dsi_write(dsi, DSI_GEN_HDR, GEN_HDATA(tx_buf[0]) | 
GEN_HTYPE(msg->type));


WARNING: line over 80 characters


+
+   ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
+val, !(val & GEN_RD_CMD_BUSY), 1000,
+CMD_PKT_STATUS_TIMEOUT_US);
+   if (ret < 0) {
+   dev_err(dsi->dev, "failed to read command response\n");
+   return ret;
+   }
+
+   for (i = 0; i < msg->rx_len;) {
+   u32 pld = dsi_read(dsi, DSI_GEN_PLD_DATA);
+   while (i < msg->rx_len) {
+   rx_buf[i] = pld & 0xff;
+   pld >>= 8;
+   i++;
+   }
+   }
+
+   return msg->rx_len;
+}
+
+static int dw_mipi_dsi_set_max_return_packet_size(struct dw_mipi_dsi *dsi,
+ size_t len)
+{
+   u8 val[] = { len & 0xff, (len >> 8) & 0xff };
+   struct mipi_dsi_msg msg = {
+   .channel = dsi->channel,
+   .type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE,
+   .tx_buf = val,
+   .tx_len = 2,
+   };
+
+   if (len > 0x)
+   return -EINVAL;
+
+   return dw_mipi_dsi_dcs_short_write(dsi, );
+}
+
  static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
 const struct mipi_dsi_msg *msg)
  {
@@ -692,6 +740,12 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
mipi_dsi_host *host,
case MIPI_DSI_DCS_LONG_WRITE:
ret = dw_mipi_dsi_dcs_long_write(dsi, msg);
break;
+   case MIPI_DSI_DCS_READ:
+   ret = dw_mipi_dsi_set_max_return_packet_size(dsi, msg->rx_len);
+   if (ret < 0)
+   return ret;
+   ret = dw_mipi_dsi_dcs_read(dsi, msg);
+   break;
default:
dev_err(dsi->dev, "unsupported message type 0x%02x\n",
msg->type);

Re: [PATCH v2 26/26] drm/rockchip: dw-mipi-dsi: support read commands

2017-01-21 Thread Chris Zhong


Hi John

On 01/22/2017 12:31 AM, John Keeping wrote:

I haven't found any method for getting the length of a response, so this
just uses the requested rx_len

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 54 ++
  1 file changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f780401e8b5e..f0cb005c6d76 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -675,6 +675,54 @@ static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi 
*dsi,
return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
  }
  
+static int dw_mipi_dsi_dcs_read(struct dw_mipi_dsi *dsi,

+   const struct mipi_dsi_msg *msg)
+{
+   const u8 *tx_buf = msg->tx_buf;
+   u8 *rx_buf = msg->rx_buf;
+   size_t i;
+   int ret, val;
+
+   dsi_write(dsi, DSI_PCKHDL_CFG, EN_CRC_RX | EN_ECC_RX | EN_BTA);
+   dsi_write(dsi, DSI_GEN_HDR, GEN_HDATA(tx_buf[0]) | 
GEN_HTYPE(msg->type));


WARNING: line over 80 characters


+
+   ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
+val, !(val & GEN_RD_CMD_BUSY), 1000,
+CMD_PKT_STATUS_TIMEOUT_US);
+   if (ret < 0) {
+   dev_err(dsi->dev, "failed to read command response\n");
+   return ret;
+   }
+
+   for (i = 0; i < msg->rx_len;) {
+   u32 pld = dsi_read(dsi, DSI_GEN_PLD_DATA);
+   while (i < msg->rx_len) {
+   rx_buf[i] = pld & 0xff;
+   pld >>= 8;
+   i++;
+   }
+   }
+
+   return msg->rx_len;
+}
+
+static int dw_mipi_dsi_set_max_return_packet_size(struct dw_mipi_dsi *dsi,
+ size_t len)
+{
+   u8 val[] = { len & 0xff, (len >> 8) & 0xff };
+   struct mipi_dsi_msg msg = {
+   .channel = dsi->channel,
+   .type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE,
+   .tx_buf = val,
+   .tx_len = 2,
+   };
+
+   if (len > 0x)
+   return -EINVAL;
+
+   return dw_mipi_dsi_dcs_short_write(dsi, );
+}
+
  static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
 const struct mipi_dsi_msg *msg)
  {
@@ -692,6 +740,12 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
mipi_dsi_host *host,
case MIPI_DSI_DCS_LONG_WRITE:
ret = dw_mipi_dsi_dcs_long_write(dsi, msg);
break;
+   case MIPI_DSI_DCS_READ:
+   ret = dw_mipi_dsi_set_max_return_packet_size(dsi, msg->rx_len);
+   if (ret < 0)
+   return ret;
+   ret = dw_mipi_dsi_dcs_read(dsi, msg);
+   break;
default:
dev_err(dsi->dev, "unsupported message type 0x%02x\n",
msg->type);

[PATCH] serial: hp300: mask the warning for people just doing build coverage

2017-01-21 Thread Paul Gortmaker

Currently this warning is triggered for allmodconfig on m68k.  It is
well intentioned, in that if you are building the driver but not
enabling one of the platforms where the hardware exists, you get a
warning.

The warning dates back to pre-git days, and now we have COMPILE_TEST
so we can use that to mask the warning for people who are obviously
just doing build coverage on tree wide changes.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Geert Uytterhoeven 
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-ser...@vger.kernel.org
Signed-off-by: Paul Gortmaker 
---
 drivers/tty/serial/8250/8250_hp300.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_hp300.c 
b/drivers/tty/serial/8250/8250_hp300.c
index 38166db2b824..115190b7962a 100644
--- a/drivers/tty/serial/8250/8250_hp300.c
+++ b/drivers/tty/serial/8250/8250_hp300.c
@@ -19,7 +19,7 @@
 
 #include "8250.h"
 
-#if !defined(CONFIG_HPDCA) && !defined(CONFIG_HPAPCI)
+#if !defined(CONFIG_HPDCA) && !defined(CONFIG_HPAPCI) && 
!defined(CONFIG_COMPILE_TEST)
 #warning CONFIG_SERIAL_8250 defined but neither CONFIG_HPDCA nor CONFIG_HPAPCI 
defined, are you sure?
 #endif
 
-- 
2.11.0

[PATCH] serial: hp300: mask the warning for people just doing build coverage

2017-01-21 Thread Paul Gortmaker

Currently this warning is triggered for allmodconfig on m68k.  It is
well intentioned, in that if you are building the driver but not
enabling one of the platforms where the hardware exists, you get a
warning.

The warning dates back to pre-git days, and now we have COMPILE_TEST
so we can use that to mask the warning for people who are obviously
just doing build coverage on tree wide changes.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Geert Uytterhoeven 
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-ser...@vger.kernel.org
Signed-off-by: Paul Gortmaker 
---
 drivers/tty/serial/8250/8250_hp300.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_hp300.c 
b/drivers/tty/serial/8250/8250_hp300.c
index 38166db2b824..115190b7962a 100644
--- a/drivers/tty/serial/8250/8250_hp300.c
+++ b/drivers/tty/serial/8250/8250_hp300.c
@@ -19,7 +19,7 @@
 
 #include "8250.h"
 
-#if !defined(CONFIG_HPDCA) && !defined(CONFIG_HPAPCI)
+#if !defined(CONFIG_HPDCA) && !defined(CONFIG_HPAPCI) && 
!defined(CONFIG_COMPILE_TEST)
 #warning CONFIG_SERIAL_8250 defined but neither CONFIG_HPDCA nor CONFIG_HPAPCI 
defined, are you sure?
 #endif
 
-- 
2.11.0

[GIT PULL] Thermal management updates for v4.10-rc5

2017-01-21 Thread Zhang Rui

Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc

to receive the latest Thermal Management updates for v4.10-rc5 with
top-most commit bad94f8068122b6342a73a218dad7d41e6ea907b:

  Merge branches 'thermal-core' and 'thermal-soc' into for-rc (2017-01-
20 16:24:54 +0800)

on top of commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:

  Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)

Specifics:

- Fix a regression that thermal zone dynamically allocated sysfs
attributes are freed before they're removed, which is introduced in
4.10-rc1. (Jacob von Chorus)

- Fix a boot warning because deprecated hwmon API is used. (Fabio
Estevam)

- A couple of fixes for rockchip thermal driver. (Brian Norris, Caesar
Wang)

thanks,
rui


Brian Norris (2):
  thermal: rockchip: improve conversion error messages
  thermal: rockchip: don't pass table structs by value

Caesar Wang (4):
  thermal: rockchip: fixes invalid temperature case
  thermal: rockchip: optimize the conversion table
  thermal: rockchip: handle set_trips without the trip points
  thermal: rockchip: fixes the conversion table

Fabio Estevam (1):
  thermal: thermal_hwmon: Convert to
hwmon_device_register_with_info()

Jacob von Chorus (1):
  thermal: core: move tz->device.groups cleanup to thermal_release

Zhang Rui (2):
  Merge branch 'fixes' of git://git.kernel.org/.../evalenti/linux-
soc-thermal into thermal-soc
  Merge branches 'thermal-core' and 'thermal-soc' into for-rc

 drivers/thermal/rockchip_thermal.c | 153 -

 drivers/thermal/thermal_core.c |  10 +--
 drivers/thermal/thermal_hwmon.c|  20 +
 3 files changed, 108 insertions(+), 75 deletions(-)

[GIT PULL] Thermal management updates for v4.10-rc5

2017-01-21 Thread Zhang Rui

Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc

to receive the latest Thermal Management updates for v4.10-rc5 with
top-most commit bad94f8068122b6342a73a218dad7d41e6ea907b:

  Merge branches 'thermal-core' and 'thermal-soc' into for-rc (2017-01-
20 16:24:54 +0800)

on top of commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:

  Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)

Specifics:

- Fix a regression that thermal zone dynamically allocated sysfs
attributes are freed before they're removed, which is introduced in
4.10-rc1. (Jacob von Chorus)

- Fix a boot warning because deprecated hwmon API is used. (Fabio
Estevam)

- A couple of fixes for rockchip thermal driver. (Brian Norris, Caesar
Wang)

thanks,
rui


Brian Norris (2):
  thermal: rockchip: improve conversion error messages
  thermal: rockchip: don't pass table structs by value

Caesar Wang (4):
  thermal: rockchip: fixes invalid temperature case
  thermal: rockchip: optimize the conversion table
  thermal: rockchip: handle set_trips without the trip points
  thermal: rockchip: fixes the conversion table

Fabio Estevam (1):
  thermal: thermal_hwmon: Convert to
hwmon_device_register_with_info()

Jacob von Chorus (1):
  thermal: core: move tz->device.groups cleanup to thermal_release

Zhang Rui (2):
  Merge branch 'fixes' of git://git.kernel.org/.../evalenti/linux-
soc-thermal into thermal-soc
  Merge branches 'thermal-core' and 'thermal-soc' into for-rc

 drivers/thermal/rockchip_thermal.c | 153 -

 drivers/thermal/thermal_core.c |  10 +--
 drivers/thermal/thermal_hwmon.c|  20 +
 3 files changed, 108 insertions(+), 75 deletions(-)

Re: [PATCH v2 18/26] drm/rockchip: dw-mipi-dsi: properly configure PHY timing

2017-01-21 Thread Chris Zhong




On 01/22/2017 12:31 AM, John Keeping wrote:

These values are specified as constant time periods but the PHY
configuration is in terms of the current lane byte clock so using
constant values guarantees that the timings will be outside the
specification with some display configurations.

Derive the necessary configuration from the byte clock in order to
ensure that the PHY configuration is correct.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 36 ++
  1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index cfe7e4ba305c..12432e41971b 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -383,6 +383,26 @@ static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi *dsi, 
u8 test_code,
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLK | PHY_UNTESTCLR);
  }
  
+/**

+ * ns2bc - Nanoseconds to byte clock cycles
+ */
+static inline unsigned int ns2bc(struct dw_mipi_dsi *dsi, int ns)
+{
+   unsigned long byte_clk_khz = dsi->lane_mbps * MSEC_PER_SEC / 8;
+
+   return (ns * (byte_clk_khz / 1000) + 999) / 1000;
+}
+
+/**
+ * ns2ui - Nanoseconds to UI time periods
+ */
+static inline unsigned int ns2ui(struct dw_mipi_dsi *dsi, int ns)
+{
+   unsigned long byte_clk_khz = dsi->lane_mbps * MSEC_PER_SEC;
+
+   return (ns * (byte_clk_khz / 1000) + 999) / 1000;
+}
+
  static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
  {
int ret, testdin, vco, val;
@@ -434,10 +454,18 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
 SETRD_MAX | POWER_MANAGE |
 TER_RESISTORS_ON);
  
-

-   dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | 0xf);
-   dw_mipi_dsi_phy_write(dsi, 0x71, THS_PRE_PROGRAM_EN | 0x55);
-   dw_mipi_dsi_phy_write(dsi, 0x72, THS_ZERO_PROGRAM_EN | 0xa);
+   dw_mipi_dsi_phy_write(dsi, 0x60, TLP_PROGRAM_EN | ns2bc(dsi, 500));
+   dw_mipi_dsi_phy_write(dsi, 0x61, THS_PRE_PROGRAM_EN | ns2ui(dsi, 40));
+   dw_mipi_dsi_phy_write(dsi, 0x62, THS_ZERO_PROGRAM_EN | ns2bc(dsi, 300));
+   dw_mipi_dsi_phy_write(dsi, 0x63, THS_PRE_PROGRAM_EN | ns2ui(dsi, 100));
+   dw_mipi_dsi_phy_write(dsi, 0x64, BIT(5) | ns2bc(dsi, 100));
+   dw_mipi_dsi_phy_write(dsi, 0x65, BIT(5) | (ns2bc(dsi, 60) + 7));
+
+   dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | ns2bc(dsi, 500));
+   dw_mipi_dsi_phy_write(dsi, 0x71, THS_PRE_PROGRAM_EN | (ns2ui(dsi, 50) + 
5));

WARNING: line over 80 characters

+   dw_mipi_dsi_phy_write(dsi, 0x72, THS_ZERO_PROGRAM_EN | (ns2bc(dsi, 140) 
+ 2));

WARNING: line over 80 characters

+   dw_mipi_dsi_phy_write(dsi, 0x73, THS_PRE_PROGRAM_EN | (ns2ui(dsi, 60) + 
8));

WARNING: line over 80 characters

+   dw_mipi_dsi_phy_write(dsi, 0x74, BIT(5) | ns2bc(dsi, 100));
  
  	dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |

 PHY_UNRSTZ | PHY_UNSHUTDOWNZ);

Re: [PATCH v2 18/26] drm/rockchip: dw-mipi-dsi: properly configure PHY timing

2017-01-21 Thread Chris Zhong




On 01/22/2017 12:31 AM, John Keeping wrote:

These values are specified as constant time periods but the PHY
configuration is in terms of the current lane byte clock so using
constant values guarantees that the timings will be outside the
specification with some display configurations.

Derive the necessary configuration from the byte clock in order to
ensure that the PHY configuration is correct.

Signed-off-by: John Keeping 
---
Unchanged in v2
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 36 ++
  1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index cfe7e4ba305c..12432e41971b 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -383,6 +383,26 @@ static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi *dsi, 
u8 test_code,
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLK | PHY_UNTESTCLR);
  }
  
+/**

+ * ns2bc - Nanoseconds to byte clock cycles
+ */
+static inline unsigned int ns2bc(struct dw_mipi_dsi *dsi, int ns)
+{
+   unsigned long byte_clk_khz = dsi->lane_mbps * MSEC_PER_SEC / 8;
+
+   return (ns * (byte_clk_khz / 1000) + 999) / 1000;
+}
+
+/**
+ * ns2ui - Nanoseconds to UI time periods
+ */
+static inline unsigned int ns2ui(struct dw_mipi_dsi *dsi, int ns)
+{
+   unsigned long byte_clk_khz = dsi->lane_mbps * MSEC_PER_SEC;
+
+   return (ns * (byte_clk_khz / 1000) + 999) / 1000;
+}
+
  static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
  {
int ret, testdin, vco, val;
@@ -434,10 +454,18 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
 SETRD_MAX | POWER_MANAGE |
 TER_RESISTORS_ON);
  
-

-   dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | 0xf);
-   dw_mipi_dsi_phy_write(dsi, 0x71, THS_PRE_PROGRAM_EN | 0x55);
-   dw_mipi_dsi_phy_write(dsi, 0x72, THS_ZERO_PROGRAM_EN | 0xa);
+   dw_mipi_dsi_phy_write(dsi, 0x60, TLP_PROGRAM_EN | ns2bc(dsi, 500));
+   dw_mipi_dsi_phy_write(dsi, 0x61, THS_PRE_PROGRAM_EN | ns2ui(dsi, 40));
+   dw_mipi_dsi_phy_write(dsi, 0x62, THS_ZERO_PROGRAM_EN | ns2bc(dsi, 300));
+   dw_mipi_dsi_phy_write(dsi, 0x63, THS_PRE_PROGRAM_EN | ns2ui(dsi, 100));
+   dw_mipi_dsi_phy_write(dsi, 0x64, BIT(5) | ns2bc(dsi, 100));
+   dw_mipi_dsi_phy_write(dsi, 0x65, BIT(5) | (ns2bc(dsi, 60) + 7));
+
+   dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | ns2bc(dsi, 500));
+   dw_mipi_dsi_phy_write(dsi, 0x71, THS_PRE_PROGRAM_EN | (ns2ui(dsi, 50) + 
5));

WARNING: line over 80 characters

+   dw_mipi_dsi_phy_write(dsi, 0x72, THS_ZERO_PROGRAM_EN | (ns2bc(dsi, 140) 
+ 2));

WARNING: line over 80 characters

+   dw_mipi_dsi_phy_write(dsi, 0x73, THS_PRE_PROGRAM_EN | (ns2ui(dsi, 60) + 
8));

WARNING: line over 80 characters

+   dw_mipi_dsi_phy_write(dsi, 0x74, BIT(5) | ns2bc(dsi, 100));
  
  	dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |

 PHY_UNRSTZ | PHY_UNSHUTDOWNZ);

Re: [PATCH] mm: extend zero pages to same element pages for zram

2017-01-21 Thread zhouxianrong


1. memset is just set a int value but i want to set a long value.
2. using clear_page rather than memset MAYBE due to in arm64 arch
   it is a 64-bytes operations.

6.6.4. Data Cache Zero

The ARMv8-A architecture introduces a Data Cache Zero by Virtual Address (DC 
ZVA) instruction. This enables a block of 64
bytes in memory, aligned to 64 bytes in size, to be set to zero. If the DC ZVA 
instruction misses in the cache, it clears main
memory, without causing an L1 or L2 cache allocation.

but i only consider the arm64 arch, other archs need to be reviewed.

On 2017/1/21 16:43, Sergey Senozhatsky wrote:

Hello,

On (01/13/17 16:29), zhouxianr...@huawei.com wrote:
[..]

--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -86,21 +86,21 @@ Description:
ones are sent by filesystem mounted with discard option,
whenever some data blocks are getting discarded.

-What:  /sys/block/zram/zero_pages
+What:  /sys/block/zram/same_pages

[..]

-zero_pagesROthe number of zero filled pages written to this disk
+same_pagesROthe number of same element filled pages written to 
this disk

[..]

-   zero_pages
+   same_pages
num_migrated
+}


we removed deprecated sysfs attrs. zero_pages does not exist anymore.


 static size_t zram_get_obj_size(struct zram_meta *meta, u32 index)
 {
return meta->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
@@ -158,31 +169,76 @@ static inline void update_used_max(struct zram *zram,
} while (old_max != cur_max);
 }

-static bool page_zero_filled(void *ptr)
+static inline void zram_fill_page(char *ptr, unsigned long value)
+{
+   int i;
+   unsigned long *page = (unsigned long *)ptr;
+
+   if (likely(value == 0)) {
+   clear_page(ptr);
+   } else {
+   for (i = PAGE_SIZE / sizeof(unsigned long) - 1; i >= 0; i--)
+   page[i] = value;
+   }


any particular reason not to use memset() here?
memset() can be faster that that, right?


[..]

 /* Flags for zram pages (table[page_no].value) */
 enum zram_pageflags {
-   /* Page consists entirely of zeros */
-   ZRAM_ZERO = ZRAM_FLAG_SHIFT,
+   /* Page consists entirely of same elements */
+   ZRAM_SAME = ZRAM_FLAG_SHIFT,
ZRAM_ACCESS,/* page is now accessed */

[..]

@@ -83,7 +86,7 @@ struct zram_stats {
atomic64_t failed_writes;   /* can happen when memory is too low */
atomic64_t invalid_io;  /* non-page-aligned I/O requests */
atomic64_t notify_free; /* no. of swap slot free notifications */
-   atomic64_t zero_pages;  /* no. of zero filled pages */
+   atomic64_t same_pages;  /* no. of same element filled pages */


not like this rename is particularity important, but ok. works for me.

-ss

.

Re: [PATCH] mm: extend zero pages to same element pages for zram

2017-01-21 Thread zhouxianrong


1. memset is just set a int value but i want to set a long value.
2. using clear_page rather than memset MAYBE due to in arm64 arch
   it is a 64-bytes operations.

6.6.4. Data Cache Zero

The ARMv8-A architecture introduces a Data Cache Zero by Virtual Address (DC 
ZVA) instruction. This enables a block of 64
bytes in memory, aligned to 64 bytes in size, to be set to zero. If the DC ZVA 
instruction misses in the cache, it clears main
memory, without causing an L1 or L2 cache allocation.

but i only consider the arm64 arch, other archs need to be reviewed.

On 2017/1/21 16:43, Sergey Senozhatsky wrote:

Hello,

On (01/13/17 16:29), zhouxianr...@huawei.com wrote:
[..]

--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -86,21 +86,21 @@ Description:
ones are sent by filesystem mounted with discard option,
whenever some data blocks are getting discarded.

-What:  /sys/block/zram/zero_pages
+What:  /sys/block/zram/same_pages

[..]

-zero_pagesROthe number of zero filled pages written to this disk
+same_pagesROthe number of same element filled pages written to 
this disk

[..]

-   zero_pages
+   same_pages
num_migrated
+}


we removed deprecated sysfs attrs. zero_pages does not exist anymore.


 static size_t zram_get_obj_size(struct zram_meta *meta, u32 index)
 {
return meta->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
@@ -158,31 +169,76 @@ static inline void update_used_max(struct zram *zram,
} while (old_max != cur_max);
 }

-static bool page_zero_filled(void *ptr)
+static inline void zram_fill_page(char *ptr, unsigned long value)
+{
+   int i;
+   unsigned long *page = (unsigned long *)ptr;
+
+   if (likely(value == 0)) {
+   clear_page(ptr);
+   } else {
+   for (i = PAGE_SIZE / sizeof(unsigned long) - 1; i >= 0; i--)
+   page[i] = value;
+   }


any particular reason not to use memset() here?
memset() can be faster that that, right?


[..]

 /* Flags for zram pages (table[page_no].value) */
 enum zram_pageflags {
-   /* Page consists entirely of zeros */
-   ZRAM_ZERO = ZRAM_FLAG_SHIFT,
+   /* Page consists entirely of same elements */
+   ZRAM_SAME = ZRAM_FLAG_SHIFT,
ZRAM_ACCESS,/* page is now accessed */

[..]

@@ -83,7 +86,7 @@ struct zram_stats {
atomic64_t failed_writes;   /* can happen when memory is too low */
atomic64_t invalid_io;  /* non-page-aligned I/O requests */
atomic64_t notify_free; /* no. of swap slot free notifications */
-   atomic64_t zero_pages;  /* no. of zero filled pages */
+   atomic64_t same_pages;  /* no. of same element filled pages */


not like this rename is particularity important, but ok. works for me.

-ss

.

Re: [RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform

2017-01-21 Thread Chunfeng Yun

On Sat, 2017-01-21 at 14:08 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 02:00:14PM +0800, Chunfeng Yun wrote:
> > add a new compatible string for "mt2712", and a new reference clock
> > for SuperSpeed analog phy;
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/phy/phy-mt65xx-usb.txt |   81 
> > +---
> >  1 file changed, 70 insertions(+), 11 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
> > b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > index 33a2b1e..8f91136 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > @@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms 
> > of Medaitek SoC.
> >  Required properties (controller (parent) node):
> >   - compatible  : should be one of
> >   "mediatek,mt2701-u3phy"
> > + "mediatek,mt2712-u3phy"
> >   "mediatek,mt8173-u3phy"
> > - - reg : offset and length of register for phy, exclude port's
> > - register.
> >   - clocks  : a list of phandle + clock-specifier pairs, one for each
> >   entry in clock-names
> >   - clock-names : must contain
> > - "u3phya_ref": for reference clock of usb3.0 analog phy.
> > + "u2ref_clk": 48M reference clock of HighSpeed analog phy.
> > + "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
> > +   sometimes is 24M, 25M or 27M, depended on platform.
> 
> _clk is redundant.
remove it
> 
> >  
> >  Required nodes : a sub-node is required for each port the controller
> >   provides. Address range information including the usual
> >   'reg' property is used inside these nodes to describe
> >   the controller's topology.
> >  
> > +Optional properties (controller (parent) node):
> > + - reg : offset and length of register shared by multiple 
> > ports,
> > + exclude port's private register. It is needed on mt2701
> > + and mt8173, but not on mt2712.
> > +
> >  Required properties (port (child) node):
> >  - reg  : address and length of the register set for the port.
> >  - #phy-cells   : should be 1 (See second example)
> > @@ -31,21 +37,27 @@ Example:
> >  u3phy: usb-phy@1129 {
> > compatible = "mediatek,mt8173-u3phy";
> > reg = <0 0x1129 0 0x800>;
> > -   clocks = < CLK_APMIXED_REF2USB_TX>;
> > -   clock-names = "u3phya_ref";
> > +   clocks = < CLK_APMIXED_REF2USB_TX>, <>;
> > +   clock-names = "u2ref_clk", "u3ref_clk";
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > status = "okay";
> >  
> > -   phy_port0: port@11290800 {
> > -   reg = <0 0x11290800 0 0x800>;
> > +   u2port0: port@11290800 {
> 
> port is for OF graph. This should be usb-phy@... instead.
Is there any problems if u2port0's name@addr is the same as its parent's
(u3phy)?  as following:
u3phy: usb-phy@1129 {
compatible = ...;
// no reg property
clocks = ...;
u2port0: usb-phy@1129 {
reg = ...;
}

> 
> > +   reg = <0 0x11290800 0 0x100>;
> > +   #phy-cells = <1>;
> > +   status = "okay";
> > +   };
> > +
> > +   u3port0: port@11290900 {
> > +   reg = <0 0x11290800 0 0x700>;
> > #phy-cells = <1>;
> > status = "okay";
> > };
> >  

> > +...

Thank you!

Re: [RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform

2017-01-21 Thread Chunfeng Yun

On Sat, 2017-01-21 at 14:08 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 02:00:14PM +0800, Chunfeng Yun wrote:
> > add a new compatible string for "mt2712", and a new reference clock
> > for SuperSpeed analog phy;
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/phy/phy-mt65xx-usb.txt |   81 
> > +---
> >  1 file changed, 70 insertions(+), 11 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
> > b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > index 33a2b1e..8f91136 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > @@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms 
> > of Medaitek SoC.
> >  Required properties (controller (parent) node):
> >   - compatible  : should be one of
> >   "mediatek,mt2701-u3phy"
> > + "mediatek,mt2712-u3phy"
> >   "mediatek,mt8173-u3phy"
> > - - reg : offset and length of register for phy, exclude port's
> > - register.
> >   - clocks  : a list of phandle + clock-specifier pairs, one for each
> >   entry in clock-names
> >   - clock-names : must contain
> > - "u3phya_ref": for reference clock of usb3.0 analog phy.
> > + "u2ref_clk": 48M reference clock of HighSpeed analog phy.
> > + "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
> > +   sometimes is 24M, 25M or 27M, depended on platform.
> 
> _clk is redundant.
remove it
> 
> >  
> >  Required nodes : a sub-node is required for each port the controller
> >   provides. Address range information including the usual
> >   'reg' property is used inside these nodes to describe
> >   the controller's topology.
> >  
> > +Optional properties (controller (parent) node):
> > + - reg : offset and length of register shared by multiple 
> > ports,
> > + exclude port's private register. It is needed on mt2701
> > + and mt8173, but not on mt2712.
> > +
> >  Required properties (port (child) node):
> >  - reg  : address and length of the register set for the port.
> >  - #phy-cells   : should be 1 (See second example)
> > @@ -31,21 +37,27 @@ Example:
> >  u3phy: usb-phy@1129 {
> > compatible = "mediatek,mt8173-u3phy";
> > reg = <0 0x1129 0 0x800>;
> > -   clocks = < CLK_APMIXED_REF2USB_TX>;
> > -   clock-names = "u3phya_ref";
> > +   clocks = < CLK_APMIXED_REF2USB_TX>, <>;
> > +   clock-names = "u2ref_clk", "u3ref_clk";
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > status = "okay";
> >  
> > -   phy_port0: port@11290800 {
> > -   reg = <0 0x11290800 0 0x800>;
> > +   u2port0: port@11290800 {
> 
> port is for OF graph. This should be usb-phy@... instead.
Is there any problems if u2port0's name@addr is the same as its parent's
(u3phy)?  as following:
u3phy: usb-phy@1129 {
compatible = ...;
// no reg property
clocks = ...;
u2port0: usb-phy@1129 {
reg = ...;
}

> 
> > +   reg = <0 0x11290800 0 0x100>;
> > +   #phy-cells = <1>;
> > +   status = "okay";
> > +   };
> > +
> > +   u3port0: port@11290900 {
> > +   reg = <0 0x11290800 0 0x700>;
> > #phy-cells = <1>;
> > status = "okay";
> > };
> >  

> > +...

Thank you!

Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

2017-01-21 Thread Jason Wang




On 2017年01月21日 00:45, Michael S. Tsirkin wrote:

On Fri, Jan 20, 2017 at 02:32:42PM +0800, Jason Wang wrote:

Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
fixing this by adding a hint (has_data_valid) and set it only on the
receiving path.

Cc: Rolf Neugebauer
Signed-off-by: Jason Wang
---
  drivers/net/macvtap.c  | 2 +-
  drivers/net/tun.c  | 2 +-
  drivers/net/virtio_net.c   | 2 +-
  include/linux/virtio_net.h | 6 +-
  net/packet/af_packet.c | 4 ++--
  5 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 5c26653..4026185 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -825,7 +825,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
return -EINVAL;
  
  		if (virtio_net_hdr_from_skb(skb, _hdr,

-   macvtap_is_little_endian(q)))
+   macvtap_is_little_endian(q), true))
BUG();
  
  		if (copy_to_iter(_hdr, sizeof(vnet_hdr), iter) !=

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index cd8e02c..2cd10b2 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1360,7 +1360,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
return -EINVAL;
  
  		if (virtio_net_hdr_from_skb(skb, ,

-   tun_is_little_endian(tun))) {
+   tun_is_little_endian(tun), true)) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
pr_err("unexpected GSO type: "
   "0x%x, gso_size %d, hdr_len %d\n",
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4a10500..3474243 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1104,7 +1104,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff 
*skb)
hdr = skb_vnet_hdr(skb);
  
  	if (virtio_net_hdr_from_skb(skb, >hdr,

-   virtio_is_little_endian(vi->vdev)))
+   virtio_is_little_endian(vi->vdev), false))
BUG();
  
  	if (vi->mergeable_rx_bufs)

diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 5643647..5209b5e 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -56,7 +56,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
  
  static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,

  struct virtio_net_hdr *hdr,
- bool little_endian)
+ bool little_endian,
+ bool has_data_valid)
  {
memset(hdr, 0, sizeof(*hdr));   /* no info leak */
  

I would prefer naming it is_rx. Callers should not know about
internal details like data valid, the issue we are trying to fix
here is that tx and tx headers are slightly different.



Actually, I've considered something like this, but the problem is:

- tun use this on xmit, so is_rx = true may cause some confusion here
- I believe we may want to support DATA_VALID (like xen-netback) on tx 
(probably with a feature) in the future.


Thanks

Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

2017-01-21 Thread Jason Wang




On 2017年01月21日 00:45, Michael S. Tsirkin wrote:

On Fri, Jan 20, 2017 at 02:32:42PM +0800, Jason Wang wrote:

Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
fixing this by adding a hint (has_data_valid) and set it only on the
receiving path.

Cc: Rolf Neugebauer
Signed-off-by: Jason Wang
---
  drivers/net/macvtap.c  | 2 +-
  drivers/net/tun.c  | 2 +-
  drivers/net/virtio_net.c   | 2 +-
  include/linux/virtio_net.h | 6 +-
  net/packet/af_packet.c | 4 ++--
  5 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 5c26653..4026185 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -825,7 +825,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
return -EINVAL;
  
  		if (virtio_net_hdr_from_skb(skb, _hdr,

-   macvtap_is_little_endian(q)))
+   macvtap_is_little_endian(q), true))
BUG();
  
  		if (copy_to_iter(_hdr, sizeof(vnet_hdr), iter) !=

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index cd8e02c..2cd10b2 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1360,7 +1360,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
return -EINVAL;
  
  		if (virtio_net_hdr_from_skb(skb, ,

-   tun_is_little_endian(tun))) {
+   tun_is_little_endian(tun), true)) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
pr_err("unexpected GSO type: "
   "0x%x, gso_size %d, hdr_len %d\n",
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4a10500..3474243 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1104,7 +1104,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff 
*skb)
hdr = skb_vnet_hdr(skb);
  
  	if (virtio_net_hdr_from_skb(skb, >hdr,

-   virtio_is_little_endian(vi->vdev)))
+   virtio_is_little_endian(vi->vdev), false))
BUG();
  
  	if (vi->mergeable_rx_bufs)

diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 5643647..5209b5e 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -56,7 +56,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
  
  static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,

  struct virtio_net_hdr *hdr,
- bool little_endian)
+ bool little_endian,
+ bool has_data_valid)
  {
memset(hdr, 0, sizeof(*hdr));   /* no info leak */
  

I would prefer naming it is_rx. Callers should not know about
internal details like data valid, the issue we are trying to fix
here is that tx and tx headers are slightly different.



Actually, I've considered something like this, but the problem is:

- tun use this on xmit, so is_rx = true may cause some confusion here
- I believe we may want to support DATA_VALID (like xen-netback) on tx 
(probably with a feature) in the future.


Thanks

Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node

2017-01-21 Thread Guochun Mao

Hi,
On Thu, 2017-01-19 at 08:18 -0600, Rob Herring wrote:
> On Thu, Jan 19, 2017 at 2:14 AM, Boris Brezillon
> > One last question and I'm done: is something like that acceptable?
> >
> > compatible = ",",",";
> >
> > This can happen when someone adds support for an unsupported feature
> > on a brand new SoC, and then someone else use the same driver for an
> > older SoC embedding the same IP but still wants to add a new compatible
> > just in case these 2 IPs appear to be slightly different.
> 
> Yes, it's old and new compatible strings in this case and it's newest
> compatible string first.
> 
> > Here the order of compat strings is no longer following a clear rule
> > like 'most-specific compatible first' or 'newest IP/SoC version first',
> > it's completely dependent on the order these IPs were supported in the
> > OS (Linux). I'm perfectly fine with that BTW, just want to make sure
> > this is authorized.
> 
> I guess we should say "newest compatible for IP first" instead. There
> are some exceptions where we add fallbacks later on, but that falls
> under the most-specific part.
> 
> It's order that the bindings are defined, not Linux support really,
> but in practice those are the same.
> 
> Rob

Thanks for all your effort for code reviewing.
Our mt2701-nor's hardware is designed base on mt8713-nor,
even so, there would be some slight difference.
If I don't misunderstand your viewpoint in this discussion,
there's no need to drop mt2701-nor compatible.
And if not, is there any other suggestion?

Thanks.

Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node

2017-01-21 Thread Guochun Mao

Hi,
On Thu, 2017-01-19 at 08:18 -0600, Rob Herring wrote:
> On Thu, Jan 19, 2017 at 2:14 AM, Boris Brezillon
> > One last question and I'm done: is something like that acceptable?
> >
> > compatible = ",",",";
> >
> > This can happen when someone adds support for an unsupported feature
> > on a brand new SoC, and then someone else use the same driver for an
> > older SoC embedding the same IP but still wants to add a new compatible
> > just in case these 2 IPs appear to be slightly different.
> 
> Yes, it's old and new compatible strings in this case and it's newest
> compatible string first.
> 
> > Here the order of compat strings is no longer following a clear rule
> > like 'most-specific compatible first' or 'newest IP/SoC version first',
> > it's completely dependent on the order these IPs were supported in the
> > OS (Linux). I'm perfectly fine with that BTW, just want to make sure
> > this is authorized.
> 
> I guess we should say "newest compatible for IP first" instead. There
> are some exceptions where we add fallbacks later on, but that falls
> under the most-specific part.
> 
> It's order that the bindings are defined, not Linux support really,
> but in practice those are the same.
> 
> Rob

Thanks for all your effort for code reviewing.
Our mt2701-nor's hardware is designed base on mt8713-nor,
even so, there would be some slight difference.
If I don't misunderstand your viewpoint in this discussion,
there's no need to drop mt2701-nor compatible.
And if not, is there any other suggestion?

Thanks.

[PATCH] locking/rwsem: Reinit wake_q after use

2017-01-21 Thread Waiman Long

In __rwsem_down_write_failed_common(), the same wake_q variable name
is defined twice, with the inner wake_q hiding the one in outer scope.
We can either use different names for the two wake_q's. Even better,
we can use the same wake_q twice, if necessary. To enable the latter
change, we need to define a new helper function wake_q_init() to
enable reinitalization of wake_q after use.

Signed-off-by: Waiman Long 
---
 include/linux/sched.h   | 6 ++
 kernel/locking/rwsem-xadd.c | 7 +--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8a9bbb6..3640bde 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1019,6 +1019,12 @@ struct wake_q_head {
 #define DEFINE_WAKE_Q(name)\
struct wake_q_head name = { WAKE_Q_TAIL,  }
 
+static inline void wake_q_init(struct wake_q_head *head)
+{
+   head->first = WAKE_Q_TAIL;
+   head->lastp = >first;
+}
+
 extern void wake_q_add(struct wake_q_head *head,
   struct task_struct *task);
 extern void wake_up_q(struct wake_q_head *head);
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index a3a381a..2ad8d8d 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -502,8 +502,6 @@ static inline bool rwsem_has_spinner(struct rw_semaphore 
*sem)
 * wake any read locks that were queued ahead of us.
 */
if (count > RWSEM_WAITING_BIAS) {
-   DEFINE_WAKE_Q(wake_q);
-
__rwsem_mark_wake(sem, RWSEM_WAKE_READERS, _q);
/*
 * The wakeup is normally called _after_ the wait_lock
@@ -513,6 +511,11 @@ static inline bool rwsem_has_spinner(struct rw_semaphore 
*sem)
 * for attempting rwsem_try_write_lock().
 */
wake_up_q(_q);
+
+   /*
+* Reinitialize wake_q after use.
+*/
+   wake_q_init(_q);
}
 
} else
-- 
1.8.3.1

[PATCH] locking/rwsem: Reinit wake_q after use

2017-01-21 Thread Waiman Long

In __rwsem_down_write_failed_common(), the same wake_q variable name
is defined twice, with the inner wake_q hiding the one in outer scope.
We can either use different names for the two wake_q's. Even better,
we can use the same wake_q twice, if necessary. To enable the latter
change, we need to define a new helper function wake_q_init() to
enable reinitalization of wake_q after use.

Signed-off-by: Waiman Long 
---
 include/linux/sched.h   | 6 ++
 kernel/locking/rwsem-xadd.c | 7 +--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8a9bbb6..3640bde 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1019,6 +1019,12 @@ struct wake_q_head {
 #define DEFINE_WAKE_Q(name)\
struct wake_q_head name = { WAKE_Q_TAIL,  }
 
+static inline void wake_q_init(struct wake_q_head *head)
+{
+   head->first = WAKE_Q_TAIL;
+   head->lastp = >first;
+}
+
 extern void wake_q_add(struct wake_q_head *head,
   struct task_struct *task);
 extern void wake_up_q(struct wake_q_head *head);
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index a3a381a..2ad8d8d 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -502,8 +502,6 @@ static inline bool rwsem_has_spinner(struct rw_semaphore 
*sem)
 * wake any read locks that were queued ahead of us.
 */
if (count > RWSEM_WAITING_BIAS) {
-   DEFINE_WAKE_Q(wake_q);
-
__rwsem_mark_wake(sem, RWSEM_WAKE_READERS, _q);
/*
 * The wakeup is normally called _after_ the wait_lock
@@ -513,6 +511,11 @@ static inline bool rwsem_has_spinner(struct rw_semaphore 
*sem)
 * for attempting rwsem_try_write_lock().
 */
wake_up_q(_q);
+
+   /*
+* Reinitialize wake_q after use.
+*/
+   wake_q_init(_q);
}
 
} else
-- 
1.8.3.1

Re:Re: [PATCH] setlocalversion: fix error detectition of kernel git repository

2017-01-21 Thread xufeng


I'm sorry. My patch is error.
But I just want to get the git version  when we use git as SCM. No matter what 
.git directory where.
Thanks.


At 2017-01-22 04:54:54, "Nico Schottelius" 
 wrote:
>
>Hello Xufeng,
>
>why do you think redirecting *all* output to /dev/null is the right
>thing todo?
>
>And which problem does it exactly fix?
>
>Do you see that there is a difference between a "return value"
>(i.e. exit code) and the output (in this case stdout) of a program?
>
>Best,
>
>Nico
>
>xufeng  writes:
>
>> This patch fixed the error using 'git rev-parse --show-cdup' to check
>> that git is used as SCM to track the current directory. The return
>> value of this command is not null string when the .git directory is
>> not in kernel topdir.
>>
>> Signed-off-by: Xufeng Wang 
>> ---
>> scripts/setlocalversion | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
>> index 966dd39..7966e39 100755
>> --- a/scripts/setlocalversion
>> +++ b/scripts/setlocalversion
>> @@ -43,7 +43,7 @@ scm_version()
>> fi
>>
>> # Check for git and a git repo.
>> -if test -z "$(git rev-parse --show-cdup 2>/dev/null)" &&
>> +if test -z "$(git rev-parse --show-cdup &>/dev/null)" &&
>> head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
>>
>> # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
>
>
>--
>Werde Teil des modernen Arbeitens im Glarnerland auf www.digitalglarus.ch!
>Lese Neuigkeiten auf Twitter: www.twitter.com/DigitalGlarus
>Diskutiere mit auf Facebook:  www.facebook.com/digitalglarus

Re:Re: [PATCH] setlocalversion: fix error detectition of kernel git repository

2017-01-21 Thread xufeng


I'm sorry. My patch is error.
But I just want to get the git version  when we use git as SCM. No matter what 
.git directory where.
Thanks.


At 2017-01-22 04:54:54, "Nico Schottelius" 
 wrote:
>
>Hello Xufeng,
>
>why do you think redirecting *all* output to /dev/null is the right
>thing todo?
>
>And which problem does it exactly fix?
>
>Do you see that there is a difference between a "return value"
>(i.e. exit code) and the output (in this case stdout) of a program?
>
>Best,
>
>Nico
>
>xufeng  writes:
>
>> This patch fixed the error using 'git rev-parse --show-cdup' to check
>> that git is used as SCM to track the current directory. The return
>> value of this command is not null string when the .git directory is
>> not in kernel topdir.
>>
>> Signed-off-by: Xufeng Wang 
>> ---
>> scripts/setlocalversion | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
>> index 966dd39..7966e39 100755
>> --- a/scripts/setlocalversion
>> +++ b/scripts/setlocalversion
>> @@ -43,7 +43,7 @@ scm_version()
>> fi
>>
>> # Check for git and a git repo.
>> -if test -z "$(git rev-parse --show-cdup 2>/dev/null)" &&
>> +if test -z "$(git rev-parse --show-cdup &>/dev/null)" &&
>> head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
>>
>> # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
>
>
>--
>Werde Teil des modernen Arbeitens im Glarnerland auf www.digitalglarus.ch!
>Lese Neuigkeiten auf Twitter: www.twitter.com/DigitalGlarus
>Diskutiere mit auf Facebook:  www.facebook.com/digitalglarus

Re: [PATCH v11 2/8] power: add power sequence library

2017-01-21 Thread Peter Chen

On Fri, Jan 20, 2017 at 11:21:27AM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 20, 2017 at 8:52 AM, Peter Chen  wrote:
> > On Tue, Jan 10, 2017 at 03:02:41PM +0800, Peter Chen wrote:
> >> On Sat, Jan 07, 2017 at 10:54:56AM +0200, Krzysztof Kozlowski wrote:
> >> > On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote:
> >> > > We have an well-known problem that the device needs to do some power
> >> > > sequence before it can be recognized by related host, the typical
> >> > > example like hard-wired mmc devices and usb devices.
> >> > >
> >> > > This power sequence is hard to be described at device tree and handled 
> >> > > by
> >> > > related host driver, so we have created a common power sequence
> >> > > library to cover this requirement. The core code has supplied
> >> > > some common helpers for host driver, and individual power sequence
> >> > > libraries handle kinds of power sequence for devices. The pwrseq
> >> > > librares always need to allocate extra instance for compatible
> >> > > string match.
> >> > >
> >> > > pwrseq_generic is intended for general purpose of power sequence, which
> >> > > handles gpios and clocks currently, and can cover other controls in
> >> > > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> >> > > if only one power sequence is needed, else call of_pwrseq_on_list
> >> > > /of_pwrseq_off_list instead (eg, USB hub driver).
> >> > >
> >> > > For new power sequence library, it can add its compatible string
> >> > > to pwrseq_of_match_table, then the pwrseq core will match it with
> >> > > DT's, and choose this library at runtime.
> >> > >
> >> > > Signed-off-by: Peter Chen 
> >> > > Tested-by: Maciej S. Szmigiero 
> >> > > Tested-by Joshua Clayton 
> >> > > Reviewed-by: Matthias Kaehlcke 
> >> > > Tested-by: Matthias Kaehlcke 
> >> >
> >> > Acked-by: Krzysztof Kozlowski 
> >> > Tested on Odroid U3 (reset sequence for LAN9730):
> >> > Tested-by: Krzysztof Kozlowski 
> >> >
> >>
> >> A nice ping...
> >>
> >
> > Rafael, would you please review it? This series was discussed about
> > half a year, and many people need it, I hope it can be in v4.11-rc1,
> > thanks.
> 
> I'm travelling now
> (http://marc.info/?l=linux-pm=148410629024194=2) and (as stated in
> this message) I'll get to the patches when I'm back home.
> 
> There is a good chance for your code to go into 4.11-rc1 if the review
> comments so far have been addressed.
> 

Thanks, Rafael. I think I have addressed all your comments.

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 2/8] power: add power sequence library

2017-01-21 Thread Peter Chen

On Fri, Jan 20, 2017 at 11:21:27AM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 20, 2017 at 8:52 AM, Peter Chen  wrote:
> > On Tue, Jan 10, 2017 at 03:02:41PM +0800, Peter Chen wrote:
> >> On Sat, Jan 07, 2017 at 10:54:56AM +0200, Krzysztof Kozlowski wrote:
> >> > On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote:
> >> > > We have an well-known problem that the device needs to do some power
> >> > > sequence before it can be recognized by related host, the typical
> >> > > example like hard-wired mmc devices and usb devices.
> >> > >
> >> > > This power sequence is hard to be described at device tree and handled 
> >> > > by
> >> > > related host driver, so we have created a common power sequence
> >> > > library to cover this requirement. The core code has supplied
> >> > > some common helpers for host driver, and individual power sequence
> >> > > libraries handle kinds of power sequence for devices. The pwrseq
> >> > > librares always need to allocate extra instance for compatible
> >> > > string match.
> >> > >
> >> > > pwrseq_generic is intended for general purpose of power sequence, which
> >> > > handles gpios and clocks currently, and can cover other controls in
> >> > > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> >> > > if only one power sequence is needed, else call of_pwrseq_on_list
> >> > > /of_pwrseq_off_list instead (eg, USB hub driver).
> >> > >
> >> > > For new power sequence library, it can add its compatible string
> >> > > to pwrseq_of_match_table, then the pwrseq core will match it with
> >> > > DT's, and choose this library at runtime.
> >> > >
> >> > > Signed-off-by: Peter Chen 
> >> > > Tested-by: Maciej S. Szmigiero 
> >> > > Tested-by Joshua Clayton 
> >> > > Reviewed-by: Matthias Kaehlcke 
> >> > > Tested-by: Matthias Kaehlcke 
> >> >
> >> > Acked-by: Krzysztof Kozlowski 
> >> > Tested on Odroid U3 (reset sequence for LAN9730):
> >> > Tested-by: Krzysztof Kozlowski 
> >> >
> >>
> >> A nice ping...
> >>
> >
> > Rafael, would you please review it? This series was discussed about
> > half a year, and many people need it, I hope it can be in v4.11-rc1,
> > thanks.
> 
> I'm travelling now
> (http://marc.info/?l=linux-pm=148410629024194=2) and (as stated in
> this message) I'll get to the patches when I'm back home.
> 
> There is a good chance for your code to go into 4.11-rc1 if the review
> comments so far have been addressed.
> 

Thanks, Rafael. I think I have addressed all your comments.

-- 

Best Regards,
Peter Chen

Re: [PATCH v7 2/5] usb: chipidea: msm: Configure phy for appropriate mode

2017-01-21 Thread Peter Chen

On Fri, Jan 20, 2017 at 10:50:54AM -0800, Stephen Boyd wrote:
> When the qcom chipidea controller is used with an extcon, we need
> to signal device mode or host mode to the phy so it can configure
> itself for the correct mode. This should be done after the phy is
> powered up, so that the register writes work correctly. Add in
> the appropriate phy_set_mode() call here.
> 
> To signal the correct state to the qcom glue driver we need to
> change the ci->role before we do the role switch. Make sure to
> undo the change if the role switch fails, but otherwise update
> the state before calling the role start function so that the glue
> driver knows what state to configure for.
> 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
> 
> Made this msm specific because of how msm handles phy powerup.
> 
>  drivers/usb/chipidea/ci.h  | 7 +--
>  drivers/usb/chipidea/ci_hdrc_msm.c | 4 
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 59e22389c10b..18348b0529af 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -268,6 +268,7 @@ static inline struct ci_role_driver *ci_role(struct 
> ci_hdrc *ci)
>  static inline int ci_role_start(struct ci_hdrc *ci, enum ci_role role)
>  {
>   int ret;
> + enum ci_role prev_role;
>  
>   if (role >= CI_ROLE_END)
>   return -EINVAL;
> @@ -275,9 +276,11 @@ static inline int ci_role_start(struct ci_hdrc *ci, enum 
> ci_role role)
>   if (!ci->roles[role])
>   return -ENXIO;
>  
> + prev_role = ci->role;
> + ci->role = role;
>   ret = ci->roles[role]->start(ci);
> - if (!ret)
> - ci->role = role;
> + if (ret)
> + ci->role = prev_role;
>   return ret;

Sorry, this changes ci->role's life cycle. You may try to get coming
role at your glue layer code (eg, through usbmode), or add your
changes at ci_role_start directly if the sequence can make your requirement.

Peter
>  }
>  
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index f1ede7909f54..9c58d13970ca 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -125,6 +125,10 @@ static int ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   hw_write(ci, OP_USBCMD, HSPHY_SESS_VLD_CTRL,
>HSPHY_SESS_VLD_CTRL);
>  
> + if (ci->role == CI_ROLE_GADGET)
> + phy_set_mode(ci->phy, PHY_MODE_USB_DEVICE);
> + else if (ci->role == CI_ROLE_HOST)
> + phy_set_mode(ci->phy, PHY_MODE_USB_HOST);
>   }
>   break;
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
> -- 
> 2.10.0.297.gf6727b0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [PATCH v7 2/5] usb: chipidea: msm: Configure phy for appropriate mode

2017-01-21 Thread Peter Chen

On Fri, Jan 20, 2017 at 10:50:54AM -0800, Stephen Boyd wrote:
> When the qcom chipidea controller is used with an extcon, we need
> to signal device mode or host mode to the phy so it can configure
> itself for the correct mode. This should be done after the phy is
> powered up, so that the register writes work correctly. Add in
> the appropriate phy_set_mode() call here.
> 
> To signal the correct state to the qcom glue driver we need to
> change the ci->role before we do the role switch. Make sure to
> undo the change if the role switch fails, but otherwise update
> the state before calling the role start function so that the glue
> driver knows what state to configure for.
> 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
> 
> Made this msm specific because of how msm handles phy powerup.
> 
>  drivers/usb/chipidea/ci.h  | 7 +--
>  drivers/usb/chipidea/ci_hdrc_msm.c | 4 
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 59e22389c10b..18348b0529af 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -268,6 +268,7 @@ static inline struct ci_role_driver *ci_role(struct 
> ci_hdrc *ci)
>  static inline int ci_role_start(struct ci_hdrc *ci, enum ci_role role)
>  {
>   int ret;
> + enum ci_role prev_role;
>  
>   if (role >= CI_ROLE_END)
>   return -EINVAL;
> @@ -275,9 +276,11 @@ static inline int ci_role_start(struct ci_hdrc *ci, enum 
> ci_role role)
>   if (!ci->roles[role])
>   return -ENXIO;
>  
> + prev_role = ci->role;
> + ci->role = role;
>   ret = ci->roles[role]->start(ci);
> - if (!ret)
> - ci->role = role;
> + if (ret)
> + ci->role = prev_role;
>   return ret;

Sorry, this changes ci->role's life cycle. You may try to get coming
role at your glue layer code (eg, through usbmode), or add your
changes at ci_role_start directly if the sequence can make your requirement.

Peter
>  }
>  
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index f1ede7909f54..9c58d13970ca 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -125,6 +125,10 @@ static int ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   hw_write(ci, OP_USBCMD, HSPHY_SESS_VLD_CTRL,
>HSPHY_SESS_VLD_CTRL);
>  
> + if (ci->role == CI_ROLE_GADGET)
> + phy_set_mode(ci->phy, PHY_MODE_USB_DEVICE);
> + else if (ci->role == CI_ROLE_HOST)
> + phy_set_mode(ci->phy, PHY_MODE_USB_HOST);
>   }
>   break;
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
> -- 
> 2.10.0.297.gf6727b0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

1 2 3 4 5 6 >

1 - 100 of 534 matches

Mail list logo