Re: [PATCH v4 3/3] powerpc/lib: optimise PPC32 memcmp

[Christophe LEROY]

Le 24/05/2018 à 19:24, Segher Boessenkool a écrit :

On Wed, May 23, 2018 at 09:47:32AM +0200, Christophe Leroy wrote:

At the time being, memcmp() compares two chunks of memory
byte per byte.

This patch optimises the comparison by comparing word by word.

A small benchmark performed on an 8xx comparing two chuncks
of 512 bytes performed 10 times gives:

Before : 5852274 TB ticks
After:   1488638 TB ticks



diff --git a/arch/powerpc/lib/string_32.S b/arch/powerpc/lib/string_32.S
index 40a576d56ac7..542e6cecbcaf 100644
--- a/arch/powerpc/lib/string_32.S
+++ b/arch/powerpc/lib/string_32.S
@@ -16,17 +16,45 @@
.text

  _GLOBAL(memcmp)
-   cmpwi   cr0, r5, 0
-   beq-2f
-   mtctr   r5
-   addir6,r3,-1
-   addir4,r4,-1
-1: lbzur3,1(r6)
-   lbzur0,1(r4)
-   subf.   r3,r0,r3
-   bdnzt   2,1b
+   srawi.  r7, r5, 2   /* Divide len by 4 */
+   mr  r6, r3
+   beq-3f
+   mtctr   r7
+   li  r7, 0
+1:
+#ifdef __LITTLE_ENDIAN__
+   lwbrx   r3, r6, r7
+   lwbrx   r0, r4, r7
+#else
+   lwzxr3, r6, r7
+   lwzxr0, r4, r7
+#endif


You don't test whether the pointers are word-aligned.  Does that work?


copy_tofrom_user() word-aligns the store address and doesn't take care 
of the load address, so I believe it works.


Now, I just read in the MPC885 Ref Manual that unaligned access 
generates alignment exception when the processor is running in LE mode.


Ref. made to the discussion on patch "powerpc/32be: use stmw/lmw for 
registers save/restore in asm" 
(https://patchwork.ozlabs.org/patch/899465/), I will drop the handling 
for LE mode.


Christophe


Say, when a load is crossing a page boundary, or segment boundary.


Segher

Re: [PATCH v4 3/3] powerpc/lib: optimise PPC32 memcmp

[Christophe LEROY]

Le 24/05/2018 à 19:24, Segher Boessenkool a écrit :

On Wed, May 23, 2018 at 09:47:32AM +0200, Christophe Leroy wrote:

At the time being, memcmp() compares two chunks of memory
byte per byte.

This patch optimises the comparison by comparing word by word.

A small benchmark performed on an 8xx comparing two chuncks
of 512 bytes performed 10 times gives:

Before : 5852274 TB ticks
After:   1488638 TB ticks



diff --git a/arch/powerpc/lib/string_32.S b/arch/powerpc/lib/string_32.S
index 40a576d56ac7..542e6cecbcaf 100644
--- a/arch/powerpc/lib/string_32.S
+++ b/arch/powerpc/lib/string_32.S
@@ -16,17 +16,45 @@
.text

  _GLOBAL(memcmp)
-   cmpwi   cr0, r5, 0
-   beq-2f
-   mtctr   r5
-   addir6,r3,-1
-   addir4,r4,-1
-1: lbzur3,1(r6)
-   lbzur0,1(r4)
-   subf.   r3,r0,r3
-   bdnzt   2,1b
+   srawi.  r7, r5, 2   /* Divide len by 4 */
+   mr  r6, r3
+   beq-3f
+   mtctr   r7
+   li  r7, 0
+1:
+#ifdef __LITTLE_ENDIAN__
+   lwbrx   r3, r6, r7
+   lwbrx   r0, r4, r7
+#else
+   lwzxr3, r6, r7
+   lwzxr0, r4, r7
+#endif


You don't test whether the pointers are word-aligned.  Does that work?


copy_tofrom_user() word-aligns the store address and doesn't take care 
of the load address, so I believe it works.


Now, I just read in the MPC885 Ref Manual that unaligned access 
generates alignment exception when the processor is running in LE mode.


Ref. made to the discussion on patch "powerpc/32be: use stmw/lmw for 
registers save/restore in asm" 
(https://patchwork.ozlabs.org/patch/899465/), I will drop the handling 
for LE mode.


Christophe


Say, when a load is crossing a page boundary, or segment boundary.


Segher

Re: [PATCH V2 rdma-next 4/4] RDMA/hns: Fix the illegal memory operation when cross page

[Wei Hu (Xavier)]

On 2018/5/25 5:40, Jason Gunthorpe wrote:
> On Wed, May 23, 2018 at 06:16:30PM +0800, Wei Hu (Xavier) wrote:
>> This patch fixed the potential illegal operation when using the
>> extend sge buffer cross page in post send operation. The bug
>> will cause the calltrace.
> Should include the oops for reference here..
OK, we will fix it in v3.
Thanks
>> Reported-by: Jie Chen 
>> Reported-by: Xiping Zhang (Francis) 
>> Fixes: b1c158350968("RDMA/hns: Get rid of virt_to_page and vmap calls after 
>> dma_alloc_coherent")
>> Signed-off-by: Wei Hu (Xavier) 
>>
>> v1->v2: Modify the Fixes statement according to Leon's comment.
>>  drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 70 
>> +-
>>  drivers/infiniband/hw/hns/hns_roce_hw_v2.h |  1 +
>>  2 files changed, 51 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c 
>> b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> index a70d07b..62c1eb5 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> @@ -52,6 +52,52 @@ static void set_data_seg_v2(struct 
>> hns_roce_v2_wqe_data_seg *dseg,
>>  dseg->len  = cpu_to_le32(sg->length);
>>  }
>>  
>> +static void set_extend_sge(struct hns_roce_qp *qp, struct ib_send_wr *wr,
>> +   unsigned int *sge_ind)
>> +{
>> +struct hns_roce_v2_wqe_data_seg *dseg;
>> +struct ib_sge *sg;
>> +int num_in_wqe = 0;
>> +int extend_sge_num;
>> +int fi_sge_num;
>> +int se_sge_num;
>> +int shift;
>> +int i;
>> +
>> +if (qp->ibqp.qp_type == IB_QPT_RC || qp->ibqp.qp_type == IB_QPT_UC)
>> +num_in_wqe = HNS_ROCE_V2_UC_RC_SGE_NUM_IN_WQE;
>> +extend_sge_num = wr->num_sge - num_in_wqe;
>> +sg = wr->sg_list + num_in_wqe;
>> +shift = qp->hr_buf.page_shift;
>> +
>> +/*
>> + * Check whether wr->num_sge sges are in the same page. If not, we
>> + * should calculate how many sges in the first page and the second
>> + * page.
>> + */
>> +dseg = get_send_extend_sge(qp, (*sge_ind) & (qp->sge.sge_cnt - 1));
>> +fi_sge_num = (u64)dseg >> shift) + 1) << shift) - (u64)dseg) /
>> +  sizeof(struct hns_roce_v2_wqe_data_seg);
> desg is a pointer.. that u64 should be a uinptr_t
>
> And it is better written as
>
>   (round_up((uintptr_t)dseg, 1 << shift) - (uintptr)desg)/sizeof(struct 
> hns_roce_v2_wqe_data_seg)
>
> if I got it right..
Ok, we will fix it v3.
Thanks

Wei Hu
> Jason
>
> .
>

Re: [PATCH V2 rdma-next 4/4] RDMA/hns: Fix the illegal memory operation when cross page

[Wei Hu (Xavier)]

On 2018/5/25 5:40, Jason Gunthorpe wrote:
> On Wed, May 23, 2018 at 06:16:30PM +0800, Wei Hu (Xavier) wrote:
>> This patch fixed the potential illegal operation when using the
>> extend sge buffer cross page in post send operation. The bug
>> will cause the calltrace.
> Should include the oops for reference here..
OK, we will fix it in v3.
Thanks
>> Reported-by: Jie Chen 
>> Reported-by: Xiping Zhang (Francis) 
>> Fixes: b1c158350968("RDMA/hns: Get rid of virt_to_page and vmap calls after 
>> dma_alloc_coherent")
>> Signed-off-by: Wei Hu (Xavier) 
>>
>> v1->v2: Modify the Fixes statement according to Leon's comment.
>>  drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 70 
>> +-
>>  drivers/infiniband/hw/hns/hns_roce_hw_v2.h |  1 +
>>  2 files changed, 51 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c 
>> b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> index a70d07b..62c1eb5 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> @@ -52,6 +52,52 @@ static void set_data_seg_v2(struct 
>> hns_roce_v2_wqe_data_seg *dseg,
>>  dseg->len  = cpu_to_le32(sg->length);
>>  }
>>  
>> +static void set_extend_sge(struct hns_roce_qp *qp, struct ib_send_wr *wr,
>> +   unsigned int *sge_ind)
>> +{
>> +struct hns_roce_v2_wqe_data_seg *dseg;
>> +struct ib_sge *sg;
>> +int num_in_wqe = 0;
>> +int extend_sge_num;
>> +int fi_sge_num;
>> +int se_sge_num;
>> +int shift;
>> +int i;
>> +
>> +if (qp->ibqp.qp_type == IB_QPT_RC || qp->ibqp.qp_type == IB_QPT_UC)
>> +num_in_wqe = HNS_ROCE_V2_UC_RC_SGE_NUM_IN_WQE;
>> +extend_sge_num = wr->num_sge - num_in_wqe;
>> +sg = wr->sg_list + num_in_wqe;
>> +shift = qp->hr_buf.page_shift;
>> +
>> +/*
>> + * Check whether wr->num_sge sges are in the same page. If not, we
>> + * should calculate how many sges in the first page and the second
>> + * page.
>> + */
>> +dseg = get_send_extend_sge(qp, (*sge_ind) & (qp->sge.sge_cnt - 1));
>> +fi_sge_num = (u64)dseg >> shift) + 1) << shift) - (u64)dseg) /
>> +  sizeof(struct hns_roce_v2_wqe_data_seg);
> desg is a pointer.. that u64 should be a uinptr_t
>
> And it is better written as
>
>   (round_up((uintptr_t)dseg, 1 << shift) - (uintptr)desg)/sizeof(struct 
> hns_roce_v2_wqe_data_seg)
>
> if I got it right..
Ok, we will fix it v3.
Thanks

Wei Hu
> Jason
>
> .
>

Re: [PATCH V2 rdma-next 3/4] RDMA/hns: Add reset process for RoCE in hip08

[Wei Hu (Xavier)]

On 2018/5/25 5:31, Jason Gunthorpe wrote:
> On Wed, May 23, 2018 at 06:16:29PM +0800, Wei Hu (Xavier) wrote:
>> This patch added reset process for RoCE in hip08.
>>
>> Signed-off-by: Wei Hu (Xavier) 
>>
>> v1->v2: 1.Delete handle->priv = NULL in hns_roce_hw_v2_uninit_instance.
>>  2.Add hns_roce_hw_v2_reset_notify_init callback function,
>>When RoCE reinit failed in this function, inform NIC driver.
>>  The related link of Jason's commets:
>>  https://www.spinics.net/lists/linux-rdma/msg65009.html
>>  drivers/infiniband/hw/hns/hns_roce_cmd.c|  3 ++
>>  drivers/infiniband/hw/hns/hns_roce_device.h |  2 +
>>  drivers/infiniband/hw/hns/hns_roce_hw_v2.c  | 76 
>> +
>>  drivers/infiniband/hw/hns/hns_roce_main.c   |  7 +++
>>  4 files changed, 88 insertions(+)
>>
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_cmd.c 
>> b/drivers/infiniband/hw/hns/hns_roce_cmd.c
>> index 9ebe839..a0ba19d 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_cmd.c
>> @@ -176,6 +176,9 @@ int hns_roce_cmd_mbox(struct hns_roce_dev *hr_dev, u64 
>> in_param, u64 out_param,
>>unsigned long in_modifier, u8 op_modifier, u16 op,
>>unsigned long timeout)
>>  {
>> +if (hr_dev->is_reset)
>> +return 0;
>> +
>>  if (hr_dev->cmd.use_events)
>>  return hns_roce_cmd_mbox_wait(hr_dev, in_param, out_param,
>>in_modifier, op_modifier, op,
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h 
>> b/drivers/infiniband/hw/hns/hns_roce_device.h
>> index 412297d4..da8512b 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_device.h
>> @@ -774,6 +774,8 @@ struct hns_roce_dev {
>>  const char  *irq_names[HNS_ROCE_MAX_IRQ_NUM];
>>  spinlock_t  sm_lock;
>>  spinlock_t  bt_cmd_lock;
>> +boolactive;
>> +boolis_reset;
>>  struct hns_roce_ib_iboe iboe;
>>  
>>  struct list_headpgdir_list;
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c 
>> b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> index e0ab672..a70d07b 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> @@ -768,6 +768,9 @@ static int hns_roce_cmq_send(struct hns_roce_dev *hr_dev,
>>  int ret = 0;
>>  int ntc;
>>  
>> +if (hr_dev->is_reset)
>> +return 0;
>> +
>>  spin_lock_bh(>lock);
>>  
>>  if (num > hns_roce_cmq_space(csq)) {
>> @@ -4790,14 +4793,87 @@ static void hns_roce_hw_v2_uninit_instance(struct 
>> hnae3_handle *handle,
>>  {
>>  struct hns_roce_dev *hr_dev = (struct hns_roce_dev *)handle->priv;
>>  
>> +if (!hr_dev)
>> +return;
>> +
>>  hns_roce_exit(hr_dev);
>>  kfree(hr_dev->priv);
>>  ib_dealloc_device(_dev->ib_dev);
>>  }
>>  
>> +static int hns_roce_hw_v2_reset_notify_down(struct hnae3_handle *handle)
>> +{
>> +struct hns_roce_dev *hr_dev = (struct hns_roce_dev *)handle->priv;
>> +struct ib_event event;
>> +
>> +if (!hr_dev) {
>> +dev_err(>pdev->dev,
>> +"Input parameter handle->priv is NULL!\n");
>> +return -EINVAL;
>> +}
>> +
>> +hr_dev->active = false;
>> +hr_dev->is_reset = true;
>> +
>> +event.event = IB_EVENT_DEVICE_FATAL;
>> +event.device = _dev->ib_dev;
>> +event.element.port_num = 1;
>> +ib_dispatch_event();
>> +
>> +return 0;
>> +}
>> +
>> +static int hns_roce_hw_v2_reset_notify_init(struct hnae3_handle *handle)
>> +{
>> +int ret;
>> +
>> +ret = hns_roce_hw_v2_init_instance(handle);
>> +if (ret) {
>> +/* when reset notify type is HNAE3_INIT_CLIENT In reset notify
>> + * callback function, RoCE Engine reinitialize. If RoCE reinit
>> + * failed, we should inform NIC driver.
>> + */
>> +handle->priv = NULL;
>> +dev_err(>pdev->dev,
>> +"In reset process RoCE reinit failed %d.\n", ret);
>> +}
>> +
>> +return ret;
>> +}
>> +
>> +static int hns_roce_hw_v2_reset_notify_uninit(struct hnae3_handle *handle)
>> +{
>> +msleep(100);
>> +hns_roce_hw_v2_uninit_instance(handle, false);
>> +return 0;
>> +}
>> +
>> +static int hns_roce_hw_v2_reset_notify(struct hnae3_handle *handle,
>> +   enum hnae3_reset_notify_type type)
>> +{
>> +int ret = 0;
>> +
>> +switch (type) {
>> +case HNAE3_DOWN_CLIENT:
>> +ret = hns_roce_hw_v2_reset_notify_down(handle);
>> +break;
>> +case HNAE3_INIT_CLIENT:
>> +ret = hns_roce_hw_v2_reset_notify_init(handle);
>> +break;
>> +case HNAE3_UNINIT_CLIENT:
>> +ret = hns_roce_hw_v2_reset_notify_uninit(handle);
>> +break;
>> +default:
>> +break;
>> +}
>> +
>> +return ret;
>> +}
>> +
>>  static const struct hnae3_client_ops 

Re: [PATCH V2 rdma-next 3/4] RDMA/hns: Add reset process for RoCE in hip08

[Wei Hu (Xavier)]

On 2018/5/25 5:31, Jason Gunthorpe wrote:
> On Wed, May 23, 2018 at 06:16:29PM +0800, Wei Hu (Xavier) wrote:
>> This patch added reset process for RoCE in hip08.
>>
>> Signed-off-by: Wei Hu (Xavier) 
>>
>> v1->v2: 1.Delete handle->priv = NULL in hns_roce_hw_v2_uninit_instance.
>>  2.Add hns_roce_hw_v2_reset_notify_init callback function,
>>When RoCE reinit failed in this function, inform NIC driver.
>>  The related link of Jason's commets:
>>  https://www.spinics.net/lists/linux-rdma/msg65009.html
>>  drivers/infiniband/hw/hns/hns_roce_cmd.c|  3 ++
>>  drivers/infiniband/hw/hns/hns_roce_device.h |  2 +
>>  drivers/infiniband/hw/hns/hns_roce_hw_v2.c  | 76 
>> +
>>  drivers/infiniband/hw/hns/hns_roce_main.c   |  7 +++
>>  4 files changed, 88 insertions(+)
>>
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_cmd.c 
>> b/drivers/infiniband/hw/hns/hns_roce_cmd.c
>> index 9ebe839..a0ba19d 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_cmd.c
>> @@ -176,6 +176,9 @@ int hns_roce_cmd_mbox(struct hns_roce_dev *hr_dev, u64 
>> in_param, u64 out_param,
>>unsigned long in_modifier, u8 op_modifier, u16 op,
>>unsigned long timeout)
>>  {
>> +if (hr_dev->is_reset)
>> +return 0;
>> +
>>  if (hr_dev->cmd.use_events)
>>  return hns_roce_cmd_mbox_wait(hr_dev, in_param, out_param,
>>in_modifier, op_modifier, op,
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h 
>> b/drivers/infiniband/hw/hns/hns_roce_device.h
>> index 412297d4..da8512b 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_device.h
>> @@ -774,6 +774,8 @@ struct hns_roce_dev {
>>  const char  *irq_names[HNS_ROCE_MAX_IRQ_NUM];
>>  spinlock_t  sm_lock;
>>  spinlock_t  bt_cmd_lock;
>> +boolactive;
>> +boolis_reset;
>>  struct hns_roce_ib_iboe iboe;
>>  
>>  struct list_headpgdir_list;
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c 
>> b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> index e0ab672..a70d07b 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> @@ -768,6 +768,9 @@ static int hns_roce_cmq_send(struct hns_roce_dev *hr_dev,
>>  int ret = 0;
>>  int ntc;
>>  
>> +if (hr_dev->is_reset)
>> +return 0;
>> +
>>  spin_lock_bh(>lock);
>>  
>>  if (num > hns_roce_cmq_space(csq)) {
>> @@ -4790,14 +4793,87 @@ static void hns_roce_hw_v2_uninit_instance(struct 
>> hnae3_handle *handle,
>>  {
>>  struct hns_roce_dev *hr_dev = (struct hns_roce_dev *)handle->priv;
>>  
>> +if (!hr_dev)
>> +return;
>> +
>>  hns_roce_exit(hr_dev);
>>  kfree(hr_dev->priv);
>>  ib_dealloc_device(_dev->ib_dev);
>>  }
>>  
>> +static int hns_roce_hw_v2_reset_notify_down(struct hnae3_handle *handle)
>> +{
>> +struct hns_roce_dev *hr_dev = (struct hns_roce_dev *)handle->priv;
>> +struct ib_event event;
>> +
>> +if (!hr_dev) {
>> +dev_err(>pdev->dev,
>> +"Input parameter handle->priv is NULL!\n");
>> +return -EINVAL;
>> +}
>> +
>> +hr_dev->active = false;
>> +hr_dev->is_reset = true;
>> +
>> +event.event = IB_EVENT_DEVICE_FATAL;
>> +event.device = _dev->ib_dev;
>> +event.element.port_num = 1;
>> +ib_dispatch_event();
>> +
>> +return 0;
>> +}
>> +
>> +static int hns_roce_hw_v2_reset_notify_init(struct hnae3_handle *handle)
>> +{
>> +int ret;
>> +
>> +ret = hns_roce_hw_v2_init_instance(handle);
>> +if (ret) {
>> +/* when reset notify type is HNAE3_INIT_CLIENT In reset notify
>> + * callback function, RoCE Engine reinitialize. If RoCE reinit
>> + * failed, we should inform NIC driver.
>> + */
>> +handle->priv = NULL;
>> +dev_err(>pdev->dev,
>> +"In reset process RoCE reinit failed %d.\n", ret);
>> +}
>> +
>> +return ret;
>> +}
>> +
>> +static int hns_roce_hw_v2_reset_notify_uninit(struct hnae3_handle *handle)
>> +{
>> +msleep(100);
>> +hns_roce_hw_v2_uninit_instance(handle, false);
>> +return 0;
>> +}
>> +
>> +static int hns_roce_hw_v2_reset_notify(struct hnae3_handle *handle,
>> +   enum hnae3_reset_notify_type type)
>> +{
>> +int ret = 0;
>> +
>> +switch (type) {
>> +case HNAE3_DOWN_CLIENT:
>> +ret = hns_roce_hw_v2_reset_notify_down(handle);
>> +break;
>> +case HNAE3_INIT_CLIENT:
>> +ret = hns_roce_hw_v2_reset_notify_init(handle);
>> +break;
>> +case HNAE3_UNINIT_CLIENT:
>> +ret = hns_roce_hw_v2_reset_notify_uninit(handle);
>> +break;
>> +default:
>> +break;
>> +}
>> +
>> +return ret;
>> +}
>> +
>>  static const struct hnae3_client_ops hns_roce_hw_v2_ops = {
>>  

Re: [PATCH 4/9] regulator: bd71837: Devicetree bindings for BD71837 regulators

[Matti Vaittinen]

On Thu, May 24, 2018 at 06:57:21PM +0100, Mark Brown wrote:
> On Thu, May 24, 2018 at 05:30:57PM +, Vaittinen, Matti wrote:
> > > > On Thu, May 24, 2018 at 08:57:52AM +0300, Matti Vaittinen wrote:
> > >
> > > > +Required properties:
> > > > + - compatible: should be "rohm,bd71837-pmic".
> > > > + - regulator-name: should be "buck1", ..., "buck8" and "ldo1", ..., 
> > > > "ldo7"
> > >
> > > The MFD is for a single device, there should be no need for compatibles
> > > on subfunctions.
> > 
> > I will check this. I must admit I am not sure what is the de-facto mechanism
> > for assigning the correct device-tree nodes to sub devices if compatibles
> > are not used? I think I saw device-tree node name being used for regulators
> 
> You can look at the regulators node within the parent device, you know
> that in Linux the parent device will be the MFD.

So I should parse the device-tree in MFD my driver in order to locate
the regulators node? Isn't that somewhat like code dublication? If we
rely on compatibles we can avoid device-tree parsing in MFD driver,
right? An in-tree example of this is:

Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt
>Required properties:
>- compatible: should be "sprd,sc27xx-regulator".
//snip
>Example:
>   regulators {
>   compatible = "sprd,sc27xx-regulator";
>
>vddarm0: BUCK_CPU0 {
>   regulator-name = "vddarm0";
>   regulator-min-microvolt = <40>;

drivers/mfd/sprd-sc27xx-spi.c
> static const struct mfd_cell sprd_pmic_devs[] = {
//snip
>}, {
>.name = "sc27xx-regulator",
>.of_compatible = "sprd,sc27xx-regulator",
>}, {
//snip
> };

and in probe just:
>ret = devm_mfd_add_devices(>dev, PLATFORM_DEVID_AUTO,
>   sprd_pmic_devs, ARRAY_SIZE(sprd_pmic_devs),
>   NULL, 0,
>   regmap_irq_get_domain(ddata->irq_data));

this looks clean to me and offloads the device-tree parsing completely
to generic code. Wouldn't that be simpler approach that looking up the
regulator node in MFD driver code? (I can do as you suggested but to me
the approach used in sprd-sc27xx-spi.c makes sense)

> > Also, another thing I was wondering is how supply regulators should be
> > handled? In this case the LDO5 is supplied by BUCK6 and LDO6 by
> > BUCK7. 
> 
> > From generic regulator bindings
> > /Documentation/devicetree/bindings/regulator/regulator.txt
> > I found statement:
> 
> > > - -supply: phandle to the parent supply/regulator node
> 
> None of that stuff uses compatible strings, just handle it as covered in
> the bindings.
Sorry. I have not been clear with my question. This part was unrelated
to compatible properties - I should have stated it in my previous mail.

What I meant is that I tried out adding
xxx-supply = <>;
in LDO5 device tree node and expected that the regulator core code would
take care of parsing this from device-tree and adding the supply
information to LDO5. This was not done and I did not fing parsing for
*-supply from drivers/regulator/of_regulator.c. So I was wondering if I
am missing something? I guess the *-supply properties in device-tree for
BD71837 regulators are now ignored. Should the supply parsing be added
in drivers/regulator/of_regulator.c - or have I simply misunderstood
something?

Anyways, I ended up hard coding:
.supply_name = "buck6"
in LDO5 regulator_desc before passing the desc to regulator_register().
This works but it means the buck6 name must be fixed to "buck6".

Br,
Matti Vaittinen

Re: [PATCH 4/9] regulator: bd71837: Devicetree bindings for BD71837 regulators

[Matti Vaittinen]

On Thu, May 24, 2018 at 06:57:21PM +0100, Mark Brown wrote:
> On Thu, May 24, 2018 at 05:30:57PM +, Vaittinen, Matti wrote:
> > > > On Thu, May 24, 2018 at 08:57:52AM +0300, Matti Vaittinen wrote:
> > >
> > > > +Required properties:
> > > > + - compatible: should be "rohm,bd71837-pmic".
> > > > + - regulator-name: should be "buck1", ..., "buck8" and "ldo1", ..., 
> > > > "ldo7"
> > >
> > > The MFD is for a single device, there should be no need for compatibles
> > > on subfunctions.
> > 
> > I will check this. I must admit I am not sure what is the de-facto mechanism
> > for assigning the correct device-tree nodes to sub devices if compatibles
> > are not used? I think I saw device-tree node name being used for regulators
> 
> You can look at the regulators node within the parent device, you know
> that in Linux the parent device will be the MFD.

So I should parse the device-tree in MFD my driver in order to locate
the regulators node? Isn't that somewhat like code dublication? If we
rely on compatibles we can avoid device-tree parsing in MFD driver,
right? An in-tree example of this is:

Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt
>Required properties:
>- compatible: should be "sprd,sc27xx-regulator".
//snip
>Example:
>   regulators {
>   compatible = "sprd,sc27xx-regulator";
>
>vddarm0: BUCK_CPU0 {
>   regulator-name = "vddarm0";
>   regulator-min-microvolt = <40>;

drivers/mfd/sprd-sc27xx-spi.c
> static const struct mfd_cell sprd_pmic_devs[] = {
//snip
>}, {
>.name = "sc27xx-regulator",
>.of_compatible = "sprd,sc27xx-regulator",
>}, {
//snip
> };

and in probe just:
>ret = devm_mfd_add_devices(>dev, PLATFORM_DEVID_AUTO,
>   sprd_pmic_devs, ARRAY_SIZE(sprd_pmic_devs),
>   NULL, 0,
>   regmap_irq_get_domain(ddata->irq_data));

this looks clean to me and offloads the device-tree parsing completely
to generic code. Wouldn't that be simpler approach that looking up the
regulator node in MFD driver code? (I can do as you suggested but to me
the approach used in sprd-sc27xx-spi.c makes sense)

> > Also, another thing I was wondering is how supply regulators should be
> > handled? In this case the LDO5 is supplied by BUCK6 and LDO6 by
> > BUCK7. 
> 
> > From generic regulator bindings
> > /Documentation/devicetree/bindings/regulator/regulator.txt
> > I found statement:
> 
> > > - -supply: phandle to the parent supply/regulator node
> 
> None of that stuff uses compatible strings, just handle it as covered in
> the bindings.
Sorry. I have not been clear with my question. This part was unrelated
to compatible properties - I should have stated it in my previous mail.

What I meant is that I tried out adding
xxx-supply = <>;
in LDO5 device tree node and expected that the regulator core code would
take care of parsing this from device-tree and adding the supply
information to LDO5. This was not done and I did not fing parsing for
*-supply from drivers/regulator/of_regulator.c. So I was wondering if I
am missing something? I guess the *-supply properties in device-tree for
BD71837 regulators are now ignored. Should the supply parsing be added
in drivers/regulator/of_regulator.c - or have I simply misunderstood
something?

Anyways, I ended up hard coding:
.supply_name = "buck6"
in LDO5 regulator_desc before passing the desc to regulator_register().
This works but it means the buck6 name must be fixed to "buck6".

Br,
Matti Vaittinen

[git pull] drm fixes for v4.17-rc7

[Dave Airlie]

Hi Linus,

Only two sets of drivers fixes, one rcar-du lvds regression fix, and a
group of fixes for vmwgfx.

Regards,
Dave.

The following changes since commit 771c577c23bac90597c685971d7297ea00f99d11:

  Linux 4.17-rc6 (2018-05-20 15:31:38 -0700)

are available in the Git repository at:

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

for you to fetch changes up to 4bc6f777952cf2d5b39e0c5a97a18caa743f03b7:

  Merge branch 'vmwgfx-fixes-4.17' of
git://people.freedesktop.org/~thomash/linux into drm-fixes (2018-05-25
09:47:56 +1000)


vmwgfx, rcar-du fixes


Dave Airlie (2):
  Merge branch 'drm/du/fixes' of git://linuxtv.org/pinchartl/media
into drm-fixes
  Merge branch 'vmwgfx-fixes-4.17' of
git://people.freedesktop.org/~thomash/linux into drm-fixes

Laurent Pinchart (1):
  drm: rcar-du: lvds: Fix crash in .atomic_check when disabling connector

Thomas Hellstrom (3):
  drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macros
  drm/vmwgfx: Fix host logging / guestinfo reading error paths
  drm/vmwgfx: Schedule an fb dirty update after resume

 drivers/gpu/drm/rcar-du/rcar_lvds.c |  3 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  5 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  1 -
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  | 22 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 48 -
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.h | 25 ---
 6 files changed, 58 insertions(+), 46 deletions(-)

[git pull] drm fixes for v4.17-rc7

[Dave Airlie]

Hi Linus,

Only two sets of drivers fixes, one rcar-du lvds regression fix, and a
group of fixes for vmwgfx.

Regards,
Dave.

The following changes since commit 771c577c23bac90597c685971d7297ea00f99d11:

  Linux 4.17-rc6 (2018-05-20 15:31:38 -0700)

are available in the Git repository at:

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

for you to fetch changes up to 4bc6f777952cf2d5b39e0c5a97a18caa743f03b7:

  Merge branch 'vmwgfx-fixes-4.17' of
git://people.freedesktop.org/~thomash/linux into drm-fixes (2018-05-25
09:47:56 +1000)


vmwgfx, rcar-du fixes


Dave Airlie (2):
  Merge branch 'drm/du/fixes' of git://linuxtv.org/pinchartl/media
into drm-fixes
  Merge branch 'vmwgfx-fixes-4.17' of
git://people.freedesktop.org/~thomash/linux into drm-fixes

Laurent Pinchart (1):
  drm: rcar-du: lvds: Fix crash in .atomic_check when disabling connector

Thomas Hellstrom (3):
  drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macros
  drm/vmwgfx: Fix host logging / guestinfo reading error paths
  drm/vmwgfx: Schedule an fb dirty update after resume

 drivers/gpu/drm/rcar-du/rcar_lvds.c |  3 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  5 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  1 -
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  | 22 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 48 -
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.h | 25 ---
 6 files changed, 58 insertions(+), 46 deletions(-)

[PATCH 0/6] arm64: dts: Add missing cooling device properties for CPUs

[Viresh Kumar]

Hello,

This fixes missing cooling device properties for CPUs for the ARM64
platforms. This is build tested by the zero day testing infrastructure
as well.

Individual maintainers can pick the patches to their SoC trees or I will
ask ARM SoC maintainers to pick them up later.

--
viresh

Viresh Kumar (6):
  arm64: dts: amlogic: Add missing cooling device properties for CPUs
  arm64: dts: freescale: Add missing cooling device properties for CPUs
  arm64: dts: hisilicon: Add missing cooling device properties for CPUs
  arm64: dts: mediatek: Add missing cooling device properties for CPUs
  arm64: dts: rockchip: Add missing cooling device properties for CPUs
  arm64: dts: socionext: Add missing cooling device properties for CPUs

 .../boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 24 ++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |  5 -
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |  3 +++
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi |  6 ++
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |  4 
 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi |  4 
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  | 16 ++-
 arch/arm64/boot/dts/mediatek/mt7622.dtsi   |  1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  2 ++
 arch/arm64/boot/dts/rockchip/rk3328.dtsi   |  3 +++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi   | 12 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |  8 ++--
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   |  2 ++
 13 files changed, 86 insertions(+), 4 deletions(-)

-- 
2.15.0.194.g9af6a3dea062

[PATCH 0/6] arm64: dts: Add missing cooling device properties for CPUs

[Viresh Kumar]

Hello,

This fixes missing cooling device properties for CPUs for the ARM64
platforms. This is build tested by the zero day testing infrastructure
as well.

Individual maintainers can pick the patches to their SoC trees or I will
ask ARM SoC maintainers to pick them up later.

--
viresh

Viresh Kumar (6):
  arm64: dts: amlogic: Add missing cooling device properties for CPUs
  arm64: dts: freescale: Add missing cooling device properties for CPUs
  arm64: dts: hisilicon: Add missing cooling device properties for CPUs
  arm64: dts: mediatek: Add missing cooling device properties for CPUs
  arm64: dts: rockchip: Add missing cooling device properties for CPUs
  arm64: dts: socionext: Add missing cooling device properties for CPUs

 .../boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 24 ++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |  5 -
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |  3 +++
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi |  6 ++
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |  4 
 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi |  4 
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  | 16 ++-
 arch/arm64/boot/dts/mediatek/mt7622.dtsi   |  1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  2 ++
 arch/arm64/boot/dts/rockchip/rk3328.dtsi   |  3 +++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi   | 12 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |  8 ++--
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   |  2 ++
 13 files changed, 86 insertions(+), 4 deletions(-)

-- 
2.15.0.194.g9af6a3dea062

[PATCH 5/6] arm64: dts: rockchip: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Do minor rearrangement as well to keep ordering consistent.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi |  3 +++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 12 
 arch/arm64/boot/dts/rockchip/rk3399.dtsi |  8 ++--
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index b8e9da15e00c..902a0907ad34 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -89,6 +89,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x1>;
clocks = < ARMCLK>;
+   #cooling-cells = <2>;
dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
@@ -100,6 +101,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x2>;
clocks = < ARMCLK>;
+   #cooling-cells = <2>;
dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
@@ -111,6 +113,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x3>;
clocks = < ARMCLK>;
+   #cooling-cells = <2>;
dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index ad91ced78649..c32f2a551a1f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -122,6 +122,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_l2: cpu@2 {
@@ -129,6 +131,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_l3: cpu@3 {
@@ -136,6 +140,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_b0: cpu@100 {
@@ -152,6 +158,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x101>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_b2: cpu@102 {
@@ -159,6 +167,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x102>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_b3: cpu@103 {
@@ -166,6 +176,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x103>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e0040b648f43..da935383a8f2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -108,8 +108,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
-   #cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKL>;
+   #cooling-cells = <2>; /* min followed by max */
dynamic-power-coefficient = <100>;
};
 
@@ -119,6 +119,7 @@
reg = <0x0 0x1>;
  

[PATCH 5/6] arm64: dts: rockchip: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Do minor rearrangement as well to keep ordering consistent.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi |  3 +++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 12 
 arch/arm64/boot/dts/rockchip/rk3399.dtsi |  8 ++--
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index b8e9da15e00c..902a0907ad34 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -89,6 +89,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x1>;
clocks = < ARMCLK>;
+   #cooling-cells = <2>;
dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
@@ -100,6 +101,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x2>;
clocks = < ARMCLK>;
+   #cooling-cells = <2>;
dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
@@ -111,6 +113,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x3>;
clocks = < ARMCLK>;
+   #cooling-cells = <2>;
dynamic-power-coefficient = <120>;
enable-method = "psci";
next-level-cache = <>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index ad91ced78649..c32f2a551a1f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -122,6 +122,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_l2: cpu@2 {
@@ -129,6 +131,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_l3: cpu@3 {
@@ -136,6 +140,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_b0: cpu@100 {
@@ -152,6 +158,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x101>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_b2: cpu@102 {
@@ -159,6 +167,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x102>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_b3: cpu@103 {
@@ -166,6 +176,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x103>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e0040b648f43..da935383a8f2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -108,8 +108,8 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
-   #cooling-cells = <2>; /* min followed by max */
clocks = < ARMCLKL>;
+   #cooling-cells = <2>; /* min followed by max */
dynamic-power-coefficient = <100>;
};
 
@@ -119,6 +119,7 @@
reg = <0x0 0x1>;
enable-method = 

[PATCH 3/6] arm64: dts: hisilicon: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Do minor rearrangement as well to keep ordering consistent.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 586b281cd531..247024df714f 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -88,8 +88,8 @@
next-level-cache = <_L2>;
clocks = <_clock 0>;
operating-points-v2 = <_opp_table>;
-   #cooling-cells = <2>; /* min followed by max */
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
dynamic-power-coefficient = <311>;
};
 
@@ -101,6 +101,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu2: cpu@2 {
@@ -111,6 +113,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu3: cpu@3 {
@@ -121,6 +125,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu4: cpu@100 {
@@ -131,6 +137,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu5: cpu@101 {
@@ -141,6 +149,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu6: cpu@102 {
@@ -151,6 +161,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu7: cpu@103 {
@@ -161,6 +173,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
CLUSTER0_L2: l2-cache0 {
-- 
2.15.0.194.g9af6a3dea062

[PATCH 3/6] arm64: dts: hisilicon: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Do minor rearrangement as well to keep ordering consistent.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 586b281cd531..247024df714f 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -88,8 +88,8 @@
next-level-cache = <_L2>;
clocks = <_clock 0>;
operating-points-v2 = <_opp_table>;
-   #cooling-cells = <2>; /* min followed by max */
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
dynamic-power-coefficient = <311>;
};
 
@@ -101,6 +101,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu2: cpu@2 {
@@ -111,6 +113,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu3: cpu@3 {
@@ -121,6 +125,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu4: cpu@100 {
@@ -131,6 +137,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu5: cpu@101 {
@@ -141,6 +149,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu6: cpu@102 {
@@ -151,6 +161,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
cpu7: cpu@103 {
@@ -161,6 +173,8 @@
next-level-cache = <_L2>;
operating-points-v2 = <_opp_table>;
cpu-idle-states = <_SLEEP _SLEEP>;
+   #cooling-cells = <2>; /* min followed by max */
+   dynamic-power-coefficient = <311>;
};
 
CLUSTER0_L2: l2-cache0 {
-- 
2.15.0.194.g9af6a3dea062

[PATCH 4/6] arm64: dts: mediatek: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi 
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 9213c966c224..d49fe125e770 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -89,6 +89,7 @@
 < CLK_APMIXED_MAIN_CORE_EN>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <_opp_table>;
+   #cooling-cells = <2>;
enable-method = "psci";
clock-frequency = <13>;
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 94597e33c806..abd2f15a544b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -168,6 +168,7 @@
reg = <0x001>;
enable-method = "psci";
cpu-idle-states = <_SLEEP_0>;
+   #cooling-cells = <2>;
clocks = < CLK_INFRA_CA53SEL>,
 < CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
@@ -193,6 +194,7 @@
reg = <0x101>;
enable-method = "psci";
cpu-idle-states = <_SLEEP_0>;
+   #cooling-cells = <2>;
clocks = < CLK_INFRA_CA57SEL>,
 < CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
-- 
2.15.0.194.g9af6a3dea062

[PATCH 4/6] arm64: dts: mediatek: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi 
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 9213c966c224..d49fe125e770 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -89,6 +89,7 @@
 < CLK_APMIXED_MAIN_CORE_EN>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <_opp_table>;
+   #cooling-cells = <2>;
enable-method = "psci";
clock-frequency = <13>;
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 94597e33c806..abd2f15a544b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -168,6 +168,7 @@
reg = <0x001>;
enable-method = "psci";
cpu-idle-states = <_SLEEP_0>;
+   #cooling-cells = <2>;
clocks = < CLK_INFRA_CA53SEL>,
 < CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
@@ -193,6 +194,7 @@
reg = <0x101>;
enable-method = "psci";
cpu-idle-states = <_SLEEP_0>;
+   #cooling-cells = <2>;
clocks = < CLK_INFRA_CA57SEL>,
 < CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
-- 
2.15.0.194.g9af6a3dea062

[PATCH 1/6] arm64: dts: amlogic: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Signed-off-by: Viresh Kumar 
---
 .../boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 24 ++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index 0868da476e41..313f88f8759e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -209,10 +209,34 @@
#cooling-cells = <2>;
 };
 
+ {
+   #cooling-cells = <2>;
+};
+
+ {
+   #cooling-cells = <2>;
+};
+
+ {
+   #cooling-cells = <2>;
+};
+
  {
#cooling-cells = <2>;
 };
 
+ {
+   #cooling-cells = <2>;
+};
+
+ {
+   #cooling-cells = <2>;
+};
+
+ {
+   #cooling-cells = <2>;
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
2.15.0.194.g9af6a3dea062

Re: [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions

[Sricharan R]

Hi Bjorn,

On 5/24/2018 11:09 PM, Bjorn Andersson wrote:
> On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
> 
>> From: Stephen Boyd 
>>
>> Krait CPUs have a handful of L2 cache controller registers that
>> live behind a cp15 based indirection register. First you program
>> the indirection register (l2cpselr) to point the L2 'window'
>> register (l2cpdr) at what you want to read/write.  Then you
>> read/write the 'window' register to do what you want. The
>> l2cpselr register is not banked per-cpu so we must lock around
>> accesses to it to prevent other CPUs from re-pointing l2cpdr
>> underneath us.
>>
>> Cc: Mark Rutland 
>> Cc: Russell King 
>> Signed-off-by: Stephen Boyd 
> 
> This should have your signed-off-by here as well.
> 

 ok.

> Apart from that:
> 
> Acked-by: Bjorn Andersson 
> 

 Thanks.

Regards,
 Sricharan


> Regards,
> Bjorn
> 
>> ---
>>  arch/arm/common/Kconfig   |  3 ++
>>  arch/arm/common/Makefile  |  1 +
>>  arch/arm/common/krait-l2-accessors.c  | 48 
>> +++
>>  arch/arm/include/asm/krait-l2-accessors.h | 10 +++
>>  4 files changed, 62 insertions(+)
>>  create mode 100644 arch/arm/common/krait-l2-accessors.c
>>  create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
>>
>> diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
>> index e5ad070..c8e1986 100644
>> --- a/arch/arm/common/Kconfig
>> +++ b/arch/arm/common/Kconfig
>> @@ -7,6 +7,9 @@ config DMABOUNCE
>>  bool
>>  select ZONE_DMA
>>  
>> +config KRAIT_L2_ACCESSORS
>> +bool
>> +
>>  config SHARP_LOCOMO
>>  bool
>>  
>> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
>> index 70b4a14..eec6cd1 100644
>> --- a/arch/arm/common/Makefile
>> +++ b/arch/arm/common/Makefile
>> @@ -7,6 +7,7 @@ obj-y+= firmware.o
>>  
>>  obj-$(CONFIG_SA)+= sa.o
>>  obj-$(CONFIG_DMABOUNCE) += dmabounce.o
>> +obj-$(CONFIG_KRAIT_L2_ACCESSORS) += krait-l2-accessors.o
>>  obj-$(CONFIG_SHARP_LOCOMO)  += locomo.o
>>  obj-$(CONFIG_SHARP_PARAM)   += sharpsl_param.o
>>  obj-$(CONFIG_SHARP_SCOOP)   += scoop.o
>> diff --git a/arch/arm/common/krait-l2-accessors.c 
>> b/arch/arm/common/krait-l2-accessors.c
>> new file mode 100644
>> index 000..9a97dda
>> --- /dev/null
>> +++ b/arch/arm/common/krait-l2-accessors.c
>> @@ -0,0 +1,48 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2018, The Linux Foundation. All rights reserved.
>> +
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +static DEFINE_RAW_SPINLOCK(krait_l2_lock);
>> +
>> +void krait_set_l2_indirect_reg(u32 addr, u32 val)
>> +{
>> +unsigned long flags;
>> +
>> +raw_spin_lock_irqsave(_l2_lock, flags);
>> +/*
>> + * Select the L2 window by poking l2cpselr, then write to the window
>> + * via l2cpdr.
>> + */
>> +asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr));
>> +isb();
>> +asm volatile ("mcr p15, 3, %0, c15, c0, 7 @ l2cpdr" : : "r" (val));
>> +isb();
>> +
>> +raw_spin_unlock_irqrestore(_l2_lock, flags);
>> +}
>> +EXPORT_SYMBOL(krait_set_l2_indirect_reg);
>> +
>> +u32 krait_get_l2_indirect_reg(u32 addr)
>> +{
>> +u32 val;
>> +unsigned long flags;
>> +
>> +raw_spin_lock_irqsave(_l2_lock, flags);
>> +/*
>> + * Select the L2 window by poking l2cpselr, then read from the window
>> + * via l2cpdr.
>> + */
>> +asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr));
>> +isb();
>> +asm volatile ("mrc p15, 3, %0, c15, c0, 7 @ l2cpdr" : "=r" (val));
>> +
>> +raw_spin_unlock_irqrestore(_l2_lock, flags);
>> +
>> +return val;
>> +}
>> +EXPORT_SYMBOL(krait_get_l2_indirect_reg);
>> diff --git a/arch/arm/include/asm/krait-l2-accessors.h 
>> b/arch/arm/include/asm/krait-l2-accessors.h
>> new file mode 100644
>> index 000..dd7c474
>> --- /dev/null
>> +++ b/arch/arm/include/asm/krait-l2-accessors.h
>> @@ -0,0 +1,10 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2018, The Linux Foundation. All rights reserved.
>> +
>> +#ifndef __ASMARM_KRAIT_L2_ACCESSORS_H
>> +#define __ASMARM_KRAIT_L2_ACCESSORS_H
>> +
>> +extern void krait_set_l2_indirect_reg(u32 addr, u32 val);
>> +extern u32 krait_get_l2_indirect_reg(u32 addr);
>> +
>> +#endif
>> -- 
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
>> Code Aurora Forum, hosted by The Linux Foundation
>>

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 2/6] arm64: dts: freescale: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Do minor rearrangement as well to keep ordering consistent.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 5 -
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 +++
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 6 ++
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 4 
 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 4 
 5 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 1109f22bda5e..630ee47441f2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -80,8 +80,8 @@
reg = <0x0>;
clocks = < 1 0>;
next-level-cache = <>;
-   #cooling-cells = <2>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu1: cpu@1 {
@@ -91,6 +91,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu2: cpu@2 {
@@ -100,6 +101,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu3: cpu@3 {
@@ -109,6 +111,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
l2: l2-cache {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 136ebfa9b333..ee7beab8bfae 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -87,6 +87,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu2: cpu@2 {
@@ -96,6 +97,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu3: cpu@3 {
@@ -105,6 +107,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
l2: l2-cache {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 1c6556bcfddf..e64823a25158 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -76,6 +76,7 @@
reg = <0x1>;
clocks = < 1 0>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu2: cpu@2 {
@@ -84,6 +85,7 @@
reg = <0x2>;
clocks = < 1 0>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu3: cpu@3 {
@@ -92,6 +94,7 @@
reg = <0x3>;
clocks = < 1 0>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu4: cpu@100 {
@@ -109,6 +112,7 @@
reg = <0x101>;
clocks = < 1 1>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu6: cpu@102 {
@@ -117,6 +121,7 @@
reg = <0x102>;
clocks = < 1 1>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu7: cpu@103 {
@@ -125,6 +130,7 @@
reg = <0x103>;
clocks = < 1 1>;
cpu-idle-states = <_PH20>;
+   

[PATCH 1/6] arm64: dts: amlogic: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Signed-off-by: Viresh Kumar 
---
 .../boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 24 ++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index 0868da476e41..313f88f8759e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -209,10 +209,34 @@
#cooling-cells = <2>;
 };
 
+ {
+   #cooling-cells = <2>;
+};
+
+ {
+   #cooling-cells = <2>;
+};
+
+ {
+   #cooling-cells = <2>;
+};
+
  {
#cooling-cells = <2>;
 };
 
+ {
+   #cooling-cells = <2>;
+};
+
+ {
+   #cooling-cells = <2>;
+};
+
+ {
+   #cooling-cells = <2>;
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
2.15.0.194.g9af6a3dea062

[PATCH 2/6] arm64: dts: freescale: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Do minor rearrangement as well to keep ordering consistent.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 5 -
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 +++
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 6 ++
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 4 
 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 4 
 5 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 1109f22bda5e..630ee47441f2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -80,8 +80,8 @@
reg = <0x0>;
clocks = < 1 0>;
next-level-cache = <>;
-   #cooling-cells = <2>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu1: cpu@1 {
@@ -91,6 +91,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu2: cpu@2 {
@@ -100,6 +101,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu3: cpu@3 {
@@ -109,6 +111,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
l2: l2-cache {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 136ebfa9b333..ee7beab8bfae 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -87,6 +87,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu2: cpu@2 {
@@ -96,6 +97,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu3: cpu@3 {
@@ -105,6 +107,7 @@
clocks = < 1 0>;
next-level-cache = <>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
l2: l2-cache {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 1c6556bcfddf..e64823a25158 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -76,6 +76,7 @@
reg = <0x1>;
clocks = < 1 0>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu2: cpu@2 {
@@ -84,6 +85,7 @@
reg = <0x2>;
clocks = < 1 0>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu3: cpu@3 {
@@ -92,6 +94,7 @@
reg = <0x3>;
clocks = < 1 0>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu4: cpu@100 {
@@ -109,6 +112,7 @@
reg = <0x101>;
clocks = < 1 1>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu6: cpu@102 {
@@ -117,6 +121,7 @@
reg = <0x102>;
clocks = < 1 1>;
cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
};
 
cpu7: cpu@103 {
@@ -125,6 +130,7 @@
reg = <0x103>;
clocks = < 1 1>;
cpu-idle-states = <_PH20>;
+   

Re: [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions

[Sricharan R]

Hi Bjorn,

On 5/24/2018 11:09 PM, Bjorn Andersson wrote:
> On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
> 
>> From: Stephen Boyd 
>>
>> Krait CPUs have a handful of L2 cache controller registers that
>> live behind a cp15 based indirection register. First you program
>> the indirection register (l2cpselr) to point the L2 'window'
>> register (l2cpdr) at what you want to read/write.  Then you
>> read/write the 'window' register to do what you want. The
>> l2cpselr register is not banked per-cpu so we must lock around
>> accesses to it to prevent other CPUs from re-pointing l2cpdr
>> underneath us.
>>
>> Cc: Mark Rutland 
>> Cc: Russell King 
>> Signed-off-by: Stephen Boyd 
> 
> This should have your signed-off-by here as well.
> 

 ok.

> Apart from that:
> 
> Acked-by: Bjorn Andersson 
> 

 Thanks.

Regards,
 Sricharan


> Regards,
> Bjorn
> 
>> ---
>>  arch/arm/common/Kconfig   |  3 ++
>>  arch/arm/common/Makefile  |  1 +
>>  arch/arm/common/krait-l2-accessors.c  | 48 
>> +++
>>  arch/arm/include/asm/krait-l2-accessors.h | 10 +++
>>  4 files changed, 62 insertions(+)
>>  create mode 100644 arch/arm/common/krait-l2-accessors.c
>>  create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
>>
>> diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
>> index e5ad070..c8e1986 100644
>> --- a/arch/arm/common/Kconfig
>> +++ b/arch/arm/common/Kconfig
>> @@ -7,6 +7,9 @@ config DMABOUNCE
>>  bool
>>  select ZONE_DMA
>>  
>> +config KRAIT_L2_ACCESSORS
>> +bool
>> +
>>  config SHARP_LOCOMO
>>  bool
>>  
>> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
>> index 70b4a14..eec6cd1 100644
>> --- a/arch/arm/common/Makefile
>> +++ b/arch/arm/common/Makefile
>> @@ -7,6 +7,7 @@ obj-y+= firmware.o
>>  
>>  obj-$(CONFIG_SA)+= sa.o
>>  obj-$(CONFIG_DMABOUNCE) += dmabounce.o
>> +obj-$(CONFIG_KRAIT_L2_ACCESSORS) += krait-l2-accessors.o
>>  obj-$(CONFIG_SHARP_LOCOMO)  += locomo.o
>>  obj-$(CONFIG_SHARP_PARAM)   += sharpsl_param.o
>>  obj-$(CONFIG_SHARP_SCOOP)   += scoop.o
>> diff --git a/arch/arm/common/krait-l2-accessors.c 
>> b/arch/arm/common/krait-l2-accessors.c
>> new file mode 100644
>> index 000..9a97dda
>> --- /dev/null
>> +++ b/arch/arm/common/krait-l2-accessors.c
>> @@ -0,0 +1,48 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2018, The Linux Foundation. All rights reserved.
>> +
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +static DEFINE_RAW_SPINLOCK(krait_l2_lock);
>> +
>> +void krait_set_l2_indirect_reg(u32 addr, u32 val)
>> +{
>> +unsigned long flags;
>> +
>> +raw_spin_lock_irqsave(_l2_lock, flags);
>> +/*
>> + * Select the L2 window by poking l2cpselr, then write to the window
>> + * via l2cpdr.
>> + */
>> +asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr));
>> +isb();
>> +asm volatile ("mcr p15, 3, %0, c15, c0, 7 @ l2cpdr" : : "r" (val));
>> +isb();
>> +
>> +raw_spin_unlock_irqrestore(_l2_lock, flags);
>> +}
>> +EXPORT_SYMBOL(krait_set_l2_indirect_reg);
>> +
>> +u32 krait_get_l2_indirect_reg(u32 addr)
>> +{
>> +u32 val;
>> +unsigned long flags;
>> +
>> +raw_spin_lock_irqsave(_l2_lock, flags);
>> +/*
>> + * Select the L2 window by poking l2cpselr, then read from the window
>> + * via l2cpdr.
>> + */
>> +asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr));
>> +isb();
>> +asm volatile ("mrc p15, 3, %0, c15, c0, 7 @ l2cpdr" : "=r" (val));
>> +
>> +raw_spin_unlock_irqrestore(_l2_lock, flags);
>> +
>> +return val;
>> +}
>> +EXPORT_SYMBOL(krait_get_l2_indirect_reg);
>> diff --git a/arch/arm/include/asm/krait-l2-accessors.h 
>> b/arch/arm/include/asm/krait-l2-accessors.h
>> new file mode 100644
>> index 000..dd7c474
>> --- /dev/null
>> +++ b/arch/arm/include/asm/krait-l2-accessors.h
>> @@ -0,0 +1,10 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2018, The Linux Foundation. All rights reserved.
>> +
>> +#ifndef __ASMARM_KRAIT_L2_ACCESSORS_H
>> +#define __ASMARM_KRAIT_L2_ACCESSORS_H
>> +
>> +extern void krait_set_l2_indirect_reg(u32 addr, u32 val);
>> +extern u32 krait_get_l2_indirect_reg(u32 addr);
>> +
>> +#endif
>> -- 
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
>> Code Aurora Forum, hosted by The Linux Foundation
>>

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 6/6] arm64: dts: socionext: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index 3a5ed789c056..10ffb5019013 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -58,6 +58,7 @@
clocks = <_clk 32>;
enable-method = "psci";
operating-points-v2 = <_opp>;
+   #cooling-cells = <2>;
};
 
cpu2: cpu@100 {
@@ -77,6 +78,7 @@
clocks = <_clk 33>;
enable-method = "psci";
operating-points-v2 = <_opp>;
+   #cooling-cells = <2>;
};
};
 
-- 
2.15.0.194.g9af6a3dea062

[PATCH 6/6] arm64: dts: socionext: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index 3a5ed789c056..10ffb5019013 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -58,6 +58,7 @@
clocks = <_clk 32>;
enable-method = "psci";
operating-points-v2 = <_opp>;
+   #cooling-cells = <2>;
};
 
cpu2: cpu@100 {
@@ -77,6 +78,7 @@
clocks = <_clk 33>;
enable-method = "psci";
operating-points-v2 = <_opp>;
+   #cooling-cells = <2>;
};
};
 
-- 
2.15.0.194.g9af6a3dea062

Re: [PATCH v9 02/15] clk: mux: Split out register accessors for reuse

[Sricharan R]

Hi Bjorn,

On 5/24/2018 10:20 PM, Bjorn Andersson wrote:
> On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
> 
>> From: Stephen Boyd 
>>
>> We want to reuse the logic in clk-mux.c for other clock drivers
>> that don't use readl as register accessors. Fortunately, there
>> really isn't much to the mux code besides the table indirection
>> and quirk flags if you assume any bit shifting and masking has
>> been done already. Pull that logic out into reusable functions
>> that operate on an optional table and some flags so that other
>> drivers can use the same logic.
>>
>> [Sricharan: Rebased for mainline]
>> Signed-off-by: Sricharan R 
>> Signed-off-by: Stephen Boyd 
> 
> This should read as a log, where the first entry is Stephen stating that
> he acquired or wrote the code and can release it according to the
> license requirements. Then you state that you acquired it, changed it
> and are releasing it according to the license requirements.
> 

 ok, will fix this to make it more clear.

> 
> PS. Please expand your last name.
> 

 ok. Just that, all my previous patches has so far gone like this :-)

Regards,
 Sricharan

> Regards,
> Bjorn
> 
>> ---
>>  drivers/clk/clk-mux.c | 74 
>> +++
>>  drivers/clk/nxp/clk-lpc32xx.c | 21 +++-
>>  include/linux/clk-provider.h  |  6 
>>  3 files changed, 57 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
>> index 39cabe1..28223fa 100644
>> --- a/drivers/clk/clk-mux.c
>> +++ b/drivers/clk/clk-mux.c
>> @@ -26,35 +26,25 @@
>>   * parent - parent is adjustable through clk_set_parent
>>   */
>>  
>> -static u8 clk_mux_get_parent(struct clk_hw *hw)
>> +unsigned int clk_mux_get_parent(struct clk_hw *hw, unsigned int val,
>> +unsigned int *table,
>> +unsigned long flags)
>>  {
>> -struct clk_mux *mux = to_clk_mux(hw);
>>  int num_parents = clk_hw_get_num_parents(hw);
>> -u32 val;
>> -
>> -/*
>> - * FIXME need a mux-specific flag to determine if val is bitwise or 
>> numeric
>> - * e.g. sys_clkin_ck's clksel field is 3 bits wide, but ranges from 0x1
>> - * to 0x7 (index starts at one)
>> - * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
>> - * val = 0x4 really means "bit 2, index starts at bit 0"
>> - */
>> -val = clk_readl(mux->reg) >> mux->shift;
>> -val &= mux->mask;
>>  
>> -if (mux->table) {
>> +if (table) {
>>  int i;
>>  
>>  for (i = 0; i < num_parents; i++)
>> -if (mux->table[i] == val)
>> +if (table[i] == val)
>>  return i;
>>  return -EINVAL;
>>  }
>>  
>> -if (val && (mux->flags & CLK_MUX_INDEX_BIT))
>> +if (val && (flags & CLK_MUX_INDEX_BIT))
>>  val = ffs(val) - 1;
>>  
>> -if (val && (mux->flags & CLK_MUX_INDEX_ONE))
>> +if (val && (flags & CLK_MUX_INDEX_ONE))
>>  val--;
>>  
>>  if (val >= num_parents)
>> @@ -62,23 +52,53 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
>>  
>>  return val;
>>  }
>> +EXPORT_SYMBOL_GPL(clk_mux_get_parent);
>>  
>> -static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
>> +static u8 _clk_mux_get_parent(struct clk_hw *hw)
>>  {
>>  struct clk_mux *mux = to_clk_mux(hw);
>>  u32 val;
>> -unsigned long flags = 0;
>>  
>> -if (mux->table) {
>> -index = mux->table[index];
>> +/*
>> + * FIXME need a mux-specific flag to determine if val is bitwise or
>> + * numeric e.g. sys_clkin_ck's clksel field is 3 bits wide,
>> + * but ranges from 0x1 to 0x7 (index starts at one)
>> + * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
>> + * val = 0x4 really means "bit 2, index starts at bit 0"
>> + */
>> +val = clk_readl(mux->reg) >> mux->shift;
>> +val &= mux->mask;
>> +
>> +return clk_mux_get_parent(hw, val, mux->table, mux->flags);
>> +}
>> +
>> +unsigned int clk_mux_reindex(u8 index, unsigned int *table,
>> + unsigned long flags)
>> +{
>> +unsigned int val = index;
>> +
>> +if (table) {
>> +val = table[val];
>>  } else {
>> -if (mux->flags & CLK_MUX_INDEX_BIT)
>> -index = 1 << index;
>> +if (flags & CLK_MUX_INDEX_BIT)
>> +val = 1 << index;
>>  
>> -if (mux->flags & CLK_MUX_INDEX_ONE)
>> -index++;
>> +if (flags & CLK_MUX_INDEX_ONE)
>> +val++;
>>  }
>>  
>> +return val;
>> +}
>> +EXPORT_SYMBOL_GPL(clk_mux_reindex);
>> +
>> +static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
>> +{
>> +struct clk_mux *mux = to_clk_mux(hw);
>> +u32 val;
>> +unsigned long flags = 0;
>> +
>> +index = 

Re: [PATCH v9 02/15] clk: mux: Split out register accessors for reuse

[Sricharan R]

Hi Bjorn,

On 5/24/2018 10:20 PM, Bjorn Andersson wrote:
> On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
> 
>> From: Stephen Boyd 
>>
>> We want to reuse the logic in clk-mux.c for other clock drivers
>> that don't use readl as register accessors. Fortunately, there
>> really isn't much to the mux code besides the table indirection
>> and quirk flags if you assume any bit shifting and masking has
>> been done already. Pull that logic out into reusable functions
>> that operate on an optional table and some flags so that other
>> drivers can use the same logic.
>>
>> [Sricharan: Rebased for mainline]
>> Signed-off-by: Sricharan R 
>> Signed-off-by: Stephen Boyd 
> 
> This should read as a log, where the first entry is Stephen stating that
> he acquired or wrote the code and can release it according to the
> license requirements. Then you state that you acquired it, changed it
> and are releasing it according to the license requirements.
> 

 ok, will fix this to make it more clear.

> 
> PS. Please expand your last name.
> 

 ok. Just that, all my previous patches has so far gone like this :-)

Regards,
 Sricharan

> Regards,
> Bjorn
> 
>> ---
>>  drivers/clk/clk-mux.c | 74 
>> +++
>>  drivers/clk/nxp/clk-lpc32xx.c | 21 +++-
>>  include/linux/clk-provider.h  |  6 
>>  3 files changed, 57 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
>> index 39cabe1..28223fa 100644
>> --- a/drivers/clk/clk-mux.c
>> +++ b/drivers/clk/clk-mux.c
>> @@ -26,35 +26,25 @@
>>   * parent - parent is adjustable through clk_set_parent
>>   */
>>  
>> -static u8 clk_mux_get_parent(struct clk_hw *hw)
>> +unsigned int clk_mux_get_parent(struct clk_hw *hw, unsigned int val,
>> +unsigned int *table,
>> +unsigned long flags)
>>  {
>> -struct clk_mux *mux = to_clk_mux(hw);
>>  int num_parents = clk_hw_get_num_parents(hw);
>> -u32 val;
>> -
>> -/*
>> - * FIXME need a mux-specific flag to determine if val is bitwise or 
>> numeric
>> - * e.g. sys_clkin_ck's clksel field is 3 bits wide, but ranges from 0x1
>> - * to 0x7 (index starts at one)
>> - * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
>> - * val = 0x4 really means "bit 2, index starts at bit 0"
>> - */
>> -val = clk_readl(mux->reg) >> mux->shift;
>> -val &= mux->mask;
>>  
>> -if (mux->table) {
>> +if (table) {
>>  int i;
>>  
>>  for (i = 0; i < num_parents; i++)
>> -if (mux->table[i] == val)
>> +if (table[i] == val)
>>  return i;
>>  return -EINVAL;
>>  }
>>  
>> -if (val && (mux->flags & CLK_MUX_INDEX_BIT))
>> +if (val && (flags & CLK_MUX_INDEX_BIT))
>>  val = ffs(val) - 1;
>>  
>> -if (val && (mux->flags & CLK_MUX_INDEX_ONE))
>> +if (val && (flags & CLK_MUX_INDEX_ONE))
>>  val--;
>>  
>>  if (val >= num_parents)
>> @@ -62,23 +52,53 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
>>  
>>  return val;
>>  }
>> +EXPORT_SYMBOL_GPL(clk_mux_get_parent);
>>  
>> -static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
>> +static u8 _clk_mux_get_parent(struct clk_hw *hw)
>>  {
>>  struct clk_mux *mux = to_clk_mux(hw);
>>  u32 val;
>> -unsigned long flags = 0;
>>  
>> -if (mux->table) {
>> -index = mux->table[index];
>> +/*
>> + * FIXME need a mux-specific flag to determine if val is bitwise or
>> + * numeric e.g. sys_clkin_ck's clksel field is 3 bits wide,
>> + * but ranges from 0x1 to 0x7 (index starts at one)
>> + * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
>> + * val = 0x4 really means "bit 2, index starts at bit 0"
>> + */
>> +val = clk_readl(mux->reg) >> mux->shift;
>> +val &= mux->mask;
>> +
>> +return clk_mux_get_parent(hw, val, mux->table, mux->flags);
>> +}
>> +
>> +unsigned int clk_mux_reindex(u8 index, unsigned int *table,
>> + unsigned long flags)
>> +{
>> +unsigned int val = index;
>> +
>> +if (table) {
>> +val = table[val];
>>  } else {
>> -if (mux->flags & CLK_MUX_INDEX_BIT)
>> -index = 1 << index;
>> +if (flags & CLK_MUX_INDEX_BIT)
>> +val = 1 << index;
>>  
>> -if (mux->flags & CLK_MUX_INDEX_ONE)
>> -index++;
>> +if (flags & CLK_MUX_INDEX_ONE)
>> +val++;
>>  }
>>  
>> +return val;
>> +}
>> +EXPORT_SYMBOL_GPL(clk_mux_reindex);
>> +
>> +static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
>> +{
>> +struct clk_mux *mux = to_clk_mux(hw);
>> +u32 val;
>> +unsigned long flags = 0;
>> +
>> +index = clk_mux_reindex(index, mux->table, mux->flags);
>> +
>>  if (mux->lock)
>> 

Re: [PATCH v2] drm/xen-front: fix pointer casts

[Oleksandr Andrushchenko]

On 05/23/2018 02:46 PM, Juergen Gross wrote:

On 23/05/18 13:36, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Building for a 32-bit target results in warnings from casting
between a 32-bit pointer and a 64-bit integer. Fix the warnings
by casting those pointers to uintptr_t first.

Signed-off-by: Oleksandr Andrushchenko 

Reviewed-by: Juergen Gross 

Thank you, applied to drm-misc-next


Juergen

Re: [PATCH v2] drm/xen-front: fix pointer casts

[Oleksandr Andrushchenko]

On 05/23/2018 02:46 PM, Juergen Gross wrote:

On 23/05/18 13:36, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Building for a 32-bit target results in warnings from casting
between a 32-bit pointer and a 64-bit integer. Fix the warnings
by casting those pointers to uintptr_t first.

Signed-off-by: Oleksandr Andrushchenko 

Reviewed-by: Juergen Gross 

Thank you, applied to drm-misc-next


Juergen

[PATCH] hwmon: binding: Fix "#cooling-cells" property's name

[Viresh Kumar]

It should be "#cooling-cells" instead of "cooling-cells". Fix it.

Signed-off-by: Viresh Kumar 
---
 Documentation/devicetree/bindings/hwmon/gpio-fan.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt 
b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
index 439a7430fc68..2becdcfdc840 100644
--- a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
@@ -11,7 +11,7 @@ Bindings for fan connected to GPIO lines
   must have the RPM values in ascending order.
 - alarm-gpios: This pin going active indicates something is wrong with
   the fan, and a udev event will be fired.
-- cooling-cells: If used as a cooling device, must be <2>
+- #cooling-cells: If used as a cooling device, must be <2>
   Also see: Documentation/devicetree/bindings/thermal/thermal.txt
   min and max states are derived from the speed-map of the fan.
 
-- 
2.15.0.194.g9af6a3dea062

[PATCH] hwmon: binding: Fix "#cooling-cells" property's name

[Viresh Kumar]

It should be "#cooling-cells" instead of "cooling-cells". Fix it.

Signed-off-by: Viresh Kumar 
---
 Documentation/devicetree/bindings/hwmon/gpio-fan.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt 
b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
index 439a7430fc68..2becdcfdc840 100644
--- a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
@@ -11,7 +11,7 @@ Bindings for fan connected to GPIO lines
   must have the RPM values in ascending order.
 - alarm-gpios: This pin going active indicates something is wrong with
   the fan, and a udev event will be fired.
-- cooling-cells: If used as a cooling device, must be <2>
+- #cooling-cells: If used as a cooling device, must be <2>
   Also see: Documentation/devicetree/bindings/thermal/thermal.txt
   min and max states are derived from the speed-map of the fan.
 
-- 
2.15.0.194.g9af6a3dea062

[GIT PULL] sound fixes for 4.17-rc7

[Takashi Iwai]

Linus,

please pull sound fixes for v4.17-rc7 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
tags/sound-4.17-rc7

The topmost commit is 009f8c90f571d87855914dbc20e6c0ea2a3b19ae



sound fixes for 4.17-rc7

Two fixes:
- A timer pause event notification was garbled upon the recent
  hardening work; corrected now
- HD-audio runtime PM regression fix due to the incorrect return
  type



Ben Hutchings (1):
  ALSA: timer: Fix pause event notification

Lukas Wunner (1):
  ALSA: hda - Fix runtime PM

---
 sound/core/timer.c| 4 ++--
 sound/pci/hda/hda_local.h | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/core/timer.c b/sound/core/timer.c
index dc87728c5b74..0ddcae495838 100644
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -592,7 +592,7 @@ static int snd_timer_stop1(struct snd_timer_instance 
*timeri, bool stop)
else
timeri->flags |= SNDRV_TIMER_IFLG_PAUSED;
snd_timer_notify1(timeri, stop ? SNDRV_TIMER_EVENT_STOP :
- SNDRV_TIMER_EVENT_CONTINUE);
+ SNDRV_TIMER_EVENT_PAUSE);
  unlock:
spin_unlock_irqrestore(>lock, flags);
return result;
@@ -614,7 +614,7 @@ static int snd_timer_stop_slave(struct snd_timer_instance 
*timeri, bool stop)
list_del_init(>ack_list);
list_del_init(>active_list);
snd_timer_notify1(timeri, stop ? SNDRV_TIMER_EVENT_STOP :
- SNDRV_TIMER_EVENT_CONTINUE);
+ SNDRV_TIMER_EVENT_PAUSE);
spin_unlock(>timer->lock);
}
spin_unlock_irqrestore(_active_lock, flags);
diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
index 321e78baa63c..9bd935216c18 100644
--- a/sound/pci/hda/hda_local.h
+++ b/sound/pci/hda/hda_local.h
@@ -622,8 +622,10 @@ snd_hda_check_power_state(struct hda_codec *codec, 
hda_nid_t nid,
 {
return snd_hdac_check_power_state(>core, nid, target_state);
 }
-static inline bool snd_hda_sync_power_state(struct hda_codec *codec,
-  hda_nid_t nid, unsigned int target_state)
+
+static inline unsigned int snd_hda_sync_power_state(struct hda_codec *codec,
+   hda_nid_t nid,
+   unsigned int target_state)
 {
return snd_hdac_sync_power_state(>core, nid, target_state);
 }

[GIT PULL] sound fixes for 4.17-rc7

[Takashi Iwai]

Linus,

please pull sound fixes for v4.17-rc7 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
tags/sound-4.17-rc7

The topmost commit is 009f8c90f571d87855914dbc20e6c0ea2a3b19ae



sound fixes for 4.17-rc7

Two fixes:
- A timer pause event notification was garbled upon the recent
  hardening work; corrected now
- HD-audio runtime PM regression fix due to the incorrect return
  type



Ben Hutchings (1):
  ALSA: timer: Fix pause event notification

Lukas Wunner (1):
  ALSA: hda - Fix runtime PM

---
 sound/core/timer.c| 4 ++--
 sound/pci/hda/hda_local.h | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/core/timer.c b/sound/core/timer.c
index dc87728c5b74..0ddcae495838 100644
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -592,7 +592,7 @@ static int snd_timer_stop1(struct snd_timer_instance 
*timeri, bool stop)
else
timeri->flags |= SNDRV_TIMER_IFLG_PAUSED;
snd_timer_notify1(timeri, stop ? SNDRV_TIMER_EVENT_STOP :
- SNDRV_TIMER_EVENT_CONTINUE);
+ SNDRV_TIMER_EVENT_PAUSE);
  unlock:
spin_unlock_irqrestore(>lock, flags);
return result;
@@ -614,7 +614,7 @@ static int snd_timer_stop_slave(struct snd_timer_instance 
*timeri, bool stop)
list_del_init(>ack_list);
list_del_init(>active_list);
snd_timer_notify1(timeri, stop ? SNDRV_TIMER_EVENT_STOP :
- SNDRV_TIMER_EVENT_CONTINUE);
+ SNDRV_TIMER_EVENT_PAUSE);
spin_unlock(>timer->lock);
}
spin_unlock_irqrestore(_active_lock, flags);
diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
index 321e78baa63c..9bd935216c18 100644
--- a/sound/pci/hda/hda_local.h
+++ b/sound/pci/hda/hda_local.h
@@ -622,8 +622,10 @@ snd_hda_check_power_state(struct hda_codec *codec, 
hda_nid_t nid,
 {
return snd_hdac_check_power_state(>core, nid, target_state);
 }
-static inline bool snd_hda_sync_power_state(struct hda_codec *codec,
-  hda_nid_t nid, unsigned int target_state)
+
+static inline unsigned int snd_hda_sync_power_state(struct hda_codec *codec,
+   hda_nid_t nid,
+   unsigned int target_state)
 {
return snd_hdac_sync_power_state(>core, nid, target_state);
 }

Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

[Byungchul Park]

On 2018-05-09 15:33, Byungchul Park wrote:

On Thu, Jan 11, 2018 at 10:07:16AM +0100, Peter Zijlstra wrote:



Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Please consider this. Even though it's not a big bug, anyway leading
mis-behavior in certain situaions.


Could you see this patches, it's been too long since the start tho?

--
Thanks,
Byungchul

Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

[Byungchul Park]

On 2018-05-09 15:33, Byungchul Park wrote:

On Thu, Jan 11, 2018 at 10:07:16AM +0100, Peter Zijlstra wrote:



Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Please consider this. Even though it's not a big bug, anyway leading
mis-behavior in certain situaions.


Could you see this patches, it's been too long since the start tho?

--
Thanks,
Byungchul

[PATCH] f2fs: let fstrim issue discard commands in lower priority

[Jaegeuk Kim]

The fstrim gathers huge number of large discard commands, and tries to issue
without IO awareness, which results in long user-perceive IO latencies on
READ, WRITE, and FLUSH in UFS. We've observed some of commands take several
seconds due to long discard latency.

This patch limits the maximum size to 2MB per candidate, and check IO congestion
when issuing them to disk.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h|   4 +-
 fs/f2fs/segment.c | 123 +++---
 2 files changed, 64 insertions(+), 63 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 3bddf13794d9..75ae7fc86ae8 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -178,6 +178,7 @@ enum {
 
 #define MAX_DISCARD_BLOCKS(sbi)BLKS_PER_SEC(sbi)
 #define DEF_MAX_DISCARD_REQUEST8   /* issue 8 discards per 
round */
+#define DEF_MAX_DISCARD_LEN512 /* Max. 2MB per discard */
 #define DEF_MIN_DISCARD_ISSUE_TIME 50  /* 50 ms, if exists */
 #define DEF_MID_DISCARD_ISSUE_TIME 500 /* 500 ms, if device busy */
 #define DEF_MAX_DISCARD_ISSUE_TIME 6   /* 60 s, if no candidates */
@@ -698,7 +699,8 @@ static inline void set_extent_info(struct extent_info *ei, 
unsigned int fofs,
 static inline bool __is_discard_mergeable(struct discard_info *back,
struct discard_info *front)
 {
-   return back->lstart + back->len == front->lstart;
+   return (back->lstart + back->len == front->lstart) &&
+   (back->len + front->len < DEF_MAX_DISCARD_LEN);
 }
 
 static inline bool __is_discard_back_mergeable(struct discard_info *cur,
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 843fc2e6d41c..ba996d4091bc 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1139,68 +1139,6 @@ static int __queue_discard_cmd(struct f2fs_sb_info *sbi,
return 0;
 }
 
-static void __issue_discard_cmd_range(struct f2fs_sb_info *sbi,
-   struct discard_policy *dpolicy,
-   unsigned int start, unsigned int end)
-{
-   struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
-   struct discard_cmd *prev_dc = NULL, *next_dc = NULL;
-   struct rb_node **insert_p = NULL, *insert_parent = NULL;
-   struct discard_cmd *dc;
-   struct blk_plug plug;
-   int issued;
-
-next:
-   issued = 0;
-
-   mutex_lock(>cmd_lock);
-   f2fs_bug_on(sbi, !__check_rb_tree_consistence(sbi, >root));
-
-   dc = (struct discard_cmd *)__lookup_rb_tree_ret(>root,
-   NULL, start,
-   (struct rb_entry **)_dc,
-   (struct rb_entry **)_dc,
-   _p, _parent, true);
-   if (!dc)
-   dc = next_dc;
-
-   blk_start_plug();
-
-   while (dc && dc->lstart <= end) {
-   struct rb_node *node;
-
-   if (dc->len < dpolicy->granularity)
-   goto skip;
-
-   if (dc->state != D_PREP) {
-   list_move_tail(>list, >fstrim_list);
-   goto skip;
-   }
-
-   __submit_discard_cmd(sbi, dpolicy, dc);
-
-   if (++issued >= dpolicy->max_requests) {
-   start = dc->lstart + dc->len;
-
-   blk_finish_plug();
-   mutex_unlock(>cmd_lock);
-
-   schedule();
-
-   goto next;
-   }
-skip:
-   node = rb_next(>rb_node);
-   dc = rb_entry_safe(node, struct discard_cmd, rb_node);
-
-   if (fatal_signal_pending(current))
-   break;
-   }
-
-   blk_finish_plug();
-   mutex_unlock(>cmd_lock);
-}
-
 static int __issue_discard_cmd(struct f2fs_sb_info *sbi,
struct discard_policy *dpolicy)
 {
@@ -2397,6 +2335,67 @@ bool exist_trim_candidates(struct f2fs_sb_info *sbi, 
struct cp_control *cpc)
return has_candidate;
 }
 
+static void __issue_discard_cmd_range(struct f2fs_sb_info *sbi,
+   struct discard_policy *dpolicy,
+   unsigned int start, unsigned int end)
+{
+   struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
+   struct discard_cmd *prev_dc = NULL, *next_dc = NULL;
+   struct rb_node **insert_p = NULL, *insert_parent = NULL;
+   struct discard_cmd *dc;
+   struct blk_plug plug;
+   int issued;
+
+next:
+   issued = 0;
+
+   mutex_lock(>cmd_lock);
+   f2fs_bug_on(sbi, !__check_rb_tree_consistence(sbi, >root));
+
+   dc = (struct discard_cmd *)__lookup_rb_tree_ret(>root,
+   NULL, start,
+   (struct rb_entry **)_dc,
+

[PATCH] f2fs: let fstrim issue discard commands in lower priority

[Jaegeuk Kim]

The fstrim gathers huge number of large discard commands, and tries to issue
without IO awareness, which results in long user-perceive IO latencies on
READ, WRITE, and FLUSH in UFS. We've observed some of commands take several
seconds due to long discard latency.

This patch limits the maximum size to 2MB per candidate, and check IO congestion
when issuing them to disk.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h|   4 +-
 fs/f2fs/segment.c | 123 +++---
 2 files changed, 64 insertions(+), 63 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 3bddf13794d9..75ae7fc86ae8 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -178,6 +178,7 @@ enum {
 
 #define MAX_DISCARD_BLOCKS(sbi)BLKS_PER_SEC(sbi)
 #define DEF_MAX_DISCARD_REQUEST8   /* issue 8 discards per 
round */
+#define DEF_MAX_DISCARD_LEN512 /* Max. 2MB per discard */
 #define DEF_MIN_DISCARD_ISSUE_TIME 50  /* 50 ms, if exists */
 #define DEF_MID_DISCARD_ISSUE_TIME 500 /* 500 ms, if device busy */
 #define DEF_MAX_DISCARD_ISSUE_TIME 6   /* 60 s, if no candidates */
@@ -698,7 +699,8 @@ static inline void set_extent_info(struct extent_info *ei, 
unsigned int fofs,
 static inline bool __is_discard_mergeable(struct discard_info *back,
struct discard_info *front)
 {
-   return back->lstart + back->len == front->lstart;
+   return (back->lstart + back->len == front->lstart) &&
+   (back->len + front->len < DEF_MAX_DISCARD_LEN);
 }
 
 static inline bool __is_discard_back_mergeable(struct discard_info *cur,
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 843fc2e6d41c..ba996d4091bc 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1139,68 +1139,6 @@ static int __queue_discard_cmd(struct f2fs_sb_info *sbi,
return 0;
 }
 
-static void __issue_discard_cmd_range(struct f2fs_sb_info *sbi,
-   struct discard_policy *dpolicy,
-   unsigned int start, unsigned int end)
-{
-   struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
-   struct discard_cmd *prev_dc = NULL, *next_dc = NULL;
-   struct rb_node **insert_p = NULL, *insert_parent = NULL;
-   struct discard_cmd *dc;
-   struct blk_plug plug;
-   int issued;
-
-next:
-   issued = 0;
-
-   mutex_lock(>cmd_lock);
-   f2fs_bug_on(sbi, !__check_rb_tree_consistence(sbi, >root));
-
-   dc = (struct discard_cmd *)__lookup_rb_tree_ret(>root,
-   NULL, start,
-   (struct rb_entry **)_dc,
-   (struct rb_entry **)_dc,
-   _p, _parent, true);
-   if (!dc)
-   dc = next_dc;
-
-   blk_start_plug();
-
-   while (dc && dc->lstart <= end) {
-   struct rb_node *node;
-
-   if (dc->len < dpolicy->granularity)
-   goto skip;
-
-   if (dc->state != D_PREP) {
-   list_move_tail(>list, >fstrim_list);
-   goto skip;
-   }
-
-   __submit_discard_cmd(sbi, dpolicy, dc);
-
-   if (++issued >= dpolicy->max_requests) {
-   start = dc->lstart + dc->len;
-
-   blk_finish_plug();
-   mutex_unlock(>cmd_lock);
-
-   schedule();
-
-   goto next;
-   }
-skip:
-   node = rb_next(>rb_node);
-   dc = rb_entry_safe(node, struct discard_cmd, rb_node);
-
-   if (fatal_signal_pending(current))
-   break;
-   }
-
-   blk_finish_plug();
-   mutex_unlock(>cmd_lock);
-}
-
 static int __issue_discard_cmd(struct f2fs_sb_info *sbi,
struct discard_policy *dpolicy)
 {
@@ -2397,6 +2335,67 @@ bool exist_trim_candidates(struct f2fs_sb_info *sbi, 
struct cp_control *cpc)
return has_candidate;
 }
 
+static void __issue_discard_cmd_range(struct f2fs_sb_info *sbi,
+   struct discard_policy *dpolicy,
+   unsigned int start, unsigned int end)
+{
+   struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
+   struct discard_cmd *prev_dc = NULL, *next_dc = NULL;
+   struct rb_node **insert_p = NULL, *insert_parent = NULL;
+   struct discard_cmd *dc;
+   struct blk_plug plug;
+   int issued;
+
+next:
+   issued = 0;
+
+   mutex_lock(>cmd_lock);
+   f2fs_bug_on(sbi, !__check_rb_tree_consistence(sbi, >root));
+
+   dc = (struct discard_cmd *)__lookup_rb_tree_ret(>root,
+   NULL, start,
+   (struct rb_entry **)_dc,
+

Re: [PATCH 8/9] regulator: bd71837: BD71837 PMIC regulator driver

[Matti Vaittinen]

On Thu, May 24, 2018 at 06:59:40PM +0100, Mark Brown wrote:
> On Thu, May 24, 2018 at 05:51:27PM +, Vaittinen, Matti wrote:
> 
> > > what is the lock doing and what is this wrapper function intended to do?
> 
> > This was the other spot which I was unsure how to handle. Datasheet for
> > the chip says that if voltage is to be changed, the regulator must be
> > disabled. Thus my voltage changing function checks if regulator is enabled
> 
> Ugh, this chip is not very good is it?
I am not the correct guy to judge that as I don't have too wide
experience on PMICs. (This is first PMIC I have been working with).
Probably this chip has some other advantages and is thus used.

>  Don't bounce the supply to
> change the voltage silently, that's clearly a bad idea - the devices
> using the supply are going to get very upset when the power gets removed
> just because they changed the voltage.  Instead implement a custom set
> operation that returns an error if the user attempts to change the
> voltage while the regualtor is enabled.

Makes perfect sense. I will change the operation to this.

Br,
Matti Vaittinen

Re: [PATCH 8/9] regulator: bd71837: BD71837 PMIC regulator driver

[Matti Vaittinen]

On Thu, May 24, 2018 at 06:59:40PM +0100, Mark Brown wrote:
> On Thu, May 24, 2018 at 05:51:27PM +, Vaittinen, Matti wrote:
> 
> > > what is the lock doing and what is this wrapper function intended to do?
> 
> > This was the other spot which I was unsure how to handle. Datasheet for
> > the chip says that if voltage is to be changed, the regulator must be
> > disabled. Thus my voltage changing function checks if regulator is enabled
> 
> Ugh, this chip is not very good is it?
I am not the correct guy to judge that as I don't have too wide
experience on PMICs. (This is first PMIC I have been working with).
Probably this chip has some other advantages and is thus used.

>  Don't bounce the supply to
> change the voltage silently, that's clearly a bad idea - the devices
> using the supply are going to get very upset when the power gets removed
> just because they changed the voltage.  Instead implement a custom set
> operation that returns an error if the user attempts to change the
> voltage while the regualtor is enabled.

Makes perfect sense. I will change the operation to this.

Br,
Matti Vaittinen

Re: [PATCH 1/7] fs: allow per-device dax status checking for filesystems

[Darrick J. Wong]

On Thu, May 24, 2018 at 08:55:12PM -0600, Ross Zwisler wrote:
> From: "Darrick J. Wong" 
> 
> Remove __bdev_dax_supported and change to bdev_dax_supported that takes a
> bdev parameter.  This enables multi-device filesystems like xfs to check
> that a dax device can work for the particular filesystem.  Once that's
> in place, actually fix all the parts of XFS where we need to be able to
> distinguish between datadev and rtdev.
> 
> This patch fixes the problem where we screw up the dax support checking
> in xfs if the datadev and rtdev have different dax capabilities.
> 
> Signed-off-by: Darrick J. Wong 
> Signed-off-by: Ross Zwisler 

Reviewed-by: Darr...oh, I'm not allowed to do that, am I?

Would you mind (re)sending this to the xfs list so that someone else can
review it?

--D

> ---
>  drivers/dax/super.c | 30 +++---
>  fs/ext2/super.c |  2 +-
>  fs/ext4/super.c |  2 +-
>  fs/xfs/xfs_ioctl.c  |  3 ++-
>  fs/xfs/xfs_iops.c   | 30 +-
>  fs/xfs/xfs_super.c  | 10 --
>  include/linux/dax.h | 10 +++---
>  7 files changed, 55 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index 2b2332b605e4..9206539c8330 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -73,8 +73,8 @@ EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev);
>  #endif
>  
>  /**
> - * __bdev_dax_supported() - Check if the device supports dax for filesystem
> - * @sb: The superblock of the device
> + * bdev_dax_supported() - Check if the device supports dax for filesystem
> + * @bdev: block device to check
>   * @blocksize: The block size of the device
>   *
>   * This is a library function for filesystems to check if the block device
> @@ -82,33 +82,33 @@ EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev);
>   *
>   * Return: negative errno if unsupported, 0 if supported.
>   */
> -int __bdev_dax_supported(struct super_block *sb, int blocksize)
> +int bdev_dax_supported(struct block_device *bdev, int blocksize)
>  {
> - struct block_device *bdev = sb->s_bdev;
>   struct dax_device *dax_dev;
>   pgoff_t pgoff;
>   int err, id;
>   void *kaddr;
>   pfn_t pfn;
>   long len;
> + char buf[BDEVNAME_SIZE];
>  
>   if (blocksize != PAGE_SIZE) {
> - pr_debug("VFS (%s): error: unsupported blocksize for dax\n",
> - sb->s_id);
> + pr_debug("%s: error: unsupported blocksize for dax\n",
> + bdevname(bdev, buf));
>   return -EINVAL;
>   }
>  
>   err = bdev_dax_pgoff(bdev, 0, PAGE_SIZE, );
>   if (err) {
> - pr_debug("VFS (%s): error: unaligned partition for dax\n",
> - sb->s_id);
> + pr_debug("%s: error: unaligned partition for dax\n",
> + bdevname(bdev, buf));
>   return err;
>   }
>  
>   dax_dev = dax_get_by_host(bdev->bd_disk->disk_name);
>   if (!dax_dev) {
> - pr_debug("VFS (%s): error: device does not support dax\n",
> - sb->s_id);
> + pr_debug("%s: error: device does not support dax\n",
> + bdevname(bdev, buf));
>   return -EOPNOTSUPP;
>   }
>  
> @@ -119,8 +119,8 @@ int __bdev_dax_supported(struct super_block *sb, int 
> blocksize)
>   put_dax(dax_dev);
>  
>   if (len < 1) {
> - pr_debug("VFS (%s): error: dax access failed (%ld)\n",
> - sb->s_id, len);
> + pr_debug("%s: error: dax access failed (%ld)\n",
> + bdevname(bdev, buf), len);
>   return len < 0 ? len : -EIO;
>   }
>  
> @@ -137,14 +137,14 @@ int __bdev_dax_supported(struct super_block *sb, int 
> blocksize)
>   } else if (pfn_t_devmap(pfn)) {
>   /* pass */;
>   } else {
> - pr_debug("VFS (%s): error: dax support not enabled\n",
> - sb->s_id);
> + pr_debug("%s: error: dax support not enabled\n",
> + bdevname(bdev, buf));
>   return -EOPNOTSUPP;
>   }
>  
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(__bdev_dax_supported);
> +EXPORT_SYMBOL_GPL(bdev_dax_supported);
>  #endif
>  
>  enum dax_device_flags {
> diff --git a/fs/ext2/super.c b/fs/ext2/super.c
> index de1694512f1f..9627c3054b5c 100644
> --- a/fs/ext2/super.c
> +++ b/fs/ext2/super.c
> @@ -961,7 +961,7 @@ static int ext2_fill_super(struct super_block *sb, void 
> *data, int silent)
>   blocksize = BLOCK_SIZE << le32_to_cpu(sbi->s_es->s_log_block_size);
>  
>   if (sbi->s_mount_opt & EXT2_MOUNT_DAX) {
> - err = bdev_dax_supported(sb, blocksize);
> + err = bdev_dax_supported(sb->s_bdev, blocksize);
>   if (err) {
>   ext2_msg(sb, KERN_ERR,
> 

Re: [PATCH 1/7] fs: allow per-device dax status checking for filesystems

[Darrick J. Wong]

On Thu, May 24, 2018 at 08:55:12PM -0600, Ross Zwisler wrote:
> From: "Darrick J. Wong" 
> 
> Remove __bdev_dax_supported and change to bdev_dax_supported that takes a
> bdev parameter.  This enables multi-device filesystems like xfs to check
> that a dax device can work for the particular filesystem.  Once that's
> in place, actually fix all the parts of XFS where we need to be able to
> distinguish between datadev and rtdev.
> 
> This patch fixes the problem where we screw up the dax support checking
> in xfs if the datadev and rtdev have different dax capabilities.
> 
> Signed-off-by: Darrick J. Wong 
> Signed-off-by: Ross Zwisler 

Reviewed-by: Darr...oh, I'm not allowed to do that, am I?

Would you mind (re)sending this to the xfs list so that someone else can
review it?

--D

> ---
>  drivers/dax/super.c | 30 +++---
>  fs/ext2/super.c |  2 +-
>  fs/ext4/super.c |  2 +-
>  fs/xfs/xfs_ioctl.c  |  3 ++-
>  fs/xfs/xfs_iops.c   | 30 +-
>  fs/xfs/xfs_super.c  | 10 --
>  include/linux/dax.h | 10 +++---
>  7 files changed, 55 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index 2b2332b605e4..9206539c8330 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -73,8 +73,8 @@ EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev);
>  #endif
>  
>  /**
> - * __bdev_dax_supported() - Check if the device supports dax for filesystem
> - * @sb: The superblock of the device
> + * bdev_dax_supported() - Check if the device supports dax for filesystem
> + * @bdev: block device to check
>   * @blocksize: The block size of the device
>   *
>   * This is a library function for filesystems to check if the block device
> @@ -82,33 +82,33 @@ EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev);
>   *
>   * Return: negative errno if unsupported, 0 if supported.
>   */
> -int __bdev_dax_supported(struct super_block *sb, int blocksize)
> +int bdev_dax_supported(struct block_device *bdev, int blocksize)
>  {
> - struct block_device *bdev = sb->s_bdev;
>   struct dax_device *dax_dev;
>   pgoff_t pgoff;
>   int err, id;
>   void *kaddr;
>   pfn_t pfn;
>   long len;
> + char buf[BDEVNAME_SIZE];
>  
>   if (blocksize != PAGE_SIZE) {
> - pr_debug("VFS (%s): error: unsupported blocksize for dax\n",
> - sb->s_id);
> + pr_debug("%s: error: unsupported blocksize for dax\n",
> + bdevname(bdev, buf));
>   return -EINVAL;
>   }
>  
>   err = bdev_dax_pgoff(bdev, 0, PAGE_SIZE, );
>   if (err) {
> - pr_debug("VFS (%s): error: unaligned partition for dax\n",
> - sb->s_id);
> + pr_debug("%s: error: unaligned partition for dax\n",
> + bdevname(bdev, buf));
>   return err;
>   }
>  
>   dax_dev = dax_get_by_host(bdev->bd_disk->disk_name);
>   if (!dax_dev) {
> - pr_debug("VFS (%s): error: device does not support dax\n",
> - sb->s_id);
> + pr_debug("%s: error: device does not support dax\n",
> + bdevname(bdev, buf));
>   return -EOPNOTSUPP;
>   }
>  
> @@ -119,8 +119,8 @@ int __bdev_dax_supported(struct super_block *sb, int 
> blocksize)
>   put_dax(dax_dev);
>  
>   if (len < 1) {
> - pr_debug("VFS (%s): error: dax access failed (%ld)\n",
> - sb->s_id, len);
> + pr_debug("%s: error: dax access failed (%ld)\n",
> + bdevname(bdev, buf), len);
>   return len < 0 ? len : -EIO;
>   }
>  
> @@ -137,14 +137,14 @@ int __bdev_dax_supported(struct super_block *sb, int 
> blocksize)
>   } else if (pfn_t_devmap(pfn)) {
>   /* pass */;
>   } else {
> - pr_debug("VFS (%s): error: dax support not enabled\n",
> - sb->s_id);
> + pr_debug("%s: error: dax support not enabled\n",
> + bdevname(bdev, buf));
>   return -EOPNOTSUPP;
>   }
>  
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(__bdev_dax_supported);
> +EXPORT_SYMBOL_GPL(bdev_dax_supported);
>  #endif
>  
>  enum dax_device_flags {
> diff --git a/fs/ext2/super.c b/fs/ext2/super.c
> index de1694512f1f..9627c3054b5c 100644
> --- a/fs/ext2/super.c
> +++ b/fs/ext2/super.c
> @@ -961,7 +961,7 @@ static int ext2_fill_super(struct super_block *sb, void 
> *data, int silent)
>   blocksize = BLOCK_SIZE << le32_to_cpu(sbi->s_es->s_log_block_size);
>  
>   if (sbi->s_mount_opt & EXT2_MOUNT_DAX) {
> - err = bdev_dax_supported(sb, blocksize);
> + err = bdev_dax_supported(sb->s_bdev, blocksize);
>   if (err) {
>   ext2_msg(sb, KERN_ERR,
>   "DAX unsupported by block device. Turning off 
> 

Re: [PATCH 2/7] dax: change bdev_dax_supported() to support boolean returns

[Darrick J. Wong]

On Thu, May 24, 2018 at 08:55:13PM -0600, Ross Zwisler wrote:
> From: Dave Jiang 
> 
> The function return values are confusing with the way the function is
> named. We expect a true or false return value but it actually returns
> 0/-errno.  This makes the code very confusing. Changing the return values
> to return a bool where if DAX is supported then return true and no DAX
> support returns false.
> 
> Signed-off-by: Dave Jiang 
> Signed-off-by: Ross Zwisler 

Looks ok,
Reviewed-by: Darrick J. Wong 

--D

> ---
>  drivers/dax/super.c | 16 
>  fs/ext2/super.c |  3 +--
>  fs/ext4/super.c |  3 +--
>  fs/xfs/xfs_ioctl.c  |  4 ++--
>  fs/xfs/xfs_super.c  | 12 ++--
>  include/linux/dax.h |  6 +++---
>  6 files changed, 21 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index 9206539c8330..e5447eddecf8 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -80,9 +80,9 @@ EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev);
>   * This is a library function for filesystems to check if the block device
>   * can be mounted with dax option.
>   *
> - * Return: negative errno if unsupported, 0 if supported.
> + * Return: true if supported, false if unsupported
>   */
> -int bdev_dax_supported(struct block_device *bdev, int blocksize)
> +bool bdev_dax_supported(struct block_device *bdev, int blocksize)
>  {
>   struct dax_device *dax_dev;
>   pgoff_t pgoff;
> @@ -95,21 +95,21 @@ int bdev_dax_supported(struct block_device *bdev, int 
> blocksize)
>   if (blocksize != PAGE_SIZE) {
>   pr_debug("%s: error: unsupported blocksize for dax\n",
>   bdevname(bdev, buf));
> - return -EINVAL;
> + return false;
>   }
>  
>   err = bdev_dax_pgoff(bdev, 0, PAGE_SIZE, );
>   if (err) {
>   pr_debug("%s: error: unaligned partition for dax\n",
>   bdevname(bdev, buf));
> - return err;
> + return false;
>   }
>  
>   dax_dev = dax_get_by_host(bdev->bd_disk->disk_name);
>   if (!dax_dev) {
>   pr_debug("%s: error: device does not support dax\n",
>   bdevname(bdev, buf));
> - return -EOPNOTSUPP;
> + return false;
>   }
>  
>   id = dax_read_lock();
> @@ -121,7 +121,7 @@ int bdev_dax_supported(struct block_device *bdev, int 
> blocksize)
>   if (len < 1) {
>   pr_debug("%s: error: dax access failed (%ld)\n",
>   bdevname(bdev, buf), len);
> - return len < 0 ? len : -EIO;
> + return false;
>   }
>  
>   if (IS_ENABLED(CONFIG_FS_DAX_LIMITED) && pfn_t_special(pfn)) {
> @@ -139,10 +139,10 @@ int bdev_dax_supported(struct block_device *bdev, int 
> blocksize)
>   } else {
>   pr_debug("%s: error: dax support not enabled\n",
>   bdevname(bdev, buf));
> - return -EOPNOTSUPP;
> + return false;
>   }
>  
> - return 0;
> + return true;
>  }
>  EXPORT_SYMBOL_GPL(bdev_dax_supported);
>  #endif
> diff --git a/fs/ext2/super.c b/fs/ext2/super.c
> index 9627c3054b5c..c09289a42dc5 100644
> --- a/fs/ext2/super.c
> +++ b/fs/ext2/super.c
> @@ -961,8 +961,7 @@ static int ext2_fill_super(struct super_block *sb, void 
> *data, int silent)
>   blocksize = BLOCK_SIZE << le32_to_cpu(sbi->s_es->s_log_block_size);
>  
>   if (sbi->s_mount_opt & EXT2_MOUNT_DAX) {
> - err = bdev_dax_supported(sb->s_bdev, blocksize);
> - if (err) {
> + if (!bdev_dax_supported(sb->s_bdev, blocksize)) {
>   ext2_msg(sb, KERN_ERR,
>   "DAX unsupported by block device. Turning off 
> DAX.");
>   sbi->s_mount_opt &= ~EXT2_MOUNT_DAX;
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 089170e99895..2e1622907f4a 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3732,8 +3732,7 @@ static int ext4_fill_super(struct super_block *sb, void 
> *data, int silent)
>   " that may contain inline data");
>   sbi->s_mount_opt &= ~EXT4_MOUNT_DAX;
>   }
> - err = bdev_dax_supported(sb->s_bdev, blocksize);
> - if (err) {
> + if (!bdev_dax_supported(sb->s_bdev, blocksize)) {
>   ext4_msg(sb, KERN_ERR,
>   "DAX unsupported by block device. Turning off 
> DAX.");
>   sbi->s_mount_opt &= ~EXT4_MOUNT_DAX;
> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index 0effd46b965f..2c70a0a4f59f 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -1103,8 +1103,8 @@ xfs_ioctl_setattr_dax_invalidate(
>   if (fa->fsx_xflags & FS_XFLAG_DAX) {
>  

Re: [PATCH 2/7] dax: change bdev_dax_supported() to support boolean returns

[Darrick J. Wong]

On Thu, May 24, 2018 at 08:55:13PM -0600, Ross Zwisler wrote:
> From: Dave Jiang 
> 
> The function return values are confusing with the way the function is
> named. We expect a true or false return value but it actually returns
> 0/-errno.  This makes the code very confusing. Changing the return values
> to return a bool where if DAX is supported then return true and no DAX
> support returns false.
> 
> Signed-off-by: Dave Jiang 
> Signed-off-by: Ross Zwisler 

Looks ok,
Reviewed-by: Darrick J. Wong 

--D

> ---
>  drivers/dax/super.c | 16 
>  fs/ext2/super.c |  3 +--
>  fs/ext4/super.c |  3 +--
>  fs/xfs/xfs_ioctl.c  |  4 ++--
>  fs/xfs/xfs_super.c  | 12 ++--
>  include/linux/dax.h |  6 +++---
>  6 files changed, 21 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index 9206539c8330..e5447eddecf8 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -80,9 +80,9 @@ EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev);
>   * This is a library function for filesystems to check if the block device
>   * can be mounted with dax option.
>   *
> - * Return: negative errno if unsupported, 0 if supported.
> + * Return: true if supported, false if unsupported
>   */
> -int bdev_dax_supported(struct block_device *bdev, int blocksize)
> +bool bdev_dax_supported(struct block_device *bdev, int blocksize)
>  {
>   struct dax_device *dax_dev;
>   pgoff_t pgoff;
> @@ -95,21 +95,21 @@ int bdev_dax_supported(struct block_device *bdev, int 
> blocksize)
>   if (blocksize != PAGE_SIZE) {
>   pr_debug("%s: error: unsupported blocksize for dax\n",
>   bdevname(bdev, buf));
> - return -EINVAL;
> + return false;
>   }
>  
>   err = bdev_dax_pgoff(bdev, 0, PAGE_SIZE, );
>   if (err) {
>   pr_debug("%s: error: unaligned partition for dax\n",
>   bdevname(bdev, buf));
> - return err;
> + return false;
>   }
>  
>   dax_dev = dax_get_by_host(bdev->bd_disk->disk_name);
>   if (!dax_dev) {
>   pr_debug("%s: error: device does not support dax\n",
>   bdevname(bdev, buf));
> - return -EOPNOTSUPP;
> + return false;
>   }
>  
>   id = dax_read_lock();
> @@ -121,7 +121,7 @@ int bdev_dax_supported(struct block_device *bdev, int 
> blocksize)
>   if (len < 1) {
>   pr_debug("%s: error: dax access failed (%ld)\n",
>   bdevname(bdev, buf), len);
> - return len < 0 ? len : -EIO;
> + return false;
>   }
>  
>   if (IS_ENABLED(CONFIG_FS_DAX_LIMITED) && pfn_t_special(pfn)) {
> @@ -139,10 +139,10 @@ int bdev_dax_supported(struct block_device *bdev, int 
> blocksize)
>   } else {
>   pr_debug("%s: error: dax support not enabled\n",
>   bdevname(bdev, buf));
> - return -EOPNOTSUPP;
> + return false;
>   }
>  
> - return 0;
> + return true;
>  }
>  EXPORT_SYMBOL_GPL(bdev_dax_supported);
>  #endif
> diff --git a/fs/ext2/super.c b/fs/ext2/super.c
> index 9627c3054b5c..c09289a42dc5 100644
> --- a/fs/ext2/super.c
> +++ b/fs/ext2/super.c
> @@ -961,8 +961,7 @@ static int ext2_fill_super(struct super_block *sb, void 
> *data, int silent)
>   blocksize = BLOCK_SIZE << le32_to_cpu(sbi->s_es->s_log_block_size);
>  
>   if (sbi->s_mount_opt & EXT2_MOUNT_DAX) {
> - err = bdev_dax_supported(sb->s_bdev, blocksize);
> - if (err) {
> + if (!bdev_dax_supported(sb->s_bdev, blocksize)) {
>   ext2_msg(sb, KERN_ERR,
>   "DAX unsupported by block device. Turning off 
> DAX.");
>   sbi->s_mount_opt &= ~EXT2_MOUNT_DAX;
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 089170e99895..2e1622907f4a 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3732,8 +3732,7 @@ static int ext4_fill_super(struct super_block *sb, void 
> *data, int silent)
>   " that may contain inline data");
>   sbi->s_mount_opt &= ~EXT4_MOUNT_DAX;
>   }
> - err = bdev_dax_supported(sb->s_bdev, blocksize);
> - if (err) {
> + if (!bdev_dax_supported(sb->s_bdev, blocksize)) {
>   ext4_msg(sb, KERN_ERR,
>   "DAX unsupported by block device. Turning off 
> DAX.");
>   sbi->s_mount_opt &= ~EXT4_MOUNT_DAX;
> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index 0effd46b965f..2c70a0a4f59f 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -1103,8 +1103,8 @@ xfs_ioctl_setattr_dax_invalidate(
>   if (fa->fsx_xflags & FS_XFLAG_DAX) {
>   if (!(S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode)))
>   return 

Re: [PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries

[Manivannan Sadhasivam]

Hi Andreas,

On Fri, May 25, 2018 at 06:12:00AM +0200, Andreas Färber wrote:
> Am 23.05.2018 um 10:40 schrieb Linus Walleij:
> > On Sun, May 20, 2018 at 7:17 AM, Manivannan Sadhasivam
> >  wrote:
> > 
> >> Add S900 pinctrl entries under ARCH_ACTIONS
> >>
> >> Signed-off-by: Manivannan Sadhasivam 
> > 
> > Patch applied tentatively so we have some maintenance entry for this.
> > 
> > Andreas expressed concerns about the driver earlier, so he might want it
> > split from the platform parts and have a separate entry for the pinctrl+GPIO
> > so Manivannan can maintain that part, also it makes sense to list
> > Manivannan as comaintainer of ARCH_ACTIONS with this in.
> > 
> > Andreas: how would you like to proceed?
> > 
> > I understand that I was a bit pushy or even rude in my last message
> > about the maintenance of this platform and the code structure of
> > the pin control driver. I am sorry if it caused any bad feelings on your
> > side :( social conflicts give me the creeps, I just try my best. Maybe
> > my best isn't always what it should be.
> 
> I fail to understand how splitting the MAINTAINERS section is going to
> help with the pinctrl conflict at hand? The problem is that instead of
> refactoring my S500 pinctrl driver to his liking, Mani has submitted a
> competing S900 pinctrl driver that you went on to merge. The human
> aspect is that merging his driver took the credit away from me having
> written the earlier pinctrl driver (based on my rtd1295 pinctrl driver).
> The practical aspect is that I can't drop my pinctrl driver from my work
> branch until there is equivalent functionality in the merged driver. I
> am lacking the time to rewrite S500 pin definitions on top of Mani's
> myself at this time, and I haven't seen S500 patches from him yet.
> 

I think we discussed this few more times before and I clearly mentioned this
pinctrl driver confilct in my old pinctrl series cover letter. If you had
submitted your pinctrl driver then Linus would had the option of picking up the
most robust one. But sadly you didn't had any time to complete and submit
yours and since there was only one pinctrl driver floating for Actions, Linus
went and merged mine.

Regarding the S500/S700 support, again I told you that my goal is to set up the
base driver for Actions OWL series SoC first and then adding support for every
other SoC's of the same family later. Now, I have succeeded in setting up the
clock, pinctrl and gpio drivers, so I can now work on extending support for
other SoC's as well.

FYI, I have ordered S700 based Cubieboard and will work on adding support for
that first. I still don't have access to S500 board yet since it is not
available on my region. Will find a way to get this asap.

> Also I had been investing efforts in explaining the upstreaming process
> to Actions, last in November. I see Thomas Liau and Jeff Chen missing in
> CC and I have not seen any Reviewed-by or Acked-by from anyone at
> Actions on this and the preceding series. There are more chips than the
> one on Linaro's 96board, so I would prefer to assure that the design
> works for all. Thus I am very critical of you applying the patches
> without waiting for review by Actions.
>

I don't think Actions would be interested in any upstreaming efforts. It
is our (comunity) responsibility to add support for that in order to
have our boards running mainline kernel and that's what we both have been
doing. Moreover I only saw once David Liau responded to your patchset and
there isn't much further. So how can you expect the subsystem maintainer's
to hold the patch series waiting for a so far silent SoC manufacturer's
response?

We should get move on and since my drivers are completely tested, we can
work on adding more SoC support later. And if something breaks on other
SoC platform, we can always modify the base driver accordingly.

> Other aspects are: The reason I wrote the pinctrl driver is that I
> experienced a UART TX issue on the Sparky board and was hoping a pinctrl
> driver might resolve that, but it didn't. So I still have a mix of
> boards where some are working and some are pretty unusable, without any
> clues on why.
> 
> That said, I don't object to having a separate MAINTAINERS section for
> the pinctrl driver(s) as long as I still get CC'ed on changes. We have
> wanted to add Mani as R for Actions overall, so that would probably mean
> adding me as R to an Actions pinctrl section, to avoid syncing the paths
> between two sections. I had previously felt that it does not make sense
> to list Mani as co-maintainer (M) for Actions overall since he can't tag
> and submit from my repo. And for the record I have offered him to take
> over which he didn't want to. I still hope to find some more time to
> review and queue his SPS patches, a driver that I have designed and thus
> understand and am much happier about the incremental additions there.
> 

Yes I 

Re: [PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries

[Manivannan Sadhasivam]

Hi Andreas,

On Fri, May 25, 2018 at 06:12:00AM +0200, Andreas Färber wrote:
> Am 23.05.2018 um 10:40 schrieb Linus Walleij:
> > On Sun, May 20, 2018 at 7:17 AM, Manivannan Sadhasivam
> >  wrote:
> > 
> >> Add S900 pinctrl entries under ARCH_ACTIONS
> >>
> >> Signed-off-by: Manivannan Sadhasivam 
> > 
> > Patch applied tentatively so we have some maintenance entry for this.
> > 
> > Andreas expressed concerns about the driver earlier, so he might want it
> > split from the platform parts and have a separate entry for the pinctrl+GPIO
> > so Manivannan can maintain that part, also it makes sense to list
> > Manivannan as comaintainer of ARCH_ACTIONS with this in.
> > 
> > Andreas: how would you like to proceed?
> > 
> > I understand that I was a bit pushy or even rude in my last message
> > about the maintenance of this platform and the code structure of
> > the pin control driver. I am sorry if it caused any bad feelings on your
> > side :( social conflicts give me the creeps, I just try my best. Maybe
> > my best isn't always what it should be.
> 
> I fail to understand how splitting the MAINTAINERS section is going to
> help with the pinctrl conflict at hand? The problem is that instead of
> refactoring my S500 pinctrl driver to his liking, Mani has submitted a
> competing S900 pinctrl driver that you went on to merge. The human
> aspect is that merging his driver took the credit away from me having
> written the earlier pinctrl driver (based on my rtd1295 pinctrl driver).
> The practical aspect is that I can't drop my pinctrl driver from my work
> branch until there is equivalent functionality in the merged driver. I
> am lacking the time to rewrite S500 pin definitions on top of Mani's
> myself at this time, and I haven't seen S500 patches from him yet.
> 

I think we discussed this few more times before and I clearly mentioned this
pinctrl driver confilct in my old pinctrl series cover letter. If you had
submitted your pinctrl driver then Linus would had the option of picking up the
most robust one. But sadly you didn't had any time to complete and submit
yours and since there was only one pinctrl driver floating for Actions, Linus
went and merged mine.

Regarding the S500/S700 support, again I told you that my goal is to set up the
base driver for Actions OWL series SoC first and then adding support for every
other SoC's of the same family later. Now, I have succeeded in setting up the
clock, pinctrl and gpio drivers, so I can now work on extending support for
other SoC's as well.

FYI, I have ordered S700 based Cubieboard and will work on adding support for
that first. I still don't have access to S500 board yet since it is not
available on my region. Will find a way to get this asap.

> Also I had been investing efforts in explaining the upstreaming process
> to Actions, last in November. I see Thomas Liau and Jeff Chen missing in
> CC and I have not seen any Reviewed-by or Acked-by from anyone at
> Actions on this and the preceding series. There are more chips than the
> one on Linaro's 96board, so I would prefer to assure that the design
> works for all. Thus I am very critical of you applying the patches
> without waiting for review by Actions.
>

I don't think Actions would be interested in any upstreaming efforts. It
is our (comunity) responsibility to add support for that in order to
have our boards running mainline kernel and that's what we both have been
doing. Moreover I only saw once David Liau responded to your patchset and
there isn't much further. So how can you expect the subsystem maintainer's
to hold the patch series waiting for a so far silent SoC manufacturer's
response?

We should get move on and since my drivers are completely tested, we can
work on adding more SoC support later. And if something breaks on other
SoC platform, we can always modify the base driver accordingly.

> Other aspects are: The reason I wrote the pinctrl driver is that I
> experienced a UART TX issue on the Sparky board and was hoping a pinctrl
> driver might resolve that, but it didn't. So I still have a mix of
> boards where some are working and some are pretty unusable, without any
> clues on why.
> 
> That said, I don't object to having a separate MAINTAINERS section for
> the pinctrl driver(s) as long as I still get CC'ed on changes. We have
> wanted to add Mani as R for Actions overall, so that would probably mean
> adding me as R to an Actions pinctrl section, to avoid syncing the paths
> between two sections. I had previously felt that it does not make sense
> to list Mani as co-maintainer (M) for Actions overall since he can't tag
> and submit from my repo. And for the record I have offered him to take
> over which he didn't want to. I still hope to find some more time to
> review and queue his SPS patches, a driver that I have designed and thus
> understand and am much happier about the incremental additions there.
> 

Yes I agree that you offered me to take the Maintainership once through
IRC 

[PATCH v1] arch/x86/kernel/pci-dma: Remove useless parameter of arch_dma_alloc_attrs

[Huaisheng Ye]

From: Huaisheng Ye 

arch_dma_alloc_attrs has parameter gfp which is not used at all.
Remove it.

Signed-off-by: Huaisheng Ye 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Christoph Hellwig 
Cc: Marek Szyprowski 
Cc: Robin Murphy 
Cc: Konrad Rzeszutek Wilk 
Cc: Andrew Morton 
Cc: Greg Kroah-Hartman 
Cc: Tom Lendacky 
Cc: Kate Stewart 
Cc: Randy Dunlap 
Cc: Michal Hocko 
---
 arch/x86/include/asm/dma-mapping.h | 2 +-
 arch/x86/kernel/pci-dma.c  | 2 +-
 include/linux/dma-mapping.h| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/dma-mapping.h 
b/arch/x86/include/asm/dma-mapping.h
index 89ce4bf..ef59747 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -33,7 +33,7 @@ static inline const struct dma_map_ops 
*get_arch_dma_ops(struct bus_type *bus)
 int arch_dma_supported(struct device *dev, u64 mask);
 #define arch_dma_supported arch_dma_supported
 
-bool arch_dma_alloc_attrs(struct device **dev, gfp_t *gfp);
+bool arch_dma_alloc_attrs(struct device **dev);
 #define arch_dma_alloc_attrs arch_dma_alloc_attrs
 
 #endif
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 77625b6..94d1a49 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -76,7 +76,7 @@ void __init pci_iommu_alloc(void)
}
 }
 
-bool arch_dma_alloc_attrs(struct device **dev, gfp_t *gfp)
+bool arch_dma_alloc_attrs(struct device **dev)
 {
if (!*dev)
*dev = _dma_fallback_dev;
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f8ab1c0..c80bb09 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -502,7 +502,7 @@ void *dma_common_pages_remap(struct page **pages, size_t 
size,
 #define dma_get_sgtable(d, t, v, h, s) dma_get_sgtable_attrs(d, t, v, h, s, 0)
 
 #ifndef arch_dma_alloc_attrs
-#define arch_dma_alloc_attrs(dev, flag)(true)
+#define arch_dma_alloc_attrs(dev)  (true)
 #endif
 
 static inline void *dma_alloc_attrs(struct device *dev, size_t size,
@@ -521,7 +521,7 @@ static inline void *dma_alloc_attrs(struct device *dev, 
size_t size,
/* let the implementation decide on the zone to allocate from: */
flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
 
-   if (!arch_dma_alloc_attrs(, ))
+   if (!arch_dma_alloc_attrs())
return NULL;
if (!ops->alloc)
return NULL;
-- 
1.8.3.1

[PATCH v1] arch/x86/kernel/pci-dma: Remove useless parameter of arch_dma_alloc_attrs

[Huaisheng Ye]

From: Huaisheng Ye 

arch_dma_alloc_attrs has parameter gfp which is not used at all.
Remove it.

Signed-off-by: Huaisheng Ye 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Christoph Hellwig 
Cc: Marek Szyprowski 
Cc: Robin Murphy 
Cc: Konrad Rzeszutek Wilk 
Cc: Andrew Morton 
Cc: Greg Kroah-Hartman 
Cc: Tom Lendacky 
Cc: Kate Stewart 
Cc: Randy Dunlap 
Cc: Michal Hocko 
---
 arch/x86/include/asm/dma-mapping.h | 2 +-
 arch/x86/kernel/pci-dma.c  | 2 +-
 include/linux/dma-mapping.h| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/dma-mapping.h 
b/arch/x86/include/asm/dma-mapping.h
index 89ce4bf..ef59747 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -33,7 +33,7 @@ static inline const struct dma_map_ops 
*get_arch_dma_ops(struct bus_type *bus)
 int arch_dma_supported(struct device *dev, u64 mask);
 #define arch_dma_supported arch_dma_supported
 
-bool arch_dma_alloc_attrs(struct device **dev, gfp_t *gfp);
+bool arch_dma_alloc_attrs(struct device **dev);
 #define arch_dma_alloc_attrs arch_dma_alloc_attrs
 
 #endif
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 77625b6..94d1a49 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -76,7 +76,7 @@ void __init pci_iommu_alloc(void)
}
 }
 
-bool arch_dma_alloc_attrs(struct device **dev, gfp_t *gfp)
+bool arch_dma_alloc_attrs(struct device **dev)
 {
if (!*dev)
*dev = _dma_fallback_dev;
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f8ab1c0..c80bb09 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -502,7 +502,7 @@ void *dma_common_pages_remap(struct page **pages, size_t 
size,
 #define dma_get_sgtable(d, t, v, h, s) dma_get_sgtable_attrs(d, t, v, h, s, 0)
 
 #ifndef arch_dma_alloc_attrs
-#define arch_dma_alloc_attrs(dev, flag)(true)
+#define arch_dma_alloc_attrs(dev)  (true)
 #endif
 
 static inline void *dma_alloc_attrs(struct device *dev, size_t size,
@@ -521,7 +521,7 @@ static inline void *dma_alloc_attrs(struct device *dev, 
size_t size,
/* let the implementation decide on the zone to allocate from: */
flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
 
-   if (!arch_dma_alloc_attrs(, ))
+   if (!arch_dma_alloc_attrs())
return NULL;
if (!ops->alloc)
return NULL;
-- 
1.8.3.1

Re: [PATCH v3 8/8] drm/mediatek: add third ddp path

[CK Hu]

Hi, Stu:

On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> From: Stu Hsieh 
> 
> This patch create third crtc by third ddp path
> 

Apply this patch before the patch 'Add support for mediatek SOC MT2712'
because this patch is necessary for mt2712.

> Signed-off-by: Stu Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index b32c4cc8d051..3a866e1d6af4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>   if (ret < 0)
>   goto err_component_unbind;
>  
> + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> +   private->data->third_len);

I think you should prevent doing this for mt8173 and mt2701 because that
two SoC has only two ddp path.

Regards,
CK

> + if (ret < 0)
> + goto err_component_unbind;
> +
>   /* Use OVL device for all DMA memory allocations */
>   np = private->comp_node[private->data->main_path[0]] ?:
>private->comp_node[private->data->ext_path[0]];

Re: [PATCH v3 8/8] drm/mediatek: add third ddp path

[CK Hu]

Hi, Stu:

On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> From: Stu Hsieh 
> 
> This patch create third crtc by third ddp path
> 

Apply this patch before the patch 'Add support for mediatek SOC MT2712'
because this patch is necessary for mt2712.

> Signed-off-by: Stu Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index b32c4cc8d051..3a866e1d6af4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>   if (ret < 0)
>   goto err_component_unbind;
>  
> + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> +   private->data->third_len);

I think you should prevent doing this for mt8173 and mt2701 because that
two SoC has only two ddp path.

Regards,
CK

> + if (ret < 0)
> + goto err_component_unbind;
> +
>   /* Use OVL device for all DMA memory allocations */
>   np = private->comp_node[private->data->main_path[0]] ?:
>private->comp_node[private->data->ext_path[0]];

Re: [PATCH] kdump: add default crashkernel reserve kernel config options

[Petr Tesarik]

V Thu, 24 May 2018 11:34:05 -0500
ebied...@xmission.com (Eric W. Biederman) napsáno:

> Petr Tesarik  writes:
> 
> 2> On Thu, 24 May 2018 09:49:05 +0800
> > Dave Young  wrote:
> >  
> >> Hi Petr,
> >> 
> >> On 05/23/18 at 10:22pm, Petr Tesarik wrote:
> >>[...]  
> >> > In short, if one size fits none, what good is it to hardcode that "one
> >> > size" into the kernel image?
> >> 
> >> I agreed with all the things that we can not know the exact memory
> >> requirement for 100% use cases.  But that does not means this is useless
> >> it is still useful for common use cases of no special and memory hog
> >> requirements as I mentioned in another reply it can simplify the kdump
> >> deployment for those people who do not need the special setup.  
> >
> > I still tend to disagree. This "common-case" reservation depends on
> > things that are defined by user space. It surely does not make it
> > easier to build a distribution kernel. Today, I get bug reports that
> > the number calculated and added to the boot loader configuration by the
> > installer is inaccurate. If I put a fixed number into a kernel config
> > option, I will start getting bugs that this number is incorrect (for
> > some systems).
> >  
> >> For example, if this is a workstation I just want to break into a shell
> >> to collect some panic info, then I just need a very minimal initrd, then
> >> the Kconfig will work just fine.  
> >
> > What is "a very minimal initrd"? Last time I had to make a significant
> > adjustment to the estimation for openSUSE, this was caused by growing
> > user-space requirements (systemd in this case, but I don't want to
> > start flamewars on that topic, please).
> >
> > Anyway, if you want to improve the "common case", then look how IBM
> > tries to solve it for firmware-assisted dump (fadump) on powerpc:
> >
> > https://patchwork.ozlabs.org/patch/905026/
> >
> > The main idea is:
> >  
> >> Instead of setting aside a significant chunk of memory nobody can use,
> >> [...] reserve a significant chunk of memory that the kernel is prevented
> >> from using [...], but applications are free to use it.  
> >
> > That works great, because user space pages are filtered out in the
> > common case, so they can be used freely by the panic kernel.  
> 
> They absolutely can not be used in the kdump case.
> 
> The kdump requirement is that they are pages no-one initiates any I/O
> to.  To avoid the problem of devices doing DMA as the new kernel starts
> and runs.

Good point. This means that memory reserved for this purpose would also
have to be excluded from allocations that may be eventually used for
DMA transfers.

>  Secondarily to avoid problems with cpus that refused to halt.

Let's face it - if some CPUs refused to halt, all bets are off. The
code running on such a CPU can break many other things besides memory,
most importantly, it may meddle with the HW registers of crucial
devices in the system. To be less abstract, I have seen a failure to
stop a CPU in the crashed kernel a few times, and the panic kernel
could never successfully save anything; it always crashed at boot or a
little bit later.

Anyway, of course we would still have to keep the current method,
because user pages are not always filtered. For example, a major SUSE
account runs a database in user space and also inspects its data
structures in case of a system crash.

Petr T

Re: [PATCH] kdump: add default crashkernel reserve kernel config options

[Petr Tesarik]

V Thu, 24 May 2018 11:34:05 -0500
ebied...@xmission.com (Eric W. Biederman) napsáno:

> Petr Tesarik  writes:
> 
> 2> On Thu, 24 May 2018 09:49:05 +0800
> > Dave Young  wrote:
> >  
> >> Hi Petr,
> >> 
> >> On 05/23/18 at 10:22pm, Petr Tesarik wrote:
> >>[...]  
> >> > In short, if one size fits none, what good is it to hardcode that "one
> >> > size" into the kernel image?
> >> 
> >> I agreed with all the things that we can not know the exact memory
> >> requirement for 100% use cases.  But that does not means this is useless
> >> it is still useful for common use cases of no special and memory hog
> >> requirements as I mentioned in another reply it can simplify the kdump
> >> deployment for those people who do not need the special setup.  
> >
> > I still tend to disagree. This "common-case" reservation depends on
> > things that are defined by user space. It surely does not make it
> > easier to build a distribution kernel. Today, I get bug reports that
> > the number calculated and added to the boot loader configuration by the
> > installer is inaccurate. If I put a fixed number into a kernel config
> > option, I will start getting bugs that this number is incorrect (for
> > some systems).
> >  
> >> For example, if this is a workstation I just want to break into a shell
> >> to collect some panic info, then I just need a very minimal initrd, then
> >> the Kconfig will work just fine.  
> >
> > What is "a very minimal initrd"? Last time I had to make a significant
> > adjustment to the estimation for openSUSE, this was caused by growing
> > user-space requirements (systemd in this case, but I don't want to
> > start flamewars on that topic, please).
> >
> > Anyway, if you want to improve the "common case", then look how IBM
> > tries to solve it for firmware-assisted dump (fadump) on powerpc:
> >
> > https://patchwork.ozlabs.org/patch/905026/
> >
> > The main idea is:
> >  
> >> Instead of setting aside a significant chunk of memory nobody can use,
> >> [...] reserve a significant chunk of memory that the kernel is prevented
> >> from using [...], but applications are free to use it.  
> >
> > That works great, because user space pages are filtered out in the
> > common case, so they can be used freely by the panic kernel.  
> 
> They absolutely can not be used in the kdump case.
> 
> The kdump requirement is that they are pages no-one initiates any I/O
> to.  To avoid the problem of devices doing DMA as the new kernel starts
> and runs.

Good point. This means that memory reserved for this purpose would also
have to be excluded from allocations that may be eventually used for
DMA transfers.

>  Secondarily to avoid problems with cpus that refused to halt.

Let's face it - if some CPUs refused to halt, all bets are off. The
code running on such a CPU can break many other things besides memory,
most importantly, it may meddle with the HW registers of crucial
devices in the system. To be less abstract, I have seen a failure to
stop a CPU in the crashed kernel a few times, and the panic kernel
could never successfully save anything; it always crashed at boot or a
little bit later.

Anyway, of course we would still have to keep the current method,
because user pages are not always filtered. For example, a major SUSE
account runs a database in user space and also inspects its data
structures in case of a system crash.

Petr T

Re: [RESEND PATCH V5 00/33] block: support multipage bvec

[Kent Overstreet]

On Fri, May 25, 2018 at 11:45:48AM +0800, Ming Lei wrote:
> Hi,
> 
> This patchset brings multipage bvec into block layer:

patch series looks sane to me. goddamn that's a lot of renaming.

Things are going to get interesting when we start sticking compound pages in the
page cache, there'll be some interesting questions of semantics to deal with
then but I think getting this will only help w.r.t. plumbing that through and
not dealing with 4k pages unnecessarily - but I think even if we were to decide
that merging in bio_add_page() is not the way to go when the upper layers are
passing compound pages around already, this patch series helps because
regardless at some point everything under generic_make_request() is going to
have to deal with segments that are more than one page, and this patch series
makes that happen. So incremental progress.

Jens, any objections to getting this in?

Re: [RESEND PATCH V5 00/33] block: support multipage bvec

[Kent Overstreet]

On Fri, May 25, 2018 at 11:45:48AM +0800, Ming Lei wrote:
> Hi,
> 
> This patchset brings multipage bvec into block layer:

patch series looks sane to me. goddamn that's a lot of renaming.

Things are going to get interesting when we start sticking compound pages in the
page cache, there'll be some interesting questions of semantics to deal with
then but I think getting this will only help w.r.t. plumbing that through and
not dealing with 4k pages unnecessarily - but I think even if we were to decide
that merging in bio_add_page() is not the way to go when the upper layers are
passing compound pages around already, this patch series helps because
regardless at some point everything under generic_make_request() is going to
have to deal with segments that are more than one page, and this patch series
makes that happen. So incremental progress.

Jens, any objections to getting this in?

Re: [PATCH v3 7/8] drm/mediatek: Add support for mediatek SOC MT2712

[CK Hu]

Hi, Stu:

I've some inline comment.

On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> From: Stu Hsieh 
> 
> This patch add support for the Mediatek MT2712 DISP subsystem.
> There are two OVL engine and three disp output in MT2712.
> 
> Signed-off-by: Stu Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 46 
> +++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  8 +++--
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 42 --
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  7 +++--
>  4 files changed, 94 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 0f568dd853d8..676726249ae0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -61,6 +61,24 @@
>  #define MT8173_MUTEX_MOD_DISP_PWM1   24
>  #define MT8173_MUTEX_MOD_DISP_OD 25
>  
> +#define MT2712_MUTEX_MOD_DISP_OVL0   11
> +#define MT2712_MUTEX_MOD_DISP_OVL1   12
> +#define MT2712_MUTEX_MOD_DISP_RDMA0  13
> +#define MT2712_MUTEX_MOD_DISP_RDMA1  14
> +#define MT2712_MUTEX_MOD_DISP_RDMA2  15
> +#define MT2712_MUTEX_MOD_DISP_WDMA0  16
> +#define MT2712_MUTEX_MOD_DISP_WDMA1  17
> +#define MT2712_MUTEX_MOD_DISP_COLOR0 18
> +#define MT2712_MUTEX_MOD_DISP_COLOR1 19
> +#define MT2712_MUTEX_MOD_DISP_AAL0   20
> +#define MT2712_MUTEX_MOD_DISP_UFOE   22
> +#define MT2712_MUTEX_MOD_DISP_PWM0   23
> +#define MT2712_MUTEX_MOD_DISP_PWM1   24
> +#define MT2712_MUTEX_MOD_DISP_PWM2   10
> +#define MT2712_MUTEX_MOD_DISP_OD025
> +#define MT2712_MUTEX_MOD2_DISP_AAL1  33
> +#define MT2712_MUTEX_MOD2_DISP_OD1   34

I would like this to be in the order by index.

> +
>  #define MT2701_MUTEX_MOD_DISP_OVL3
>  #define MT2701_MUTEX_MOD_DISP_WDMA   6
>  #define MT2701_MUTEX_MOD_DISP_COLOR  7
> @@ -75,6 +93,7 @@
>  
>  #define OVL0_MOUT_EN_COLOR0  0x1
>  #define OD_MOUT_EN_RDMA0 0x1
> +#define OD1_MOUT_EN_RDMA1BIT(16)
>  #define UFOE_MOUT_EN_DSI00x1
>  #define COLOR0_SEL_IN_OVL0   0x1
>  #define OVL1_MOUT_EN_COLOR1  0x1
> @@ -109,12 +128,32 @@ static const unsigned int 
> mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
>   [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
>  };
>  
> +static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
> + [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
> + [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
> + [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
> + [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
> + [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
> + [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
> + [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
> + [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
> + [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
> + [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
> + [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
> + [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
> +};
> +
>  static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> - [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> + [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,

Move this to the patch 'add ddp component AAL1'.

>   [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
>   [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
>   [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
> - [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
> + [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,

Move this to the patch 'add ddp component OD1'.

>   [DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
>   [DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
>   [DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
> @@ -139,7 +178,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id 
> cur,
>   } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
>   *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
>   value = OVL_MOUT_EN_RDMA;
> - } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
> + } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {

Move this to the patch 'add ddp component OD1'.

>   *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
>   value = OD_MOUT_EN_RDMA0;
> 

Re: [PATCH v3 7/8] drm/mediatek: Add support for mediatek SOC MT2712

[CK Hu]

Hi, Stu:

I've some inline comment.

On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> From: Stu Hsieh 
> 
> This patch add support for the Mediatek MT2712 DISP subsystem.
> There are two OVL engine and three disp output in MT2712.
> 
> Signed-off-by: Stu Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 46 
> +++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  8 +++--
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 42 --
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  7 +++--
>  4 files changed, 94 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 0f568dd853d8..676726249ae0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -61,6 +61,24 @@
>  #define MT8173_MUTEX_MOD_DISP_PWM1   24
>  #define MT8173_MUTEX_MOD_DISP_OD 25
>  
> +#define MT2712_MUTEX_MOD_DISP_OVL0   11
> +#define MT2712_MUTEX_MOD_DISP_OVL1   12
> +#define MT2712_MUTEX_MOD_DISP_RDMA0  13
> +#define MT2712_MUTEX_MOD_DISP_RDMA1  14
> +#define MT2712_MUTEX_MOD_DISP_RDMA2  15
> +#define MT2712_MUTEX_MOD_DISP_WDMA0  16
> +#define MT2712_MUTEX_MOD_DISP_WDMA1  17
> +#define MT2712_MUTEX_MOD_DISP_COLOR0 18
> +#define MT2712_MUTEX_MOD_DISP_COLOR1 19
> +#define MT2712_MUTEX_MOD_DISP_AAL0   20
> +#define MT2712_MUTEX_MOD_DISP_UFOE   22
> +#define MT2712_MUTEX_MOD_DISP_PWM0   23
> +#define MT2712_MUTEX_MOD_DISP_PWM1   24
> +#define MT2712_MUTEX_MOD_DISP_PWM2   10
> +#define MT2712_MUTEX_MOD_DISP_OD025
> +#define MT2712_MUTEX_MOD2_DISP_AAL1  33
> +#define MT2712_MUTEX_MOD2_DISP_OD1   34

I would like this to be in the order by index.

> +
>  #define MT2701_MUTEX_MOD_DISP_OVL3
>  #define MT2701_MUTEX_MOD_DISP_WDMA   6
>  #define MT2701_MUTEX_MOD_DISP_COLOR  7
> @@ -75,6 +93,7 @@
>  
>  #define OVL0_MOUT_EN_COLOR0  0x1
>  #define OD_MOUT_EN_RDMA0 0x1
> +#define OD1_MOUT_EN_RDMA1BIT(16)
>  #define UFOE_MOUT_EN_DSI00x1
>  #define COLOR0_SEL_IN_OVL0   0x1
>  #define OVL1_MOUT_EN_COLOR1  0x1
> @@ -109,12 +128,32 @@ static const unsigned int 
> mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
>   [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
>  };
>  
> +static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
> + [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
> + [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
> + [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
> + [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
> + [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
> + [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
> + [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
> + [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
> + [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
> + [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
> + [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
> + [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
> +};
> +
>  static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> - [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> + [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,

Move this to the patch 'add ddp component AAL1'.

>   [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
>   [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
>   [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
> - [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
> + [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,

Move this to the patch 'add ddp component OD1'.

>   [DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
>   [DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
>   [DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
> @@ -139,7 +178,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id 
> cur,
>   } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
>   *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
>   value = OVL_MOUT_EN_RDMA;
> - } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
> + } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {

Move this to the patch 'add ddp component OD1'.

>   *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
>   value = OD_MOUT_EN_RDMA0;
>   } else if (cur == DDP_COMPONENT_UFOE && next 

Re: [PATCH 2/2] mm: do not warn on offline nodes unless the specific node is explicitly requested

[Anshuman Khandual]

On 05/24/2018 01:30 PM, Michal Hocko wrote:
> On Thu 24-05-18 08:52:14, Anshuman Khandual wrote:
>> On 05/23/2018 07:36 PM, Michal Hocko wrote:
>>> On Wed 23-05-18 19:15:51, Anshuman Khandual wrote:
 On 05/23/2018 06:25 PM, Michal Hocko wrote:
> when adding memory to a node that is currently offline.
>
> The VM_WARN_ON is just too loud without a good reason. In this
> particular case we are doing
>   alloc_pages_node(node, GFP_KERNEL|__GFP_RETRY_MAYFAIL|__GFP_NOWARN, 
> order)
>
> so we do not insist on allocating from the given node (it is more a
> hint) so we can fall back to any other populated node and moreover we
> explicitly ask to not warn for the allocation failure.
>
> Soften the warning only to cases when somebody asks for the given node
> explicitly by __GFP_THISNODE.

 node hint passed here eventually goes into __alloc_pages_nodemask()
 function which then picks up the applicable zonelist irrespective of
 the GFP flag __GFP_THISNODE.
>>>
>>> __GFP_THISNODE should enforce the given node without any fallbacks
>>> unless something has changed recently.
>>
>> Right. I was just saying requiring given preferred node to be online
>> whose zonelist (hence allocation zone fallback order) is getting picked
>> up during allocation and warning when that is not online still makes
>> sense.
> 
> Why? We have a fallback and that is expected to be used. How does
> offline differ from depleted node from the semantical point of view?

Hmm, right. I agree. Offlined and depleted nodes are same from memory
allocation semantics point of view. It will proceed picking up next
available zones on the zonelist in the fallback order exactly in the
same fashion either way.

> 
>> We should only hide the warning if the allocation request has
>> __GFP_NOWARN.
>>
>>>
 Though we can go into zones of other
 nodes if the present node (whose zonelist got picked up) does not
 have any memory in it's zones. So warning here might not be without
 any reason.
>>>
>>> I am not sure I follow. Are you suggesting a different VM_WARN_ON?
>>
>> I am just suggesting this instead.
>>
>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
>> index 036846fc00a6..7f860ea29ec6 100644
>> --- a/include/linux/gfp.h
>> +++ b/include/linux/gfp.h
>> @@ -464,7 +464,7 @@ static inline struct page *
>>  __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
>>  {
>>  VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
>> -VM_WARN_ON(!node_online(nid));
>> +VM_WARN_ON(!(gfp_mask & __GFP_NOWARN) && !node_online(nid));
>>  
>>  return __alloc_pages(gfp_mask, order, nid);
>>  }
> 
> I have considered that but I fail to see why should we warn about
> regular GFP_KERNEL allocations as mentioned above. Just consider an
> allocation for the preffered node. Do you want to warn just because that
> node went offline?

As you have mentioned before, the semantics is similar when the node is
offlined compared to when its depleted. Right. I tend to agree with your
approach of not warning in such situations.

Re: [PATCH 2/2] mm: do not warn on offline nodes unless the specific node is explicitly requested

[Anshuman Khandual]

On 05/24/2018 01:30 PM, Michal Hocko wrote:
> On Thu 24-05-18 08:52:14, Anshuman Khandual wrote:
>> On 05/23/2018 07:36 PM, Michal Hocko wrote:
>>> On Wed 23-05-18 19:15:51, Anshuman Khandual wrote:
 On 05/23/2018 06:25 PM, Michal Hocko wrote:
> when adding memory to a node that is currently offline.
>
> The VM_WARN_ON is just too loud without a good reason. In this
> particular case we are doing
>   alloc_pages_node(node, GFP_KERNEL|__GFP_RETRY_MAYFAIL|__GFP_NOWARN, 
> order)
>
> so we do not insist on allocating from the given node (it is more a
> hint) so we can fall back to any other populated node and moreover we
> explicitly ask to not warn for the allocation failure.
>
> Soften the warning only to cases when somebody asks for the given node
> explicitly by __GFP_THISNODE.

 node hint passed here eventually goes into __alloc_pages_nodemask()
 function which then picks up the applicable zonelist irrespective of
 the GFP flag __GFP_THISNODE.
>>>
>>> __GFP_THISNODE should enforce the given node without any fallbacks
>>> unless something has changed recently.
>>
>> Right. I was just saying requiring given preferred node to be online
>> whose zonelist (hence allocation zone fallback order) is getting picked
>> up during allocation and warning when that is not online still makes
>> sense.
> 
> Why? We have a fallback and that is expected to be used. How does
> offline differ from depleted node from the semantical point of view?

Hmm, right. I agree. Offlined and depleted nodes are same from memory
allocation semantics point of view. It will proceed picking up next
available zones on the zonelist in the fallback order exactly in the
same fashion either way.

> 
>> We should only hide the warning if the allocation request has
>> __GFP_NOWARN.
>>
>>>
 Though we can go into zones of other
 nodes if the present node (whose zonelist got picked up) does not
 have any memory in it's zones. So warning here might not be without
 any reason.
>>>
>>> I am not sure I follow. Are you suggesting a different VM_WARN_ON?
>>
>> I am just suggesting this instead.
>>
>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
>> index 036846fc00a6..7f860ea29ec6 100644
>> --- a/include/linux/gfp.h
>> +++ b/include/linux/gfp.h
>> @@ -464,7 +464,7 @@ static inline struct page *
>>  __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
>>  {
>>  VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
>> -VM_WARN_ON(!node_online(nid));
>> +VM_WARN_ON(!(gfp_mask & __GFP_NOWARN) && !node_online(nid));
>>  
>>  return __alloc_pages(gfp_mask, order, nid);
>>  }
> 
> I have considered that but I fail to see why should we warn about
> regular GFP_KERNEL allocations as mentioned above. Just consider an
> allocation for the preffered node. Do you want to warn just because that
> node went offline?

As you have mentioned before, the semantics is similar when the node is
offlined compared to when its depleted. Right. I tend to agree with your
approach of not warning in such situations.

RE: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver

[Y.b. Lu]

This patch has a dependency which is now on staging git tree.
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next=7fd899fff5907dbb02089494102ef628988f2330


> -Original Message-
> From: Yangbo Lu [mailto:yangbo...@nxp.com]
> Sent: Friday, May 25, 2018 12:41 PM
> To: net...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Richard Cochran ;
> Claudiu Manoil ; Rob Herring 
> Cc: Y.b. Lu 
> Subject: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP
> clock driver
> 
> Added myself as maintainer for QorIQ PTP clock driver.
> Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's also maintain it under
> QorIQ PTP clock driver.
> 
> Signed-off-by: Yangbo Lu 
> ---
>  MAINTAINERS |   17 +
>  1 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4b65225..a71d4fa 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4411,12 +4411,6 @@ L: linux-kernel@vger.kernel.org
>  S:   Maintained
>  F:   drivers/staging/fsl-dpaa2/ethsw
> 
> -DPAA2 PTP CLOCK DRIVER
> -M:   Yangbo Lu 
> -L:   linux-kernel@vger.kernel.org
> -S:   Maintained
> -F:   drivers/staging/fsl-dpaa2/rtc
> -
>  DPT_I2O SCSI RAID DRIVER
>  M:   Adaptec OEM Raid Solutions 
>  L:   linux-s...@vger.kernel.org
> @@ -5648,7 +5642,6 @@ M:  Claudiu Manoil 
>  L:   net...@vger.kernel.org
>  S:   Maintained
>  F:   drivers/net/ethernet/freescale/gianfar*
> -X:   drivers/net/ethernet/freescale/gianfar_ptp.c
>  F:   Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> 
>  FREESCALE GPMI NAND DRIVER
> @@ -5695,6 +5688,15 @@ S: Maintained
>  F:   drivers/net/ethernet/freescale/fman
>  F:   Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> 
> +FREESCALE QORIQ PTP CLOCK DRIVER
> +M:   Yangbo Lu 
> +L:   linux-kernel@vger.kernel.org
> +S:   Maintained
> +F:   drivers/staging/fsl-dpaa2/rtc
> +F:   drivers/ptp/ptp_qoriq.c
> +F:   include/linux/fsl/ptp_qoriq.h
> +F:   Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
> +
>  FREESCALE QUAD SPI DRIVER
>  M:   Han Xu 
>  L:   linux-...@lists.infradead.org
> @@ -11429,7 +11431,6 @@ S:Maintained
>  W:
>   https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fli
> nuxptp.sourceforge.net%2F=02%7C01%7Cyangbo.lu%40nxp.com%7Cd7
> 840089f091467d11de08d5c1f9e801%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C636628201433493648=XhJjFQyrROZzMU7zUGsUkA
> BjJD%2BJ25q2Jq77vdHoco0%3D=0
>  F:   Documentation/ABI/testing/sysfs-ptp
>  F:   Documentation/ptp/*
> -F:   drivers/net/ethernet/freescale/gianfar_ptp.c
>  F:   drivers/net/phy/dp83640*
>  F:   drivers/ptp/*
>  F:   include/linux/ptp_cl*
> --
> 1.7.1

RE: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver

[Y.b. Lu]

This patch has a dependency which is now on staging git tree.
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next=7fd899fff5907dbb02089494102ef628988f2330


> -Original Message-
> From: Yangbo Lu [mailto:yangbo...@nxp.com]
> Sent: Friday, May 25, 2018 12:41 PM
> To: net...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Richard Cochran ;
> Claudiu Manoil ; Rob Herring 
> Cc: Y.b. Lu 
> Subject: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP
> clock driver
> 
> Added myself as maintainer for QorIQ PTP clock driver.
> Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's also maintain it under
> QorIQ PTP clock driver.
> 
> Signed-off-by: Yangbo Lu 
> ---
>  MAINTAINERS |   17 +
>  1 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4b65225..a71d4fa 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4411,12 +4411,6 @@ L: linux-kernel@vger.kernel.org
>  S:   Maintained
>  F:   drivers/staging/fsl-dpaa2/ethsw
> 
> -DPAA2 PTP CLOCK DRIVER
> -M:   Yangbo Lu 
> -L:   linux-kernel@vger.kernel.org
> -S:   Maintained
> -F:   drivers/staging/fsl-dpaa2/rtc
> -
>  DPT_I2O SCSI RAID DRIVER
>  M:   Adaptec OEM Raid Solutions 
>  L:   linux-s...@vger.kernel.org
> @@ -5648,7 +5642,6 @@ M:  Claudiu Manoil 
>  L:   net...@vger.kernel.org
>  S:   Maintained
>  F:   drivers/net/ethernet/freescale/gianfar*
> -X:   drivers/net/ethernet/freescale/gianfar_ptp.c
>  F:   Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> 
>  FREESCALE GPMI NAND DRIVER
> @@ -5695,6 +5688,15 @@ S: Maintained
>  F:   drivers/net/ethernet/freescale/fman
>  F:   Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> 
> +FREESCALE QORIQ PTP CLOCK DRIVER
> +M:   Yangbo Lu 
> +L:   linux-kernel@vger.kernel.org
> +S:   Maintained
> +F:   drivers/staging/fsl-dpaa2/rtc
> +F:   drivers/ptp/ptp_qoriq.c
> +F:   include/linux/fsl/ptp_qoriq.h
> +F:   Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
> +
>  FREESCALE QUAD SPI DRIVER
>  M:   Han Xu 
>  L:   linux-...@lists.infradead.org
> @@ -11429,7 +11431,6 @@ S:Maintained
>  W:
>   https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fli
> nuxptp.sourceforge.net%2F=02%7C01%7Cyangbo.lu%40nxp.com%7Cd7
> 840089f091467d11de08d5c1f9e801%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C636628201433493648=XhJjFQyrROZzMU7zUGsUkA
> BjJD%2BJ25q2Jq77vdHoco0%3D=0
>  F:   Documentation/ABI/testing/sysfs-ptp
>  F:   Documentation/ptp/*
> -F:   drivers/net/ethernet/freescale/gianfar_ptp.c
>  F:   drivers/net/phy/dp83640*
>  F:   drivers/ptp/*
>  F:   include/linux/ptp_cl*
> --
> 1.7.1

[PATCH 3/5] net: ethernet: gianfar_ethtool: get phc index through drvdata

[Yangbo Lu]

Global variable gfar_phc_index was used to get and store
phc index through gianfar_ptp driver. However gianfar_ptp
had been renamed as ptp_qoriq for QorIQ common PTP driver.
This gfar_phc_index doesn't work any more, and the phc index
is stored in drvdata now. This patch is to support getting
phc index through ptp_qoriq drvdata.

Signed-off-by: Yangbo Lu 
---
 drivers/net/ethernet/freescale/gianfar.h |3 --
 drivers/net/ethernet/freescale/gianfar_ethtool.c |   23 +
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.h 
b/drivers/net/ethernet/freescale/gianfar.h
index 5aa8147..8e42c02 100644
--- a/drivers/net/ethernet/freescale/gianfar.h
+++ b/drivers/net/ethernet/freescale/gianfar.h
@@ -1372,7 +1372,4 @@ struct filer_table {
struct gfar_filer_entry fe[MAX_FILER_CACHE_IDX + 20];
 };
 
-/* The gianfar_ptp module will set this variable */
-extern int gfar_phc_index;
-
 #endif /* __GIANFAR_H */
diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c 
b/drivers/net/ethernet/freescale/gianfar_ethtool.c
index a93e019..8cb98ca 100644
--- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
+++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
@@ -41,6 +41,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "gianfar.h"
 
@@ -1509,24 +1511,35 @@ static int gfar_get_nfc(struct net_device *dev, struct 
ethtool_rxnfc *cmd,
return ret;
 }
 
-int gfar_phc_index = -1;
-EXPORT_SYMBOL(gfar_phc_index);
-
 static int gfar_get_ts_info(struct net_device *dev,
struct ethtool_ts_info *info)
 {
struct gfar_private *priv = netdev_priv(dev);
+   struct platform_device *ptp_dev;
+   struct device_node *ptp_node;
+   struct qoriq_ptp *ptp = NULL;
+
+   info->phc_index = -1;
 
if (!(priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)) {
info->so_timestamping = SOF_TIMESTAMPING_RX_SOFTWARE |
SOF_TIMESTAMPING_SOFTWARE;
-   info->phc_index = -1;
return 0;
}
+
+   ptp_node = of_find_compatible_node(NULL, NULL, "fsl,etsec-ptp");
+   if (ptp_node) {
+   ptp_dev = of_find_device_by_node(ptp_node);
+   if (ptp_dev)
+   ptp = platform_get_drvdata(ptp_dev);
+   }
+
+   if (ptp)
+   info->phc_index = ptp->phc_index;
+
info->so_timestamping = SOF_TIMESTAMPING_TX_HARDWARE |
SOF_TIMESTAMPING_RX_HARDWARE |
SOF_TIMESTAMPING_RAW_HARDWARE;
-   info->phc_index = gfar_phc_index;
info->tx_types = (1 << HWTSTAMP_TX_OFF) |
 (1 << HWTSTAMP_TX_ON);
info->rx_filters = (1 << HWTSTAMP_FILTER_NONE) |
-- 
1.7.1

[PATCH 3/5] net: ethernet: gianfar_ethtool: get phc index through drvdata

[Yangbo Lu]

Global variable gfar_phc_index was used to get and store
phc index through gianfar_ptp driver. However gianfar_ptp
had been renamed as ptp_qoriq for QorIQ common PTP driver.
This gfar_phc_index doesn't work any more, and the phc index
is stored in drvdata now. This patch is to support getting
phc index through ptp_qoriq drvdata.

Signed-off-by: Yangbo Lu 
---
 drivers/net/ethernet/freescale/gianfar.h |3 --
 drivers/net/ethernet/freescale/gianfar_ethtool.c |   23 +
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.h 
b/drivers/net/ethernet/freescale/gianfar.h
index 5aa8147..8e42c02 100644
--- a/drivers/net/ethernet/freescale/gianfar.h
+++ b/drivers/net/ethernet/freescale/gianfar.h
@@ -1372,7 +1372,4 @@ struct filer_table {
struct gfar_filer_entry fe[MAX_FILER_CACHE_IDX + 20];
 };
 
-/* The gianfar_ptp module will set this variable */
-extern int gfar_phc_index;
-
 #endif /* __GIANFAR_H */
diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c 
b/drivers/net/ethernet/freescale/gianfar_ethtool.c
index a93e019..8cb98ca 100644
--- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
+++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
@@ -41,6 +41,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "gianfar.h"
 
@@ -1509,24 +1511,35 @@ static int gfar_get_nfc(struct net_device *dev, struct 
ethtool_rxnfc *cmd,
return ret;
 }
 
-int gfar_phc_index = -1;
-EXPORT_SYMBOL(gfar_phc_index);
-
 static int gfar_get_ts_info(struct net_device *dev,
struct ethtool_ts_info *info)
 {
struct gfar_private *priv = netdev_priv(dev);
+   struct platform_device *ptp_dev;
+   struct device_node *ptp_node;
+   struct qoriq_ptp *ptp = NULL;
+
+   info->phc_index = -1;
 
if (!(priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)) {
info->so_timestamping = SOF_TIMESTAMPING_RX_SOFTWARE |
SOF_TIMESTAMPING_SOFTWARE;
-   info->phc_index = -1;
return 0;
}
+
+   ptp_node = of_find_compatible_node(NULL, NULL, "fsl,etsec-ptp");
+   if (ptp_node) {
+   ptp_dev = of_find_device_by_node(ptp_node);
+   if (ptp_dev)
+   ptp = platform_get_drvdata(ptp_dev);
+   }
+
+   if (ptp)
+   info->phc_index = ptp->phc_index;
+
info->so_timestamping = SOF_TIMESTAMPING_TX_HARDWARE |
SOF_TIMESTAMPING_RX_HARDWARE |
SOF_TIMESTAMPING_RAW_HARDWARE;
-   info->phc_index = gfar_phc_index;
info->tx_types = (1 << HWTSTAMP_TX_OFF) |
 (1 << HWTSTAMP_TX_ON);
info->rx_filters = (1 << HWTSTAMP_FILTER_NONE) |
-- 
1.7.1

[PATCH 1/5] ptp: rework gianfar_ptp as QorIQ common PTP driver

[Yangbo Lu]

gianfar_ptp was the PTP clock driver for 1588 timer
module of Freescale QorIQ eTSEC (Enhanced Three-Speed
Ethernet Controllers) platforms. Actually QorIQ DPAA
(Data Path Acceleration Architecture) platforms is
also using the same 1588 timer module in hardware.

This patch is to rework gianfar_ptp as QorIQ common
PTP driver to support both DPAA and eTSEC. Moved
gianfar_ptp.c to drivers/ptp/, renamed it as
ptp_qoriq.c, and renamed many variables. There were
not any function changes.

Signed-off-by: Yangbo Lu 
---
 drivers/net/ethernet/freescale/Makefile|1 -
 drivers/ptp/Kconfig|   14 +-
 drivers/ptp/Makefile   |1 +
 .../freescale/gianfar_ptp.c => ptp/ptp_qoriq.c}|  320 ++--
 4 files changed, 174 insertions(+), 162 deletions(-)
 rename drivers/{net/ethernet/freescale/gianfar_ptp.c => ptp/ptp_qoriq.c} (58%)

diff --git a/drivers/net/ethernet/freescale/Makefile 
b/drivers/net/ethernet/freescale/Makefile
index ed8ad0f..0914a3e 100644
--- a/drivers/net/ethernet/freescale/Makefile
+++ b/drivers/net/ethernet/freescale/Makefile
@@ -14,7 +14,6 @@ obj-$(CONFIG_FS_ENET) += fs_enet/
 obj-$(CONFIG_FSL_PQ_MDIO) += fsl_pq_mdio.o
 obj-$(CONFIG_FSL_XGMAC_MDIO) += xgmac_mdio.o
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
-obj-$(CONFIG_PTP_1588_CLOCK_GIANFAR) += gianfar_ptp.o
 gianfar_driver-objs := gianfar.o \
gianfar_ethtool.o
 obj-$(CONFIG_UCC_GETH) += ucc_geth_driver.o
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index a21ad10..474c988 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -41,19 +41,19 @@ config PTP_1588_CLOCK_DTE
  To compile this driver as a module, choose M here: the module
  will be called ptp_dte.
 
-config PTP_1588_CLOCK_GIANFAR
-   tristate "Freescale eTSEC as PTP clock"
+config PTP_1588_CLOCK_QORIQ
+   tristate "Freescale QorIQ 1588 timer as PTP clock"
depends on GIANFAR
depends on PTP_1588_CLOCK
default y
help
- This driver adds support for using the eTSEC as a PTP
- clock. This clock is only useful if your PTP programs are
- getting hardware time stamps on the PTP Ethernet packets
- using the SO_TIMESTAMPING API.
+ This driver adds support for using the Freescale QorIQ 1588
+ timer as a PTP clock. This clock is only useful if your PTP
+ programs are getting hardware time stamps on the PTP Ethernet
+ packets using the SO_TIMESTAMPING API.
 
  To compile this driver as a module, choose M here: the module
- will be called gianfar_ptp.
+ will be called ptp_qoriq.
 
 config PTP_1588_CLOCK_IXP46X
tristate "Intel IXP46x as PTP clock"
diff --git a/drivers/ptp/Makefile b/drivers/ptp/Makefile
index fd28207..19efa9c 100644
--- a/drivers/ptp/Makefile
+++ b/drivers/ptp/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_PTP_1588_CLOCK_DTE)+= ptp_dte.o
 obj-$(CONFIG_PTP_1588_CLOCK_IXP46X)+= ptp_ixp46x.o
 obj-$(CONFIG_PTP_1588_CLOCK_PCH)   += ptp_pch.o
 obj-$(CONFIG_PTP_1588_CLOCK_KVM)   += ptp_kvm.o
+obj-$(CONFIG_PTP_1588_CLOCK_QORIQ) += ptp_qoriq.o
diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c 
b/drivers/ptp/ptp_qoriq.c
similarity index 58%
rename from drivers/net/ethernet/freescale/gianfar_ptp.c
rename to drivers/ptp/ptp_qoriq.c
index 9f8d4f8..5110cce 100644
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/ptp/ptp_qoriq.c
@@ -1,5 +1,5 @@
 /*
- * PTP 1588 clock using the eTSEC
+ * PTP 1588 clock for Freescale QorIQ 1588 timer
  *
  * Copyright (C) 2010 OMICRON electronics GmbH
  *
@@ -29,16 +29,15 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
-#include "gianfar.h"
-
 /*
- * gianfar ptp registers
+ * qoriq ptp registers
  * Generated by regen.tcl on Thu May 13 01:38:57 PM CEST 2010
  */
-struct gianfar_ptp_registers {
+struct qoriq_ptp_registers {
u32 tmr_ctrl; /* Timer control register */
u32 tmr_tevent;   /* Timestamp event register */
u32 tmr_temask;   /* Timer event mask register */
@@ -127,18 +126,19 @@ struct gianfar_ptp_registers {
 #define PRSC_OCK_MASK (0x)
 
 
-#define DRIVER "gianfar_ptp"
+#define DRIVER "ptp_qoriq"
 #define DEFAULT_CKSEL  1
 #define N_EXT_TS   2
-#define REG_SIZE   sizeof(struct gianfar_ptp_registers)
+#define REG_SIZE   sizeof(struct qoriq_ptp_registers)
 
-struct etsects {
-   struct gianfar_ptp_registers __iomem *regs;
+struct qoriq_ptp {
+   struct qoriq_ptp_registers __iomem *regs;
spinlock_t lock; /* protects regs */
struct ptp_clock *clock;
struct ptp_clock_info caps;
struct resource *rsrc;
int irq;
+   int phc_index;
u64 alarm_interval; /* for periodic alarm */
u64 alarm_value;
u32 tclk_period;  /* nanoseconds */
@@ -149,54 +149,67 @@ struct etsects {
u32 tmr_fiper2;
 };
 

[PATCH 1/5] ptp: rework gianfar_ptp as QorIQ common PTP driver

[Yangbo Lu]

gianfar_ptp was the PTP clock driver for 1588 timer
module of Freescale QorIQ eTSEC (Enhanced Three-Speed
Ethernet Controllers) platforms. Actually QorIQ DPAA
(Data Path Acceleration Architecture) platforms is
also using the same 1588 timer module in hardware.

This patch is to rework gianfar_ptp as QorIQ common
PTP driver to support both DPAA and eTSEC. Moved
gianfar_ptp.c to drivers/ptp/, renamed it as
ptp_qoriq.c, and renamed many variables. There were
not any function changes.

Signed-off-by: Yangbo Lu 
---
 drivers/net/ethernet/freescale/Makefile|1 -
 drivers/ptp/Kconfig|   14 +-
 drivers/ptp/Makefile   |1 +
 .../freescale/gianfar_ptp.c => ptp/ptp_qoriq.c}|  320 ++--
 4 files changed, 174 insertions(+), 162 deletions(-)
 rename drivers/{net/ethernet/freescale/gianfar_ptp.c => ptp/ptp_qoriq.c} (58%)

diff --git a/drivers/net/ethernet/freescale/Makefile 
b/drivers/net/ethernet/freescale/Makefile
index ed8ad0f..0914a3e 100644
--- a/drivers/net/ethernet/freescale/Makefile
+++ b/drivers/net/ethernet/freescale/Makefile
@@ -14,7 +14,6 @@ obj-$(CONFIG_FS_ENET) += fs_enet/
 obj-$(CONFIG_FSL_PQ_MDIO) += fsl_pq_mdio.o
 obj-$(CONFIG_FSL_XGMAC_MDIO) += xgmac_mdio.o
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
-obj-$(CONFIG_PTP_1588_CLOCK_GIANFAR) += gianfar_ptp.o
 gianfar_driver-objs := gianfar.o \
gianfar_ethtool.o
 obj-$(CONFIG_UCC_GETH) += ucc_geth_driver.o
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index a21ad10..474c988 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -41,19 +41,19 @@ config PTP_1588_CLOCK_DTE
  To compile this driver as a module, choose M here: the module
  will be called ptp_dte.
 
-config PTP_1588_CLOCK_GIANFAR
-   tristate "Freescale eTSEC as PTP clock"
+config PTP_1588_CLOCK_QORIQ
+   tristate "Freescale QorIQ 1588 timer as PTP clock"
depends on GIANFAR
depends on PTP_1588_CLOCK
default y
help
- This driver adds support for using the eTSEC as a PTP
- clock. This clock is only useful if your PTP programs are
- getting hardware time stamps on the PTP Ethernet packets
- using the SO_TIMESTAMPING API.
+ This driver adds support for using the Freescale QorIQ 1588
+ timer as a PTP clock. This clock is only useful if your PTP
+ programs are getting hardware time stamps on the PTP Ethernet
+ packets using the SO_TIMESTAMPING API.
 
  To compile this driver as a module, choose M here: the module
- will be called gianfar_ptp.
+ will be called ptp_qoriq.
 
 config PTP_1588_CLOCK_IXP46X
tristate "Intel IXP46x as PTP clock"
diff --git a/drivers/ptp/Makefile b/drivers/ptp/Makefile
index fd28207..19efa9c 100644
--- a/drivers/ptp/Makefile
+++ b/drivers/ptp/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_PTP_1588_CLOCK_DTE)+= ptp_dte.o
 obj-$(CONFIG_PTP_1588_CLOCK_IXP46X)+= ptp_ixp46x.o
 obj-$(CONFIG_PTP_1588_CLOCK_PCH)   += ptp_pch.o
 obj-$(CONFIG_PTP_1588_CLOCK_KVM)   += ptp_kvm.o
+obj-$(CONFIG_PTP_1588_CLOCK_QORIQ) += ptp_qoriq.o
diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c 
b/drivers/ptp/ptp_qoriq.c
similarity index 58%
rename from drivers/net/ethernet/freescale/gianfar_ptp.c
rename to drivers/ptp/ptp_qoriq.c
index 9f8d4f8..5110cce 100644
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/ptp/ptp_qoriq.c
@@ -1,5 +1,5 @@
 /*
- * PTP 1588 clock using the eTSEC
+ * PTP 1588 clock for Freescale QorIQ 1588 timer
  *
  * Copyright (C) 2010 OMICRON electronics GmbH
  *
@@ -29,16 +29,15 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
-#include "gianfar.h"
-
 /*
- * gianfar ptp registers
+ * qoriq ptp registers
  * Generated by regen.tcl on Thu May 13 01:38:57 PM CEST 2010
  */
-struct gianfar_ptp_registers {
+struct qoriq_ptp_registers {
u32 tmr_ctrl; /* Timer control register */
u32 tmr_tevent;   /* Timestamp event register */
u32 tmr_temask;   /* Timer event mask register */
@@ -127,18 +126,19 @@ struct gianfar_ptp_registers {
 #define PRSC_OCK_MASK (0x)
 
 
-#define DRIVER "gianfar_ptp"
+#define DRIVER "ptp_qoriq"
 #define DEFAULT_CKSEL  1
 #define N_EXT_TS   2
-#define REG_SIZE   sizeof(struct gianfar_ptp_registers)
+#define REG_SIZE   sizeof(struct qoriq_ptp_registers)
 
-struct etsects {
-   struct gianfar_ptp_registers __iomem *regs;
+struct qoriq_ptp {
+   struct qoriq_ptp_registers __iomem *regs;
spinlock_t lock; /* protects regs */
struct ptp_clock *clock;
struct ptp_clock_info caps;
struct resource *rsrc;
int irq;
+   int phc_index;
u64 alarm_interval; /* for periodic alarm */
u64 alarm_value;
u32 tclk_period;  /* nanoseconds */
@@ -149,54 +149,67 @@ struct etsects {
u32 tmr_fiper2;
 };
 
+static inline u32 

[PATCH 2/5] ptp_qoriq: move some definitions to header file

[Yangbo Lu]

This patch is to move some definitions in ptp_qoriq.c
to the header file.

Signed-off-by: Yangbo Lu 
---
 drivers/ptp/ptp_qoriq.c   |  132 +--
 include/linux/fsl/ptp_qoriq.h |  141 +
 2 files changed, 142 insertions(+), 131 deletions(-)
 create mode 100644 include/linux/fsl/ptp_qoriq.h

diff --git a/drivers/ptp/ptp_qoriq.c b/drivers/ptp/ptp_qoriq.c
index 5110cce..1468a16 100644
--- a/drivers/ptp/ptp_qoriq.c
+++ b/drivers/ptp/ptp_qoriq.c
@@ -28,139 +28,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
-#include 
-
-/*
- * qoriq ptp registers
- * Generated by regen.tcl on Thu May 13 01:38:57 PM CEST 2010
- */
-struct qoriq_ptp_registers {
-   u32 tmr_ctrl; /* Timer control register */
-   u32 tmr_tevent;   /* Timestamp event register */
-   u32 tmr_temask;   /* Timer event mask register */
-   u32 tmr_pevent;   /* Timestamp event register */
-   u32 tmr_pemask;   /* Timer event mask register */
-   u32 tmr_stat; /* Timestamp status register */
-   u32 tmr_cnt_h;/* Timer counter high register */
-   u32 tmr_cnt_l;/* Timer counter low register */
-   u32 tmr_add;  /* Timer drift compensation addend register */
-   u32 tmr_acc;  /* Timer accumulator register */
-   u32 tmr_prsc; /* Timer prescale */
-   u8  res1[4];
-   u32 tmroff_h; /* Timer offset high */
-   u32 tmroff_l; /* Timer offset low */
-   u8  res2[8];
-   u32 tmr_alarm1_h; /* Timer alarm 1 high register */
-   u32 tmr_alarm1_l; /* Timer alarm 1 high register */
-   u32 tmr_alarm2_h; /* Timer alarm 2 high register */
-   u32 tmr_alarm2_l; /* Timer alarm 2 high register */
-   u8  res3[48];
-   u32 tmr_fiper1;   /* Timer fixed period interval */
-   u32 tmr_fiper2;   /* Timer fixed period interval */
-   u32 tmr_fiper3;   /* Timer fixed period interval */
-   u8  res4[20];
-   u32 tmr_etts1_h;  /* Timestamp of general purpose external trigger */
-   u32 tmr_etts1_l;  /* Timestamp of general purpose external trigger */
-   u32 tmr_etts2_h;  /* Timestamp of general purpose external trigger */
-   u32 tmr_etts2_l;  /* Timestamp of general purpose external trigger */
-};
-
-/* Bit definitions for the TMR_CTRL register */
-#define ALM1P (1<<31) /* Alarm1 output polarity */
-#define ALM2P (1<<30) /* Alarm2 output polarity */
-#define FIPERST   (1<<28) /* FIPER start indication */
-#define PP1L  (1<<27) /* Fiper1 pulse loopback mode enabled. */
-#define PP2L  (1<<26) /* Fiper2 pulse loopback mode enabled. */
-#define TCLK_PERIOD_SHIFT (16) /* 1588 timer reference clock period. */
-#define TCLK_PERIOD_MASK  (0x3ff)
-#define RTPE  (1<<15) /* Record Tx Timestamp to PAL Enable. */
-#define FRD   (1<<14) /* FIPER Realignment Disable */
-#define ESFDP (1<<11) /* External Tx/Rx SFD Polarity. */
-#define ESFDE (1<<10) /* External Tx/Rx SFD Enable. */
-#define ETEP2 (1<<9) /* External trigger 2 edge polarity */
-#define ETEP1 (1<<8) /* External trigger 1 edge polarity */
-#define COPH  (1<<7) /* Generated clock output phase. */
-#define CIPH  (1<<6) /* External oscillator input clock phase 
*/
-#define TMSR  (1<<5) /* Timer soft reset. */
-#define BYP   (1<<3) /* Bypass drift compensated clock */
-#define TE(1<<2) /* 1588 timer enable. */
-#define CKSEL_SHIFT   (0)/* 1588 Timer reference clock source */
-#define CKSEL_MASK(0x3)
-
-/* Bit definitions for the TMR_TEVENT register */
-#define ETS2  (1<<25) /* External trigger 2 timestamp sampled 
*/
-#define ETS1  (1<<24) /* External trigger 1 timestamp sampled 
*/
-#define ALM2  (1<<17) /* Current time = alarm time register 2 
*/
-#define ALM1  (1<<16) /* Current time = alarm time register 1 
*/
-#define PP1   (1<<7)  /* periodic pulse generated on FIPER1 */
-#define PP2   (1<<6)  /* periodic pulse generated on FIPER2 */
-#define PP3   (1<<5)  /* periodic pulse generated on FIPER3 */
-
-/* Bit definitions for the TMR_TEMASK register */
-#define ETS2EN(1<<25) /* External trigger 2 timestamp enable */
-#define ETS1EN(1<<24) /* External trigger 1 timestamp enable */
-#define ALM2EN(1<<17) /* Timer ALM2 event enable */
-#define ALM1EN(1<<16) /* Timer ALM1 event enable */
-#define PP1EN (1<<7) /* Periodic pulse event 1 enable */
-#define PP2EN (1<<6) /* Periodic pulse event 2 enable */
-
-/* Bit definitions for the TMR_PEVENT register */
-#define TXP2  (1<<9) /* PTP 

[PATCH 2/5] ptp_qoriq: move some definitions to header file

[Yangbo Lu]

This patch is to move some definitions in ptp_qoriq.c
to the header file.

Signed-off-by: Yangbo Lu 
---
 drivers/ptp/ptp_qoriq.c   |  132 +--
 include/linux/fsl/ptp_qoriq.h |  141 +
 2 files changed, 142 insertions(+), 131 deletions(-)
 create mode 100644 include/linux/fsl/ptp_qoriq.h

diff --git a/drivers/ptp/ptp_qoriq.c b/drivers/ptp/ptp_qoriq.c
index 5110cce..1468a16 100644
--- a/drivers/ptp/ptp_qoriq.c
+++ b/drivers/ptp/ptp_qoriq.c
@@ -28,139 +28,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
-#include 
-
-/*
- * qoriq ptp registers
- * Generated by regen.tcl on Thu May 13 01:38:57 PM CEST 2010
- */
-struct qoriq_ptp_registers {
-   u32 tmr_ctrl; /* Timer control register */
-   u32 tmr_tevent;   /* Timestamp event register */
-   u32 tmr_temask;   /* Timer event mask register */
-   u32 tmr_pevent;   /* Timestamp event register */
-   u32 tmr_pemask;   /* Timer event mask register */
-   u32 tmr_stat; /* Timestamp status register */
-   u32 tmr_cnt_h;/* Timer counter high register */
-   u32 tmr_cnt_l;/* Timer counter low register */
-   u32 tmr_add;  /* Timer drift compensation addend register */
-   u32 tmr_acc;  /* Timer accumulator register */
-   u32 tmr_prsc; /* Timer prescale */
-   u8  res1[4];
-   u32 tmroff_h; /* Timer offset high */
-   u32 tmroff_l; /* Timer offset low */
-   u8  res2[8];
-   u32 tmr_alarm1_h; /* Timer alarm 1 high register */
-   u32 tmr_alarm1_l; /* Timer alarm 1 high register */
-   u32 tmr_alarm2_h; /* Timer alarm 2 high register */
-   u32 tmr_alarm2_l; /* Timer alarm 2 high register */
-   u8  res3[48];
-   u32 tmr_fiper1;   /* Timer fixed period interval */
-   u32 tmr_fiper2;   /* Timer fixed period interval */
-   u32 tmr_fiper3;   /* Timer fixed period interval */
-   u8  res4[20];
-   u32 tmr_etts1_h;  /* Timestamp of general purpose external trigger */
-   u32 tmr_etts1_l;  /* Timestamp of general purpose external trigger */
-   u32 tmr_etts2_h;  /* Timestamp of general purpose external trigger */
-   u32 tmr_etts2_l;  /* Timestamp of general purpose external trigger */
-};
-
-/* Bit definitions for the TMR_CTRL register */
-#define ALM1P (1<<31) /* Alarm1 output polarity */
-#define ALM2P (1<<30) /* Alarm2 output polarity */
-#define FIPERST   (1<<28) /* FIPER start indication */
-#define PP1L  (1<<27) /* Fiper1 pulse loopback mode enabled. */
-#define PP2L  (1<<26) /* Fiper2 pulse loopback mode enabled. */
-#define TCLK_PERIOD_SHIFT (16) /* 1588 timer reference clock period. */
-#define TCLK_PERIOD_MASK  (0x3ff)
-#define RTPE  (1<<15) /* Record Tx Timestamp to PAL Enable. */
-#define FRD   (1<<14) /* FIPER Realignment Disable */
-#define ESFDP (1<<11) /* External Tx/Rx SFD Polarity. */
-#define ESFDE (1<<10) /* External Tx/Rx SFD Enable. */
-#define ETEP2 (1<<9) /* External trigger 2 edge polarity */
-#define ETEP1 (1<<8) /* External trigger 1 edge polarity */
-#define COPH  (1<<7) /* Generated clock output phase. */
-#define CIPH  (1<<6) /* External oscillator input clock phase 
*/
-#define TMSR  (1<<5) /* Timer soft reset. */
-#define BYP   (1<<3) /* Bypass drift compensated clock */
-#define TE(1<<2) /* 1588 timer enable. */
-#define CKSEL_SHIFT   (0)/* 1588 Timer reference clock source */
-#define CKSEL_MASK(0x3)
-
-/* Bit definitions for the TMR_TEVENT register */
-#define ETS2  (1<<25) /* External trigger 2 timestamp sampled 
*/
-#define ETS1  (1<<24) /* External trigger 1 timestamp sampled 
*/
-#define ALM2  (1<<17) /* Current time = alarm time register 2 
*/
-#define ALM1  (1<<16) /* Current time = alarm time register 1 
*/
-#define PP1   (1<<7)  /* periodic pulse generated on FIPER1 */
-#define PP2   (1<<6)  /* periodic pulse generated on FIPER2 */
-#define PP3   (1<<5)  /* periodic pulse generated on FIPER3 */
-
-/* Bit definitions for the TMR_TEMASK register */
-#define ETS2EN(1<<25) /* External trigger 2 timestamp enable */
-#define ETS1EN(1<<24) /* External trigger 1 timestamp enable */
-#define ALM2EN(1<<17) /* Timer ALM2 event enable */
-#define ALM1EN(1<<16) /* Timer ALM1 event enable */
-#define PP1EN (1<<7) /* Periodic pulse event 1 enable */
-#define PP2EN (1<<6) /* Periodic pulse event 2 enable */
-
-/* Bit definitions for the TMR_PEVENT register */
-#define TXP2  (1<<9) /* PTP transmitted 

[PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver

[Yangbo Lu]

Added myself as maintainer for QorIQ PTP clock driver.
Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's
also maintain it under QorIQ PTP clock driver.

Signed-off-by: Yangbo Lu 
---
 MAINTAINERS |   17 +
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4b65225..a71d4fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4411,12 +4411,6 @@ L:   linux-kernel@vger.kernel.org
 S: Maintained
 F: drivers/staging/fsl-dpaa2/ethsw
 
-DPAA2 PTP CLOCK DRIVER
-M: Yangbo Lu 
-L: linux-kernel@vger.kernel.org
-S: Maintained
-F: drivers/staging/fsl-dpaa2/rtc
-
 DPT_I2O SCSI RAID DRIVER
 M: Adaptec OEM Raid Solutions 
 L: linux-s...@vger.kernel.org
@@ -5648,7 +5642,6 @@ M:Claudiu Manoil 
 L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/ethernet/freescale/gianfar*
-X: drivers/net/ethernet/freescale/gianfar_ptp.c
 F: Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
 
 FREESCALE GPMI NAND DRIVER
@@ -5695,6 +5688,15 @@ S:   Maintained
 F: drivers/net/ethernet/freescale/fman
 F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt
 
+FREESCALE QORIQ PTP CLOCK DRIVER
+M: Yangbo Lu 
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: drivers/staging/fsl-dpaa2/rtc
+F: drivers/ptp/ptp_qoriq.c
+F: include/linux/fsl/ptp_qoriq.h
+F: Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
+
 FREESCALE QUAD SPI DRIVER
 M: Han Xu 
 L: linux-...@lists.infradead.org
@@ -11429,7 +11431,6 @@ S:  Maintained
 W: http://linuxptp.sourceforge.net/
 F: Documentation/ABI/testing/sysfs-ptp
 F: Documentation/ptp/*
-F: drivers/net/ethernet/freescale/gianfar_ptp.c
 F: drivers/net/phy/dp83640*
 F: drivers/ptp/*
 F: include/linux/ptp_cl*
-- 
1.7.1

[PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver

[Yangbo Lu]

Added myself as maintainer for QorIQ PTP clock driver.
Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's
also maintain it under QorIQ PTP clock driver.

Signed-off-by: Yangbo Lu 
---
 MAINTAINERS |   17 +
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4b65225..a71d4fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4411,12 +4411,6 @@ L:   linux-kernel@vger.kernel.org
 S: Maintained
 F: drivers/staging/fsl-dpaa2/ethsw
 
-DPAA2 PTP CLOCK DRIVER
-M: Yangbo Lu 
-L: linux-kernel@vger.kernel.org
-S: Maintained
-F: drivers/staging/fsl-dpaa2/rtc
-
 DPT_I2O SCSI RAID DRIVER
 M: Adaptec OEM Raid Solutions 
 L: linux-s...@vger.kernel.org
@@ -5648,7 +5642,6 @@ M:Claudiu Manoil 
 L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/ethernet/freescale/gianfar*
-X: drivers/net/ethernet/freescale/gianfar_ptp.c
 F: Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
 
 FREESCALE GPMI NAND DRIVER
@@ -5695,6 +5688,15 @@ S:   Maintained
 F: drivers/net/ethernet/freescale/fman
 F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt
 
+FREESCALE QORIQ PTP CLOCK DRIVER
+M: Yangbo Lu 
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: drivers/staging/fsl-dpaa2/rtc
+F: drivers/ptp/ptp_qoriq.c
+F: include/linux/fsl/ptp_qoriq.h
+F: Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
+
 FREESCALE QUAD SPI DRIVER
 M: Han Xu 
 L: linux-...@lists.infradead.org
@@ -11429,7 +11431,6 @@ S:  Maintained
 W: http://linuxptp.sourceforge.net/
 F: Documentation/ABI/testing/sysfs-ptp
 F: Documentation/ptp/*
-F: drivers/net/ethernet/freescale/gianfar_ptp.c
 F: drivers/net/phy/dp83640*
 F: drivers/ptp/*
 F: include/linux/ptp_cl*
-- 
1.7.1

[PATCH 4/5] dt-bindings: ptp: add ptp-qoriq.txt

[Yangbo Lu]

This patch is to add a documentation for ptp_qoriq dt-bindings.
The description for ptp_qoriq dt-bindings was actually moved
from Documentation/devicetree/bindings/net/fsl-tsec-phy.txt,
since gianfar_ptp driver was moved to ptp_qoriq driver.

Signed-off-by: Yangbo Lu 
---
 .../devicetree/bindings/net/fsl-tsec-phy.txt   |   68 +---
 .../devicetree/bindings/ptp/ptp-qoriq.txt  |   69 
 2 files changed, 70 insertions(+), 67 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ptp/ptp-qoriq.txt

diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt 
b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index 79bf352..047bdf7 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -86,70 +86,4 @@ Example:
 
 * Gianfar PTP clock nodes
 
-General Properties:
-
-  - compatible   Should be "fsl,etsec-ptp"
-  - reg  Offset and length of the register set for the device
-  - interrupts   There should be at least two interrupts. Some devices
- have as many as four PTP related interrupts.
-
-Clock Properties:
-
-  - fsl,ckselTimer reference clock source.
-  - fsl,tclk-period  Timer reference clock period in nanoseconds.
-  - fsl,tmr-prsc Prescaler, divides the output clock.
-  - fsl,tmr-add  Frequency compensation value.
-  - fsl,tmr-fiper1   Fixed interval period pulse generator.
-  - fsl,tmr-fiper2   Fixed interval period pulse generator.
-  - fsl,max-adj  Maximum frequency adjustment in parts per billion.
-
-  These properties set the operational parameters for the PTP
-  clock. You must choose these carefully for the clock to work right.
-  Here is how to figure good values:
-
-  TimerOsc = selected reference clock   MHz
-  tclk_period  = desired clock period   nanoseconds
-  NominalFreq  = 1000 / tclk_period MHz
-  FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0)
-  tmr_add  = ceil(2^32 / FreqDivRatio)
-  OutputClock  = NominalFreq / tmr_prsc MHz
-  PulseWidth   = 1 / OutputClockmicroseconds
-  FiperFreq1   = desired frequency in Hz
-  FiperDiv1= 100 * OutputClock / FiperFreq1
-  tmr_fiper1   = tmr_prsc * tclk_period * FiperDiv1 - tclk_period
-  max_adj  = 10 * (FreqDivRatio - 1.0) - 1
-
-  The calculation for tmr_fiper2 is the same as for tmr_fiper1. The
-  driver expects that tmr_fiper1 will be correctly set to produce a 1
-  Pulse Per Second (PPS) signal, since this will be offered to the PPS
-  subsystem to synchronize the Linux clock.
-
-  Reference clock source is determined by the value, which is holded
-  in CKSEL bits in TMR_CTRL register. "fsl,cksel" property keeps the
-  value, which will be directly written in those bits, that is why,
-  according to reference manual, the next clock sources can be used:
-
-  <0> - external high precision timer reference clock (TSEC_TMR_CLK
-input is used for this purpose);
-  <1> - eTSEC system clock;
-  <2> - eTSEC1 transmit clock;
-  <3> - RTC clock input.
-
-  When this attribute is not used, eTSEC system clock will serve as
-  IEEE 1588 timer reference clock.
-
-Example:
-
-   ptp_clock@24e00 {
-   compatible = "fsl,etsec-ptp";
-   reg = <0x24E00 0xB0>;
-   interrupts = <12 0x8 13 0x8>;
-   interrupt-parent = <  >;
-   fsl,cksel   = <1>;
-   fsl,tclk-period = <10>;
-   fsl,tmr-prsc= <100>;
-   fsl,tmr-add = <0x99A4>;
-   fsl,tmr-fiper1  = <0x3B9AC9F6>;
-   fsl,tmr-fiper2  = <0x00018696>;
-   fsl,max-adj = <65998>;
-   };
+Refer to Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
diff --git a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt 
b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
new file mode 100644
index 000..0f569d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
@@ -0,0 +1,69 @@
+* Freescale QorIQ 1588 timer based PTP clock
+
+General Properties:
+
+  - compatible   Should be "fsl,etsec-ptp"
+  - reg  Offset and length of the register set for the device
+  - interrupts   There should be at least two interrupts. Some devices
+ have as many as four PTP related interrupts.
+
+Clock Properties:
+
+  - fsl,ckselTimer reference clock source.
+  - fsl,tclk-period  Timer reference clock period in nanoseconds.
+  - fsl,tmr-prsc Prescaler, divides the output clock.
+  - fsl,tmr-add  Frequency compensation value.
+  - fsl,tmr-fiper1   Fixed interval period pulse generator.
+  - fsl,tmr-fiper2   Fixed interval period pulse generator.
+  - fsl,max-adj  Maximum frequency adjustment in parts per billion.
+
+  These properties set the operational parameters for the PTP
+  clock. You must choose these carefully for the clock to 

Re: [RESEND PATCH V5 12/33] block: introduce bio_segments()

[Kent Overstreet]

On Fri, May 25, 2018 at 11:46:00AM +0800, Ming Lei wrote:
> There are still cases in which we need to use bio_segments() for get the
> number of segment, so introduce it.
> 
> Signed-off-by: Ming Lei 
> ---
>  include/linux/bio.h | 25 -
>  1 file changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/bio.h b/include/linux/bio.h
> index 08af9272687f..b24c00f99c9c 100644
> --- a/include/linux/bio.h
> +++ b/include/linux/bio.h
> @@ -227,9 +227,9 @@ static inline bool bio_rewind_iter(struct bio *bio, 
> struct bvec_iter *iter,
>  
>  #define bio_iter_last(bvec, iter) ((iter).bi_size == (bvec).bv_len)
>  
> -static inline unsigned bio_pages(struct bio *bio)
> +static inline unsigned __bio_elements(struct bio *bio, bool seg)

This is a rather silly helper function, there isn't any actual code that's
shared, everything's behind an if () statement. Just open code it in bio_pages()
and bio_segments()

>  {
> - unsigned segs = 0;
> + unsigned elems = 0;
>   struct bio_vec bv;
>   struct bvec_iter iter;
>  
> @@ -249,10 +249,25 @@ static inline unsigned bio_pages(struct bio *bio)
>   break;
>   }
>  
> - bio_for_each_page(bv, bio, iter)
> - segs++;
> + if (!seg) {
> + bio_for_each_page(bv, bio, iter)
> + elems++;
> + } else {
> + bio_for_each_segment(bv, bio, iter)
> + elems++;
> + }
> +
> + return elems;
> +}
> +
> +static inline unsigned bio_pages(struct bio *bio)
> +{
> + return __bio_elements(bio, false);
> +}
>  
> - return segs;
> +static inline unsigned bio_segments(struct bio *bio)
> +{
> + return __bio_elements(bio, true);
>  }
>  
>  /*
> -- 
> 2.9.5
> 

[PATCH 4/5] dt-bindings: ptp: add ptp-qoriq.txt

[Yangbo Lu]

This patch is to add a documentation for ptp_qoriq dt-bindings.
The description for ptp_qoriq dt-bindings was actually moved
from Documentation/devicetree/bindings/net/fsl-tsec-phy.txt,
since gianfar_ptp driver was moved to ptp_qoriq driver.

Signed-off-by: Yangbo Lu 
---
 .../devicetree/bindings/net/fsl-tsec-phy.txt   |   68 +---
 .../devicetree/bindings/ptp/ptp-qoriq.txt  |   69 
 2 files changed, 70 insertions(+), 67 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ptp/ptp-qoriq.txt

diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt 
b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index 79bf352..047bdf7 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -86,70 +86,4 @@ Example:
 
 * Gianfar PTP clock nodes
 
-General Properties:
-
-  - compatible   Should be "fsl,etsec-ptp"
-  - reg  Offset and length of the register set for the device
-  - interrupts   There should be at least two interrupts. Some devices
- have as many as four PTP related interrupts.
-
-Clock Properties:
-
-  - fsl,ckselTimer reference clock source.
-  - fsl,tclk-period  Timer reference clock period in nanoseconds.
-  - fsl,tmr-prsc Prescaler, divides the output clock.
-  - fsl,tmr-add  Frequency compensation value.
-  - fsl,tmr-fiper1   Fixed interval period pulse generator.
-  - fsl,tmr-fiper2   Fixed interval period pulse generator.
-  - fsl,max-adj  Maximum frequency adjustment in parts per billion.
-
-  These properties set the operational parameters for the PTP
-  clock. You must choose these carefully for the clock to work right.
-  Here is how to figure good values:
-
-  TimerOsc = selected reference clock   MHz
-  tclk_period  = desired clock period   nanoseconds
-  NominalFreq  = 1000 / tclk_period MHz
-  FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0)
-  tmr_add  = ceil(2^32 / FreqDivRatio)
-  OutputClock  = NominalFreq / tmr_prsc MHz
-  PulseWidth   = 1 / OutputClockmicroseconds
-  FiperFreq1   = desired frequency in Hz
-  FiperDiv1= 100 * OutputClock / FiperFreq1
-  tmr_fiper1   = tmr_prsc * tclk_period * FiperDiv1 - tclk_period
-  max_adj  = 10 * (FreqDivRatio - 1.0) - 1
-
-  The calculation for tmr_fiper2 is the same as for tmr_fiper1. The
-  driver expects that tmr_fiper1 will be correctly set to produce a 1
-  Pulse Per Second (PPS) signal, since this will be offered to the PPS
-  subsystem to synchronize the Linux clock.
-
-  Reference clock source is determined by the value, which is holded
-  in CKSEL bits in TMR_CTRL register. "fsl,cksel" property keeps the
-  value, which will be directly written in those bits, that is why,
-  according to reference manual, the next clock sources can be used:
-
-  <0> - external high precision timer reference clock (TSEC_TMR_CLK
-input is used for this purpose);
-  <1> - eTSEC system clock;
-  <2> - eTSEC1 transmit clock;
-  <3> - RTC clock input.
-
-  When this attribute is not used, eTSEC system clock will serve as
-  IEEE 1588 timer reference clock.
-
-Example:
-
-   ptp_clock@24e00 {
-   compatible = "fsl,etsec-ptp";
-   reg = <0x24E00 0xB0>;
-   interrupts = <12 0x8 13 0x8>;
-   interrupt-parent = <  >;
-   fsl,cksel   = <1>;
-   fsl,tclk-period = <10>;
-   fsl,tmr-prsc= <100>;
-   fsl,tmr-add = <0x99A4>;
-   fsl,tmr-fiper1  = <0x3B9AC9F6>;
-   fsl,tmr-fiper2  = <0x00018696>;
-   fsl,max-adj = <65998>;
-   };
+Refer to Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
diff --git a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt 
b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
new file mode 100644
index 000..0f569d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
@@ -0,0 +1,69 @@
+* Freescale QorIQ 1588 timer based PTP clock
+
+General Properties:
+
+  - compatible   Should be "fsl,etsec-ptp"
+  - reg  Offset and length of the register set for the device
+  - interrupts   There should be at least two interrupts. Some devices
+ have as many as four PTP related interrupts.
+
+Clock Properties:
+
+  - fsl,ckselTimer reference clock source.
+  - fsl,tclk-period  Timer reference clock period in nanoseconds.
+  - fsl,tmr-prsc Prescaler, divides the output clock.
+  - fsl,tmr-add  Frequency compensation value.
+  - fsl,tmr-fiper1   Fixed interval period pulse generator.
+  - fsl,tmr-fiper2   Fixed interval period pulse generator.
+  - fsl,max-adj  Maximum frequency adjustment in parts per billion.
+
+  These properties set the operational parameters for the PTP
+  clock. You must choose these carefully for the clock to work right.
+  Here is 

Re: [RESEND PATCH V5 12/33] block: introduce bio_segments()

[Kent Overstreet]

On Fri, May 25, 2018 at 11:46:00AM +0800, Ming Lei wrote:
> There are still cases in which we need to use bio_segments() for get the
> number of segment, so introduce it.
> 
> Signed-off-by: Ming Lei 
> ---
>  include/linux/bio.h | 25 -
>  1 file changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/bio.h b/include/linux/bio.h
> index 08af9272687f..b24c00f99c9c 100644
> --- a/include/linux/bio.h
> +++ b/include/linux/bio.h
> @@ -227,9 +227,9 @@ static inline bool bio_rewind_iter(struct bio *bio, 
> struct bvec_iter *iter,
>  
>  #define bio_iter_last(bvec, iter) ((iter).bi_size == (bvec).bv_len)
>  
> -static inline unsigned bio_pages(struct bio *bio)
> +static inline unsigned __bio_elements(struct bio *bio, bool seg)

This is a rather silly helper function, there isn't any actual code that's
shared, everything's behind an if () statement. Just open code it in bio_pages()
and bio_segments()

>  {
> - unsigned segs = 0;
> + unsigned elems = 0;
>   struct bio_vec bv;
>   struct bvec_iter iter;
>  
> @@ -249,10 +249,25 @@ static inline unsigned bio_pages(struct bio *bio)
>   break;
>   }
>  
> - bio_for_each_page(bv, bio, iter)
> - segs++;
> + if (!seg) {
> + bio_for_each_page(bv, bio, iter)
> + elems++;
> + } else {
> + bio_for_each_segment(bv, bio, iter)
> + elems++;
> + }
> +
> + return elems;
> +}
> +
> +static inline unsigned bio_pages(struct bio *bio)
> +{
> + return __bio_elements(bio, false);
> +}
>  
> - return segs;
> +static inline unsigned bio_segments(struct bio *bio)
> +{
> + return __bio_elements(bio, true);
>  }
>  
>  /*
> -- 
> 2.9.5
> 

Re: [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver

[Tomasz Figa]

On Thu, May 24, 2018 at 8:30 PM Baruch Siach  wrote:

> Hi Tomasz,

> On Mon, May 07, 2018 at 06:41:50AM +, Tomasz Figa wrote:
> > On Mon, May 7, 2018 at 3:38 PM Baruch Siach  wrote:
> > > On Mon, May 07, 2018 at 06:13:27AM +, Tomasz Figa wrote:
> > > > On Thu, May 3, 2018 at 6:09 PM Baruch Siach 
wrote:
> > > > > On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote:
> > > > > > +static int rkisp1_isp_sd_s_power(struct v4l2_subdev *sd, int
on)
> > > > > > +{
> > > > > > + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd);
> > > > > > + int ret;
> > > > > > +
> > > > > > + v4l2_dbg(1, rkisp1_debug, _dev->v4l2_dev, "s_power:
%d\n",
> > > > on);
> > > > > > +
> > > > > > + if (on) {
> > > > > > + ret = pm_runtime_get_sync(isp_dev->dev);
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + rkisp1_config_clk(isp_dev);
> > > > > > + } else {
> > > > > > + ret = pm_runtime_put(isp_dev->dev);
> > > >
> > > > > I commented this line out to make more than one STREAMON work.
> > Otherwise,
> > > > > the second STREAMON hangs. I guess the bug is not this driver.
> > Probably
> > > > > something in drivers/soc/rockchip/pm_domains.c. Just noting that
in
> > case
> > > > > you or someone on Cc would like to investigate it further.
> > > > >
> > > > > I tested v4.16-rc4 on the Tinkerboard.
> > > >
> > > > Looks like that version doesn't include the IOMMU PM and clock
handling
> > > > rework [1], which should fix a lot of runtime PM issues. FWIW,
> > linux-next
> > > > seems to already include it.
> > > >
> > > > [1] https://lkml.org/lkml/2018/3/23/44
> >
> > > Thanks for the reference.
> >
> > > It looks like the iommu driver part is in Linus' tree already. The DT
> > part is
> > > in the v4.18-armsoc/dts32 branch of Heiko's tree. Am I missing
anything?
> >
> > You're right, most of the series made it in time for 4.17. However, the
DT
> > part (precisely, the clocks properties added to IOMMU nodes) is crucial
for
> > the fixes to be effective.
> >
> > > Anyway, I'll take a look.
> >
> > Thanks for testing. :) (Forgot to mention in my previous email...)

> I finally got around to testing. Unfortunately, kernel v4.17-rc6 with
> cherry-pick of commit c78751f91c0b (ARM: dts: rockchip: add clocks in
iommu
> nodes) from Heiko's tree still exhibit the same problem. STREAMON hangs on
> second try. The same workaround "fixes" it.

Thanks for testing. I'm out of ideas, since the same code seems to work
fine for us in Chrome OS 4.4 kernel. Maybe we could have someone from RK
take a look.

Best regards,
Tomasz

Re: [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver

[Tomasz Figa]

On Thu, May 24, 2018 at 8:30 PM Baruch Siach  wrote:

> Hi Tomasz,

> On Mon, May 07, 2018 at 06:41:50AM +, Tomasz Figa wrote:
> > On Mon, May 7, 2018 at 3:38 PM Baruch Siach  wrote:
> > > On Mon, May 07, 2018 at 06:13:27AM +, Tomasz Figa wrote:
> > > > On Thu, May 3, 2018 at 6:09 PM Baruch Siach 
wrote:
> > > > > On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote:
> > > > > > +static int rkisp1_isp_sd_s_power(struct v4l2_subdev *sd, int
on)
> > > > > > +{
> > > > > > + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd);
> > > > > > + int ret;
> > > > > > +
> > > > > > + v4l2_dbg(1, rkisp1_debug, _dev->v4l2_dev, "s_power:
%d\n",
> > > > on);
> > > > > > +
> > > > > > + if (on) {
> > > > > > + ret = pm_runtime_get_sync(isp_dev->dev);
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + rkisp1_config_clk(isp_dev);
> > > > > > + } else {
> > > > > > + ret = pm_runtime_put(isp_dev->dev);
> > > >
> > > > > I commented this line out to make more than one STREAMON work.
> > Otherwise,
> > > > > the second STREAMON hangs. I guess the bug is not this driver.
> > Probably
> > > > > something in drivers/soc/rockchip/pm_domains.c. Just noting that
in
> > case
> > > > > you or someone on Cc would like to investigate it further.
> > > > >
> > > > > I tested v4.16-rc4 on the Tinkerboard.
> > > >
> > > > Looks like that version doesn't include the IOMMU PM and clock
handling
> > > > rework [1], which should fix a lot of runtime PM issues. FWIW,
> > linux-next
> > > > seems to already include it.
> > > >
> > > > [1] https://lkml.org/lkml/2018/3/23/44
> >
> > > Thanks for the reference.
> >
> > > It looks like the iommu driver part is in Linus' tree already. The DT
> > part is
> > > in the v4.18-armsoc/dts32 branch of Heiko's tree. Am I missing
anything?
> >
> > You're right, most of the series made it in time for 4.17. However, the
DT
> > part (precisely, the clocks properties added to IOMMU nodes) is crucial
for
> > the fixes to be effective.
> >
> > > Anyway, I'll take a look.
> >
> > Thanks for testing. :) (Forgot to mention in my previous email...)

> I finally got around to testing. Unfortunately, kernel v4.17-rc6 with
> cherry-pick of commit c78751f91c0b (ARM: dts: rockchip: add clocks in
iommu
> nodes) from Heiko's tree still exhibit the same problem. STREAMON hangs on
> second try. The same workaround "fixes" it.

Thanks for testing. I'm out of ideas, since the same code seems to work
fine for us in Chrome OS 4.4 kernel. Maybe we could have someone from RK
take a look.

Best regards,
Tomasz

Re: [PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node

[Joel Stanley]

Hello Andrew,

On 16 March 2018 at 11:17, Wang, Haiyue  wrote:
> Hi Joel and Andrew,
>
> Have time to review this patch ? Hope for your comments. :-)
>
> BR,
> Haiyue
>
>
> On 2018-03-07 13:04, Haiyue Wang wrote:
>>
>> The IPMI KCS device part of the LPC interface and is used for
>> communication with the host processor.
>>
>> Signed-off-by: Haiyue Wang 

Do you have time to take a look at these? The device tree doesn't make
sense to me.

Cheers,

Joel

>> ---
>>   arch/arm/boot/dts/aspeed-g5.dtsi | 43
>> +++-
>>   1 file changed, 42 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi
>> b/arch/arm/boot/dts/aspeed-g5.dtsi
>> index 8eac57c..f443169 100644
>> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
>> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
>> @@ -267,8 +267,40 @@
>> ranges = <0x0 0x1e789000 0x1000>;
>> lpc_bmc: lpc-bmc@0 {
>> -   compatible =
>> "aspeed,ast2500-lpc-bmc";
>> +   compatible =
>> "aspeed,ast2500-lpc-bmc", "simple-mfd", "syscon";
>> reg = <0x0 0x80>;
>> +   reg-io-width = <4>;
>> +
>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
>> +   ranges = <0x0 0x0 0x80>;
>> +
>> +   kcs1: kcs1@0 {
>> +   compatible =
>> "aspeed,ast2500-kcs-bmc";
>> +   reg = <0x0 0x80>;
>> +   interrupts = <8>;
>> +   kcs_chan = <1>;
>> +   kcs_addr = <0x0>;
>> +   status = "disabled";
>> +   };
>> +
>> +   kcs2: kcs2@0 {
>> +   compatible =
>> "aspeed,ast2500-kcs-bmc";
>> +   reg = <0x0 0x80>;
>> +   interrupts = <8>;
>> +   kcs_chan = <2>;
>> +   kcs_addr = <0x0>;
>> +   status = "disabled";
>> +   };
>> +
>> +   kcs3: kcs3@0 {
>> +   compatible =
>> "aspeed,ast2500-kcs-bmc";
>> +   reg = <0x0 0x80>;
>> +   interrupts = <8>;
>> +   kcs_chan = <3>;
>> +   kcs_addr = <0x0>;
>> +   status = "disabled";
>> +   };
>> };
>> lpc_host: lpc-host@80 {
>> @@ -294,6 +326,15 @@
>> status = "disabled";
>> };
>>   + kcs4: kcs4@0 {
>> +   compatible =
>> "aspeed,ast2500-kcs-bmc";
>> +   reg = <0x0 0xa0>;
>> +   interrupts = <8>;
>> +   kcs_chan = <4>;
>> +   kcs_addr = <0x0>;
>> +   status = "disabled";
>> +   };
>> +
>> lhc: lhc@20 {
>> compatible =
>> "aspeed,ast2500-lhc";
>> reg = <0x20 0x24 0x48
>> 0x8>;
>
>

Re: [PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node

[Joel Stanley]

Hello Andrew,

On 16 March 2018 at 11:17, Wang, Haiyue  wrote:
> Hi Joel and Andrew,
>
> Have time to review this patch ? Hope for your comments. :-)
>
> BR,
> Haiyue
>
>
> On 2018-03-07 13:04, Haiyue Wang wrote:
>>
>> The IPMI KCS device part of the LPC interface and is used for
>> communication with the host processor.
>>
>> Signed-off-by: Haiyue Wang 

Do you have time to take a look at these? The device tree doesn't make
sense to me.

Cheers,

Joel

>> ---
>>   arch/arm/boot/dts/aspeed-g5.dtsi | 43
>> +++-
>>   1 file changed, 42 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi
>> b/arch/arm/boot/dts/aspeed-g5.dtsi
>> index 8eac57c..f443169 100644
>> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
>> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
>> @@ -267,8 +267,40 @@
>> ranges = <0x0 0x1e789000 0x1000>;
>> lpc_bmc: lpc-bmc@0 {
>> -   compatible =
>> "aspeed,ast2500-lpc-bmc";
>> +   compatible =
>> "aspeed,ast2500-lpc-bmc", "simple-mfd", "syscon";
>> reg = <0x0 0x80>;
>> +   reg-io-width = <4>;
>> +
>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
>> +   ranges = <0x0 0x0 0x80>;
>> +
>> +   kcs1: kcs1@0 {
>> +   compatible =
>> "aspeed,ast2500-kcs-bmc";
>> +   reg = <0x0 0x80>;
>> +   interrupts = <8>;
>> +   kcs_chan = <1>;
>> +   kcs_addr = <0x0>;
>> +   status = "disabled";
>> +   };
>> +
>> +   kcs2: kcs2@0 {
>> +   compatible =
>> "aspeed,ast2500-kcs-bmc";
>> +   reg = <0x0 0x80>;
>> +   interrupts = <8>;
>> +   kcs_chan = <2>;
>> +   kcs_addr = <0x0>;
>> +   status = "disabled";
>> +   };
>> +
>> +   kcs3: kcs3@0 {
>> +   compatible =
>> "aspeed,ast2500-kcs-bmc";
>> +   reg = <0x0 0x80>;
>> +   interrupts = <8>;
>> +   kcs_chan = <3>;
>> +   kcs_addr = <0x0>;
>> +   status = "disabled";
>> +   };
>> };
>> lpc_host: lpc-host@80 {
>> @@ -294,6 +326,15 @@
>> status = "disabled";
>> };
>>   + kcs4: kcs4@0 {
>> +   compatible =
>> "aspeed,ast2500-kcs-bmc";
>> +   reg = <0x0 0xa0>;
>> +   interrupts = <8>;
>> +   kcs_chan = <4>;
>> +   kcs_addr = <0x0>;
>> +   status = "disabled";
>> +   };
>> +
>> lhc: lhc@20 {
>> compatible =
>> "aspeed,ast2500-lhc";
>> reg = <0x20 0x24 0x48
>> 0x8>;
>
>

Re: [PATCH v3 4/8] drm/mediatek: add ddp component AAL1

[CK Hu]

Hi, Stu:

On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> From: Stu Hsieh 
> 
> This patch add component AAL1 and
> rename AAL to AAL0
> 
> Signed-off-by: Stu Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 0828cf8bf85c..eee3c0cc2632 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -41,7 +41,8 @@ enum mtk_ddp_comp_type {
>  };
>  
>  enum mtk_ddp_comp_id {
> - DDP_COMPONENT_AAL,
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_AAL1,

Be sure compiling is success when you apply each patch of a series. I
think when you apply to this patch, it would cause compiling error
because some related modification is in the patch 'Add support for
mediatek SOC MT2712'. So move the modification from that patch to this
patch.

Regards,
CK

>   DDP_COMPONENT_BLS,
>   DDP_COMPONENT_COLOR0,
>   DDP_COMPONENT_COLOR1,

Re: [PATCH v3 4/8] drm/mediatek: add ddp component AAL1

[CK Hu]

Hi, Stu:

On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> From: Stu Hsieh 
> 
> This patch add component AAL1 and
> rename AAL to AAL0
> 
> Signed-off-by: Stu Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 0828cf8bf85c..eee3c0cc2632 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -41,7 +41,8 @@ enum mtk_ddp_comp_type {
>  };
>  
>  enum mtk_ddp_comp_id {
> - DDP_COMPONENT_AAL,
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_AAL1,

Be sure compiling is success when you apply each patch of a series. I
think when you apply to this patch, it would cause compiling error
because some related modification is in the patch 'Add support for
mediatek SOC MT2712'. So move the modification from that patch to this
patch.

Regards,
CK

>   DDP_COMPONENT_BLS,
>   DDP_COMPONENT_COLOR0,
>   DDP_COMPONENT_COLOR1,

Re: [PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries

[Andreas Färber]

Am 23.05.2018 um 10:40 schrieb Linus Walleij:
> On Sun, May 20, 2018 at 7:17 AM, Manivannan Sadhasivam
>  wrote:
> 
>> Add S900 pinctrl entries under ARCH_ACTIONS
>>
>> Signed-off-by: Manivannan Sadhasivam 
> 
> Patch applied tentatively so we have some maintenance entry for this.
> 
> Andreas expressed concerns about the driver earlier, so he might want it
> split from the platform parts and have a separate entry for the pinctrl+GPIO
> so Manivannan can maintain that part, also it makes sense to list
> Manivannan as comaintainer of ARCH_ACTIONS with this in.
> 
> Andreas: how would you like to proceed?
> 
> I understand that I was a bit pushy or even rude in my last message
> about the maintenance of this platform and the code structure of
> the pin control driver. I am sorry if it caused any bad feelings on your
> side :( social conflicts give me the creeps, I just try my best. Maybe
> my best isn't always what it should be.

I fail to understand how splitting the MAINTAINERS section is going to
help with the pinctrl conflict at hand? The problem is that instead of
refactoring my S500 pinctrl driver to his liking, Mani has submitted a
competing S900 pinctrl driver that you went on to merge. The human
aspect is that merging his driver took the credit away from me having
written the earlier pinctrl driver (based on my rtd1295 pinctrl driver).
The practical aspect is that I can't drop my pinctrl driver from my work
branch until there is equivalent functionality in the merged driver. I
am lacking the time to rewrite S500 pin definitions on top of Mani's
myself at this time, and I haven't seen S500 patches from him yet.

Also I had been investing efforts in explaining the upstreaming process
to Actions, last in November. I see Thomas Liau and Jeff Chen missing in
CC and I have not seen any Reviewed-by or Acked-by from anyone at
Actions on this and the preceding series. There are more chips than the
one on Linaro's 96board, so I would prefer to assure that the design
works for all. Thus I am very critical of you applying the patches
without waiting for review by Actions.

Other aspects are: The reason I wrote the pinctrl driver is that I
experienced a UART TX issue on the Sparky board and was hoping a pinctrl
driver might resolve that, but it didn't. So I still have a mix of
boards where some are working and some are pretty unusable, without any
clues on why.

That said, I don't object to having a separate MAINTAINERS section for
the pinctrl driver(s) as long as I still get CC'ed on changes. We have
wanted to add Mani as R for Actions overall, so that would probably mean
adding me as R to an Actions pinctrl section, to avoid syncing the paths
between two sections. I had previously felt that it does not make sense
to list Mani as co-maintainer (M) for Actions overall since he can't tag
and submit from my repo. And for the record I have offered him to take
over which he didn't want to. I still hope to find some more time to
review and queue his SPS patches, a driver that I have designed and thus
understand and am much happier about the incremental additions there.

A further side note is that I had reached out about setting up an
infradead mailing list linux-actions, but there was no response from
David or anyone. Having an L on the section(s) would avoid messing with
R and hand-maintained CC lists. Any help with that appreciated.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries

[Andreas Färber]

Am 23.05.2018 um 10:40 schrieb Linus Walleij:
> On Sun, May 20, 2018 at 7:17 AM, Manivannan Sadhasivam
>  wrote:
> 
>> Add S900 pinctrl entries under ARCH_ACTIONS
>>
>> Signed-off-by: Manivannan Sadhasivam 
> 
> Patch applied tentatively so we have some maintenance entry for this.
> 
> Andreas expressed concerns about the driver earlier, so he might want it
> split from the platform parts and have a separate entry for the pinctrl+GPIO
> so Manivannan can maintain that part, also it makes sense to list
> Manivannan as comaintainer of ARCH_ACTIONS with this in.
> 
> Andreas: how would you like to proceed?
> 
> I understand that I was a bit pushy or even rude in my last message
> about the maintenance of this platform and the code structure of
> the pin control driver. I am sorry if it caused any bad feelings on your
> side :( social conflicts give me the creeps, I just try my best. Maybe
> my best isn't always what it should be.

I fail to understand how splitting the MAINTAINERS section is going to
help with the pinctrl conflict at hand? The problem is that instead of
refactoring my S500 pinctrl driver to his liking, Mani has submitted a
competing S900 pinctrl driver that you went on to merge. The human
aspect is that merging his driver took the credit away from me having
written the earlier pinctrl driver (based on my rtd1295 pinctrl driver).
The practical aspect is that I can't drop my pinctrl driver from my work
branch until there is equivalent functionality in the merged driver. I
am lacking the time to rewrite S500 pin definitions on top of Mani's
myself at this time, and I haven't seen S500 patches from him yet.

Also I had been investing efforts in explaining the upstreaming process
to Actions, last in November. I see Thomas Liau and Jeff Chen missing in
CC and I have not seen any Reviewed-by or Acked-by from anyone at
Actions on this and the preceding series. There are more chips than the
one on Linaro's 96board, so I would prefer to assure that the design
works for all. Thus I am very critical of you applying the patches
without waiting for review by Actions.

Other aspects are: The reason I wrote the pinctrl driver is that I
experienced a UART TX issue on the Sparky board and was hoping a pinctrl
driver might resolve that, but it didn't. So I still have a mix of
boards where some are working and some are pretty unusable, without any
clues on why.

That said, I don't object to having a separate MAINTAINERS section for
the pinctrl driver(s) as long as I still get CC'ed on changes. We have
wanted to add Mani as R for Actions overall, so that would probably mean
adding me as R to an Actions pinctrl section, to avoid syncing the paths
between two sections. I had previously felt that it does not make sense
to list Mani as co-maintainer (M) for Actions overall since he can't tag
and submit from my repo. And for the record I have offered him to take
over which he didn't want to. I still hope to find some more time to
review and queue his SPS patches, a driver that I have designed and thus
understand and am much happier about the incremental additions there.

A further side note is that I had reached out about setting up an
infradead mailing list linux-actions, but there was no response from
David or anyone. Having an L on the section(s) would avoid messing with
R and hand-maintained CC lists. Any help with that appreciated.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts

[Darrick J. Wong]

On Fri, May 25, 2018 at 01:57:16PM +1000, Dave Chinner wrote:
> On Thu, May 24, 2018 at 06:23:30PM -0500, Eric W. Biederman wrote:
> > "Theodore Y. Ts'o"  writes:
> > 
> > > On Wed, May 23, 2018 at 06:22:56PM -0500, Eric W. Biederman wrote:
> > >> 
> > >> Very slowly the work has been progressing to ensure the vfs has the
> > >> necessary support for mounting filesystems without privilege.
> > >
> > > What's the thinking behind how system administrators and/or file
> > > systems would configure whether or not a particular file system type
> > > will be allowed to be mounted w/o privilege?
> > 
> > The mechanism is .fs_flags in file_system_type.   If the FS_USERNS_MOUNT
> > flag is set then root in a user namespace (AKA an unprivileged user)
> > will be allowed to mount to mount the filesystem.
> > 
> > There are very real concerns about attacking a filesystem with an
> > invalid filesystem image, or by a malicious protocol speaker.  So I
> > don't want to enable anything without the file system maintainers
> > consent and without a reasonable expecation that neither a system wide
> > denial of service attack nor a privilege escalation attack is possible
> > from if the filesystem is enabled.
> > 
> > So at a practical level what we have in the vfs is the non-fuse specific
> > bits that enable unprivileged mounts of fuse.  Things like handling
> > of unmapped uid and gids, how normally trusted xattrs are dealt with,
> > etc.
> > 
> > A big practical one for me is that if either the uid or gid is not
> > mapped the vfs avoids writing to the inode.
> > 
> > Right now my practical goal is to be able to say: "Go run your
> > filesystem in userspace with fuse if you want stronger security
> > guarantees."  I think that will be enough to make removable media
> > reasonably safe from privilege escalation attacks.
> > 
> > There is enough code in most filesystems that I don't know what our
> > chances of locking down very many of them are.  But I figure a few more
> > of them are possible.
> 
> I'm not sure we need to - fusefs-lkl gives users the ability to
> mount any of the kernel filesystems via fuse without us needing to
> support unprivileged kernel mounts for those filesystems.

/me wonders, is there a fusefs-lkl package for Linux?

(He says, knowing that freebsd has one... :))

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.com

Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts

[Darrick J. Wong]

On Fri, May 25, 2018 at 01:57:16PM +1000, Dave Chinner wrote:
> On Thu, May 24, 2018 at 06:23:30PM -0500, Eric W. Biederman wrote:
> > "Theodore Y. Ts'o"  writes:
> > 
> > > On Wed, May 23, 2018 at 06:22:56PM -0500, Eric W. Biederman wrote:
> > >> 
> > >> Very slowly the work has been progressing to ensure the vfs has the
> > >> necessary support for mounting filesystems without privilege.
> > >
> > > What's the thinking behind how system administrators and/or file
> > > systems would configure whether or not a particular file system type
> > > will be allowed to be mounted w/o privilege?
> > 
> > The mechanism is .fs_flags in file_system_type.   If the FS_USERNS_MOUNT
> > flag is set then root in a user namespace (AKA an unprivileged user)
> > will be allowed to mount to mount the filesystem.
> > 
> > There are very real concerns about attacking a filesystem with an
> > invalid filesystem image, or by a malicious protocol speaker.  So I
> > don't want to enable anything without the file system maintainers
> > consent and without a reasonable expecation that neither a system wide
> > denial of service attack nor a privilege escalation attack is possible
> > from if the filesystem is enabled.
> > 
> > So at a practical level what we have in the vfs is the non-fuse specific
> > bits that enable unprivileged mounts of fuse.  Things like handling
> > of unmapped uid and gids, how normally trusted xattrs are dealt with,
> > etc.
> > 
> > A big practical one for me is that if either the uid or gid is not
> > mapped the vfs avoids writing to the inode.
> > 
> > Right now my practical goal is to be able to say: "Go run your
> > filesystem in userspace with fuse if you want stronger security
> > guarantees."  I think that will be enough to make removable media
> > reasonably safe from privilege escalation attacks.
> > 
> > There is enough code in most filesystems that I don't know what our
> > chances of locking down very many of them are.  But I figure a few more
> > of them are possible.
> 
> I'm not sure we need to - fusefs-lkl gives users the ability to
> mount any of the kernel filesystems via fuse without us needing to
> support unprivileged kernel mounts for those filesystems.

/me wonders, is there a fusefs-lkl package for Linux?

(He says, knowing that freebsd has one... :))

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.com

Re: [PATCH v13 1/2] cpufreq: Add Kryo CPU scaling driver

[Viresh Kumar]

On 25-05-18, 07:00, Ilia Lin wrote:
> 
> 
> On May 25, 2018 6:54:12 AM GMT+03:00, Viresh Kumar  
> wrote:
> >On 24-05-18, 18:03, Ilia Lin wrote:
> >> +static int __init qcom_cpufreq_kryo_init(void)
> >> +{
> >> +  struct device_node *np;
> >> +  struct device *cpu_dev;
> >> +  int ret;
> >> +
> >> +  cpu_dev = get_cpu_device(0);
> >> +  if (NULL == cpu_dev)
> >> +  ret = -ENODEV;
> >> +
> >> +  np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
> >> +  if (IS_ERR(np))
> >> +  return PTR_ERR(np);
> >> +
> >> +  ret = of_device_is_compatible(np, "operating-points-v2-kryo-cpu");
> >> +  of_node_put(np);
> >> +  if (!ret)
> >> +  return -ENOENT;
> >> +
> >
> >I hate the fact that it is taking so long to get done with this. But
> >can't you
> >just check machine compatibility instead of this complicated setup to
> >check OPP
> >node ? Like:
> >
> >if (!of_device_is_compatible("qcom,apq8096") &&
> >!of_device_is_compatible("qcom,msm8996"))
> >return;
> 
> I have to check the "operating-points-v2-kryo-cpu" anyway, so I moved it from 
> probe to the init.

Okay, leave it as is then. Don't send anything yet and wait for Sudeep to
respond.

> >
> >And please see if you can add an entry in MAINTAINERS and add your
> >working email
> >id there.
> 
> Sure. Should this be part of the patch itself?

If you need to send another version of this series, then add it to this patch
itself. Else send it separately and don't resend this stuff.

-- 
viresh

Re: [PATCH v13 1/2] cpufreq: Add Kryo CPU scaling driver

[Viresh Kumar]

On 25-05-18, 07:00, Ilia Lin wrote:
> 
> 
> On May 25, 2018 6:54:12 AM GMT+03:00, Viresh Kumar  
> wrote:
> >On 24-05-18, 18:03, Ilia Lin wrote:
> >> +static int __init qcom_cpufreq_kryo_init(void)
> >> +{
> >> +  struct device_node *np;
> >> +  struct device *cpu_dev;
> >> +  int ret;
> >> +
> >> +  cpu_dev = get_cpu_device(0);
> >> +  if (NULL == cpu_dev)
> >> +  ret = -ENODEV;
> >> +
> >> +  np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
> >> +  if (IS_ERR(np))
> >> +  return PTR_ERR(np);
> >> +
> >> +  ret = of_device_is_compatible(np, "operating-points-v2-kryo-cpu");
> >> +  of_node_put(np);
> >> +  if (!ret)
> >> +  return -ENOENT;
> >> +
> >
> >I hate the fact that it is taking so long to get done with this. But
> >can't you
> >just check machine compatibility instead of this complicated setup to
> >check OPP
> >node ? Like:
> >
> >if (!of_device_is_compatible("qcom,apq8096") &&
> >!of_device_is_compatible("qcom,msm8996"))
> >return;
> 
> I have to check the "operating-points-v2-kryo-cpu" anyway, so I moved it from 
> probe to the init.

Okay, leave it as is then. Don't send anything yet and wait for Sudeep to
respond.

> >
> >And please see if you can add an entry in MAINTAINERS and add your
> >working email
> >id there.
> 
> Sure. Should this be part of the patch itself?

If you need to send another version of this series, then add it to this patch
itself. Else send it separately and don't resend this stuff.

-- 
viresh

[PATCH] arm64: defconfig: Enable UFS on msm8996

[Bjorn Andersson]

Enable GLINK RPM so that we get RPM regulators and clocks and enable the
UFS host controller driver and the Qualcomm UFS platform driver. The UFS
phy is selected by the Qualcomm UFS driver.

The simple ondemand devfreq governor must be builtin, as there's no
mechanism for automatically loading it, causing UFS HCD initialization
to fail.

Signed-off-by: Bjorn Andersson 
---
 arch/arm64/configs/defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 329950545603..895b2d92124d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -191,6 +191,9 @@ CONFIG_BLK_DEV_SD=y
 CONFIG_SCSI_SAS_ATA=y
 CONFIG_SCSI_HISI_SAS=y
 CONFIG_SCSI_HISI_SAS_PCI=y
+CONFIG_SCSI_UFSHCD=m
+CONFIG_SCSI_UFSHCD_PLATFORM=m
+CONFIG_SCSI_UFS_QCOM=m
 CONFIG_ATA=y
 CONFIG_SATA_AHCI=y
 CONFIG_SATA_AHCI_PLATFORM=y
@@ -574,6 +577,7 @@ CONFIG_TEGRA_IOMMU_SMMU=y
 CONFIG_ARM_SMMU=y
 CONFIG_ARM_SMMU_V3=y
 CONFIG_QCOM_IOMMU=y
+CONFIG_RPMSG_QCOM_GLINK_RPM=y
 CONFIG_RPMSG_QCOM_SMD=y
 CONFIG_RASPBERRYPI_POWER=y
 CONFIG_QCOM_SMEM=y
@@ -585,6 +589,7 @@ CONFIG_ARCH_TEGRA_132_SOC=y
 CONFIG_ARCH_TEGRA_210_SOC=y
 CONFIG_ARCH_TEGRA_186_SOC=y
 CONFIG_ARCH_TEGRA_194_SOC=y
+CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y
 CONFIG_EXTCON_USB_GPIO=y
 CONFIG_EXTCON_USBC_CROS_EC=y
 CONFIG_MEMORY=y
-- 
2.17.0

[PATCH] arm64: defconfig: Enable UFS on msm8996

[Bjorn Andersson]

Enable GLINK RPM so that we get RPM regulators and clocks and enable the
UFS host controller driver and the Qualcomm UFS platform driver. The UFS
phy is selected by the Qualcomm UFS driver.

The simple ondemand devfreq governor must be builtin, as there's no
mechanism for automatically loading it, causing UFS HCD initialization
to fail.

Signed-off-by: Bjorn Andersson 
---
 arch/arm64/configs/defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 329950545603..895b2d92124d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -191,6 +191,9 @@ CONFIG_BLK_DEV_SD=y
 CONFIG_SCSI_SAS_ATA=y
 CONFIG_SCSI_HISI_SAS=y
 CONFIG_SCSI_HISI_SAS_PCI=y
+CONFIG_SCSI_UFSHCD=m
+CONFIG_SCSI_UFSHCD_PLATFORM=m
+CONFIG_SCSI_UFS_QCOM=m
 CONFIG_ATA=y
 CONFIG_SATA_AHCI=y
 CONFIG_SATA_AHCI_PLATFORM=y
@@ -574,6 +577,7 @@ CONFIG_TEGRA_IOMMU_SMMU=y
 CONFIG_ARM_SMMU=y
 CONFIG_ARM_SMMU_V3=y
 CONFIG_QCOM_IOMMU=y
+CONFIG_RPMSG_QCOM_GLINK_RPM=y
 CONFIG_RPMSG_QCOM_SMD=y
 CONFIG_RASPBERRYPI_POWER=y
 CONFIG_QCOM_SMEM=y
@@ -585,6 +589,7 @@ CONFIG_ARCH_TEGRA_132_SOC=y
 CONFIG_ARCH_TEGRA_210_SOC=y
 CONFIG_ARCH_TEGRA_186_SOC=y
 CONFIG_ARCH_TEGRA_194_SOC=y
+CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y
 CONFIG_EXTCON_USB_GPIO=y
 CONFIG_EXTCON_USBC_CROS_EC=y
 CONFIG_MEMORY=y
-- 
2.17.0

[PATCH v5 1/1] PCI: kirin: Add MSI support

[Xiaowei Song]

Add support for MSI.

Signed-off-by: Xiaowei Song 
---
 drivers/pci/dwc/pcie-kirin.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
index d2970a009eb5..6997276eb69c 100644
--- a/drivers/pci/dwc/pcie-kirin.c
+++ b/drivers/pci/dwc/pcie-kirin.c
@@ -430,6 +430,9 @@ static int kirin_pcie_host_init(struct pcie_port *pp)
 {
kirin_pcie_establish_link(pp);
 
+   if (IS_ENABLED(CONFIG_PCI_MSI))
+   dw_pcie_msi_init(pp);
+
return 0;
 }
 
@@ -445,9 +448,34 @@ static const struct dw_pcie_host_ops kirin_pcie_host_ops = 
{
.host_init = kirin_pcie_host_init,
 };
 
+static int kirin_pcie_add_msi(struct dw_pcie *pci,
+   struct platform_device *pdev)
+{
+   int ret = 0;
+
+   if (IS_ENABLED(CONFIG_PCI_MSI)) {
+   ret = platform_get_irq(pdev, 0);
+   if (ret < 0) {
+   dev_err(>dev,
+   "failed to get MSI IRQ (%d)\n", ret);
+   return ret;
+   }
+
+   pci->pp.msi_irq = ret;
+   }
+
+   return ret;
+}
+
 static int __init kirin_add_pcie_port(struct dw_pcie *pci,
  struct platform_device *pdev)
 {
+   int ret;
+
+   ret = kirin_pcie_add_msi(pci, pdev);
+   if (ret)
+   return ret;
+
pci->pp.ops = _pcie_host_ops;
 
return dw_pcie_host_init(>pp);
-- 
2.11.GIT

[PATCH v5 0/1] *** PCI: kirin: Add MSI support ***

[Xiaowei Song]

Before Version Patches
==
patch v4
https://patchwork.kernel.org/patch/10402399/
patch v3
https://www.spinics.net/lists/linux-pci/msg72322.html
patch v2
https://www.spinics.net/lists/kernel/msg2797610.html

patch v1
https://www.spinics.net/lists/kernel/msg2796410.html

Changes between V5 and V4
=
1. rebase the patch based on Linux next-version branch.
2. fix issues according to review comments from Andy Shevchenko and Lorenzo.
   (1) Del MSI irq handler for DW handle it, while Kirin only read the number 
from DT,
   (2) Use the function dw_pcie_msi_init directly if CONFIG_PCI_MSI is enabled.

Changes between V4 and V3
=
1. remove DT binding patch, for Wei Xu had applied it.
2. fix issues according to review comments from Andy Shevchenko.
   (1) Take the msi number get and request as a seperate function,
   (2) Use the result of  platform_get_irq as return val.

Changes between V3 and V2
=
1. fix issues according to review comments
   (1)from Bjorn Helgaas: Check for 'pci->pp.msi_irq < 0'.
   (2)from Bjorn Helgaas: Update the message of 'msi irq' in dev_err().

Changes between V2 and V1
=
1. seperate DT binding patch.
2. fix issues according to review comments
   (1)from Bjorn Helgaas: Update the style of subject and changelog.
   (2)from Bjorn Helgaas: Add msi irq number in the message.
   (3)from Bjorn Helgaas: Delete unnecessary code 'pci->pp.root_bus_nr = -1'.
   (4)from Dmitry Shmidt: Fix typing error. Replace 'interrupts-names' of 
'interrupt-names'.

Xiaowei Song (1):
  PCI: kirin: Add MSI support

 drivers/pci/dwc/pcie-kirin.c | 28 
 1 file changed, 28 insertions(+)

-- 
2.11.GIT

[PATCH v5 1/1] PCI: kirin: Add MSI support

[Xiaowei Song]

Add support for MSI.

Signed-off-by: Xiaowei Song 
---
 drivers/pci/dwc/pcie-kirin.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
index d2970a009eb5..6997276eb69c 100644
--- a/drivers/pci/dwc/pcie-kirin.c
+++ b/drivers/pci/dwc/pcie-kirin.c
@@ -430,6 +430,9 @@ static int kirin_pcie_host_init(struct pcie_port *pp)
 {
kirin_pcie_establish_link(pp);
 
+   if (IS_ENABLED(CONFIG_PCI_MSI))
+   dw_pcie_msi_init(pp);
+
return 0;
 }
 
@@ -445,9 +448,34 @@ static const struct dw_pcie_host_ops kirin_pcie_host_ops = 
{
.host_init = kirin_pcie_host_init,
 };
 
+static int kirin_pcie_add_msi(struct dw_pcie *pci,
+   struct platform_device *pdev)
+{
+   int ret = 0;
+
+   if (IS_ENABLED(CONFIG_PCI_MSI)) {
+   ret = platform_get_irq(pdev, 0);
+   if (ret < 0) {
+   dev_err(>dev,
+   "failed to get MSI IRQ (%d)\n", ret);
+   return ret;
+   }
+
+   pci->pp.msi_irq = ret;
+   }
+
+   return ret;
+}
+
 static int __init kirin_add_pcie_port(struct dw_pcie *pci,
  struct platform_device *pdev)
 {
+   int ret;
+
+   ret = kirin_pcie_add_msi(pci, pdev);
+   if (ret)
+   return ret;
+
pci->pp.ops = _pcie_host_ops;
 
return dw_pcie_host_init(>pp);
-- 
2.11.GIT

[PATCH v5 0/1] *** PCI: kirin: Add MSI support ***

[Xiaowei Song]

Before Version Patches
==
patch v4
https://patchwork.kernel.org/patch/10402399/
patch v3
https://www.spinics.net/lists/linux-pci/msg72322.html
patch v2
https://www.spinics.net/lists/kernel/msg2797610.html

patch v1
https://www.spinics.net/lists/kernel/msg2796410.html

Changes between V5 and V4
=
1. rebase the patch based on Linux next-version branch.
2. fix issues according to review comments from Andy Shevchenko and Lorenzo.
   (1) Del MSI irq handler for DW handle it, while Kirin only read the number 
from DT,
   (2) Use the function dw_pcie_msi_init directly if CONFIG_PCI_MSI is enabled.

Changes between V4 and V3
=
1. remove DT binding patch, for Wei Xu had applied it.
2. fix issues according to review comments from Andy Shevchenko.
   (1) Take the msi number get and request as a seperate function,
   (2) Use the result of  platform_get_irq as return val.

Changes between V3 and V2
=
1. fix issues according to review comments
   (1)from Bjorn Helgaas: Check for 'pci->pp.msi_irq < 0'.
   (2)from Bjorn Helgaas: Update the message of 'msi irq' in dev_err().

Changes between V2 and V1
=
1. seperate DT binding patch.
2. fix issues according to review comments
   (1)from Bjorn Helgaas: Update the style of subject and changelog.
   (2)from Bjorn Helgaas: Add msi irq number in the message.
   (3)from Bjorn Helgaas: Delete unnecessary code 'pci->pp.root_bus_nr = -1'.
   (4)from Dmitry Shmidt: Fix typing error. Replace 'interrupts-names' of 
'interrupt-names'.

Xiaowei Song (1):
  PCI: kirin: Add MSI support

 drivers/pci/dwc/pcie-kirin.c | 28 
 1 file changed, 28 insertions(+)

-- 
2.11.GIT

Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts

[Dave Chinner]

On Thu, May 24, 2018 at 06:23:30PM -0500, Eric W. Biederman wrote:
> "Theodore Y. Ts'o"  writes:
> 
> > On Wed, May 23, 2018 at 06:22:56PM -0500, Eric W. Biederman wrote:
> >> 
> >> Very slowly the work has been progressing to ensure the vfs has the
> >> necessary support for mounting filesystems without privilege.
> >
> > What's the thinking behind how system administrators and/or file
> > systems would configure whether or not a particular file system type
> > will be allowed to be mounted w/o privilege?
> 
> The mechanism is .fs_flags in file_system_type.   If the FS_USERNS_MOUNT
> flag is set then root in a user namespace (AKA an unprivileged user)
> will be allowed to mount to mount the filesystem.
> 
> There are very real concerns about attacking a filesystem with an
> invalid filesystem image, or by a malicious protocol speaker.  So I
> don't want to enable anything without the file system maintainers
> consent and without a reasonable expecation that neither a system wide
> denial of service attack nor a privilege escalation attack is possible
> from if the filesystem is enabled.
> 
> So at a practical level what we have in the vfs is the non-fuse specific
> bits that enable unprivileged mounts of fuse.  Things like handling
> of unmapped uid and gids, how normally trusted xattrs are dealt with,
> etc.
> 
> A big practical one for me is that if either the uid or gid is not
> mapped the vfs avoids writing to the inode.
> 
> Right now my practical goal is to be able to say: "Go run your
> filesystem in userspace with fuse if you want stronger security
> guarantees."  I think that will be enough to make removable media
> reasonably safe from privilege escalation attacks.
> 
> There is enough code in most filesystems that I don't know what our
> chances of locking down very many of them are.  But I figure a few more
> of them are possible.

I'm not sure we need to - fusefs-lkl gives users the ability to
mount any of the kernel filesystems via fuse without us needing to
support unprivileged kernel mounts for those filesystems.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts

[Dave Chinner]

On Thu, May 24, 2018 at 06:23:30PM -0500, Eric W. Biederman wrote:
> "Theodore Y. Ts'o"  writes:
> 
> > On Wed, May 23, 2018 at 06:22:56PM -0500, Eric W. Biederman wrote:
> >> 
> >> Very slowly the work has been progressing to ensure the vfs has the
> >> necessary support for mounting filesystems without privilege.
> >
> > What's the thinking behind how system administrators and/or file
> > systems would configure whether or not a particular file system type
> > will be allowed to be mounted w/o privilege?
> 
> The mechanism is .fs_flags in file_system_type.   If the FS_USERNS_MOUNT
> flag is set then root in a user namespace (AKA an unprivileged user)
> will be allowed to mount to mount the filesystem.
> 
> There are very real concerns about attacking a filesystem with an
> invalid filesystem image, or by a malicious protocol speaker.  So I
> don't want to enable anything without the file system maintainers
> consent and without a reasonable expecation that neither a system wide
> denial of service attack nor a privilege escalation attack is possible
> from if the filesystem is enabled.
> 
> So at a practical level what we have in the vfs is the non-fuse specific
> bits that enable unprivileged mounts of fuse.  Things like handling
> of unmapped uid and gids, how normally trusted xattrs are dealt with,
> etc.
> 
> A big practical one for me is that if either the uid or gid is not
> mapped the vfs avoids writing to the inode.
> 
> Right now my practical goal is to be able to say: "Go run your
> filesystem in userspace with fuse if you want stronger security
> guarantees."  I think that will be enough to make removable media
> reasonably safe from privilege escalation attacks.
> 
> There is enough code in most filesystems that I don't know what our
> chances of locking down very many of them are.  But I figure a few more
> of them are possible.

I'm not sure we need to - fusefs-lkl gives users the ability to
mount any of the kernel filesystems via fuse without us needing to
support unprivileged kernel mounts for those filesystems.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH -next 0/6] rhashtable: guarantee first allocation

[Davidlohr Bueso]

On Thu, 24 May 2018, Linus Torvalds wrote:


On Thu, May 24, 2018 at 2:28 PM Davidlohr Bueso  wrote:

  10 files changed, 79 insertions(+), 86 deletions(-)


I certainly can't complain about this small code removal, but I think if we
did the kvmalloc_node() cleanup, we'd be able to get rid of even more.

For example, bucket_table_alloc() does that

if (gfp != GFP_KERNEL)
tbl = kzalloc(size, gfp | __GFP_NOWARN | __GFP_NORETRY);
else
tbl = kvzalloc(size, gfp);

purely due to the kvalloc_node() oddity. Wouldn't it be nice to just write
it as

tbl = kvzalloc(size, gfp);

knowing that the whole point of all the kv*alloc*() functions is to "just
do the right thing given size, gpf mask, and ease of allocation".


Yes this makes a lot of sense. I'll see about adding it on top.

Thanks,
Davidlohr

Re: [PATCH -next 0/6] rhashtable: guarantee first allocation

[Davidlohr Bueso]

On Thu, 24 May 2018, Linus Torvalds wrote:


On Thu, May 24, 2018 at 2:28 PM Davidlohr Bueso  wrote:

  10 files changed, 79 insertions(+), 86 deletions(-)


I certainly can't complain about this small code removal, but I think if we
did the kvmalloc_node() cleanup, we'd be able to get rid of even more.

For example, bucket_table_alloc() does that

if (gfp != GFP_KERNEL)
tbl = kzalloc(size, gfp | __GFP_NOWARN | __GFP_NORETRY);
else
tbl = kvzalloc(size, gfp);

purely due to the kvalloc_node() oddity. Wouldn't it be nice to just write
it as

tbl = kvzalloc(size, gfp);

knowing that the whole point of all the kv*alloc*() functions is to "just
do the right thing given size, gpf mask, and ease of allocation".


Yes this makes a lot of sense. I'll see about adding it on top.

Thanks,
Davidlohr

[RESEND PATCH V5 23/33] ext4: conver to bio_for_each_page_all2

[Ming Lei]

bio_for_each_page_all() can't be used any more after multipage bvec is
enabled, so we have to convert to bio_for_each_page_all2().

Signed-off-by: Ming Lei 
---
 fs/ext4/page-io.c  | 3 ++-
 fs/ext4/readpage.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
index 52f2937f5603..b56a733f33c0 100644
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -63,8 +63,9 @@ static void ext4_finish_bio(struct bio *bio)
 {
int i;
struct bio_vec *bvec;
+   struct bvec_iter_all bia;
 
-   bio_for_each_page_all(bvec, bio, i) {
+   bio_for_each_page_all2(bvec, bio, i, bia) {
struct page *page = bvec->bv_page;
 #ifdef CONFIG_EXT4_FS_ENCRYPTION
struct page *data_page = NULL;
diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c
index 572b6296f709..c46b5ff68fa8 100644
--- a/fs/ext4/readpage.c
+++ b/fs/ext4/readpage.c
@@ -72,6 +72,7 @@ static void mpage_end_io(struct bio *bio)
 {
struct bio_vec *bv;
int i;
+   struct bvec_iter_all bia;
 
if (ext4_bio_encrypted(bio)) {
if (bio->bi_status) {
@@ -81,7 +82,7 @@ static void mpage_end_io(struct bio *bio)
return;
}
}
-   bio_for_each_page_all(bv, bio, i) {
+   bio_for_each_page_all2(bv, bio, i, bia) {
struct page *page = bv->bv_page;
 
if (!bio->bi_status) {
-- 
2.9.5

Re: [PATCH v13 1/2] cpufreq: Add Kryo CPU scaling driver

[Viresh Kumar]

On 24-05-18, 18:03, Ilia Lin wrote:
> +static int __init qcom_cpufreq_kryo_init(void)
> +{
> + struct device_node *np;
> + struct device *cpu_dev;
> + int ret;
> +
> + cpu_dev = get_cpu_device(0);
> + if (NULL == cpu_dev)
> + ret = -ENODEV;
> +
> + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
> + if (IS_ERR(np))
> + return PTR_ERR(np);
> +
> + ret = of_device_is_compatible(np, "operating-points-v2-kryo-cpu");
> + of_node_put(np);
> + if (!ret)
> + return -ENOENT;
> +

I hate the fact that it is taking so long to get done with this. But can't you
just check machine compatibility instead of this complicated setup to check OPP
node ? Like:

if (!of_device_is_compatible("qcom,apq8096") &&
!of_device_is_compatible("qcom,msm8996"))
return;

And please see if you can add an entry in MAINTAINERS and add your working email
id there.

-- 
viresh

[RESEND PATCH V5 23/33] ext4: conver to bio_for_each_page_all2

[Ming Lei]

bio_for_each_page_all() can't be used any more after multipage bvec is
enabled, so we have to convert to bio_for_each_page_all2().

Signed-off-by: Ming Lei 
---
 fs/ext4/page-io.c  | 3 ++-
 fs/ext4/readpage.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
index 52f2937f5603..b56a733f33c0 100644
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -63,8 +63,9 @@ static void ext4_finish_bio(struct bio *bio)
 {
int i;
struct bio_vec *bvec;
+   struct bvec_iter_all bia;
 
-   bio_for_each_page_all(bvec, bio, i) {
+   bio_for_each_page_all2(bvec, bio, i, bia) {
struct page *page = bvec->bv_page;
 #ifdef CONFIG_EXT4_FS_ENCRYPTION
struct page *data_page = NULL;
diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c
index 572b6296f709..c46b5ff68fa8 100644
--- a/fs/ext4/readpage.c
+++ b/fs/ext4/readpage.c
@@ -72,6 +72,7 @@ static void mpage_end_io(struct bio *bio)
 {
struct bio_vec *bv;
int i;
+   struct bvec_iter_all bia;
 
if (ext4_bio_encrypted(bio)) {
if (bio->bi_status) {
@@ -81,7 +82,7 @@ static void mpage_end_io(struct bio *bio)
return;
}
}
-   bio_for_each_page_all(bv, bio, i) {
+   bio_for_each_page_all2(bv, bio, i, bia) {
struct page *page = bv->bv_page;
 
if (!bio->bi_status) {
-- 
2.9.5

Re: [PATCH v13 1/2] cpufreq: Add Kryo CPU scaling driver

[Viresh Kumar]

On 24-05-18, 18:03, Ilia Lin wrote:
> +static int __init qcom_cpufreq_kryo_init(void)
> +{
> + struct device_node *np;
> + struct device *cpu_dev;
> + int ret;
> +
> + cpu_dev = get_cpu_device(0);
> + if (NULL == cpu_dev)
> + ret = -ENODEV;
> +
> + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
> + if (IS_ERR(np))
> + return PTR_ERR(np);
> +
> + ret = of_device_is_compatible(np, "operating-points-v2-kryo-cpu");
> + of_node_put(np);
> + if (!ret)
> + return -ENOENT;
> +

I hate the fact that it is taking so long to get done with this. But can't you
just check machine compatibility instead of this complicated setup to check OPP
node ? Like:

if (!of_device_is_compatible("qcom,apq8096") &&
!of_device_is_compatible("qcom,msm8996"))
return;

And please see if you can add an entry in MAINTAINERS and add your working email
id there.

-- 
viresh

[RESEND PATCH V5 30/33] block: enable multipage bvecs

[Ming Lei]

This patch pulls the trigger for multipage bvecs.

Now any request queue which supports queue cluster will see multipage
bvecs.

Signed-off-by: Ming Lei 
---
 block/bio.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/block/bio.c b/block/bio.c
index c160c143cc1b..bc3992f52fe8 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -876,6 +876,11 @@ int bio_add_page(struct bio *bio, struct page *page,
 * a consecutive offset.  Optimize this special case.
 */
if (bio->bi_vcnt > 0) {
+   struct request_queue *q = NULL;
+
+   if (bio->bi_disk)
+   q = bio->bi_disk->queue;
+
bv = >bi_io_vec[bio->bi_vcnt - 1];
 
if (page == bv->bv_page &&
@@ -883,6 +888,14 @@ int bio_add_page(struct bio *bio, struct page *page,
bv->bv_len += len;
goto done;
}
+
+   /* disable multipage bvec too if cluster isn't enabled */
+   if (q && blk_queue_cluster(q) &&
+   (bvec_to_phys(bv) + bv->bv_len ==
+page_to_phys(page) + offset)) {
+   bv->bv_len += len;
+   goto done;
+   }
}
 
if (bio->bi_vcnt >= bio->bi_max_vecs)
-- 
2.9.5

[RESEND PATCH V5 30/33] block: enable multipage bvecs

[Ming Lei]

This patch pulls the trigger for multipage bvecs.

Now any request queue which supports queue cluster will see multipage
bvecs.

Signed-off-by: Ming Lei 
---
 block/bio.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/block/bio.c b/block/bio.c
index c160c143cc1b..bc3992f52fe8 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -876,6 +876,11 @@ int bio_add_page(struct bio *bio, struct page *page,
 * a consecutive offset.  Optimize this special case.
 */
if (bio->bi_vcnt > 0) {
+   struct request_queue *q = NULL;
+
+   if (bio->bi_disk)
+   q = bio->bi_disk->queue;
+
bv = >bi_io_vec[bio->bi_vcnt - 1];
 
if (page == bv->bv_page &&
@@ -883,6 +888,14 @@ int bio_add_page(struct bio *bio, struct page *page,
bv->bv_len += len;
goto done;
}
+
+   /* disable multipage bvec too if cluster isn't enabled */
+   if (q && blk_queue_cluster(q) &&
+   (bvec_to_phys(bv) + bv->bv_len ==
+page_to_phys(page) + offset)) {
+   bv->bv_len += len;
+   goto done;
+   }
}
 
if (bio->bi_vcnt >= bio->bi_max_vecs)
-- 
2.9.5