答复: [PATCH] staging: rtsx: Add support for RTS5260

[冯锐]

> On Fri, Oct 13, 2017 at 10:54:22AM +0100, Lee Jones wrote:
> > On Fri, 13 Oct 2017, Greg KH wrote:
> >
> > > On Fri, Oct 13, 2017 at 04:50:35PM +0800, rui_f...@realsil.com.cn wrote:
> > > > From: rui_feng 
> > > >
> > > > Add support for new chip rts5260.
> > > > In order to support rts5260，the definitions of some internal
> > > > registers and workflow have to be modified and are different from
> > > > its predecessors and OCP function is added for RTS5260.
> > > > So we need this patch to ensure RTS5260 can work.
> > > >
> > > > Signed-off-by: Rui Feng 
> > >
> > > Your from and signed-off-by name does not match :(
> > >
> > > > ---
> > > >  drivers/mfd/Makefile  |   4 +
> > > >  drivers/mfd/rtsx_pcr.c| 127 ++-
> > > >  drivers/mfd/rtsx_pcr.h|  12 +
> > > >  drivers/staging/Kconfig   |   2 +
> > > >  drivers/staging/rts5260/Kconfig   |   6 +
> > > >  drivers/staging/rts5260/rts5260.c | 748
> > > > ++
> > > >  drivers/staging/rts5260/rts5260.h |  45 +++
> > > >  include/linux/mfd/rtsx_pci.h  | 234 +++-
> > >
> > > I do not see a reason why this is a staging driver.  Where is the
> > > TODO file listing what needs to be done to get it out of staging?
> > > Why can it not just go into the "real" part of the kernel?
> >
> > It's not a staging driver.  Rui's focus appears to be to have this
> > driver accepted into Mainline by hook or by crock.  He's tried MFD,
> > Misc and now Staging!
> 
> Yeah, I've watched it too :)
> 
> > Background:
> >
> > There are a number of drivers in this family which currently reside in
> > MFD.  These were accepted before my time.  After a recent review I've
> > made the decision that these aren't MFD drivers at all.
> >
> > MFD drivers are ones which aid in registering and setting up shared
> > resources for sub-devices which reside on the same piece of silicon.
> > This driver does basically none of that.  Instead it *is* the (what we
> > describe above as) sub-device.  It does everything.
> 
> I agree with your assessment.
> 
> > In the absence of a subsystem which covers this type of device, I
> > suggested Misk as a good location to place these drivers.
> 
> What type of device is this thing?  I can't seem to figure that out.  If we 
> can
> determine that, then we can find the proper place for it in the kernel.
> 
> Rui, what does this hardware do?  What is the interface between the
> hardware and userspace that this driver is creating?
> 
This driver is a pcie driver, it bridge mmc subsystem and memstick subsystem, 
and it does not deal with userspace.

> thanks,
> 
> greg k-h
> 
> --Please consider the environment before printing this e-mail.

答复: [PATCH] staging: rtsx: Add support for RTS5260

[冯锐]

> On Fri, Oct 13, 2017 at 10:54:22AM +0100, Lee Jones wrote:
> > On Fri, 13 Oct 2017, Greg KH wrote:
> >
> > > On Fri, Oct 13, 2017 at 04:50:35PM +0800, rui_f...@realsil.com.cn wrote:
> > > > From: rui_feng 
> > > >
> > > > Add support for new chip rts5260.
> > > > In order to support rts5260，the definitions of some internal
> > > > registers and workflow have to be modified and are different from
> > > > its predecessors and OCP function is added for RTS5260.
> > > > So we need this patch to ensure RTS5260 can work.
> > > >
> > > > Signed-off-by: Rui Feng 
> > >
> > > Your from and signed-off-by name does not match :(
> > >
> > > > ---
> > > >  drivers/mfd/Makefile  |   4 +
> > > >  drivers/mfd/rtsx_pcr.c| 127 ++-
> > > >  drivers/mfd/rtsx_pcr.h|  12 +
> > > >  drivers/staging/Kconfig   |   2 +
> > > >  drivers/staging/rts5260/Kconfig   |   6 +
> > > >  drivers/staging/rts5260/rts5260.c | 748
> > > > ++
> > > >  drivers/staging/rts5260/rts5260.h |  45 +++
> > > >  include/linux/mfd/rtsx_pci.h  | 234 +++-
> > >
> > > I do not see a reason why this is a staging driver.  Where is the
> > > TODO file listing what needs to be done to get it out of staging?
> > > Why can it not just go into the "real" part of the kernel?
> >
> > It's not a staging driver.  Rui's focus appears to be to have this
> > driver accepted into Mainline by hook or by crock.  He's tried MFD,
> > Misc and now Staging!
> 
> Yeah, I've watched it too :)
> 
> > Background:
> >
> > There are a number of drivers in this family which currently reside in
> > MFD.  These were accepted before my time.  After a recent review I've
> > made the decision that these aren't MFD drivers at all.
> >
> > MFD drivers are ones which aid in registering and setting up shared
> > resources for sub-devices which reside on the same piece of silicon.
> > This driver does basically none of that.  Instead it *is* the (what we
> > describe above as) sub-device.  It does everything.
> 
> I agree with your assessment.
> 
> > In the absence of a subsystem which covers this type of device, I
> > suggested Misk as a good location to place these drivers.
> 
> What type of device is this thing?  I can't seem to figure that out.  If we 
> can
> determine that, then we can find the proper place for it in the kernel.
> 
> Rui, what does this hardware do?  What is the interface between the
> hardware and userspace that this driver is creating?
> 
This driver is a pcie driver, it bridge mmc subsystem and memstick subsystem, 
and it does not deal with userspace.

> thanks,
> 
> greg k-h
> 
> --Please consider the environment before printing this e-mail.

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

[Julia Lawall]

On Sun, 15 Oct 2017, Gang He wrote:

> Hello Intel Kbuild team,
>
> You just upgrade GCC version when compiling the latest kernel?
> Since these code looks a little old, I am sure that the related contributors 
> are still work on OCFS2 project.

I'm not sure to understand the comment.  The report is due to the fact
that Bhumika's patch depends on other patches that have not been applied
yet.

julia


>
>
> Thanks
> Gang
>
>
> >>>
> > Hi Bhumika,
> >
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on v4.14-rc4 next-20171013]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improve the system]
> >
> > url:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_l
> > inux_commits_Bhumika-2DGoyal_ocfs2-2Dcluster-2Dmake-2Dconfig-5Fitem-5Ftype-2Dconst_2
> > 0171014-2D185701=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=f4ohdmG
> > rYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrjbR5Spv4mvmdj2s377WohnG6h6z1
> > WB7E=hFVfDC8STTMTIDNtdipf8BlwR_V8RJG6an_l-r9MKyA=
> > config: tile-allyesconfig (attached as .config)
> > compiler: tilegx-linux-gcc (GCC) 4.6.2
> > reproduce:
> > wget
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.c
> > om_intel_lkp-2Dtests_master_sbin_make.cross=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxB
> > KCX5YTpkKY057SbK10=f4ohdmGrYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrj
> > bR5Spv4mvmdj2s377WohnG6h6z1WB7E=f5lUGF9NCtygTaG6AR0HkjhG7fOwD5nKFLaYCvPpju0
> > =  -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=tile
> >
> > All warnings (new ones prefixed by >>):
> >
> >fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_node_group_make_item':
> >fs/ocfs2/cluster/nodemanager.c:573:2: warning: passing argument 3 of
> > 'config_item_init_type_name' discards 'const' qualifier from pointer target
> > type [enabled by default]
> >include/linux/configfs.h:73:13: note: expected 'struct config_item_type
> > *' but argument is of type 'const struct config_item_type *'
> >fs/ocfs2/cluster/nodemanager.c: In function
> > 'o2nm_cluster_group_make_group':
> >fs/ocfs2/cluster/nodemanager.c:681:9: warning: passing argument 3 of
> > 'config_group_init_type_name' discards 'const' qualifier from pointer target
> > type [enabled by default]
> >include/linux/configfs.h:102:13: note: expected 'struct config_item_type
> > *' but argument is of type 'const struct config_item_type *'
> >fs/ocfs2/cluster/nodemanager.c:685:9: warning: passing argument 3 of
> > 'config_group_init_type_name' discards 'const' qualifier from pointer target
> > type [enabled by default]
> >include/linux/configfs.h:102:13: note: expected 'struct config_item_type
> > *' but argument is of type 'const struct config_item_type *'
> >fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_depend_item':
> >fs/ocfs2/cluster/nodemanager.c:743:2: warning: passing argument 1 of
> > 'configfs_depend_item' discards 'const' qualifier from pointer target type
> > [enabled by default]
> >include/linux/configfs.h:269:5: note: expected 'struct configfs_subsystem
> > *' but argument is of type 'const struct configfs_subsystem *'
> >fs/ocfs2/cluster/nodemanager.c: In function 'exit_o2nm':
> >fs/ocfs2/cluster/nodemanager.c:785:2: warning: passing argument 1 of
> > 'configfs_unregister_subsystem' discards 'const' qualifier from pointer
> > target type [enabled by default]
> >include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem
> > *' but argument is of type 'const struct configfs_subsystem *'
> >fs/ocfs2/cluster/nodemanager.c: In function 'init_o2nm':
> >fs/ocfs2/cluster/nodemanager.c:808:2: warning: passing argument 1 of
> > 'config_group_init' discards 'const' qualifier from pointer target type
> > [enabled by default]
> >include/linux/configfs.h:101:13: note: expected 'struct config_group *'
> > but argument is of type 'const struct config_group *'
> >>> fs/ocfs2/cluster/nodemanager.c:809:2: warning: passing argument 1 of
> > '__mutex_init' discards 'const' qualifier from pointer target type [enabled
> > by default]
> >include/linux/mutex.h:133:13: note: expected 'struct mutex *' but
> > argument is of type 'const struct mutex *'
> >fs/ocfs2/cluster/nodemanager.c:810:2: warning: passing argument 1 of
> > 'configfs_register_subsystem' discards 'const' qualifier from pointer target
> > type [enabled by default]
> >include/linux/configfs.h:252:5: note: expected 'struct configfs_subsystem
> > *' but argument is of type 'const struct configfs_subsystem *'
> >fs/ocfs2/cluster/nodemanager.c:820:2: warning: passing argument 1 of
> > 'configfs_unregister_subsystem' discards 'const' qualifier from pointer
> > target type [enabled by default]
> >include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem
> > *' but argument is of type 'const 

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

[Julia Lawall]

On Sun, 15 Oct 2017, Gang He wrote:

> Hello Intel Kbuild team,
>
> You just upgrade GCC version when compiling the latest kernel?
> Since these code looks a little old, I am sure that the related contributors 
> are still work on OCFS2 project.

I'm not sure to understand the comment.  The report is due to the fact
that Bhumika's patch depends on other patches that have not been applied
yet.

julia


>
>
> Thanks
> Gang
>
>
> >>>
> > Hi Bhumika,
> >
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on v4.14-rc4 next-20171013]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improve the system]
> >
> > url:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_l
> > inux_commits_Bhumika-2DGoyal_ocfs2-2Dcluster-2Dmake-2Dconfig-5Fitem-5Ftype-2Dconst_2
> > 0171014-2D185701=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=f4ohdmG
> > rYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrjbR5Spv4mvmdj2s377WohnG6h6z1
> > WB7E=hFVfDC8STTMTIDNtdipf8BlwR_V8RJG6an_l-r9MKyA=
> > config: tile-allyesconfig (attached as .config)
> > compiler: tilegx-linux-gcc (GCC) 4.6.2
> > reproduce:
> > wget
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.c
> > om_intel_lkp-2Dtests_master_sbin_make.cross=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxB
> > KCX5YTpkKY057SbK10=f4ohdmGrYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrj
> > bR5Spv4mvmdj2s377WohnG6h6z1WB7E=f5lUGF9NCtygTaG6AR0HkjhG7fOwD5nKFLaYCvPpju0
> > =  -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=tile
> >
> > All warnings (new ones prefixed by >>):
> >
> >fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_node_group_make_item':
> >fs/ocfs2/cluster/nodemanager.c:573:2: warning: passing argument 3 of
> > 'config_item_init_type_name' discards 'const' qualifier from pointer target
> > type [enabled by default]
> >include/linux/configfs.h:73:13: note: expected 'struct config_item_type
> > *' but argument is of type 'const struct config_item_type *'
> >fs/ocfs2/cluster/nodemanager.c: In function
> > 'o2nm_cluster_group_make_group':
> >fs/ocfs2/cluster/nodemanager.c:681:9: warning: passing argument 3 of
> > 'config_group_init_type_name' discards 'const' qualifier from pointer target
> > type [enabled by default]
> >include/linux/configfs.h:102:13: note: expected 'struct config_item_type
> > *' but argument is of type 'const struct config_item_type *'
> >fs/ocfs2/cluster/nodemanager.c:685:9: warning: passing argument 3 of
> > 'config_group_init_type_name' discards 'const' qualifier from pointer target
> > type [enabled by default]
> >include/linux/configfs.h:102:13: note: expected 'struct config_item_type
> > *' but argument is of type 'const struct config_item_type *'
> >fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_depend_item':
> >fs/ocfs2/cluster/nodemanager.c:743:2: warning: passing argument 1 of
> > 'configfs_depend_item' discards 'const' qualifier from pointer target type
> > [enabled by default]
> >include/linux/configfs.h:269:5: note: expected 'struct configfs_subsystem
> > *' but argument is of type 'const struct configfs_subsystem *'
> >fs/ocfs2/cluster/nodemanager.c: In function 'exit_o2nm':
> >fs/ocfs2/cluster/nodemanager.c:785:2: warning: passing argument 1 of
> > 'configfs_unregister_subsystem' discards 'const' qualifier from pointer
> > target type [enabled by default]
> >include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem
> > *' but argument is of type 'const struct configfs_subsystem *'
> >fs/ocfs2/cluster/nodemanager.c: In function 'init_o2nm':
> >fs/ocfs2/cluster/nodemanager.c:808:2: warning: passing argument 1 of
> > 'config_group_init' discards 'const' qualifier from pointer target type
> > [enabled by default]
> >include/linux/configfs.h:101:13: note: expected 'struct config_group *'
> > but argument is of type 'const struct config_group *'
> >>> fs/ocfs2/cluster/nodemanager.c:809:2: warning: passing argument 1 of
> > '__mutex_init' discards 'const' qualifier from pointer target type [enabled
> > by default]
> >include/linux/mutex.h:133:13: note: expected 'struct mutex *' but
> > argument is of type 'const struct mutex *'
> >fs/ocfs2/cluster/nodemanager.c:810:2: warning: passing argument 1 of
> > 'configfs_register_subsystem' discards 'const' qualifier from pointer target
> > type [enabled by default]
> >include/linux/configfs.h:252:5: note: expected 'struct configfs_subsystem
> > *' but argument is of type 'const struct configfs_subsystem *'
> >fs/ocfs2/cluster/nodemanager.c:820:2: warning: passing argument 1 of
> > 'configfs_unregister_subsystem' discards 'const' qualifier from pointer
> > target type [enabled by default]
> >include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem
> > *' but argument is of type 'const 

[tip:x86/asm 4/5] drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.o: warning: objtool: kiblnd_post_tx_locked()+0x94: stack state mismatch: cfa1=7+224 cfa2=7+208

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/asm
head:   fc72ae40e30327aa24eb88a24b9c7058f938bd36
commit: 11af847446ed0d131cf24d16a7ef3d5ea7a49554 [4/5] x86/unwind: Rename 
unwinder config options to 'CONFIG_UNWINDER_*'
config: x86_64-randconfig-a0-10161235 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 11af847446ed0d131cf24d16a7ef3d5ea7a49554
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.o: warning: objtool: 
>> kiblnd_post_tx_locked()+0x94: stack state mismatch: cfa1=7+224 cfa2=7+208

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


.config.gz
Description: application/gzip

[tip:x86/asm 4/5] drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.o: warning: objtool: kiblnd_post_tx_locked()+0x94: stack state mismatch: cfa1=7+224 cfa2=7+208

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/asm
head:   fc72ae40e30327aa24eb88a24b9c7058f938bd36
commit: 11af847446ed0d131cf24d16a7ef3d5ea7a49554 [4/5] x86/unwind: Rename 
unwinder config options to 'CONFIG_UNWINDER_*'
config: x86_64-randconfig-a0-10161235 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 11af847446ed0d131cf24d16a7ef3d5ea7a49554
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.o: warning: objtool: 
>> kiblnd_post_tx_locked()+0x94: stack state mismatch: cfa1=7+224 cfa2=7+208

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


.config.gz
Description: application/gzip

Re: [PATCH] scsi: qedi: Delete redundant variables

[Rangankar, Manish]

On 14/10/17 5:47 PM, "Christos Gkekas"  wrote:

>Remove redundant variables in quedi_fw.c that are set but not used.
>
>Signed-off-by: Christos Gkekas 
>---
> drivers/scsi/qedi/qedi_fw.c | 17 +
> 1 file changed, 1 insertion(+), 16 deletions(-)
>
>diff --git a/drivers/scsi/qedi/qedi_fw.c b/drivers/scsi/qedi/qedi_fw.c
>index 93d54ac..bd302d3 100644
>--- a/drivers/scsi/qedi/qedi_fw.c
>+++ b/drivers/scsi/qedi/qedi_fw.c
>@@ -92,7 +92,6 @@ static void qedi_process_text_resp(struct qedi_ctx
>*qedi,
>   struct iscsi_text_response_hdr *cqe_text_response;
>   struct qedi_cmd *cmd;
>   int pld_len;
>-  u32 *tmp;
> 
>   cmd = (struct qedi_cmd *)task->dd_data;
>   task_ctx = qedi_get_task_mem(>tasks, cmd->task_id);
>@@ -108,7 +107,6 @@ static void qedi_process_text_resp(struct qedi_ctx
>*qedi,
>   hton24(resp_hdr_ptr->dlength,
>  (cqe_text_response->hdr_second_dword &
>   ISCSI_TEXT_RESPONSE_HDR_DATA_SEG_LEN_MASK));
>-  tmp = (u32 *)resp_hdr_ptr->dlength;
> 
>   resp_hdr_ptr->itt = build_itt(cqe->cqe_solicited.itid,
> conn->session->age);
>@@ -196,7 +194,6 @@ static void qedi_process_tmf_resp(struct qedi_ctx
>*qedi,
>   struct iscsi_tm_rsp *resp_hdr_ptr;
>   struct iscsi_tm *tmf_hdr;
>   struct qedi_cmd *qedi_cmd = NULL;
>-  u32 *tmp;
> 
>   cqe_tmp_response = >cqe_common.iscsi_hdr.tmf_response;
> 
>@@ -222,7 +219,6 @@ static void qedi_process_tmf_resp(struct qedi_ctx
>*qedi,
>   hton24(resp_hdr_ptr->dlength,
>  (cqe_tmp_response->hdr_second_dword &
>   ISCSI_TMF_RESPONSE_HDR_DATA_SEG_LEN_MASK));
>-  tmp = (u32 *)resp_hdr_ptr->dlength;
>   resp_hdr_ptr->itt = build_itt(cqe->cqe_solicited.itid,
> conn->session->age);
>   resp_hdr_ptr->statsn = cpu_to_be32(cqe_tmp_response->stat_sn);
>@@ -269,7 +265,6 @@ static void qedi_process_login_resp(struct qedi_ctx
>*qedi,
>   struct iscsi_login_response_hdr *cqe_login_response;
>   struct qedi_cmd *cmd;
>   int pld_len;
>-  u32 *tmp;
> 
>   cmd = (struct qedi_cmd *)task->dd_data;
> 
>@@ -286,7 +281,6 @@ static void qedi_process_login_resp(struct qedi_ctx
>*qedi,
>   hton24(resp_hdr_ptr->dlength,
>  (cqe_login_response->hdr_second_dword &
>   ISCSI_LOGIN_RESPONSE_HDR_DATA_SEG_LEN_MASK));
>-  tmp = (u32 *)resp_hdr_ptr->dlength;
>   resp_hdr_ptr->itt = build_itt(cqe->cqe_solicited.itid,
> conn->session->age);
>   resp_hdr_ptr->tsih = cqe_login_response->tsih;
>@@ -590,7 +584,6 @@ static void qedi_scsi_completion(struct qedi_ctx
>*qedi,
>   int datalen = 0;
>   struct qedi_conn *qedi_conn;
>   u32 iscsi_cid;
>-  bool mark_cmd_node_deleted = false;
>   u8 cqe_err_bits = 0;
> 
>   iscsi_cid  = cqe->cqe_common.conn_id;
>@@ -674,7 +667,6 @@ static void qedi_scsi_completion(struct qedi_ctx
>*qedi,
>   cmd->io_cmd_in_list = false;
>   list_del_init(>io_cmd);
>   qedi_conn->active_cmd_count--;
>-  mark_cmd_node_deleted = true;
>   }
>   spin_unlock(_conn->list_lock);
> 
>@@ -763,7 +755,7 @@ static void qedi_process_cmd_cleanup_resp(struct
>qedi_ctx *qedi,
>   u32 rtid = 0;
>   u32 iscsi_cid;
>   struct qedi_conn *qedi_conn;
>-  struct qedi_cmd *cmd_new, *dbg_cmd;
>+  struct qedi_cmd *dbg_cmd;
>   struct iscsi_task *mtask;
>   struct iscsi_tm *tmf_hdr = NULL;
> 
>@@ -856,7 +848,6 @@ static void qedi_process_cmd_cleanup_resp(struct
>qedi_ctx *qedi,
>   }
>   qedi_conn->cmd_cleanup_cmpl++;
>   wake_up(_conn->wait_queue);
>-  cmd_new = task->dd_data;
> 
>   QEDI_INFO(>dbg_ctx, QEDI_LOG_TID,
> "Freeing tid=0x%x for cid=0x%x\n",
>@@ -1029,7 +1020,6 @@ int qedi_send_iscsi_login(struct qedi_conn
>*qedi_conn,
>   struct iscsi_task_context *fw_task_ctx;
>   struct qedi_ctx *qedi = qedi_conn->qedi;
>   struct iscsi_login_req *login_hdr;
>-  struct scsi_sge *req_sge = NULL;
>   struct scsi_sge *resp_sge = NULL;
>   struct qedi_cmd *qedi_cmd;
>   struct qedi_endpoint *ep;
>@@ -1037,7 +1027,6 @@ int qedi_send_iscsi_login(struct qedi_conn
>*qedi_conn,
>   u16 sq_idx = 0;
>   int rval = 0;
> 
>-  req_sge = (struct scsi_sge *)qedi_conn->gen_pdu.req_bd_tbl;
>   resp_sge = (struct scsi_sge *)qedi_conn->gen_pdu.resp_bd_tbl;
>   qedi_cmd = (struct qedi_cmd *)task->dd_data;
>   ep = qedi_conn->ep;
>@@ -1718,7 +1707,6 @@ int qedi_send_iscsi_nopout(struct qedi_conn
>*qedi_conn,
>   struct qedi_ctx *qedi = qedi_conn->qedi;
>   struct iscsi_task_context *fw_task_ctx;
>   struct iscsi_nopout *nopout_hdr;
>-  struct scsi_sge *req_sge = NULL;
>   struct scsi_sge *resp_sge = NULL;
>   struct qedi_cmd *qedi_cmd;

Re: [PATCH] scsi: qedi: Delete redundant variables

[Rangankar, Manish]

On 14/10/17 5:47 PM, "Christos Gkekas"  wrote:

>Remove redundant variables in quedi_fw.c that are set but not used.
>
>Signed-off-by: Christos Gkekas 
>---
> drivers/scsi/qedi/qedi_fw.c | 17 +
> 1 file changed, 1 insertion(+), 16 deletions(-)
>
>diff --git a/drivers/scsi/qedi/qedi_fw.c b/drivers/scsi/qedi/qedi_fw.c
>index 93d54ac..bd302d3 100644
>--- a/drivers/scsi/qedi/qedi_fw.c
>+++ b/drivers/scsi/qedi/qedi_fw.c
>@@ -92,7 +92,6 @@ static void qedi_process_text_resp(struct qedi_ctx
>*qedi,
>   struct iscsi_text_response_hdr *cqe_text_response;
>   struct qedi_cmd *cmd;
>   int pld_len;
>-  u32 *tmp;
> 
>   cmd = (struct qedi_cmd *)task->dd_data;
>   task_ctx = qedi_get_task_mem(>tasks, cmd->task_id);
>@@ -108,7 +107,6 @@ static void qedi_process_text_resp(struct qedi_ctx
>*qedi,
>   hton24(resp_hdr_ptr->dlength,
>  (cqe_text_response->hdr_second_dword &
>   ISCSI_TEXT_RESPONSE_HDR_DATA_SEG_LEN_MASK));
>-  tmp = (u32 *)resp_hdr_ptr->dlength;
> 
>   resp_hdr_ptr->itt = build_itt(cqe->cqe_solicited.itid,
> conn->session->age);
>@@ -196,7 +194,6 @@ static void qedi_process_tmf_resp(struct qedi_ctx
>*qedi,
>   struct iscsi_tm_rsp *resp_hdr_ptr;
>   struct iscsi_tm *tmf_hdr;
>   struct qedi_cmd *qedi_cmd = NULL;
>-  u32 *tmp;
> 
>   cqe_tmp_response = >cqe_common.iscsi_hdr.tmf_response;
> 
>@@ -222,7 +219,6 @@ static void qedi_process_tmf_resp(struct qedi_ctx
>*qedi,
>   hton24(resp_hdr_ptr->dlength,
>  (cqe_tmp_response->hdr_second_dword &
>   ISCSI_TMF_RESPONSE_HDR_DATA_SEG_LEN_MASK));
>-  tmp = (u32 *)resp_hdr_ptr->dlength;
>   resp_hdr_ptr->itt = build_itt(cqe->cqe_solicited.itid,
> conn->session->age);
>   resp_hdr_ptr->statsn = cpu_to_be32(cqe_tmp_response->stat_sn);
>@@ -269,7 +265,6 @@ static void qedi_process_login_resp(struct qedi_ctx
>*qedi,
>   struct iscsi_login_response_hdr *cqe_login_response;
>   struct qedi_cmd *cmd;
>   int pld_len;
>-  u32 *tmp;
> 
>   cmd = (struct qedi_cmd *)task->dd_data;
> 
>@@ -286,7 +281,6 @@ static void qedi_process_login_resp(struct qedi_ctx
>*qedi,
>   hton24(resp_hdr_ptr->dlength,
>  (cqe_login_response->hdr_second_dword &
>   ISCSI_LOGIN_RESPONSE_HDR_DATA_SEG_LEN_MASK));
>-  tmp = (u32 *)resp_hdr_ptr->dlength;
>   resp_hdr_ptr->itt = build_itt(cqe->cqe_solicited.itid,
> conn->session->age);
>   resp_hdr_ptr->tsih = cqe_login_response->tsih;
>@@ -590,7 +584,6 @@ static void qedi_scsi_completion(struct qedi_ctx
>*qedi,
>   int datalen = 0;
>   struct qedi_conn *qedi_conn;
>   u32 iscsi_cid;
>-  bool mark_cmd_node_deleted = false;
>   u8 cqe_err_bits = 0;
> 
>   iscsi_cid  = cqe->cqe_common.conn_id;
>@@ -674,7 +667,6 @@ static void qedi_scsi_completion(struct qedi_ctx
>*qedi,
>   cmd->io_cmd_in_list = false;
>   list_del_init(>io_cmd);
>   qedi_conn->active_cmd_count--;
>-  mark_cmd_node_deleted = true;
>   }
>   spin_unlock(_conn->list_lock);
> 
>@@ -763,7 +755,7 @@ static void qedi_process_cmd_cleanup_resp(struct
>qedi_ctx *qedi,
>   u32 rtid = 0;
>   u32 iscsi_cid;
>   struct qedi_conn *qedi_conn;
>-  struct qedi_cmd *cmd_new, *dbg_cmd;
>+  struct qedi_cmd *dbg_cmd;
>   struct iscsi_task *mtask;
>   struct iscsi_tm *tmf_hdr = NULL;
> 
>@@ -856,7 +848,6 @@ static void qedi_process_cmd_cleanup_resp(struct
>qedi_ctx *qedi,
>   }
>   qedi_conn->cmd_cleanup_cmpl++;
>   wake_up(_conn->wait_queue);
>-  cmd_new = task->dd_data;
> 
>   QEDI_INFO(>dbg_ctx, QEDI_LOG_TID,
> "Freeing tid=0x%x for cid=0x%x\n",
>@@ -1029,7 +1020,6 @@ int qedi_send_iscsi_login(struct qedi_conn
>*qedi_conn,
>   struct iscsi_task_context *fw_task_ctx;
>   struct qedi_ctx *qedi = qedi_conn->qedi;
>   struct iscsi_login_req *login_hdr;
>-  struct scsi_sge *req_sge = NULL;
>   struct scsi_sge *resp_sge = NULL;
>   struct qedi_cmd *qedi_cmd;
>   struct qedi_endpoint *ep;
>@@ -1037,7 +1027,6 @@ int qedi_send_iscsi_login(struct qedi_conn
>*qedi_conn,
>   u16 sq_idx = 0;
>   int rval = 0;
> 
>-  req_sge = (struct scsi_sge *)qedi_conn->gen_pdu.req_bd_tbl;
>   resp_sge = (struct scsi_sge *)qedi_conn->gen_pdu.resp_bd_tbl;
>   qedi_cmd = (struct qedi_cmd *)task->dd_data;
>   ep = qedi_conn->ep;
>@@ -1718,7 +1707,6 @@ int qedi_send_iscsi_nopout(struct qedi_conn
>*qedi_conn,
>   struct qedi_ctx *qedi = qedi_conn->qedi;
>   struct iscsi_task_context *fw_task_ctx;
>   struct iscsi_nopout *nopout_hdr;
>-  struct scsi_sge *req_sge = NULL;
>   struct scsi_sge *resp_sge = NULL;
>   struct qedi_cmd *qedi_cmd;
>   struct qedi_endpoint *ep;
>@@ -1727,7 

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

[Li, Aubrey]

On 2017/10/16 12:45, Mike Galbraith wrote:
> On Mon, 2017-10-16 at 11:26 +0800, Li, Aubrey wrote:
>>
>> I'll try to move quiet_vmstat() into the normal idle branch if this patch 
>> series
>> are reasonable. Is fast_idle a good indication for it?
> 
> see x86_tip 62cb1188ed86 sched/idle: Move quiet_vmstate() into the NOHZ code

It looks like this commit makes tick stop critical as it can be invoked in 
interrupt
exit path?

->smp_apic_timer_interrupt
-->irq_exit
--->tick_nohz_irq_exit
>__tick_nohz_idle_enter
->tick_nohz_stop_sched_tick
-->quiet_vmstat

Thanks,
-Aubrey

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

[Li, Aubrey]

On 2017/10/16 12:45, Mike Galbraith wrote:
> On Mon, 2017-10-16 at 11:26 +0800, Li, Aubrey wrote:
>>
>> I'll try to move quiet_vmstat() into the normal idle branch if this patch 
>> series
>> are reasonable. Is fast_idle a good indication for it?
> 
> see x86_tip 62cb1188ed86 sched/idle: Move quiet_vmstate() into the NOHZ code

It looks like this commit makes tick stop critical as it can be invoked in 
interrupt
exit path?

->smp_apic_timer_interrupt
-->irq_exit
--->tick_nohz_irq_exit
>__tick_nohz_idle_enter
->tick_nohz_stop_sched_tick
-->quiet_vmstat

Thanks,
-Aubrey

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Lukas Wunner]

On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> + :c:func:`dev_pm_set_driver_flags` helper function.]  If the first of
> + tese flags is set, the PM core will not apply the direct-complete
^
these

> + proceudre described above to the given device and, consequenty, to any
^
procedure

Lukas

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Lukas Wunner]

On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> + :c:func:`dev_pm_set_driver_flags` helper function.]  If the first of
> + tese flags is set, the PM core will not apply the direct-complete
^
these

> + proceudre described above to the given device and, consequenty, to any
^
procedure

Lukas

[PATCH] dmaengine: rcar-dmac: read DMATCRB instead of DMATCR for residue

[Kuninori Morimoto]

From: Kuninori Morimoto 

SYS/RT/Audio DMAC have both TCR/TCRB register.
Its difference is transfer counter value of read (= TCR)
or write (= TCRB). The relationship is like below.

 TCR   TCRB
 [SOURCE] -> [DMAC] -> [DESTINATION]

Thus, we want to read TCRB instead of TCR for residue.
Otherwise, Sound Capture has noise after PluseAudio support
(= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate"))

Signed-off-by: Hiroyuki Yokoyama 
[Kuninori: added detail information in log]
Signed-off-by: Kuninori Morimoto 
---
 drivers/dma/sh/rcar-dmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 2b2c7db..50c4950 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1310,7 +1310,7 @@ static unsigned int rcar_dmac_chan_get_residue(struct 
rcar_dmac_chan *chan,
}
 
/* Add the residue for the current chunk. */
-   residue += rcar_dmac_chan_read(chan, RCAR_DMATCR) << desc->xfer_shift;
+   residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift;
 
return residue;
 }
-- 
1.9.1

[PATCH] dmaengine: rcar-dmac: read DMATCRB instead of DMATCR for residue

[Kuninori Morimoto]

From: Kuninori Morimoto 

SYS/RT/Audio DMAC have both TCR/TCRB register.
Its difference is transfer counter value of read (= TCR)
or write (= TCRB). The relationship is like below.

 TCR   TCRB
 [SOURCE] -> [DMAC] -> [DESTINATION]

Thus, we want to read TCRB instead of TCR for residue.
Otherwise, Sound Capture has noise after PluseAudio support
(= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate"))

Signed-off-by: Hiroyuki Yokoyama 
[Kuninori: added detail information in log]
Signed-off-by: Kuninori Morimoto 
---
 drivers/dma/sh/rcar-dmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 2b2c7db..50c4950 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1310,7 +1310,7 @@ static unsigned int rcar_dmac_chan_get_residue(struct 
rcar_dmac_chan *chan,
}
 
/* Add the residue for the current chunk. */
-   residue += rcar_dmac_chan_read(chan, RCAR_DMATCR) << desc->xfer_shift;
+   residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift;
 
return residue;
 }
-- 
1.9.1

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

[Marian Mihailescu]

I am using 4.14-rc4 with a patch on top that includes
arch/arm/include/asm/dma-mapping.h in a module.

I have MMU enabled, so
select DMA_NOOP_OPS if !MMU
does nothing for me, and I get a compile error because dma_noop_ops is unknown.

Maybe I should include linux/dma-mapping.h?

Thanks for the quick reply.


On Mon, Oct 16, 2017 at 2:28 PM, Randy Dunlap  wrote:
> On 10/15/17 20:29, Randy Dunlap wrote:
>> On 10/15/17 20:27, Randy Dunlap wrote:
>>> On 10/15/17 19:27, Marian Mihailescu wrote:
 After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
 are built only for architectures that use it.

 For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
 be selected.
>
> What kernel version are you looking at?
> I see that it is selected:
>
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -22,6 +22,7 @@ config ARM
> select CLONE_BACKWARDS
> select CPU_PM if (SUSPEND || CPU_IDLE)
> select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
> +   select DMA_NOOP_OPS if !MMU
> select EDAC_SUPPORT
> select EDAC_ATOMIC_SCRUB
> select GENERIC_ALLOCATOR
>
>
> That's in commit ID 1c51c429f30ea10428337f3a33c12059ba59f668 from May 24, 
> 2017.
>
 However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:

 static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
 *bus)
 {
 return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
 }

 I will let a maintainer suggest the best resolution for this :)

>>>
>>> add Bart and iommu mailing list.
>>>
>>
>> and add Vladimir.
>>
>>
>
>
> --
> ~Randy

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

[Marian Mihailescu]

I am using 4.14-rc4 with a patch on top that includes
arch/arm/include/asm/dma-mapping.h in a module.

I have MMU enabled, so
select DMA_NOOP_OPS if !MMU
does nothing for me, and I get a compile error because dma_noop_ops is unknown.

Maybe I should include linux/dma-mapping.h?

Thanks for the quick reply.


On Mon, Oct 16, 2017 at 2:28 PM, Randy Dunlap  wrote:
> On 10/15/17 20:29, Randy Dunlap wrote:
>> On 10/15/17 20:27, Randy Dunlap wrote:
>>> On 10/15/17 19:27, Marian Mihailescu wrote:
 After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
 are built only for architectures that use it.

 For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
 be selected.
>
> What kernel version are you looking at?
> I see that it is selected:
>
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -22,6 +22,7 @@ config ARM
> select CLONE_BACKWARDS
> select CPU_PM if (SUSPEND || CPU_IDLE)
> select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
> +   select DMA_NOOP_OPS if !MMU
> select EDAC_SUPPORT
> select EDAC_ATOMIC_SCRUB
> select GENERIC_ALLOCATOR
>
>
> That's in commit ID 1c51c429f30ea10428337f3a33c12059ba59f668 from May 24, 
> 2017.
>
 However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:

 static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
 *bus)
 {
 return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
 }

 I will let a maintainer suggest the best resolution for this :)

>>>
>>> add Bart and iommu mailing list.
>>>
>>
>> and add Vladimir.
>>
>>
>
>
> --
> ~Randy

Re: [PATCH v2] usb: musb: sunxi: Explicitly release USB PHY on exit

[Jonathan Liu]

On 10 October 2017 at 14:22, Bin Liu  wrote:
> On Tue, Oct 10, 2017 at 01:45:25PM +1100, Jonathan Liu wrote:
>> This fixes a kernel oops when unloading the driver due to usb_put_phy
>> being called after usb_phy_generic_unregister when the device is
>> detached. Calling usb_phy_generic_unregister causes x->dev->driver to
>> be NULL in usb_put_phy and results in a NULL pointer dereference.
>>
>> Cc: sta...@vger.kernel.org # v4.3+
>> Signed-off-by: Jonathan Liu 
>> ---
>> Changes for v2:
>>  - Use devm_usb_put_phy instead of usb_put_phy
>>
>>  drivers/usb/musb/sunxi.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
>> index c9a09b5bb6e5..dc353e24d53c 100644
>> --- a/drivers/usb/musb/sunxi.c
>> +++ b/drivers/usb/musb/sunxi.c
>> @@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
>>   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
>>   sunxi_sram_release(musb->controller->parent);
>>
>> + devm_usb_put_phy(glue->dev, glue->xceiv);
>> +
>>   return 0;
>>  }
>
>

> Applied. Thanks.
> -Bin.

Which repository was it applied to?

Regards,
Jonathan

Re: [PATCH v2] usb: musb: sunxi: Explicitly release USB PHY on exit

[Jonathan Liu]

On 10 October 2017 at 14:22, Bin Liu  wrote:
> On Tue, Oct 10, 2017 at 01:45:25PM +1100, Jonathan Liu wrote:
>> This fixes a kernel oops when unloading the driver due to usb_put_phy
>> being called after usb_phy_generic_unregister when the device is
>> detached. Calling usb_phy_generic_unregister causes x->dev->driver to
>> be NULL in usb_put_phy and results in a NULL pointer dereference.
>>
>> Cc: sta...@vger.kernel.org # v4.3+
>> Signed-off-by: Jonathan Liu 
>> ---
>> Changes for v2:
>>  - Use devm_usb_put_phy instead of usb_put_phy
>>
>>  drivers/usb/musb/sunxi.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
>> index c9a09b5bb6e5..dc353e24d53c 100644
>> --- a/drivers/usb/musb/sunxi.c
>> +++ b/drivers/usb/musb/sunxi.c
>> @@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
>>   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
>>   sunxi_sram_release(musb->controller->parent);
>>
>> + devm_usb_put_phy(glue->dev, glue->xceiv);
>> +
>>   return 0;
>>  }
>
>

> Applied. Thanks.
> -Bin.

Which repository was it applied to?

Regards,
Jonathan

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

[Mike Galbraith]

On Mon, 2017-10-16 at 11:26 +0800, Li, Aubrey wrote:
> 
> I'll try to move quiet_vmstat() into the normal idle branch if this patch 
> series
> are reasonable. Is fast_idle a good indication for it?

see x86_tip 62cb1188ed86 sched/idle: Move quiet_vmstate() into the NOHZ code

-Mike

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

[Mike Galbraith]

On Mon, 2017-10-16 at 11:26 +0800, Li, Aubrey wrote:
> 
> I'll try to move quiet_vmstat() into the normal idle branch if this patch 
> series
> are reasonable. Is fast_idle a good indication for it?

see x86_tip 62cb1188ed86 sched/idle: Move quiet_vmstate() into the NOHZ code

-Mike

RE: [PATCH] of: dynamic: fix memory leak related to properties of __of_node_dup

[Wang, Alan 1. (NSB - CN/Hangzhou)]

Hi Rob and Frank,

Thanks for your comments.
Frank's description is exactly what I meant. I will changed the description as 
yours if you don't mind.

We are using Linux v3.10.64 and a patch from https://lkml.org/lkml/2014/4/4/207.
With this patch all properties are added dynamically to the dynamic nodes. This 
is where I firstly found this issue using kmemleak.

And in our environment, the nodes for OCXO are kept empty in the dts file, and 
the properties will be generated at runtime 
according to sensor details read from ocxo EEPROM. In this case, I think memory 
leak remains on latest version when resetting that devices.

Thanks.
Lixin

RE: [PATCH] of: dynamic: fix memory leak related to properties of __of_node_dup

[Wang, Alan 1. (NSB - CN/Hangzhou)]

Hi Rob and Frank,

Thanks for your comments.
Frank's description is exactly what I meant. I will changed the description as 
yours if you don't mind.

We are using Linux v3.10.64 and a patch from https://lkml.org/lkml/2014/4/4/207.
With this patch all properties are added dynamically to the dynamic nodes. This 
is where I firstly found this issue using kmemleak.

And in our environment, the nodes for OCXO are kept empty in the dts file, and 
the properties will be generated at runtime 
according to sensor details read from ocxo EEPROM. In this case, I think memory 
leak remains on latest version when resetting that devices.

Thanks.
Lixin

A issue about ptrace/SINGLESTEP on arm64

[chengjian (D)]

Hi
I write demo use ptrace/SINGLESTEP to count the number of instructions 
executed by the process

The parent process fork+exec a child process, and trace(SINGLESTEP) it,

It works fine under the x86_64 architecture but has an exception under 
arm64.


```cpp
//demo.c
#include 
#include 
#include 

#include 
#include 
#include 

#include 

#ifdef DEBUG
#define dprintf printf
#else
#define dprintf 0 && printf
#endif


int main(int argc, char *argv[])
{
long long counter = 0;
int wait_val;
int pid;

puts("Please wait");

switch (pid = fork()) {
case -1:
perror("fork");
break;

case 0:
ptrace(PTRACE_TRACEME, 0, 0, 0);
execl("/bin/ls", "ls", NULL);
break;

default:
//ptrace(PTRACE_ATTACH, pid, NULL, NULL);
//waitpid(pid, _val, 0);
 //while (wait_val == 1407 ) {
 while ( 1 )
 {
wait(_val);
if(WIFEXITED(_val)) {
break;
}
counter++;
if (ptrace(PTRACE_SINGLESTEP, pid, 0, 0) != 0)
perror("ptrace");
else
dprintf("counter = %lld\n", counter);
}
}

printf("Number of machine instructions : %lld\n", counter);
return 0;
}
```

It run for a long long time and seems never to stop.


./demo /bin/ls


counter = 8033129
counter = 8033130
counter = 8033131
counter = 8033132
counter = 8033133
counter = 8033134
counter = 8033135
counter = 8033136
counter = 8033137
counter = 8033138
counter = 8033139
^C




It return the same results when track other the other C processes
And then I make an assembly demo(just print Hello-World),

It looks just all right

```asm
//hello.s
// as hello.s –o hello.o
// ld hello.o –o hello
.text //code section
.globl _start
_start:
mov x0, 0 // stdout has file descriptor 0
ldr x1, =msg  // buffer to write
mov x2, len   // size of buffer
mov x8, 64// sys_write() is at index 64 in kernel functions table
svc #0// generate kernel call sys_write(stdout, msg, len);
mov x0, 123 // exit code
mov x8, 93  // sys_exit() is at index 93 in kernel functions table
svc #0  // generate kernel call sys_exit(123);
.data //data section
msg:
.ascii  "Hello, ARM!\n"
len = . - msg
```



./demo ./hello


./hello : hello

Please wait
Hello, ARM!
Number of machine instructions : 8


I want to know what's going on about it, Is this a bug?

A issue about ptrace/SINGLESTEP on arm64

[chengjian (D)]

Hi
I write demo use ptrace/SINGLESTEP to count the number of instructions 
executed by the process

The parent process fork+exec a child process, and trace(SINGLESTEP) it,

It works fine under the x86_64 architecture but has an exception under 
arm64.


```cpp
//demo.c
#include 
#include 
#include 

#include 
#include 
#include 

#include 

#ifdef DEBUG
#define dprintf printf
#else
#define dprintf 0 && printf
#endif


int main(int argc, char *argv[])
{
long long counter = 0;
int wait_val;
int pid;

puts("Please wait");

switch (pid = fork()) {
case -1:
perror("fork");
break;

case 0:
ptrace(PTRACE_TRACEME, 0, 0, 0);
execl("/bin/ls", "ls", NULL);
break;

default:
//ptrace(PTRACE_ATTACH, pid, NULL, NULL);
//waitpid(pid, _val, 0);
 //while (wait_val == 1407 ) {
 while ( 1 )
 {
wait(_val);
if(WIFEXITED(_val)) {
break;
}
counter++;
if (ptrace(PTRACE_SINGLESTEP, pid, 0, 0) != 0)
perror("ptrace");
else
dprintf("counter = %lld\n", counter);
}
}

printf("Number of machine instructions : %lld\n", counter);
return 0;
}
```

It run for a long long time and seems never to stop.


./demo /bin/ls


counter = 8033129
counter = 8033130
counter = 8033131
counter = 8033132
counter = 8033133
counter = 8033134
counter = 8033135
counter = 8033136
counter = 8033137
counter = 8033138
counter = 8033139
^C




It return the same results when track other the other C processes
And then I make an assembly demo(just print Hello-World),

It looks just all right

```asm
//hello.s
// as hello.s –o hello.o
// ld hello.o –o hello
.text //code section
.globl _start
_start:
mov x0, 0 // stdout has file descriptor 0
ldr x1, =msg  // buffer to write
mov x2, len   // size of buffer
mov x8, 64// sys_write() is at index 64 in kernel functions table
svc #0// generate kernel call sys_write(stdout, msg, len);
mov x0, 123 // exit code
mov x8, 93  // sys_exit() is at index 93 in kernel functions table
svc #0  // generate kernel call sys_exit(123);
.data //data section
msg:
.ascii  "Hello, ARM!\n"
len = . - msg
```



./demo ./hello


./hello : hello

Please wait
Hello, ARM!
Number of machine instructions : 8


I want to know what's going on about it, Is this a bug?

RE: [PATCH v2 2/5] dpaa_eth: move of_phy_connect() to the eth driver

[Madalin-cristian Bucur]

> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Sunday, October 15, 2017 9:34 PM
> To: Madalin-cristian Bucur 
> Cc: net...@vger.kernel.org; da...@davemloft.net; f.faine...@gmail.com;
> vivien.dide...@savoirfairelinux.com; jun...@outlook.com; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2 2/5] dpaa_eth: move of_phy_connect() to the eth
> driver
> 
> On Fri, Oct 13, 2017 at 05:50:09PM +0300, Madalin Bucur wrote:
> > Signed-off-by: Madalin Bucur 
> > ---
> >  drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 48 +++--
> >  drivers/net/ethernet/freescale/fman/mac.c  | 97 ++-
> ---
> >  drivers/net/ethernet/freescale/fman/mac.h  |  5 +-
> >  3 files changed, 66 insertions(+), 84 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > index 4225806..7cf61d6 100644
> > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > @@ -2435,6 +2435,48 @@ static void dpaa_eth_napi_disable(struct
> dpaa_priv *priv)
> > }
> >  }
> >
> > +static void dpaa_adjust_link(struct net_device *net_dev)
> > +{
> > +   struct mac_device *mac_dev;
> > +   struct dpaa_priv *priv;
> > +
> > +   priv = netdev_priv(net_dev);
> > +   mac_dev = priv->mac_dev;
> > +   mac_dev->adjust_link(mac_dev);
> > +}
> > +
> > +static int dpaa_phy_init(struct net_device *net_dev)
> > +{
> > +   struct mac_device *mac_dev;
> > +   struct phy_device *phy_dev;
> > +   struct dpaa_priv *priv;
> > +
> > +   priv = netdev_priv(net_dev);
> > +   mac_dev = priv->mac_dev;
> > +
> > +   phy_dev = of_phy_connect(net_dev, mac_dev->phy_node,
> > +_adjust_link, 0,
> > +mac_dev->phy_if);
> > +   if (!phy_dev) {
> > +   netif_err(priv, ifup, net_dev, "init_phy() failed\n");
> > +   return -ENODEV;
> > +   }
> > +
> > +   /* Remove any features not supported by the controller */
> > +   phy_dev->supported &= mac_dev->if_support;
> > +
> > +   /* Enable the symmetric and asymmetric PAUSE frame advertisements,
> > +* as most of the PHY drivers do not enable them by default.
> > +*/
> 
> Hi Madalin
> 
> This is just moving code around, so the patch is O.K. However, it
> would be nice to have a followup patch. This comment is wrong. The phy
> driver should never enable symmetric and asymmetric PAUSE frames. The
> MAC needs to, because only the MAC knows if the MAC supports pause
> frames.
> 
>   Andrew

Hi Andrew,

This is obsolete and it will be removed, I'll send a v3. It remained there from
a time it used to be valid (the original DPAA Ethernet driver was developed
and maintained out of tree since about 9 years ago). I see this thread on the
subject which is relatively recent:

https://www.spinics.net/lists/netdev/msg404288.html

Thanks,
Madalin

RE: [PATCH v2 2/5] dpaa_eth: move of_phy_connect() to the eth driver

[Madalin-cristian Bucur]

> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Sunday, October 15, 2017 9:34 PM
> To: Madalin-cristian Bucur 
> Cc: net...@vger.kernel.org; da...@davemloft.net; f.faine...@gmail.com;
> vivien.dide...@savoirfairelinux.com; jun...@outlook.com; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2 2/5] dpaa_eth: move of_phy_connect() to the eth
> driver
> 
> On Fri, Oct 13, 2017 at 05:50:09PM +0300, Madalin Bucur wrote:
> > Signed-off-by: Madalin Bucur 
> > ---
> >  drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 48 +++--
> >  drivers/net/ethernet/freescale/fman/mac.c  | 97 ++-
> ---
> >  drivers/net/ethernet/freescale/fman/mac.h  |  5 +-
> >  3 files changed, 66 insertions(+), 84 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > index 4225806..7cf61d6 100644
> > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > @@ -2435,6 +2435,48 @@ static void dpaa_eth_napi_disable(struct
> dpaa_priv *priv)
> > }
> >  }
> >
> > +static void dpaa_adjust_link(struct net_device *net_dev)
> > +{
> > +   struct mac_device *mac_dev;
> > +   struct dpaa_priv *priv;
> > +
> > +   priv = netdev_priv(net_dev);
> > +   mac_dev = priv->mac_dev;
> > +   mac_dev->adjust_link(mac_dev);
> > +}
> > +
> > +static int dpaa_phy_init(struct net_device *net_dev)
> > +{
> > +   struct mac_device *mac_dev;
> > +   struct phy_device *phy_dev;
> > +   struct dpaa_priv *priv;
> > +
> > +   priv = netdev_priv(net_dev);
> > +   mac_dev = priv->mac_dev;
> > +
> > +   phy_dev = of_phy_connect(net_dev, mac_dev->phy_node,
> > +_adjust_link, 0,
> > +mac_dev->phy_if);
> > +   if (!phy_dev) {
> > +   netif_err(priv, ifup, net_dev, "init_phy() failed\n");
> > +   return -ENODEV;
> > +   }
> > +
> > +   /* Remove any features not supported by the controller */
> > +   phy_dev->supported &= mac_dev->if_support;
> > +
> > +   /* Enable the symmetric and asymmetric PAUSE frame advertisements,
> > +* as most of the PHY drivers do not enable them by default.
> > +*/
> 
> Hi Madalin
> 
> This is just moving code around, so the patch is O.K. However, it
> would be nice to have a followup patch. This comment is wrong. The phy
> driver should never enable symmetric and asymmetric PAUSE frames. The
> MAC needs to, because only the MAC knows if the MAC supports pause
> frames.
> 
>   Andrew

Hi Andrew,

This is obsolete and it will be removed, I'll send a v3. It remained there from
a time it used to be valid (the original DPAA Ethernet driver was developed
and maintained out of tree since about 9 years ago). I see this thread on the
subject which is relatively recent:

https://www.spinics.net/lists/netdev/msg404288.html

Thanks,
Madalin

Re: [PATCH v3] rpmsg: Allow RPMSG_VIRTIO to be enabled via menuconfig or defconfig

[Anup Patel]

Ping ??

--
Anup

Re: [PATCH v3] rpmsg: Allow RPMSG_VIRTIO to be enabled via menuconfig or defconfig

[Anup Patel]

Ping ??

--
Anup

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

[Anup Patel]

Ping ??

--
Anup

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

[Anup Patel]

Ping ??

--
Anup

Re: [PATCH v5 11/16] perf report: properly handle branch count in match_chain

[ravi]

On Friday 13 October 2017 07:38 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Oct 13, 2017 at 10:39:03AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Mon, Oct 09, 2017 at 10:33:05PM +0200, Milian Wolff escreveu:

Some of the code paths I introduced before returned too early
without running the code to handle a node's branch count.
By refactoring match_chain to only have one exit point, this
can be remedied.

Fixing up this one now.

Millian, this is all fresher in your mind, can you please take a look at
my perf/core branch and check if the change i made to ]PATCH v5 09/16]
"perf report: compare symbol name for inlined frames when matching" is
ok wrt Ravi's fix and then, please, rebase v5 on top of what is there?

Ravi, please take a look at this as well, to see if with these changes
your fix remains valid, ok?


Yes Arnaldo, my changes are still valid.

Milian, Can you please change this patch such that it incorporates dso
comparison for CCKEY_FUNCTION.

( Also, will that be good to change macro to CCKEY_FUNCTION_DOS ?)

Thanks,
Ravi

Re: [PATCH v5 11/16] perf report: properly handle branch count in match_chain

[ravi]

On Friday 13 October 2017 07:38 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Oct 13, 2017 at 10:39:03AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Mon, Oct 09, 2017 at 10:33:05PM +0200, Milian Wolff escreveu:

Some of the code paths I introduced before returned too early
without running the code to handle a node's branch count.
By refactoring match_chain to only have one exit point, this
can be remedied.

Fixing up this one now.

Millian, this is all fresher in your mind, can you please take a look at
my perf/core branch and check if the change i made to ]PATCH v5 09/16]
"perf report: compare symbol name for inlined frames when matching" is
ok wrt Ravi's fix and then, please, rebase v5 on top of what is there?

Ravi, please take a look at this as well, to see if with these changes
your fix remains valid, ok?


Yes Arnaldo, my changes are still valid.

Milian, Can you please change this patch such that it incorporates dso
comparison for CCKEY_FUNCTION.

( Also, will that be good to change macro to CCKEY_FUNCTION_DOS ?)

Thanks,
Ravi

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

[Fengguang Wu]

Hi Gang,

On Sun, Oct 15, 2017 at 09:26:00PM -0600, Gang He wrote:

Hello Intel Kbuild team,

You just upgrade GCC version when compiling the latest kernel?


This report comes from a pretty old gcc:

   config: tile-allyesconfig (attached as .config)
   compiler: tilegx-linux-gcc (GCC) 4.6.2

Thanks,
Fengguang


Since these code looks a little old, I am sure that the related contributors 
are still work on OCFS2 project.


Thanks
Gang





Hi Bhumika,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.14-rc4 next-20171013]
[if your patch is applied to the wrong git tree, please drop us a note to
help improve the system]

url:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_l
inux_commits_Bhumika-2DGoyal_ocfs2-2Dcluster-2Dmake-2Dconfig-5Fitem-5Ftype-2Dconst_2
0171014-2D185701=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=f4ohdmG
rYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrjbR5Spv4mvmdj2s377WohnG6h6z1
WB7E=hFVfDC8STTMTIDNtdipf8BlwR_V8RJG6an_l-r9MKyA=
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget
https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.c
om_intel_lkp-2Dtests_master_sbin_make.cross=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxB
KCX5YTpkKY057SbK10=f4ohdmGrYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrj
bR5Spv4mvmdj2s377WohnG6h6z1WB7E=f5lUGF9NCtygTaG6AR0HkjhG7fOwD5nKFLaYCvPpju0
=  -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile

All warnings (new ones prefixed by >>):

   fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_node_group_make_item':
   fs/ocfs2/cluster/nodemanager.c:573:2: warning: passing argument 3 of
'config_item_init_type_name' discards 'const' qualifier from pointer target
type [enabled by default]
   include/linux/configfs.h:73:13: note: expected 'struct config_item_type
*' but argument is of type 'const struct config_item_type *'
   fs/ocfs2/cluster/nodemanager.c: In function
'o2nm_cluster_group_make_group':
   fs/ocfs2/cluster/nodemanager.c:681:9: warning: passing argument 3 of
'config_group_init_type_name' discards 'const' qualifier from pointer target
type [enabled by default]
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type
*' but argument is of type 'const struct config_item_type *'
   fs/ocfs2/cluster/nodemanager.c:685:9: warning: passing argument 3 of
'config_group_init_type_name' discards 'const' qualifier from pointer target
type [enabled by default]
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type
*' but argument is of type 'const struct config_item_type *'
   fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_depend_item':
   fs/ocfs2/cluster/nodemanager.c:743:2: warning: passing argument 1 of
'configfs_depend_item' discards 'const' qualifier from pointer target type
[enabled by default]
   include/linux/configfs.h:269:5: note: expected 'struct configfs_subsystem
*' but argument is of type 'const struct configfs_subsystem *'
   fs/ocfs2/cluster/nodemanager.c: In function 'exit_o2nm':
   fs/ocfs2/cluster/nodemanager.c:785:2: warning: passing argument 1 of
'configfs_unregister_subsystem' discards 'const' qualifier from pointer
target type [enabled by default]
   include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem
*' but argument is of type 'const struct configfs_subsystem *'
   fs/ocfs2/cluster/nodemanager.c: In function 'init_o2nm':
   fs/ocfs2/cluster/nodemanager.c:808:2: warning: passing argument 1 of
'config_group_init' discards 'const' qualifier from pointer target type
[enabled by default]
   include/linux/configfs.h:101:13: note: expected 'struct config_group *'
but argument is of type 'const struct config_group *'

fs/ocfs2/cluster/nodemanager.c:809:2: warning: passing argument 1 of

'__mutex_init' discards 'const' qualifier from pointer target type [enabled
by default]
   include/linux/mutex.h:133:13: note: expected 'struct mutex *' but
argument is of type 'const struct mutex *'
   fs/ocfs2/cluster/nodemanager.c:810:2: warning: passing argument 1 of
'configfs_register_subsystem' discards 'const' qualifier from pointer target
type [enabled by default]
   include/linux/configfs.h:252:5: note: expected 'struct configfs_subsystem
*' but argument is of type 'const struct configfs_subsystem *'
   fs/ocfs2/cluster/nodemanager.c:820:2: warning: passing argument 1 of
'configfs_unregister_subsystem' discards 'const' qualifier from pointer
target type [enabled by default]
   include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem
*' but argument is of type 'const struct configfs_subsystem *'

vim +809 fs/ocfs2/cluster/nodemanager.c

0c83ed8e Kurt Hackel   2005-12-15  740
14829422 Joel Becker   2007-06-14  741  int o2nm_depend_item(struct
config_item *item)
14829422 Joel Becker   2007-06-14  742  {
14829422 Joel Becker   2007-06-14 @743

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

[Fengguang Wu]

Hi Gang,

On Sun, Oct 15, 2017 at 09:26:00PM -0600, Gang He wrote:

Hello Intel Kbuild team,

You just upgrade GCC version when compiling the latest kernel?


This report comes from a pretty old gcc:

   config: tile-allyesconfig (attached as .config)
   compiler: tilegx-linux-gcc (GCC) 4.6.2

Thanks,
Fengguang


Since these code looks a little old, I am sure that the related contributors 
are still work on OCFS2 project.


Thanks
Gang





Hi Bhumika,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.14-rc4 next-20171013]
[if your patch is applied to the wrong git tree, please drop us a note to
help improve the system]

url:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_l
inux_commits_Bhumika-2DGoyal_ocfs2-2Dcluster-2Dmake-2Dconfig-5Fitem-5Ftype-2Dconst_2
0171014-2D185701=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=f4ohdmG
rYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrjbR5Spv4mvmdj2s377WohnG6h6z1
WB7E=hFVfDC8STTMTIDNtdipf8BlwR_V8RJG6an_l-r9MKyA=
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget
https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.c
om_intel_lkp-2Dtests_master_sbin_make.cross=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxB
KCX5YTpkKY057SbK10=f4ohdmGrYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrj
bR5Spv4mvmdj2s377WohnG6h6z1WB7E=f5lUGF9NCtygTaG6AR0HkjhG7fOwD5nKFLaYCvPpju0
=  -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile

All warnings (new ones prefixed by >>):

   fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_node_group_make_item':
   fs/ocfs2/cluster/nodemanager.c:573:2: warning: passing argument 3 of
'config_item_init_type_name' discards 'const' qualifier from pointer target
type [enabled by default]
   include/linux/configfs.h:73:13: note: expected 'struct config_item_type
*' but argument is of type 'const struct config_item_type *'
   fs/ocfs2/cluster/nodemanager.c: In function
'o2nm_cluster_group_make_group':
   fs/ocfs2/cluster/nodemanager.c:681:9: warning: passing argument 3 of
'config_group_init_type_name' discards 'const' qualifier from pointer target
type [enabled by default]
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type
*' but argument is of type 'const struct config_item_type *'
   fs/ocfs2/cluster/nodemanager.c:685:9: warning: passing argument 3 of
'config_group_init_type_name' discards 'const' qualifier from pointer target
type [enabled by default]
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type
*' but argument is of type 'const struct config_item_type *'
   fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_depend_item':
   fs/ocfs2/cluster/nodemanager.c:743:2: warning: passing argument 1 of
'configfs_depend_item' discards 'const' qualifier from pointer target type
[enabled by default]
   include/linux/configfs.h:269:5: note: expected 'struct configfs_subsystem
*' but argument is of type 'const struct configfs_subsystem *'
   fs/ocfs2/cluster/nodemanager.c: In function 'exit_o2nm':
   fs/ocfs2/cluster/nodemanager.c:785:2: warning: passing argument 1 of
'configfs_unregister_subsystem' discards 'const' qualifier from pointer
target type [enabled by default]
   include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem
*' but argument is of type 'const struct configfs_subsystem *'
   fs/ocfs2/cluster/nodemanager.c: In function 'init_o2nm':
   fs/ocfs2/cluster/nodemanager.c:808:2: warning: passing argument 1 of
'config_group_init' discards 'const' qualifier from pointer target type
[enabled by default]
   include/linux/configfs.h:101:13: note: expected 'struct config_group *'
but argument is of type 'const struct config_group *'

fs/ocfs2/cluster/nodemanager.c:809:2: warning: passing argument 1 of

'__mutex_init' discards 'const' qualifier from pointer target type [enabled
by default]
   include/linux/mutex.h:133:13: note: expected 'struct mutex *' but
argument is of type 'const struct mutex *'
   fs/ocfs2/cluster/nodemanager.c:810:2: warning: passing argument 1 of
'configfs_register_subsystem' discards 'const' qualifier from pointer target
type [enabled by default]
   include/linux/configfs.h:252:5: note: expected 'struct configfs_subsystem
*' but argument is of type 'const struct configfs_subsystem *'
   fs/ocfs2/cluster/nodemanager.c:820:2: warning: passing argument 1 of
'configfs_unregister_subsystem' discards 'const' qualifier from pointer
target type [enabled by default]
   include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem
*' but argument is of type 'const struct configfs_subsystem *'

vim +809 fs/ocfs2/cluster/nodemanager.c

0c83ed8e Kurt Hackel   2005-12-15  740
14829422 Joel Becker   2007-06-14  741  int o2nm_depend_item(struct
config_item *item)
14829422 Joel Becker   2007-06-14  742  {
14829422 Joel Becker   2007-06-14 @743

[PATCH] Makefile: Fix empty flag results for stackprotector _AUTO mode

[Kees Cook]

If the compiler didn't support any stackprotector mode, the second
empty test would still trip. This moves it to an "else" test for the
non-AUTO modes.

Reported-and-tested-by: Robert Jarzmik 
Signed-off-by: Kees Cook 
---
This is a separate fix from the issue with gcc 4.4.4. Yay compilers.
(Also, this is technically a v2 with just the commit message changed.)
---
 Makefile | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 20fafb48fdf9..74d5f037df69 100644
--- a/Makefile
+++ b/Makefile
@@ -1093,16 +1093,17 @@ PHONY += prepare-compiler-check
 prepare-compiler-check: FORCE
 # Make sure compiler supports requested stack protector flag.
 ifdef stackp-name
-  # Warn about CONFIG_CC_STACKPROTECTOR_AUTO having found no option.
   ifeq ($(stackp-flag),)
+   # Warn about CONFIG_CC_STACKPROTECTOR_AUTO having found no option.
@echo CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
  Compiler does not support any known stack-protector >&2
-  endif
-  # Fail if specifically requested stack protector is missing.
+  else
   ifeq ($(call cc-option, $(stackp-flag)),)
+   # Fail if specifically requested stack protector is missing.
@echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
  $(stackp-flag) not supported by compiler >&2 && exit 1
   endif
+  endif
 endif
 # Make sure compiler does not have buggy stack-protector support.
 ifdef stackp-check
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[PATCH] Makefile: Fix empty flag results for stackprotector _AUTO mode

[Kees Cook]

If the compiler didn't support any stackprotector mode, the second
empty test would still trip. This moves it to an "else" test for the
non-AUTO modes.

Reported-and-tested-by: Robert Jarzmik 
Signed-off-by: Kees Cook 
---
This is a separate fix from the issue with gcc 4.4.4. Yay compilers.
(Also, this is technically a v2 with just the commit message changed.)
---
 Makefile | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 20fafb48fdf9..74d5f037df69 100644
--- a/Makefile
+++ b/Makefile
@@ -1093,16 +1093,17 @@ PHONY += prepare-compiler-check
 prepare-compiler-check: FORCE
 # Make sure compiler supports requested stack protector flag.
 ifdef stackp-name
-  # Warn about CONFIG_CC_STACKPROTECTOR_AUTO having found no option.
   ifeq ($(stackp-flag),)
+   # Warn about CONFIG_CC_STACKPROTECTOR_AUTO having found no option.
@echo CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
  Compiler does not support any known stack-protector >&2
-  endif
-  # Fail if specifically requested stack protector is missing.
+  else
   ifeq ($(call cc-option, $(stackp-flag)),)
+   # Fail if specifically requested stack protector is missing.
@echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
  $(stackp-flag) not supported by compiler >&2 && exit 1
   endif
+  endif
 endif
 # Make sure compiler does not have buggy stack-protector support.
 ifdef stackp-check
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[PATCH 1/5] arm64: dts: realtek: Factor out common RTD129x parts

[Andreas Färber]

Prepares for RTD1293 and RTD1296.

Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/realtek/rtd1295.dtsi | 65 ++--
 arch/arm64/boot/dts/realtek/rtd129x.dtsi | 72 
 2 files changed, 76 insertions(+), 61 deletions(-)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd129x.dtsi

diff --git a/arch/arm64/boot/dts/realtek/rtd1295.dtsi 
b/arch/arm64/boot/dts/realtek/rtd1295.dtsi
index c8b7bb642a9a..8d9ac05d17dc 100644
--- a/arch/arm64/boot/dts/realtek/rtd1295.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd1295.dtsi
@@ -6,19 +6,10 @@
  * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  */
 
-/memreserve/   0x 0x0003;
-/memreserve/   0x0001f000 0x1000;
-/memreserve/   0x0003 0x000d;
-/memreserve/   0x01b0 0x004be000;
-/memreserve/   0x01ffe000 0x4000;
-
-#include 
+#include "rtd129x.dtsi"
 
 / {
compatible = "realtek,rtd1295";
-   interrupt-parent = <>;
-   #address-cells = <1>;
-   #size-cells = <1>;
 
cpus {
#address-cells = <2>;
@@ -68,12 +59,6 @@
};
};
 
-   arm-pmu {
-   compatible = "arm,cortex-a53-pmu";
-   interrupts = ;
-   interrupt-affinity = <>, <>, <>, <>;
-   };
-
timer {
compatible = "arm,armv8-timer";
interrupts = ;
};
+};
 
-   soc {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   /* Exclude up to 2 GiB of RAM */
-   ranges = <0x8000 0x8000 0x8000>;
-
-   uart0: serial@98007800 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x98007800 0x400>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   clock-frequency = <2700>;
-   status = "disabled";
-   };
-
-   uart1: serial@9801b200 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x9801b200 0x100>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   clock-frequency = <43200>;
-   status = "disabled";
-   };
-
-   uart2: serial@9801b400 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x9801b400 0x100>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   clock-frequency = <43200>;
-   status = "disabled";
-   };
-
-   gic: interrupt-controller@ff011000 {
-   compatible = "arm,gic-400";
-   reg = <0xff011000 0x1000>,
- <0xff012000 0x2000>,
- <0xff014000 0x2000>,
- <0xff016000 0x2000>;
-   interrupts = ;
-   interrupt-controller;
-   #interrupt-cells = <3>;
-   };
-   };
+_pmu {
+   interrupt-affinity = <>, <>, <>, <>;
 };
diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi 
b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
new file mode 100644
index ..b9cb92466fc7
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
@@ -0,0 +1,72 @@
+/*
+ * Realtek RTD1293/RTD1295/RTD1296 SoC
+ *
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/memreserve/   0x 0x0003;
+/memreserve/   0x0001f000 0x1000;
+/memreserve/   0x0003 0x000d;
+/memreserve/   0x01b0 0x004be000;
+/memreserve/   0x01ffe000 0x4000;
+
+#include 
+
+/ {
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   arm_pmu: arm-pmu {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts = ;
+   };
+
+   soc {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   /* Exclude up to 2 GiB of RAM */
+   ranges = <0x8000 0x8000 0x8000>;
+
+   uart0: serial@98007800 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0x98007800 0x400>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clock-frequency = <2700>;
+   status = "disabled";
+   };
+
+   uart1: serial@9801b200 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0x9801b200 0x100>;
+   reg-shift = <2>;
+  

[PATCH 1/5] arm64: dts: realtek: Factor out common RTD129x parts

[Andreas Färber]

Prepares for RTD1293 and RTD1296.

Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/realtek/rtd1295.dtsi | 65 ++--
 arch/arm64/boot/dts/realtek/rtd129x.dtsi | 72 
 2 files changed, 76 insertions(+), 61 deletions(-)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd129x.dtsi

diff --git a/arch/arm64/boot/dts/realtek/rtd1295.dtsi 
b/arch/arm64/boot/dts/realtek/rtd1295.dtsi
index c8b7bb642a9a..8d9ac05d17dc 100644
--- a/arch/arm64/boot/dts/realtek/rtd1295.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd1295.dtsi
@@ -6,19 +6,10 @@
  * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  */
 
-/memreserve/   0x 0x0003;
-/memreserve/   0x0001f000 0x1000;
-/memreserve/   0x0003 0x000d;
-/memreserve/   0x01b0 0x004be000;
-/memreserve/   0x01ffe000 0x4000;
-
-#include 
+#include "rtd129x.dtsi"
 
 / {
compatible = "realtek,rtd1295";
-   interrupt-parent = <>;
-   #address-cells = <1>;
-   #size-cells = <1>;
 
cpus {
#address-cells = <2>;
@@ -68,12 +59,6 @@
};
};
 
-   arm-pmu {
-   compatible = "arm,cortex-a53-pmu";
-   interrupts = ;
-   interrupt-affinity = <>, <>, <>, <>;
-   };
-
timer {
compatible = "arm,armv8-timer";
interrupts = ;
};
+};
 
-   soc {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   /* Exclude up to 2 GiB of RAM */
-   ranges = <0x8000 0x8000 0x8000>;
-
-   uart0: serial@98007800 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x98007800 0x400>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   clock-frequency = <2700>;
-   status = "disabled";
-   };
-
-   uart1: serial@9801b200 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x9801b200 0x100>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   clock-frequency = <43200>;
-   status = "disabled";
-   };
-
-   uart2: serial@9801b400 {
-   compatible = "snps,dw-apb-uart";
-   reg = <0x9801b400 0x100>;
-   reg-shift = <2>;
-   reg-io-width = <4>;
-   clock-frequency = <43200>;
-   status = "disabled";
-   };
-
-   gic: interrupt-controller@ff011000 {
-   compatible = "arm,gic-400";
-   reg = <0xff011000 0x1000>,
- <0xff012000 0x2000>,
- <0xff014000 0x2000>,
- <0xff016000 0x2000>;
-   interrupts = ;
-   interrupt-controller;
-   #interrupt-cells = <3>;
-   };
-   };
+_pmu {
+   interrupt-affinity = <>, <>, <>, <>;
 };
diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi 
b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
new file mode 100644
index ..b9cb92466fc7
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
@@ -0,0 +1,72 @@
+/*
+ * Realtek RTD1293/RTD1295/RTD1296 SoC
+ *
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/memreserve/   0x 0x0003;
+/memreserve/   0x0001f000 0x1000;
+/memreserve/   0x0003 0x000d;
+/memreserve/   0x01b0 0x004be000;
+/memreserve/   0x01ffe000 0x4000;
+
+#include 
+
+/ {
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   arm_pmu: arm-pmu {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts = ;
+   };
+
+   soc {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   /* Exclude up to 2 GiB of RAM */
+   ranges = <0x8000 0x8000 0x8000>;
+
+   uart0: serial@98007800 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0x98007800 0x400>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clock-frequency = <2700>;
+   status = "disabled";
+   };
+
+   uart1: serial@9801b200 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0x9801b200 0x100>;
+   reg-shift = <2>;
+

[PATCH 2/5] dt-bindings: arm: realtek: Document RTD1293 and Synology DS418j

[Andreas Färber]

Define compatible strings for Realtek RTD1293 SoC and Synology
DiskStation DS418j NAS.

Cc: i...@synology.com
Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/arm/realtek.txt | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/realtek.txt 
b/Documentation/devicetree/bindings/arm/realtek.txt
index 297c15eb81e2..500e771614c4 100644
--- a/Documentation/devicetree/bindings/arm/realtek.txt
+++ b/Documentation/devicetree/bindings/arm/realtek.txt
@@ -2,6 +2,23 @@ Realtek platforms device tree bindings
 --
 
 
+RTD1293 SoC
+===
+
+Required root node properties:
+
+ - compatible :  must contain "realtek,rtd1293"
+
+
+Root node property compatible must contain, depending on board:
+
+ - Synology DiskStation DS418j: "synology,ds418j"
+
+Example:
+
+compatible = "synology,ds418j", "realtek,rtd1293";
+
+
 RTD1295 SoC
 ===
 
-- 
2.13.6

[PATCH 2/5] dt-bindings: arm: realtek: Document RTD1293 and Synology DS418j

[Andreas Färber]

Define compatible strings for Realtek RTD1293 SoC and Synology
DiskStation DS418j NAS.

Cc: i...@synology.com
Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/arm/realtek.txt | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/realtek.txt 
b/Documentation/devicetree/bindings/arm/realtek.txt
index 297c15eb81e2..500e771614c4 100644
--- a/Documentation/devicetree/bindings/arm/realtek.txt
+++ b/Documentation/devicetree/bindings/arm/realtek.txt
@@ -2,6 +2,23 @@ Realtek platforms device tree bindings
 --
 
 
+RTD1293 SoC
+===
+
+Required root node properties:
+
+ - compatible :  must contain "realtek,rtd1293"
+
+
+Root node property compatible must contain, depending on board:
+
+ - Synology DiskStation DS418j: "synology,ds418j"
+
+Example:
+
+compatible = "synology,ds418j", "realtek,rtd1293";
+
+
 RTD1295 SoC
 ===
 
-- 
2.13.6

[PATCH 4/5] dt-bindings: arm: realtek: Document RTD1296 and Synology DS418

[Andreas Färber]

Define compatible strings for Realtek RTD1296 SoC and Synology
DiskStation DS418 NAS.

Cc: i...@synology.com
Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/arm/realtek.txt | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/realtek.txt 
b/Documentation/devicetree/bindings/arm/realtek.txt
index 500e771614c4..d977aa0a0f46 100644
--- a/Documentation/devicetree/bindings/arm/realtek.txt
+++ b/Documentation/devicetree/bindings/arm/realtek.txt
@@ -36,3 +36,20 @@ Root node property compatible must contain, depending on 
board:
 Example:
 
 compatible = "zidoo,x9s", "realtek,rtd1295";
+
+
+RTD1296 SoC
+===
+
+Required root node properties:
+
+ - compatible :  must contain "realtek,rtd1296"
+
+
+Root node property compatible must contain, depending on board:
+
+ - Synology DiskStation DS418: "synology,ds418"
+
+Example:
+
+compatible = "synology,ds418", "realtek,rtd1296";
-- 
2.13.6

[PATCH 4/5] dt-bindings: arm: realtek: Document RTD1296 and Synology DS418

[Andreas Färber]

Define compatible strings for Realtek RTD1296 SoC and Synology
DiskStation DS418 NAS.

Cc: i...@synology.com
Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/arm/realtek.txt | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/realtek.txt 
b/Documentation/devicetree/bindings/arm/realtek.txt
index 500e771614c4..d977aa0a0f46 100644
--- a/Documentation/devicetree/bindings/arm/realtek.txt
+++ b/Documentation/devicetree/bindings/arm/realtek.txt
@@ -36,3 +36,20 @@ Root node property compatible must contain, depending on 
board:
 Example:
 
 compatible = "zidoo,x9s", "realtek,rtd1295";
+
+
+RTD1296 SoC
+===
+
+Required root node properties:
+
+ - compatible :  must contain "realtek,rtd1296"
+
+
+Root node property compatible must contain, depending on board:
+
+ - Synology DiskStation DS418: "synology,ds418"
+
+Example:
+
+compatible = "synology,ds418", "realtek,rtd1296";
-- 
2.13.6

[PATCH 0/5] arm64: dts: Initial RTD1293/RTD1296 and DS418j/DS418 support

[Andreas Färber]

Hello,

This series adds Device Trees for the Realtek RTD1293 and RTD1296 SoCs and
Synology DiskStation DS418j and DS418 NAS devices.

To avoid too much duplication, a shared rtd129x.dtsi is introduced.

More details at:
https://en.opensuse.org/HCL:DS418j
https://en.opensuse.org/HCL:DS418

Latest experimental patches at:
https://github.com/afaerber/linux/commits/rtd1295-next

Have a lot of fun!

Cheers,
Andreas

Cc: i...@synology.com
Cc: devicet...@vger.kernel.org

Andreas Färber (5):
  arm64: dts: realtek: Factor out common RTD129x parts
  dt-bindings: arm: realtek: Document RTD1293 and Synology DS418j
  arm64: dts: realtek: Add RTD1293 and Synology DS418j
  dt-bindings: arm: realtek: Document RTD1296 and Synology DS418
  arm64: dts: realtek: Add RTD1296 and Synology DS418

 Documentation/devicetree/bindings/arm/realtek.txt | 34 +++
 arch/arm64/boot/dts/realtek/Makefile  |  4 ++
 arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts| 31 ++
 arch/arm64/boot/dts/realtek/rtd1293.dtsi  | 56 +
 arch/arm64/boot/dts/realtek/rtd1295.dtsi  | 65 ++--
 arch/arm64/boot/dts/realtek/rtd1296-ds418.dts | 31 ++
 arch/arm64/boot/dts/realtek/rtd1296.dtsi  | 74 +++
 arch/arm64/boot/dts/realtek/rtd129x.dtsi  | 72 ++
 8 files changed, 306 insertions(+), 61 deletions(-)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1293.dtsi
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1296.dtsi
 create mode 100644 arch/arm64/boot/dts/realtek/rtd129x.dtsi

-- 
2.13.6

[PATCH 5/5] arm64: dts: realtek: Add RTD1296 and Synology DS418

[Andreas Färber]

Add Device Trees for RTD1296 SoC and Synology DiskStation DS418.

Cc: i...@synology.com
Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/realtek/Makefile  |  2 +
 arch/arm64/boot/dts/realtek/rtd1296-ds418.dts | 31 +++
 arch/arm64/boot/dts/realtek/rtd1296.dtsi  | 74 +++
 3 files changed, 107 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1296.dtsi

diff --git a/arch/arm64/boot/dts/realtek/Makefile 
b/arch/arm64/boot/dts/realtek/Makefile
index 25c795272507..cf93f4db7a69 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -3,6 +3,8 @@ dtb-$(CONFIG_ARCH_REALTEK) += rtd1293-ds418j.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-probox2-ava.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
 
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1296-ds418.dtb
+
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/realtek/rtd1296-ds418.dts 
b/arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
new file mode 100644
index ..015ef06e1933
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "rtd1293.dtsi"
+
+/ {
+   compatible = "synology,ds418", "realtek,rtd1296";
+   model = "Synology DiskStation DS418";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x8000>;
+   };
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1296.dtsi 
b/arch/arm64/boot/dts/realtek/rtd1296.dtsi
new file mode 100644
index ..d30d708775f8
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1296.dtsi
@@ -0,0 +1,74 @@
+/*
+ * Realtek RTD1296 SoC
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include "rtd129x.dtsi"
+
+/ {
+   compatible = "realtek,rtd1296";
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x2>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x3>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   l2: l2-cache {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupts = ,
+,
+,
+;
+   };
+};
+
+_pmu {
+   interrupt-affinity = <>, <>, <>, <>;
+};
-- 
2.13.6

[PATCH 0/5] arm64: dts: Initial RTD1293/RTD1296 and DS418j/DS418 support

[Andreas Färber]

Hello,

This series adds Device Trees for the Realtek RTD1293 and RTD1296 SoCs and
Synology DiskStation DS418j and DS418 NAS devices.

To avoid too much duplication, a shared rtd129x.dtsi is introduced.

More details at:
https://en.opensuse.org/HCL:DS418j
https://en.opensuse.org/HCL:DS418

Latest experimental patches at:
https://github.com/afaerber/linux/commits/rtd1295-next

Have a lot of fun!

Cheers,
Andreas

Cc: i...@synology.com
Cc: devicet...@vger.kernel.org

Andreas Färber (5):
  arm64: dts: realtek: Factor out common RTD129x parts
  dt-bindings: arm: realtek: Document RTD1293 and Synology DS418j
  arm64: dts: realtek: Add RTD1293 and Synology DS418j
  dt-bindings: arm: realtek: Document RTD1296 and Synology DS418
  arm64: dts: realtek: Add RTD1296 and Synology DS418

 Documentation/devicetree/bindings/arm/realtek.txt | 34 +++
 arch/arm64/boot/dts/realtek/Makefile  |  4 ++
 arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts| 31 ++
 arch/arm64/boot/dts/realtek/rtd1293.dtsi  | 56 +
 arch/arm64/boot/dts/realtek/rtd1295.dtsi  | 65 ++--
 arch/arm64/boot/dts/realtek/rtd1296-ds418.dts | 31 ++
 arch/arm64/boot/dts/realtek/rtd1296.dtsi  | 74 +++
 arch/arm64/boot/dts/realtek/rtd129x.dtsi  | 72 ++
 8 files changed, 306 insertions(+), 61 deletions(-)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1293.dtsi
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1296.dtsi
 create mode 100644 arch/arm64/boot/dts/realtek/rtd129x.dtsi

-- 
2.13.6

[PATCH 5/5] arm64: dts: realtek: Add RTD1296 and Synology DS418

[Andreas Färber]

Add Device Trees for RTD1296 SoC and Synology DiskStation DS418.

Cc: i...@synology.com
Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/realtek/Makefile  |  2 +
 arch/arm64/boot/dts/realtek/rtd1296-ds418.dts | 31 +++
 arch/arm64/boot/dts/realtek/rtd1296.dtsi  | 74 +++
 3 files changed, 107 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1296.dtsi

diff --git a/arch/arm64/boot/dts/realtek/Makefile 
b/arch/arm64/boot/dts/realtek/Makefile
index 25c795272507..cf93f4db7a69 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -3,6 +3,8 @@ dtb-$(CONFIG_ARCH_REALTEK) += rtd1293-ds418j.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-probox2-ava.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
 
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1296-ds418.dtb
+
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/realtek/rtd1296-ds418.dts 
b/arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
new file mode 100644
index ..015ef06e1933
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "rtd1293.dtsi"
+
+/ {
+   compatible = "synology,ds418", "realtek,rtd1296";
+   model = "Synology DiskStation DS418";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x8000>;
+   };
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1296.dtsi 
b/arch/arm64/boot/dts/realtek/rtd1296.dtsi
new file mode 100644
index ..d30d708775f8
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1296.dtsi
@@ -0,0 +1,74 @@
+/*
+ * Realtek RTD1296 SoC
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include "rtd129x.dtsi"
+
+/ {
+   compatible = "realtek,rtd1296";
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x2>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x3>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   l2: l2-cache {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupts = ,
+,
+,
+;
+   };
+};
+
+_pmu {
+   interrupt-affinity = <>, <>, <>, <>;
+};
-- 
2.13.6

[PATCH 3/5] arm64: dts: realtek: Add RTD1293 and Synology DS418j

[Andreas Färber]

Add Device Trees for RTD1293 SoC and Synology DiskStation DS481j NAS.

Cc: i...@synology.com
Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/realtek/Makefile   |  2 +
 arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts | 31 ++
 arch/arm64/boot/dts/realtek/rtd1293.dtsi   | 56 ++
 3 files changed, 89 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1293.dtsi

diff --git a/arch/arm64/boot/dts/realtek/Makefile 
b/arch/arm64/boot/dts/realtek/Makefile
index f43d0209ded7..25c795272507 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -1,3 +1,5 @@
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1293-ds418j.dtb
+
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-probox2-ava.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
 
diff --git a/arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts 
b/arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
new file mode 100644
index ..0f17bbb5aabb
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "rtd1293.dtsi"
+
+/ {
+   compatible = "synology,ds418j", "realtek,rtd1293";
+   model = "Synology DiskStation DS418j";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x4000>;
+   };
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1293.dtsi 
b/arch/arm64/boot/dts/realtek/rtd1293.dtsi
new file mode 100644
index ..403f0c55ace0
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1293.dtsi
@@ -0,0 +1,56 @@
+/*
+ * Realtek RTD1293 SoC
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include "rtd129x.dtsi"
+
+/ {
+   compatible = "realtek,rtd1293";
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   l2: l2-cache {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupts = ,
+,
+,
+;
+   };
+};
+
+_pmu {
+   interrupt-affinity = <>, <>;
+};
-- 
2.13.6

[PATCH 3/5] arm64: dts: realtek: Add RTD1293 and Synology DS418j

[Andreas Färber]

Add Device Trees for RTD1293 SoC and Synology DiskStation DS481j NAS.

Cc: i...@synology.com
Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/realtek/Makefile   |  2 +
 arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts | 31 ++
 arch/arm64/boot/dts/realtek/rtd1293.dtsi   | 56 ++
 3 files changed, 89 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1293.dtsi

diff --git a/arch/arm64/boot/dts/realtek/Makefile 
b/arch/arm64/boot/dts/realtek/Makefile
index f43d0209ded7..25c795272507 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -1,3 +1,5 @@
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1293-ds418j.dtb
+
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-probox2-ava.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
 
diff --git a/arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts 
b/arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
new file mode 100644
index ..0f17bbb5aabb
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "rtd1293.dtsi"
+
+/ {
+   compatible = "synology,ds418j", "realtek,rtd1293";
+   model = "Synology DiskStation DS418j";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x4000>;
+   };
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1293.dtsi 
b/arch/arm64/boot/dts/realtek/rtd1293.dtsi
new file mode 100644
index ..403f0c55ace0
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1293.dtsi
@@ -0,0 +1,56 @@
+/*
+ * Realtek RTD1293 SoC
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include "rtd129x.dtsi"
+
+/ {
+   compatible = "realtek,rtd1293";
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0x9801aa44>;
+   next-level-cache = <>;
+   };
+
+   l2: l2-cache {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupts = ,
+,
+,
+;
+   };
+};
+
+_pmu {
+   interrupt-affinity = <>, <>;
+};
-- 
2.13.6

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

[Randy Dunlap]

On 10/15/17 20:29, Randy Dunlap wrote:
> On 10/15/17 20:27, Randy Dunlap wrote:
>> On 10/15/17 19:27, Marian Mihailescu wrote:
>>> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
>>> are built only for architectures that use it.
>>>
>>> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
>>> be selected.

What kernel version are you looking at?
I see that it is selected:

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -22,6 +22,7 @@ config ARM
select CLONE_BACKWARDS
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
+   select DMA_NOOP_OPS if !MMU
select EDAC_SUPPORT
select EDAC_ATOMIC_SCRUB
select GENERIC_ALLOCATOR


That's in commit ID 1c51c429f30ea10428337f3a33c12059ba59f668 from May 24, 2017.

>>> However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:
>>>
>>> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
>>> *bus)
>>> {
>>> return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
>>> }
>>>
>>> I will let a maintainer suggest the best resolution for this :)
>>>
>>
>> add Bart and iommu mailing list.
>>
> 
> and add Vladimir.
> 
> 


-- 
~Randy

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

[Randy Dunlap]

On 10/15/17 20:29, Randy Dunlap wrote:
> On 10/15/17 20:27, Randy Dunlap wrote:
>> On 10/15/17 19:27, Marian Mihailescu wrote:
>>> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
>>> are built only for architectures that use it.
>>>
>>> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
>>> be selected.

What kernel version are you looking at?
I see that it is selected:

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -22,6 +22,7 @@ config ARM
select CLONE_BACKWARDS
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
+   select DMA_NOOP_OPS if !MMU
select EDAC_SUPPORT
select EDAC_ATOMIC_SCRUB
select GENERIC_ALLOCATOR


That's in commit ID 1c51c429f30ea10428337f3a33c12059ba59f668 from May 24, 2017.

>>> However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:
>>>
>>> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
>>> *bus)
>>> {
>>> return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
>>> }
>>>
>>> I will let a maintainer suggest the best resolution for this :)
>>>
>>
>> add Bart and iommu mailing list.
>>
> 
> and add Vladimir.
> 
> 


-- 
~Randy

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

[Boqun Feng]

On Mon, Oct 16, 2017 at 02:00:33PM +1100, Michael Ellerman wrote:
> Mathieu Desnoyers  writes:
> 
> > Implements two basic tests of RSEQ functionality, and one more
> > exhaustive parameterizable test.
> >
> > The first, "basic_test" only asserts that RSEQ works moderately
> > correctly.
> > E.g. that:
> > - The CPUID pointer works
> > - Code infinitely looping within a critical section will eventually be
> >   interrupted.
> > - Critical sections are interrupted by signals.
> >
> > "basic_percpu_ops_test" is a slightly more "realistic" variant,
> > implementing a few simple per-cpu operations and testing their
> > correctness.
> >
> > "param_test" is a parametrizable restartable sequences test. See
> > the "--help" output for usage.
> >
> > As part of those tests, a helper library "rseq" implements a user-space
> > API around restartable sequences. It uses the cpu_opv system call as
> > fallback when single-stepped by a debugger. It exposes the instruction
> > pointer addresses where the rseq assembly blocks begin and end, as well
> > as the associated abort instruction pointer, in the __rseq_table
> > section. This section allows debuggers may know where to place
> > breakpoints when single-stepping through assembly blocks which may be
> > aborted at any point by the kernel.
> >
> > The following rseq APIs are implemented in this helper library:
> > - rseq_register_current_thread()/rseq_unregister_current_thread():
> > register/unregister current thread's use of rseq,
> > - rseq_current_cpu_raw():
> > current CPU number,
> > - rseq_start():
> > beginning of a restartable sequence,
> > - rseq_cpu_at_start():
> > CPU number at start of restartable sequence,
> > - rseq_finish():
> > End of restartable sequence made of zero or more loads, completed by
> > a word-sized store,
> > - rseq_finish2():
> > End of restartable sequence made of zero or more loads, one
> > speculative word-sized store, completed by a word-sized store,
> > - rseq_finish2_release():
> > End of restartable sequence made of zero or more loads, one
> > speculative word-sized store, completed by a word-sized store with
> > release semantic,
> > - rseq_finish_memcpy():
> > End of restartable sequence made of zero or more loads, a
> > speculative copy of a variable length memory region, completed by a
> > word-sized store.
> > - rseq_finish_memcpy_release():
> > End of restartable sequence made of zero or more loads, a
> > speculative copy of a variable length memory region, completed by a
> > word-sized store with release semantic.
> >
> > PowerPC tests have been implemented by Boqun Feng.
> 
> Hi Boqun,
> 

Hello Michael,

> I'm having trouble testing these, I get:
> 
>   ~/linus/tools/testing/selftests/cpu-opv$ ./basic_cpu_opv_test
>   Testing test_compare_eq same
>   Testing test_compare_eq different
>   Testing test_compare_ne same
>   Testing test_compare_ne different
>   Testing test_2compare_eq index
>   Testing test_2compare_ne index
>   Testing test_memcpy
>   Testing test_memcpy_u32
>   Testing test_add
>   Testing test_two_add
>   Testing test_or
>   Testing test_and
>   Testing test_xor
>   Testing test_lshift
>   Testing test_rshift
>   Testing test_cmpxchg success
>   Testing test_cmpxchg fail
>   
>   ~/linus/tools/testing/selftests/rseq$ ./basic_test
>   testing current cpu
>   testing critical section
>   testing critical section is interrupted by signal
> 
>   ~/linus/tools/testing/selftests/rseq$ ./basic_percpu_ops_test
>   ./basic_percpu_ops_test: error while loading shared libraries: 
> R_PPC64_ADDR16_HI re10d8f10a0 for symbol `' out of range
>   ~/linus/tools/testing/selftests/rseq$ ./param_test
>   ./param_test: error while loading shared libraries: R_PPC64_ADDR16_HI 
> re136251b48 for symbol `' out of range
> 

I think this one is due to the same reason as:

7998eb3dc700 ("powerpc: Fix 64 bit builds with binutils 2.24")

I have made the fix before, but seems forgot to send it to Mathieu...

so would this help?

diff --git a/tools/testing/selftests/rseq/rseq-ppc.h 
b/tools/testing/selftests/rseq/rseq-ppc.h
index bc78b4fd72b1..39cbabe89b0e 100644
--- a/tools/testing/selftests/rseq/rseq-ppc.h
+++ b/tools/testing/selftests/rseq/rseq-ppc.h
@@ -74,7 +74,7 @@ do {  
\
"lis %%r17, (3b)@highest\n\t" \
"ori %%r17, %%r17, (3b)@higher\n\t" \
"rldicr %%r17, %%r17, 32, 31\n\t" \
-   "oris %%r17, %%r17, (3b)@h\n\t" \
+   "oris %%r17, %%r17, (3b)@high\n\t" \
"ori %%r17, %%r17, (3b)@l\n\t" \
"std %%r17, 0(%[rseq_cs])\n\t" \
RSEQ_INJECT_ASM(2) \

Regards,
Boqun

> 
> Any idea what's going on with the last two? I assume you don't see that
> in your test setup :)
> 
> cheers

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

[Boqun Feng]

On Mon, Oct 16, 2017 at 02:00:33PM +1100, Michael Ellerman wrote:
> Mathieu Desnoyers  writes:
> 
> > Implements two basic tests of RSEQ functionality, and one more
> > exhaustive parameterizable test.
> >
> > The first, "basic_test" only asserts that RSEQ works moderately
> > correctly.
> > E.g. that:
> > - The CPUID pointer works
> > - Code infinitely looping within a critical section will eventually be
> >   interrupted.
> > - Critical sections are interrupted by signals.
> >
> > "basic_percpu_ops_test" is a slightly more "realistic" variant,
> > implementing a few simple per-cpu operations and testing their
> > correctness.
> >
> > "param_test" is a parametrizable restartable sequences test. See
> > the "--help" output for usage.
> >
> > As part of those tests, a helper library "rseq" implements a user-space
> > API around restartable sequences. It uses the cpu_opv system call as
> > fallback when single-stepped by a debugger. It exposes the instruction
> > pointer addresses where the rseq assembly blocks begin and end, as well
> > as the associated abort instruction pointer, in the __rseq_table
> > section. This section allows debuggers may know where to place
> > breakpoints when single-stepping through assembly blocks which may be
> > aborted at any point by the kernel.
> >
> > The following rseq APIs are implemented in this helper library:
> > - rseq_register_current_thread()/rseq_unregister_current_thread():
> > register/unregister current thread's use of rseq,
> > - rseq_current_cpu_raw():
> > current CPU number,
> > - rseq_start():
> > beginning of a restartable sequence,
> > - rseq_cpu_at_start():
> > CPU number at start of restartable sequence,
> > - rseq_finish():
> > End of restartable sequence made of zero or more loads, completed by
> > a word-sized store,
> > - rseq_finish2():
> > End of restartable sequence made of zero or more loads, one
> > speculative word-sized store, completed by a word-sized store,
> > - rseq_finish2_release():
> > End of restartable sequence made of zero or more loads, one
> > speculative word-sized store, completed by a word-sized store with
> > release semantic,
> > - rseq_finish_memcpy():
> > End of restartable sequence made of zero or more loads, a
> > speculative copy of a variable length memory region, completed by a
> > word-sized store.
> > - rseq_finish_memcpy_release():
> > End of restartable sequence made of zero or more loads, a
> > speculative copy of a variable length memory region, completed by a
> > word-sized store with release semantic.
> >
> > PowerPC tests have been implemented by Boqun Feng.
> 
> Hi Boqun,
> 

Hello Michael,

> I'm having trouble testing these, I get:
> 
>   ~/linus/tools/testing/selftests/cpu-opv$ ./basic_cpu_opv_test
>   Testing test_compare_eq same
>   Testing test_compare_eq different
>   Testing test_compare_ne same
>   Testing test_compare_ne different
>   Testing test_2compare_eq index
>   Testing test_2compare_ne index
>   Testing test_memcpy
>   Testing test_memcpy_u32
>   Testing test_add
>   Testing test_two_add
>   Testing test_or
>   Testing test_and
>   Testing test_xor
>   Testing test_lshift
>   Testing test_rshift
>   Testing test_cmpxchg success
>   Testing test_cmpxchg fail
>   
>   ~/linus/tools/testing/selftests/rseq$ ./basic_test
>   testing current cpu
>   testing critical section
>   testing critical section is interrupted by signal
> 
>   ~/linus/tools/testing/selftests/rseq$ ./basic_percpu_ops_test
>   ./basic_percpu_ops_test: error while loading shared libraries: 
> R_PPC64_ADDR16_HI re10d8f10a0 for symbol `' out of range
>   ~/linus/tools/testing/selftests/rseq$ ./param_test
>   ./param_test: error while loading shared libraries: R_PPC64_ADDR16_HI 
> re136251b48 for symbol `' out of range
> 

I think this one is due to the same reason as:

7998eb3dc700 ("powerpc: Fix 64 bit builds with binutils 2.24")

I have made the fix before, but seems forgot to send it to Mathieu...

so would this help?

diff --git a/tools/testing/selftests/rseq/rseq-ppc.h 
b/tools/testing/selftests/rseq/rseq-ppc.h
index bc78b4fd72b1..39cbabe89b0e 100644
--- a/tools/testing/selftests/rseq/rseq-ppc.h
+++ b/tools/testing/selftests/rseq/rseq-ppc.h
@@ -74,7 +74,7 @@ do {  
\
"lis %%r17, (3b)@highest\n\t" \
"ori %%r17, %%r17, (3b)@higher\n\t" \
"rldicr %%r17, %%r17, 32, 31\n\t" \
-   "oris %%r17, %%r17, (3b)@h\n\t" \
+   "oris %%r17, %%r17, (3b)@high\n\t" \
"ori %%r17, %%r17, (3b)@l\n\t" \
"std %%r17, 0(%[rseq_cs])\n\t" \
RSEQ_INJECT_ASM(2) \

Regards,
Boqun

> 
> Any idea what's going on with the last two? I assume you don't see that
> in your test setup :)
> 
> cheers

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

[Gang He]

Hello Intel Kbuild team,

You just upgrade GCC version when compiling the latest kernel? 
Since these code looks a little old, I am sure that the related contributors 
are still work on OCFS2 project.


Thanks
Gang


>>> 
> Hi Bhumika,
> 
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.14-rc4 next-20171013]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_l 
> inux_commits_Bhumika-2DGoyal_ocfs2-2Dcluster-2Dmake-2Dconfig-5Fitem-5Ftype-2Dconst_2
> 0171014-2D185701=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=f4ohdmG
> rYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrjbR5Spv4mvmdj2s377WohnG6h6z1
> WB7E=hFVfDC8STTMTIDNtdipf8BlwR_V8RJG6an_l-r9MKyA= 
> config: tile-allyesconfig (attached as .config)
> compiler: tilegx-linux-gcc (GCC) 4.6.2
> reproduce:
> wget 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.c 
> om_intel_lkp-2Dtests_master_sbin_make.cross=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxB
> KCX5YTpkKY057SbK10=f4ohdmGrYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrj
> bR5Spv4mvmdj2s377WohnG6h6z1WB7E=f5lUGF9NCtygTaG6AR0HkjhG7fOwD5nKFLaYCvPpju0
> =  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=tile 
> 
> All warnings (new ones prefixed by >>):
> 
>fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_node_group_make_item':
>fs/ocfs2/cluster/nodemanager.c:573:2: warning: passing argument 3 of 
> 'config_item_init_type_name' discards 'const' qualifier from pointer target 
> type [enabled by default]
>include/linux/configfs.h:73:13: note: expected 'struct config_item_type 
> *' but argument is of type 'const struct config_item_type *'
>fs/ocfs2/cluster/nodemanager.c: In function 
> 'o2nm_cluster_group_make_group':
>fs/ocfs2/cluster/nodemanager.c:681:9: warning: passing argument 3 of 
> 'config_group_init_type_name' discards 'const' qualifier from pointer target 
> type [enabled by default]
>include/linux/configfs.h:102:13: note: expected 'struct config_item_type 
> *' but argument is of type 'const struct config_item_type *'
>fs/ocfs2/cluster/nodemanager.c:685:9: warning: passing argument 3 of 
> 'config_group_init_type_name' discards 'const' qualifier from pointer target 
> type [enabled by default]
>include/linux/configfs.h:102:13: note: expected 'struct config_item_type 
> *' but argument is of type 'const struct config_item_type *'
>fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_depend_item':
>fs/ocfs2/cluster/nodemanager.c:743:2: warning: passing argument 1 of 
> 'configfs_depend_item' discards 'const' qualifier from pointer target type 
> [enabled by default]
>include/linux/configfs.h:269:5: note: expected 'struct configfs_subsystem 
> *' but argument is of type 'const struct configfs_subsystem *'
>fs/ocfs2/cluster/nodemanager.c: In function 'exit_o2nm':
>fs/ocfs2/cluster/nodemanager.c:785:2: warning: passing argument 1 of 
> 'configfs_unregister_subsystem' discards 'const' qualifier from pointer 
> target type [enabled by default]
>include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem 
> *' but argument is of type 'const struct configfs_subsystem *'
>fs/ocfs2/cluster/nodemanager.c: In function 'init_o2nm':
>fs/ocfs2/cluster/nodemanager.c:808:2: warning: passing argument 1 of 
> 'config_group_init' discards 'const' qualifier from pointer target type 
> [enabled by default]
>include/linux/configfs.h:101:13: note: expected 'struct config_group *' 
> but argument is of type 'const struct config_group *'
>>> fs/ocfs2/cluster/nodemanager.c:809:2: warning: passing argument 1 of 
> '__mutex_init' discards 'const' qualifier from pointer target type [enabled 
> by default]
>include/linux/mutex.h:133:13: note: expected 'struct mutex *' but 
> argument is of type 'const struct mutex *'
>fs/ocfs2/cluster/nodemanager.c:810:2: warning: passing argument 1 of 
> 'configfs_register_subsystem' discards 'const' qualifier from pointer target 
> type [enabled by default]
>include/linux/configfs.h:252:5: note: expected 'struct configfs_subsystem 
> *' but argument is of type 'const struct configfs_subsystem *'
>fs/ocfs2/cluster/nodemanager.c:820:2: warning: passing argument 1 of 
> 'configfs_unregister_subsystem' discards 'const' qualifier from pointer 
> target type [enabled by default]
>include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem 
> *' but argument is of type 'const struct configfs_subsystem *'
> 
> vim +809 fs/ocfs2/cluster/nodemanager.c
> 
> 0c83ed8e Kurt Hackel   2005-12-15  740  
> 14829422 Joel Becker   2007-06-14  741  int o2nm_depend_item(struct 
> config_item *item)
> 14829422 Joel Becker   2007-06-14  742  {
> 14829422 Joel Becker   2007-06-14 @743return 
> 

Re: [Ocfs2-devel] [PATCH] ocfs2/cluster: make config_item_type const

[Gang He]

Hello Intel Kbuild team,

You just upgrade GCC version when compiling the latest kernel? 
Since these code looks a little old, I am sure that the related contributors 
are still work on OCFS2 project.


Thanks
Gang


>>> 
> Hi Bhumika,
> 
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.14-rc4 next-20171013]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_l 
> inux_commits_Bhumika-2DGoyal_ocfs2-2Dcluster-2Dmake-2Dconfig-5Fitem-5Ftype-2Dconst_2
> 0171014-2D185701=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=f4ohdmG
> rYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrjbR5Spv4mvmdj2s377WohnG6h6z1
> WB7E=hFVfDC8STTMTIDNtdipf8BlwR_V8RJG6an_l-r9MKyA= 
> config: tile-allyesconfig (attached as .config)
> compiler: tilegx-linux-gcc (GCC) 4.6.2
> reproduce:
> wget 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.c 
> om_intel_lkp-2Dtests_master_sbin_make.cross=DwIBAg=RoP1YumCXCgaWHvlZYR8PQcxB
> KCX5YTpkKY057SbK10=f4ohdmGrYxZejY77yzx3eNgTHb1ZAfZytktjHqNVzc8=8Ca3nktkbfrj
> bR5Spv4mvmdj2s377WohnG6h6z1WB7E=f5lUGF9NCtygTaG6AR0HkjhG7fOwD5nKFLaYCvPpju0
> =  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=tile 
> 
> All warnings (new ones prefixed by >>):
> 
>fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_node_group_make_item':
>fs/ocfs2/cluster/nodemanager.c:573:2: warning: passing argument 3 of 
> 'config_item_init_type_name' discards 'const' qualifier from pointer target 
> type [enabled by default]
>include/linux/configfs.h:73:13: note: expected 'struct config_item_type 
> *' but argument is of type 'const struct config_item_type *'
>fs/ocfs2/cluster/nodemanager.c: In function 
> 'o2nm_cluster_group_make_group':
>fs/ocfs2/cluster/nodemanager.c:681:9: warning: passing argument 3 of 
> 'config_group_init_type_name' discards 'const' qualifier from pointer target 
> type [enabled by default]
>include/linux/configfs.h:102:13: note: expected 'struct config_item_type 
> *' but argument is of type 'const struct config_item_type *'
>fs/ocfs2/cluster/nodemanager.c:685:9: warning: passing argument 3 of 
> 'config_group_init_type_name' discards 'const' qualifier from pointer target 
> type [enabled by default]
>include/linux/configfs.h:102:13: note: expected 'struct config_item_type 
> *' but argument is of type 'const struct config_item_type *'
>fs/ocfs2/cluster/nodemanager.c: In function 'o2nm_depend_item':
>fs/ocfs2/cluster/nodemanager.c:743:2: warning: passing argument 1 of 
> 'configfs_depend_item' discards 'const' qualifier from pointer target type 
> [enabled by default]
>include/linux/configfs.h:269:5: note: expected 'struct configfs_subsystem 
> *' but argument is of type 'const struct configfs_subsystem *'
>fs/ocfs2/cluster/nodemanager.c: In function 'exit_o2nm':
>fs/ocfs2/cluster/nodemanager.c:785:2: warning: passing argument 1 of 
> 'configfs_unregister_subsystem' discards 'const' qualifier from pointer 
> target type [enabled by default]
>include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem 
> *' but argument is of type 'const struct configfs_subsystem *'
>fs/ocfs2/cluster/nodemanager.c: In function 'init_o2nm':
>fs/ocfs2/cluster/nodemanager.c:808:2: warning: passing argument 1 of 
> 'config_group_init' discards 'const' qualifier from pointer target type 
> [enabled by default]
>include/linux/configfs.h:101:13: note: expected 'struct config_group *' 
> but argument is of type 'const struct config_group *'
>>> fs/ocfs2/cluster/nodemanager.c:809:2: warning: passing argument 1 of 
> '__mutex_init' discards 'const' qualifier from pointer target type [enabled 
> by default]
>include/linux/mutex.h:133:13: note: expected 'struct mutex *' but 
> argument is of type 'const struct mutex *'
>fs/ocfs2/cluster/nodemanager.c:810:2: warning: passing argument 1 of 
> 'configfs_register_subsystem' discards 'const' qualifier from pointer target 
> type [enabled by default]
>include/linux/configfs.h:252:5: note: expected 'struct configfs_subsystem 
> *' but argument is of type 'const struct configfs_subsystem *'
>fs/ocfs2/cluster/nodemanager.c:820:2: warning: passing argument 1 of 
> 'configfs_unregister_subsystem' discards 'const' qualifier from pointer 
> target type [enabled by default]
>include/linux/configfs.h:253:6: note: expected 'struct configfs_subsystem 
> *' but argument is of type 'const struct configfs_subsystem *'
> 
> vim +809 fs/ocfs2/cluster/nodemanager.c
> 
> 0c83ed8e Kurt Hackel   2005-12-15  740  
> 14829422 Joel Becker   2007-06-14  741  int o2nm_depend_item(struct 
> config_item *item)
> 14829422 Joel Becker   2007-06-14  742  {
> 14829422 Joel Becker   2007-06-14 @743return 
> 

Re: [f2fs-dev] [PATCH v2] f2fs: update dirty status for CURSEG as well

[Chao Yu]

On 2017/10/14 20:53, Yunlong Song wrote:
> Oh, yes it is. I found that problem in a kernel tree which does not have 
> commit
> c6f82fe90d7458e5fa190a6820bfc24f96b0de4e (Revert "f2fs: put allocate_segment
> after refresh_sit_entry"). In that kernel, the allocate_segment is still 
> behind
> refresh_sit_entry. Now I understand the commit message:
> "This makes a leak to register dirty segments. I reproduced the issue by
>  modified postmark which injects a lot of file create/delete/update and
>  finally triggers huge number of SSR allocations."
> 
> The reason is that if refresh_sit_entry is before allocate_segment, then the
> dirty status of CURSEG is not updated, as a result, the count of dirty 
> segments
> is wrong, which is much smaller than its real value. Then the f2fs_gc 
> can not
> do its work since it can not even get one victim, then the free segments are
> used up and then triggers much SSR. So Jay reverts the patch.
> 
> It seems there are two options:
> (1) keep this patch ([PATCH v2] f2fs: update dirty status for CURSEG as 
> well)
> and we can recover commit 3436c4bdb30de421d46f58c9174669fbcfd40ce0
> (f2fs: put allocate_segment after refresh_sit_entry)
> (2) remove this patch at all
> 
> It seems (1) is robust, but (2) avoids unnecessary check.

What about reverting 5e443818fa0b ("f2fs: handle dirty segments inside
refresh_sit_entry") to keep the original order:

1. update sit info
2. allocate new segment
3. update dirty status of segment

Thanks,

> 
> On 2017/10/14 8:14, Chao Yu wrote:
>> On 2017/10/13 21:21, Yunlong Song wrote:
>>> Without this patch, it will cause all the free segments using up in some
>>> corner case. For example, there are 100 segments, and 20 of them are
>>> reserved for ovp. If 79 segments are full of data, segment 80 becomes
>>> CURSEG segment, write 512 blocks and then delete 511 blocks. Since it is
>>> CURSEG segment, the __locate_dirty_segment will not update its dirty
>>> status. Then the dirty_segments(sbi) is 0, f2fs_gc will fail to
>>> get_victim, and f2fs_balance_fs will fail to trigger gc action. After
>>> f2fs_balance_fs returns, f2fs can continue to write data to segment 81.
>>> Again, segment 81 becomes CURSEG segment, write 512 blocks and delete
>>> 511 blocks, the dirty_segments(sbi) is 0 and f2fs_gc fail again. This
>>> can finally use up all the free segments and cause panic.
>> Look into this patch again, I found refresh_sit_entry is called after
>> ->allocate_segment, so if all 512 blocks were allocated, log header should
>> have been moved to another segment, so locate_dirty_segment in
>> refresh_sit_entry should update dirty status of previous segment correctly,
>> anything I'm missing?
>>
>> Thanks,
>>
>>> Signed-off-by: Yunlong Song 
>>> ---
>>>   fs/f2fs/segment.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>>> index bfbcff8..0fce076 100644
>>> --- a/fs/f2fs/segment.c
>>> +++ b/fs/f2fs/segment.c
>>> @@ -687,7 +687,7 @@ static void __locate_dirty_segment(struct f2fs_sb_info 
>>> *sbi, unsigned int segno,
>>> struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
>>>   
>>> /* need not be added */
>>> -   if (IS_CURSEG(sbi, segno))
>>> +   if (IS_CURSEG(sbi, segno) && dirty_type == PRE)
>>> return;
>>>   
>>> if (!test_and_set_bit(segno, dirty_i->dirty_segmap[dirty_type]))
>>> @@ -737,7 +737,7 @@ static void locate_dirty_segment(struct f2fs_sb_info 
>>> *sbi, unsigned int segno)
>>> struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
>>> unsigned short valid_blocks;
>>>   
>>> -   if (segno == NULL_SEGNO || IS_CURSEG(sbi, segno))
>>> +   if (segno == NULL_SEGNO)
>>> return;
>>>   
>>> mutex_lock(_i->seglist_lock);
>>>
>> .
>>
> 

Re: [f2fs-dev] [PATCH v2] f2fs: update dirty status for CURSEG as well

[Chao Yu]

On 2017/10/14 20:53, Yunlong Song wrote:
> Oh, yes it is. I found that problem in a kernel tree which does not have 
> commit
> c6f82fe90d7458e5fa190a6820bfc24f96b0de4e (Revert "f2fs: put allocate_segment
> after refresh_sit_entry"). In that kernel, the allocate_segment is still 
> behind
> refresh_sit_entry. Now I understand the commit message:
> "This makes a leak to register dirty segments. I reproduced the issue by
>  modified postmark which injects a lot of file create/delete/update and
>  finally triggers huge number of SSR allocations."
> 
> The reason is that if refresh_sit_entry is before allocate_segment, then the
> dirty status of CURSEG is not updated, as a result, the count of dirty 
> segments
> is wrong, which is much smaller than its real value. Then the f2fs_gc 
> can not
> do its work since it can not even get one victim, then the free segments are
> used up and then triggers much SSR. So Jay reverts the patch.
> 
> It seems there are two options:
> (1) keep this patch ([PATCH v2] f2fs: update dirty status for CURSEG as 
> well)
> and we can recover commit 3436c4bdb30de421d46f58c9174669fbcfd40ce0
> (f2fs: put allocate_segment after refresh_sit_entry)
> (2) remove this patch at all
> 
> It seems (1) is robust, but (2) avoids unnecessary check.

What about reverting 5e443818fa0b ("f2fs: handle dirty segments inside
refresh_sit_entry") to keep the original order:

1. update sit info
2. allocate new segment
3. update dirty status of segment

Thanks,

> 
> On 2017/10/14 8:14, Chao Yu wrote:
>> On 2017/10/13 21:21, Yunlong Song wrote:
>>> Without this patch, it will cause all the free segments using up in some
>>> corner case. For example, there are 100 segments, and 20 of them are
>>> reserved for ovp. If 79 segments are full of data, segment 80 becomes
>>> CURSEG segment, write 512 blocks and then delete 511 blocks. Since it is
>>> CURSEG segment, the __locate_dirty_segment will not update its dirty
>>> status. Then the dirty_segments(sbi) is 0, f2fs_gc will fail to
>>> get_victim, and f2fs_balance_fs will fail to trigger gc action. After
>>> f2fs_balance_fs returns, f2fs can continue to write data to segment 81.
>>> Again, segment 81 becomes CURSEG segment, write 512 blocks and delete
>>> 511 blocks, the dirty_segments(sbi) is 0 and f2fs_gc fail again. This
>>> can finally use up all the free segments and cause panic.
>> Look into this patch again, I found refresh_sit_entry is called after
>> ->allocate_segment, so if all 512 blocks were allocated, log header should
>> have been moved to another segment, so locate_dirty_segment in
>> refresh_sit_entry should update dirty status of previous segment correctly,
>> anything I'm missing?
>>
>> Thanks,
>>
>>> Signed-off-by: Yunlong Song 
>>> ---
>>>   fs/f2fs/segment.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>>> index bfbcff8..0fce076 100644
>>> --- a/fs/f2fs/segment.c
>>> +++ b/fs/f2fs/segment.c
>>> @@ -687,7 +687,7 @@ static void __locate_dirty_segment(struct f2fs_sb_info 
>>> *sbi, unsigned int segno,
>>> struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
>>>   
>>> /* need not be added */
>>> -   if (IS_CURSEG(sbi, segno))
>>> +   if (IS_CURSEG(sbi, segno) && dirty_type == PRE)
>>> return;
>>>   
>>> if (!test_and_set_bit(segno, dirty_i->dirty_segmap[dirty_type]))
>>> @@ -737,7 +737,7 @@ static void locate_dirty_segment(struct f2fs_sb_info 
>>> *sbi, unsigned int segno)
>>> struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
>>> unsigned short valid_blocks;
>>>   
>>> -   if (segno == NULL_SEGNO || IS_CURSEG(sbi, segno))
>>> +   if (segno == NULL_SEGNO)
>>> return;
>>>   
>>> mutex_lock(_i->seglist_lock);
>>>
>> .
>>
> 

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

[Keith Packard]

Sean Paul  writes:

> Sphinx won't pick these up, and will issue warnings. Please update to @
> instead of \param
>
> If you want to try it out:
> make htmldocs

Yeah, I was attempting to emulate the existing style. I suggest that a
general cleanup to fix the docstrings should be in a separate patch and
cover a file at at time so that we can reasonably test the results. I
don't have a strong opinion on what format we should use before that
happens.

> Otherwise,
>
> Reviewed-by: Sean Paul 

Thanks for your review.

-- 
-keith


signature.asc
Description: PGP signature

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]

[Keith Packard]

Sean Paul  writes:

> Sphinx won't pick these up, and will issue warnings. Please update to @
> instead of \param
>
> If you want to try it out:
> make htmldocs

Yeah, I was attempting to emulate the existing style. I suggest that a
general cleanup to fix the docstrings should be in a separate patch and
cover a file at at time so that we can reasonably test the results. I
don't have a strong opinion on what format we should use before that
happens.

> Otherwise,
>
> Reviewed-by: Sean Paul 

Thanks for your review.

-- 
-keith


signature.asc
Description: PGP signature

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

[Randy Dunlap]

On 10/15/17 20:27, Randy Dunlap wrote:
> On 10/15/17 19:27, Marian Mihailescu wrote:
>> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
>> are built only for architectures that use it.
>>
>> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
>> be selected.
>>
>> However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:
>>
>> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
>> *bus)
>> {
>> return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
>> }
>>
>> I will let a maintainer suggest the best resolution for this :)
>>
> 
> add Bart and iommu mailing list.
> 

and add Vladimir.


-- 
~Randy

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

[Randy Dunlap]

On 10/15/17 20:27, Randy Dunlap wrote:
> On 10/15/17 19:27, Marian Mihailescu wrote:
>> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
>> are built only for architectures that use it.
>>
>> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
>> be selected.
>>
>> However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:
>>
>> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
>> *bus)
>> {
>> return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
>> }
>>
>> I will let a maintainer suggest the best resolution for this :)
>>
> 
> add Bart and iommu mailing list.
> 

and add Vladimir.


-- 
~Randy

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

[Randy Dunlap]

On 10/15/17 19:27, Marian Mihailescu wrote:
> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
> are built only for architectures that use it.
> 
> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
> be selected.
> 
> However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:
> 
> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
> {
> return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
> }
> 
> I will let a maintainer suggest the best resolution for this :)
> 

add Bart and iommu mailing list.


-- 
~Randy

Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

[Randy Dunlap]

On 10/15/17 19:27, Marian Mihailescu wrote:
> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
> are built only for architectures that use it.
> 
> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
> be selected.
> 
> However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:
> 
> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
> {
> return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
> }
> 
> I will let a maintainer suggest the best resolution for this :)
> 

add Bart and iommu mailing list.


-- 
~Randy

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

[Li, Aubrey]

On 2017/10/14 8:51, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:30 AM CEST Aubrey Li wrote:
>> If the next idle is expected to be a fast idle, we should keep tick
>> on before going into idle
>>
>> Signed-off-by: Aubrey Li 
> 
> This also can be merged with the previous patch (and the [2/8]) IMO.
> 

okay, will merge in the next version.

>> ---
>>  drivers/cpuidle/cpuidle.c | 14 ++
>>  include/linux/cpuidle.h   |  2 ++
>>  kernel/time/tick-sched.c  |  4 
>>  3 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>> index ef6f7dd..6cb7e17 100644
>> --- a/drivers/cpuidle/cpuidle.c
>> +++ b/drivers/cpuidle/cpuidle.c
>> @@ -370,6 +370,20 @@ void cpuidle_predict(void)
>>  }
>>  
>>  /**
>> + * cpuidle_fast_idle - predict whether or not the coming idle is a fast idle
>> + * This function can be called in irq exit path, make it as soon as possible
>> + */
>> +bool cpuidle_fast_idle(void)
>> +{
>> +struct cpuidle_device *dev = cpuidle_get_device();
>> +
>> +if (!dev)
>> +return false;
>> +
>> +return dev->idle_stat.fast_idle;
> 
> return dev && dev->idle_stat.fast_idle;

Thanks!

>>  
>> @@ -916,6 +917,9 @@ static bool can_stop_idle_tick(int cpu, struct 
>> tick_sched *ts)
>>  return false;
>>  }
>>  
>> +if (cpuidle_fast_idle())
>> +return false;
>> +
>>  return true;
> 
> return !cpuidle_fast_idle();

And thanks!
> 
>>  }
>>  
>>
> 
> And IMO there is quite a bit too much marketing in the "fast_idle" name,
> as it seems all about avoiding to stop the tick if the predicted idle
> duration is short enough.
> 

okay, and what's your suggestion? :)
I'll try to move quiet_vmstat() into the normal idle branch if this patch series
are reasonable. Is fast_idle a good indication for it?

Thanks,
-Aubrey

Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle

[Li, Aubrey]

On 2017/10/14 8:51, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:30 AM CEST Aubrey Li wrote:
>> If the next idle is expected to be a fast idle, we should keep tick
>> on before going into idle
>>
>> Signed-off-by: Aubrey Li 
> 
> This also can be merged with the previous patch (and the [2/8]) IMO.
> 

okay, will merge in the next version.

>> ---
>>  drivers/cpuidle/cpuidle.c | 14 ++
>>  include/linux/cpuidle.h   |  2 ++
>>  kernel/time/tick-sched.c  |  4 
>>  3 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>> index ef6f7dd..6cb7e17 100644
>> --- a/drivers/cpuidle/cpuidle.c
>> +++ b/drivers/cpuidle/cpuidle.c
>> @@ -370,6 +370,20 @@ void cpuidle_predict(void)
>>  }
>>  
>>  /**
>> + * cpuidle_fast_idle - predict whether or not the coming idle is a fast idle
>> + * This function can be called in irq exit path, make it as soon as possible
>> + */
>> +bool cpuidle_fast_idle(void)
>> +{
>> +struct cpuidle_device *dev = cpuidle_get_device();
>> +
>> +if (!dev)
>> +return false;
>> +
>> +return dev->idle_stat.fast_idle;
> 
> return dev && dev->idle_stat.fast_idle;

Thanks!

>>  
>> @@ -916,6 +917,9 @@ static bool can_stop_idle_tick(int cpu, struct 
>> tick_sched *ts)
>>  return false;
>>  }
>>  
>> +if (cpuidle_fast_idle())
>> +return false;
>> +
>>  return true;
> 
> return !cpuidle_fast_idle();

And thanks!
> 
>>  }
>>  
>>
> 
> And IMO there is quite a bit too much marketing in the "fast_idle" name,
> as it seems all about avoiding to stop the tick if the predicted idle
> duration is short enough.
> 

okay, and what's your suggestion? :)
I'll try to move quiet_vmstat() into the normal idle branch if this patch series
are reasonable. Is fast_idle a good indication for it?

Thanks,
-Aubrey

Re: [f2fs-dev] [PATCH v2] f2fs: add bug_on when f2fs_gc even fails to get one victim

[Chao Yu]

On 2017/10/14 20:34, Yunlong Song wrote:
> Do you mean check out-of-space test? I have tried that but no bugon.

Yes, test recent f2fs codes with kernel 4.13.0-rc1+ in VM, FYI:

kernel BUG at gc.c:1034!
invalid opcode:  [#1] SMP
Hardware name: Xen HVM domU, BIOS 4.1.2_115-900.260_ 11/06/2015
RIP: 0010:f2fs_gc+0x6e5/0x6f0 [f2fs]
RSP: 0018:c90004af7b40 EFLAGS: 00010202
RAX: 8801b0a15940 RBX:  RCX: 
RDX: 8801b0a15940 RSI: 8801978d5f00 RDI: 880128148048
RBP: c90004af7c38 R08: 8801978d5f00 R09: 0003
R10: 0003 R11: 8800060703a0 R12: 
R13:  R14: 0001 R15: 8801b4279800
FS:  7f23493cb740() GS:880216f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ffd05402ff8 CR3: 0001bffb3000 CR4: 001406e0
Call Trace:
 f2fs_balance_fs+0x123/0x140 [f2fs]
 f2fs_create+0x130/0x240 [f2fs]
 path_openat+0xee7/0x1360
 do_filp_open+0x7e/0xd0
 do_sys_open+0x115/0x1f0
 SyS_open+0x1e/0x20
 do_syscall_64+0x6e/0x160
 entry_SYSCALL64_slow_path+0x25/0x25

Thanks,

> 
> On 2017/10/14 8:17, Chao Yu wrote:
>> On 2017/10/13 21:31, Yunlong Song wrote:
>>> This can help us to debug on some corner case.
>> I can hit this bugon with generic/015 of fstest easily, could have a look at
>> this?
>>
>> Thanks,
>>
>>> Signed-off-by: Yunlong Song 
>>> Signed-off-by: Chao Yu 
>>> ---
>>>   fs/f2fs/gc.c | 6 +-
>>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>>> index 197ebf4..2b03202 100644
>>> --- a/fs/f2fs/gc.c
>>> +++ b/fs/f2fs/gc.c
>>> @@ -986,6 +986,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>>> .ilist = LIST_HEAD_INIT(gc_list.ilist),
>>> .iroot = RADIX_TREE_INIT(GFP_NOFS),
>>> };
>>> +   bool need_fggc = false;
>>>   
>>> trace_f2fs_gc_begin(sbi->sb, sync, background,
>>> get_pages(sbi, F2FS_DIRTY_NODES),
>>> @@ -1018,8 +1019,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>>> if (ret)
>>> goto stop;
>>> }
>>> -   if (has_not_enough_free_secs(sbi, 0, 0))
>>> +   if (has_not_enough_free_secs(sbi, 0, 0)) {
>>> gc_type = FG_GC;
>>> +   need_fggc = true;
>>> +   }
>>> }
>>>   
>>> /* f2fs_balance_fs doesn't need to do BG_GC in critical path. */
>>> @@ -1028,6 +1031,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>>> goto stop;
>>> }
>>> if (!__get_victim(sbi, , gc_type)) {
>>> +   f2fs_bug_on(sbi, !total_freed && need_fggc);
>>> ret = -ENODATA;
>>> goto stop;
>>> }
>>>
>> .
>>
> 

Re: [f2fs-dev] [PATCH v2] f2fs: add bug_on when f2fs_gc even fails to get one victim

[Chao Yu]

On 2017/10/14 20:34, Yunlong Song wrote:
> Do you mean check out-of-space test? I have tried that but no bugon.

Yes, test recent f2fs codes with kernel 4.13.0-rc1+ in VM, FYI:

kernel BUG at gc.c:1034!
invalid opcode:  [#1] SMP
Hardware name: Xen HVM domU, BIOS 4.1.2_115-900.260_ 11/06/2015
RIP: 0010:f2fs_gc+0x6e5/0x6f0 [f2fs]
RSP: 0018:c90004af7b40 EFLAGS: 00010202
RAX: 8801b0a15940 RBX:  RCX: 
RDX: 8801b0a15940 RSI: 8801978d5f00 RDI: 880128148048
RBP: c90004af7c38 R08: 8801978d5f00 R09: 0003
R10: 0003 R11: 8800060703a0 R12: 
R13:  R14: 0001 R15: 8801b4279800
FS:  7f23493cb740() GS:880216f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ffd05402ff8 CR3: 0001bffb3000 CR4: 001406e0
Call Trace:
 f2fs_balance_fs+0x123/0x140 [f2fs]
 f2fs_create+0x130/0x240 [f2fs]
 path_openat+0xee7/0x1360
 do_filp_open+0x7e/0xd0
 do_sys_open+0x115/0x1f0
 SyS_open+0x1e/0x20
 do_syscall_64+0x6e/0x160
 entry_SYSCALL64_slow_path+0x25/0x25

Thanks,

> 
> On 2017/10/14 8:17, Chao Yu wrote:
>> On 2017/10/13 21:31, Yunlong Song wrote:
>>> This can help us to debug on some corner case.
>> I can hit this bugon with generic/015 of fstest easily, could have a look at
>> this?
>>
>> Thanks,
>>
>>> Signed-off-by: Yunlong Song 
>>> Signed-off-by: Chao Yu 
>>> ---
>>>   fs/f2fs/gc.c | 6 +-
>>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>>> index 197ebf4..2b03202 100644
>>> --- a/fs/f2fs/gc.c
>>> +++ b/fs/f2fs/gc.c
>>> @@ -986,6 +986,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>>> .ilist = LIST_HEAD_INIT(gc_list.ilist),
>>> .iroot = RADIX_TREE_INIT(GFP_NOFS),
>>> };
>>> +   bool need_fggc = false;
>>>   
>>> trace_f2fs_gc_begin(sbi->sb, sync, background,
>>> get_pages(sbi, F2FS_DIRTY_NODES),
>>> @@ -1018,8 +1019,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>>> if (ret)
>>> goto stop;
>>> }
>>> -   if (has_not_enough_free_secs(sbi, 0, 0))
>>> +   if (has_not_enough_free_secs(sbi, 0, 0)) {
>>> gc_type = FG_GC;
>>> +   need_fggc = true;
>>> +   }
>>> }
>>>   
>>> /* f2fs_balance_fs doesn't need to do BG_GC in critical path. */
>>> @@ -1028,6 +1031,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
>>> goto stop;
>>> }
>>> if (!__get_victim(sbi, , gc_type)) {
>>> +   f2fs_bug_on(sbi, !total_freed && need_fggc);
>>> ret = -ENODATA;
>>> goto stop;
>>> }
>>>
>> .
>>
> 

Re: [PATCH v2 7/9] usb: host: modify description for MTK xHCI config

[Chunfeng Yun]

On Fri, 2017-10-13 at 13:32 +0300, Mathias Nyman wrote:
> On 13.10.2017 11:26, Chunfeng Yun wrote:
> > Due to all MediaTek SoCs with xHCI host controller use this
> > driver, remove limitation for specific SoCs
> >
> > Signed-off-by: Chunfeng Yun 
> > ---
> 
> xHCI parts of series look good to me, If Rob Herring agrees with the
> dt changes I can send it forward
Thanks a lot
> 
> -Mathias
> 

Re: [PATCH v2 7/9] usb: host: modify description for MTK xHCI config

[Chunfeng Yun]

On Fri, 2017-10-13 at 13:32 +0300, Mathias Nyman wrote:
> On 13.10.2017 11:26, Chunfeng Yun wrote:
> > Due to all MediaTek SoCs with xHCI host controller use this
> > driver, remove limitation for specific SoCs
> >
> > Signed-off-by: Chunfeng Yun 
> > ---
> 
> xHCI parts of series look good to me, If Rob Herring agrees with the
> dt changes I can send it forward
Thanks a lot
> 
> -Mathias
> 

[PATCH v6 3/3] media: ov7670: Add the ov7670_s_power function

[Wenyou Yang]

Add the ov7670_s_power function which is responsible for
manipulating the power dowm mode through the PWDN pin and the reset
operation through the RESET pin, and keep it powered at all times.

Signed-off-by: Wenyou Yang 
---

Changes in v6:
 - Remove .s_power callback to keep the ov7670 powered at all times.
 - Update the commit log accordingly.

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
 - Add the patch to support the get_fmt ops.
 - Remove the redundant invoking ov7670_init_gpio().

 drivers/media/i2c/ov7670.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 73ceec63a8ca..35a30605d6e3 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1544,6 +1544,22 @@ static int ov7670_s_register(struct v4l2_subdev *sd, 
const struct v4l2_dbg_regis
 }
 #endif
 
+static int ov7670_s_power(struct v4l2_subdev *sd, int on)
+{
+   struct ov7670_info *info = to_state(sd);
+
+   if (info->pwdn_gpio)
+   gpiod_direction_output(info->pwdn_gpio, !on);
+   if (on && info->resetb_gpio) {
+   gpiod_set_value(info->resetb_gpio, 1);
+   usleep_range(500, 1000);
+   gpiod_set_value(info->resetb_gpio, 0);
+   usleep_range(3000, 5000);
+   }
+
+   return 0;
+}
+
 static void ov7670_get_default_format(struct v4l2_subdev *sd,
  struct v4l2_mbus_framefmt *format)
 {
@@ -1694,23 +1710,25 @@ static int ov7670_probe(struct i2c_client *client,
if (ret)
return ret;
 
-   ret = ov7670_init_gpio(client, info);
-   if (ret)
-   goto clk_disable;
-
info->clock_speed = clk_get_rate(info->clk) / 100;
if (info->clock_speed < 10 || info->clock_speed > 48) {
ret = -EINVAL;
goto clk_disable;
}
 
+   ret = ov7670_init_gpio(client, info);
+   if (ret)
+   goto clk_disable;
+
+   ov7670_s_power(sd, 1);
+
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
if (ret) {
v4l_dbg(1, debug, client,
"chip found @ 0x%x (%s) is not an ov7670 chip.\n",
client->addr << 1, client->adapter->name);
-   goto clk_disable;
+   goto power_off;
}
v4l_info(client, "chip found @ 0x%02x (%s)\n",
client->addr << 1, client->adapter->name);
@@ -1789,6 +1807,8 @@ static int ov7670_probe(struct i2c_client *client,
 #endif
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
+power_off:
+   ov7670_s_power(sd, 0);
 clk_disable:
clk_disable_unprepare(info->clk);
return ret;
@@ -1806,6 +1826,7 @@ static int ov7670_remove(struct i2c_client *client)
 #if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>sd.entity);
 #endif
+   ov7670_s_power(sd, 0);
return 0;
 }
 
-- 
2.13.0

[PATCH v6 3/3] media: ov7670: Add the ov7670_s_power function

[Wenyou Yang]

Add the ov7670_s_power function which is responsible for
manipulating the power dowm mode through the PWDN pin and the reset
operation through the RESET pin, and keep it powered at all times.

Signed-off-by: Wenyou Yang 
---

Changes in v6:
 - Remove .s_power callback to keep the ov7670 powered at all times.
 - Update the commit log accordingly.

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
 - Add the patch to support the get_fmt ops.
 - Remove the redundant invoking ov7670_init_gpio().

 drivers/media/i2c/ov7670.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 73ceec63a8ca..35a30605d6e3 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1544,6 +1544,22 @@ static int ov7670_s_register(struct v4l2_subdev *sd, 
const struct v4l2_dbg_regis
 }
 #endif
 
+static int ov7670_s_power(struct v4l2_subdev *sd, int on)
+{
+   struct ov7670_info *info = to_state(sd);
+
+   if (info->pwdn_gpio)
+   gpiod_direction_output(info->pwdn_gpio, !on);
+   if (on && info->resetb_gpio) {
+   gpiod_set_value(info->resetb_gpio, 1);
+   usleep_range(500, 1000);
+   gpiod_set_value(info->resetb_gpio, 0);
+   usleep_range(3000, 5000);
+   }
+
+   return 0;
+}
+
 static void ov7670_get_default_format(struct v4l2_subdev *sd,
  struct v4l2_mbus_framefmt *format)
 {
@@ -1694,23 +1710,25 @@ static int ov7670_probe(struct i2c_client *client,
if (ret)
return ret;
 
-   ret = ov7670_init_gpio(client, info);
-   if (ret)
-   goto clk_disable;
-
info->clock_speed = clk_get_rate(info->clk) / 100;
if (info->clock_speed < 10 || info->clock_speed > 48) {
ret = -EINVAL;
goto clk_disable;
}
 
+   ret = ov7670_init_gpio(client, info);
+   if (ret)
+   goto clk_disable;
+
+   ov7670_s_power(sd, 1);
+
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
if (ret) {
v4l_dbg(1, debug, client,
"chip found @ 0x%x (%s) is not an ov7670 chip.\n",
client->addr << 1, client->adapter->name);
-   goto clk_disable;
+   goto power_off;
}
v4l_info(client, "chip found @ 0x%02x (%s)\n",
client->addr << 1, client->adapter->name);
@@ -1789,6 +1807,8 @@ static int ov7670_probe(struct i2c_client *client,
 #endif
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
+power_off:
+   ov7670_s_power(sd, 0);
 clk_disable:
clk_disable_unprepare(info->clk);
return ret;
@@ -1806,6 +1826,7 @@ static int ov7670_remove(struct i2c_client *client)
 #if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>sd.entity);
 #endif
+   ov7670_s_power(sd, 0);
return 0;
 }
 
-- 
2.13.0

[PATCH v6 2/3] media: ov7670: Add the get_fmt callback

[Wenyou Yang]

Add the get_fmt callback, also enable V4L2_SUBDEV_FL_HAS_DEVNODE flag
to make this subdev has device node.

Signed-off-by: Wenyou Yang 
---

Changes in v6: None
Changes in v5:
 - Fix the build warning on the declaration *mbus_fmt(ISO C90 forbids mixed).

Changes in v4:
 - Fix the build error when not enabling V4L2 sub-device userspace API option.

Changes in v3:
 - Keep tried format info in the try_fmt member of
   v4l2_subdev__pad_config struct.
 - Add the internal_ops callback to set default format.

Changes in v2: None

 drivers/media/i2c/ov7670.c | 77 +-
 1 file changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 553945d4ca28..73ceec63a8ca 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -232,6 +232,7 @@ struct ov7670_info {
struct v4l2_ctrl *saturation;
struct v4l2_ctrl *hue;
};
+   struct v4l2_mbus_framefmt format;
struct ov7670_format_struct *fmt;  /* Current format */
struct clk *clk;
struct gpio_desc *resetb_gpio;
@@ -975,6 +976,9 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
fmt->width = wsize->width;
fmt->height = wsize->height;
fmt->colorspace = ov7670_formats[index].colorspace;
+
+   info->format = *fmt;
+
return 0;
 }
 
@@ -988,6 +992,9 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
struct ov7670_format_struct *ovfmt;
struct ov7670_win_size *wsize;
struct ov7670_info *info = to_state(sd);
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+   struct v4l2_mbus_framefmt *mbus_fmt;
+#endif
unsigned char com7;
int ret;
 
@@ -998,8 +1005,13 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
ret = ov7670_try_fmt_internal(sd, >format, NULL, NULL);
if (ret)
return ret;
-   cfg->try_fmt = format->format;
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+   mbus_fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
+   *mbus_fmt = format->format;
return 0;
+#else
+   return -ENOTTY;
+#endif
}
 
ret = ov7670_try_fmt_internal(sd, >format, , );
@@ -1041,6 +1053,30 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
return 0;
 }
 
+static int ov7670_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *format)
+{
+   struct ov7670_info *info = to_state(sd);
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+   struct v4l2_mbus_framefmt *mbus_fmt;
+#endif
+
+   if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+   mbus_fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
+   format->format = *mbus_fmt;
+   return 0;
+#else
+   return -ENOTTY;
+#endif
+   } else {
+   format->format = info->format;
+   }
+
+   return 0;
+}
+
 /*
  * Implement G/S_PARM.  There is a "high quality" mode we could try
  * to do someday; for now, we just do the frame rate tweak.
@@ -1508,6 +1544,30 @@ static int ov7670_s_register(struct v4l2_subdev *sd, 
const struct v4l2_dbg_regis
 }
 #endif
 
+static void ov7670_get_default_format(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *format)
+{
+   struct ov7670_info *info = to_state(sd);
+
+   format->width = info->devtype->win_sizes[0].width;
+   format->height = info->devtype->win_sizes[0].height;
+   format->colorspace = info->fmt->colorspace;
+   format->code = info->fmt->mbus_code;
+   format->field = V4L2_FIELD_NONE;
+}
+
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+static int ov7670_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+   struct v4l2_mbus_framefmt *format =
+   v4l2_subdev_get_try_format(sd, fh->pad, 0);
+
+   ov7670_get_default_format(sd, format);
+
+   return 0;
+}
+#endif
+
 /* --- */
 
 static const struct v4l2_subdev_core_ops ov7670_core_ops = {
@@ -1528,6 +1588,7 @@ static const struct v4l2_subdev_pad_ops ov7670_pad_ops = {
.enum_frame_interval = ov7670_enum_frame_interval,
.enum_frame_size = ov7670_enum_frame_size,
.enum_mbus_code = ov7670_enum_mbus_code,
+   .get_fmt = ov7670_get_fmt,
.set_fmt = ov7670_set_fmt,
 };
 
@@ -1537,6 +1598,12 @@ static const struct v4l2_subdev_ops ov7670_ops = {
.pad = _pad_ops,
 };
 
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+static const struct v4l2_subdev_internal_ops ov7670_subdev_internal_ops = {
+   .open = ov7670_open,
+};
+#endif
+
 /* --- */
 
 static const struct ov7670_devtype ov7670_devdata[] = {
@@ 

[PATCH v6 2/3] media: ov7670: Add the get_fmt callback

[Wenyou Yang]

Add the get_fmt callback, also enable V4L2_SUBDEV_FL_HAS_DEVNODE flag
to make this subdev has device node.

Signed-off-by: Wenyou Yang 
---

Changes in v6: None
Changes in v5:
 - Fix the build warning on the declaration *mbus_fmt(ISO C90 forbids mixed).

Changes in v4:
 - Fix the build error when not enabling V4L2 sub-device userspace API option.

Changes in v3:
 - Keep tried format info in the try_fmt member of
   v4l2_subdev__pad_config struct.
 - Add the internal_ops callback to set default format.

Changes in v2: None

 drivers/media/i2c/ov7670.c | 77 +-
 1 file changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 553945d4ca28..73ceec63a8ca 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -232,6 +232,7 @@ struct ov7670_info {
struct v4l2_ctrl *saturation;
struct v4l2_ctrl *hue;
};
+   struct v4l2_mbus_framefmt format;
struct ov7670_format_struct *fmt;  /* Current format */
struct clk *clk;
struct gpio_desc *resetb_gpio;
@@ -975,6 +976,9 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
fmt->width = wsize->width;
fmt->height = wsize->height;
fmt->colorspace = ov7670_formats[index].colorspace;
+
+   info->format = *fmt;
+
return 0;
 }
 
@@ -988,6 +992,9 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
struct ov7670_format_struct *ovfmt;
struct ov7670_win_size *wsize;
struct ov7670_info *info = to_state(sd);
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+   struct v4l2_mbus_framefmt *mbus_fmt;
+#endif
unsigned char com7;
int ret;
 
@@ -998,8 +1005,13 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
ret = ov7670_try_fmt_internal(sd, >format, NULL, NULL);
if (ret)
return ret;
-   cfg->try_fmt = format->format;
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+   mbus_fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
+   *mbus_fmt = format->format;
return 0;
+#else
+   return -ENOTTY;
+#endif
}
 
ret = ov7670_try_fmt_internal(sd, >format, , );
@@ -1041,6 +1053,30 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
return 0;
 }
 
+static int ov7670_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *format)
+{
+   struct ov7670_info *info = to_state(sd);
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+   struct v4l2_mbus_framefmt *mbus_fmt;
+#endif
+
+   if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+   mbus_fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
+   format->format = *mbus_fmt;
+   return 0;
+#else
+   return -ENOTTY;
+#endif
+   } else {
+   format->format = info->format;
+   }
+
+   return 0;
+}
+
 /*
  * Implement G/S_PARM.  There is a "high quality" mode we could try
  * to do someday; for now, we just do the frame rate tweak.
@@ -1508,6 +1544,30 @@ static int ov7670_s_register(struct v4l2_subdev *sd, 
const struct v4l2_dbg_regis
 }
 #endif
 
+static void ov7670_get_default_format(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *format)
+{
+   struct ov7670_info *info = to_state(sd);
+
+   format->width = info->devtype->win_sizes[0].width;
+   format->height = info->devtype->win_sizes[0].height;
+   format->colorspace = info->fmt->colorspace;
+   format->code = info->fmt->mbus_code;
+   format->field = V4L2_FIELD_NONE;
+}
+
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+static int ov7670_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+   struct v4l2_mbus_framefmt *format =
+   v4l2_subdev_get_try_format(sd, fh->pad, 0);
+
+   ov7670_get_default_format(sd, format);
+
+   return 0;
+}
+#endif
+
 /* --- */
 
 static const struct v4l2_subdev_core_ops ov7670_core_ops = {
@@ -1528,6 +1588,7 @@ static const struct v4l2_subdev_pad_ops ov7670_pad_ops = {
.enum_frame_interval = ov7670_enum_frame_interval,
.enum_frame_size = ov7670_enum_frame_size,
.enum_mbus_code = ov7670_enum_mbus_code,
+   .get_fmt = ov7670_get_fmt,
.set_fmt = ov7670_set_fmt,
 };
 
@@ -1537,6 +1598,12 @@ static const struct v4l2_subdev_ops ov7670_ops = {
.pad = _pad_ops,
 };
 
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+static const struct v4l2_subdev_internal_ops ov7670_subdev_internal_ops = {
+   .open = ov7670_open,
+};
+#endif
+
 /* --- */
 
 static const struct ov7670_devtype ov7670_devdata[] = {
@@ -1589,6 +1656,11 @@ static 

[PATCH v6 0/3] media: ov7670: Add entity init and power operation

[Wenyou Yang]

This patch set is to add the media entity pads initialization,
the ov7670_s_power function and get_fmt callback support.

Changes in v6:
 - Remove .s_power callback to keep the ov7670 powered at all times.
 - Update the commit log accordingly.

Changes in v5:
 - Fix the build warning on the declaration *mbus_fmt(ISO C90 forbids mixed).

Changes in v4:
 - Fix the build error when not enabling Media Controller API option.
 - Fix the build error when not enabling V4L2 sub-device userspace API option.

Changes in v3:
 - Keep tried format info in the try_fmt member of
   v4l2_subdev__pad_config struct.
 - Add the internal_ops callback to set default format.

Changes in v2:
 - Add the patch to support the get_fmt ops.
 - Remove the redundant invoking ov7670_init_gpio().

Wenyou Yang (3):
  media: ov7670: Add entity pads initialization
  media: ov7670: Add the get_fmt callback
  media: ov7670: Add the ov7670_s_power function

 drivers/media/i2c/ov7670.c | 129 ++---
 1 file changed, 122 insertions(+), 7 deletions(-)

-- 
2.13.0

[PATCH v6 1/3] media: ov7670: Add entity pads initialization

[Wenyou Yang]

Add the media entity pads initialization.

Signed-off-by: Wenyou Yang 
---

Changes in v6: None
Changes in v5: None
Changes in v4:
 - Fix the build error when not enabling Media Controller API option.

Changes in v3: None
Changes in v2: None

 drivers/media/i2c/ov7670.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e88549f0e704..553945d4ca28 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -213,6 +213,9 @@ struct ov7670_devtype {
 struct ov7670_format_struct;  /* coming later */
 struct ov7670_info {
struct v4l2_subdev sd;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   struct media_pad pad;
+#endif
struct v4l2_ctrl_handler hdl;
struct {
/* gain cluster */
@@ -1688,14 +1691,27 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_auto_cluster(2, >auto_exposure,
   V4L2_EXPOSURE_MANUAL, false);
v4l2_ctrl_cluster(2, >saturation);
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   info->pad.flags = MEDIA_PAD_FL_SOURCE;
+   info->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+   ret = media_entity_pads_init(>sd.entity, 1, >pad);
+   if (ret < 0)
+   goto hdl_free;
+#endif
+
v4l2_ctrl_handler_setup(>hdl);
 
ret = v4l2_async_register_subdev(>sd);
if (ret < 0)
-   goto hdl_free;
+   goto entity_cleanup;
 
return 0;
 
+entity_cleanup:
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   media_entity_cleanup(>sd.entity);
+#endif
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
 clk_disable:
@@ -1712,6 +1728,9 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(>hdl);
clk_disable_unprepare(info->clk);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   media_entity_cleanup(>sd.entity);
+#endif
return 0;
 }
 
-- 
2.13.0

[PATCH v6 0/3] media: ov7670: Add entity init and power operation

[Wenyou Yang]

This patch set is to add the media entity pads initialization,
the ov7670_s_power function and get_fmt callback support.

Changes in v6:
 - Remove .s_power callback to keep the ov7670 powered at all times.
 - Update the commit log accordingly.

Changes in v5:
 - Fix the build warning on the declaration *mbus_fmt(ISO C90 forbids mixed).

Changes in v4:
 - Fix the build error when not enabling Media Controller API option.
 - Fix the build error when not enabling V4L2 sub-device userspace API option.

Changes in v3:
 - Keep tried format info in the try_fmt member of
   v4l2_subdev__pad_config struct.
 - Add the internal_ops callback to set default format.

Changes in v2:
 - Add the patch to support the get_fmt ops.
 - Remove the redundant invoking ov7670_init_gpio().

Wenyou Yang (3):
  media: ov7670: Add entity pads initialization
  media: ov7670: Add the get_fmt callback
  media: ov7670: Add the ov7670_s_power function

 drivers/media/i2c/ov7670.c | 129 ++---
 1 file changed, 122 insertions(+), 7 deletions(-)

-- 
2.13.0

[PATCH v6 1/3] media: ov7670: Add entity pads initialization

[Wenyou Yang]

Add the media entity pads initialization.

Signed-off-by: Wenyou Yang 
---

Changes in v6: None
Changes in v5: None
Changes in v4:
 - Fix the build error when not enabling Media Controller API option.

Changes in v3: None
Changes in v2: None

 drivers/media/i2c/ov7670.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e88549f0e704..553945d4ca28 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -213,6 +213,9 @@ struct ov7670_devtype {
 struct ov7670_format_struct;  /* coming later */
 struct ov7670_info {
struct v4l2_subdev sd;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   struct media_pad pad;
+#endif
struct v4l2_ctrl_handler hdl;
struct {
/* gain cluster */
@@ -1688,14 +1691,27 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_auto_cluster(2, >auto_exposure,
   V4L2_EXPOSURE_MANUAL, false);
v4l2_ctrl_cluster(2, >saturation);
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   info->pad.flags = MEDIA_PAD_FL_SOURCE;
+   info->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+   ret = media_entity_pads_init(>sd.entity, 1, >pad);
+   if (ret < 0)
+   goto hdl_free;
+#endif
+
v4l2_ctrl_handler_setup(>hdl);
 
ret = v4l2_async_register_subdev(>sd);
if (ret < 0)
-   goto hdl_free;
+   goto entity_cleanup;
 
return 0;
 
+entity_cleanup:
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   media_entity_cleanup(>sd.entity);
+#endif
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
 clk_disable:
@@ -1712,6 +1728,9 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(>hdl);
clk_disable_unprepare(info->clk);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   media_entity_cleanup(>sd.entity);
+#endif
return 0;
 }
 
-- 
2.13.0

RE: [PATCH v2 5/5] fsl/fman: add dpaa in module names

[Madalin-cristian Bucur]

> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: Friday, October 13, 2017 8:39 PM
> To: Madalin-cristian Bucur ;
> net...@vger.kernel.org; da...@davemloft.net
> Cc: and...@lunn.ch; vivien.dide...@savoirfairelinux.com;
> jun...@outlook.com; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 5/5] fsl/fman: add dpaa in module names
> 
> On 10/13/2017 07:50 AM, Madalin Bucur wrote:
> > Signed-off-by: Madalin Bucur 
> 
> You should provide a line or two to explain why are you making this
> change, it is to resolve modular build configurations?

This change just renames the FMan driver modules, using a common prefix for
the DPAA FMan and DPAA Ethernet drivers. Besides making the names more aligned,
this allows writing udev rules that match on either driver name, if needed,
using the fsl_dpaa_* prefix. The change of netdev dev required for the DSA
probing makes the previous rules written using this prefix fail, this change
makes them work again.

> > ---
> >  drivers/net/ethernet/freescale/fman/Makefile | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/fman/Makefile
> b/drivers/net/ethernet/freescale/fman/Makefile
> > index 2c38119..4ae524a 100644
> > --- a/drivers/net/ethernet/freescale/fman/Makefile
> > +++ b/drivers/net/ethernet/freescale/fman/Makefile
> > @@ -1,9 +1,9 @@
> >  subdir-ccflags-y +=  -I$(srctree)/drivers/net/ethernet/freescale/fman
> >
> > -obj-$(CONFIG_FSL_FMAN) += fsl_fman.o
> > -obj-$(CONFIG_FSL_FMAN) += fsl_fman_port.o
> > -obj-$(CONFIG_FSL_FMAN) += fsl_mac.o
> > +obj-$(CONFIG_FSL_FMAN) += fsl_dpaa_fman.o
> > +obj-$(CONFIG_FSL_FMAN) += fsl_dpaa_fman_port.o
> > +obj-$(CONFIG_FSL_FMAN) += fsl_dpaa_mac.o
> >
> > -fsl_fman-objs  := fman_muram.o fman.o fman_sp.o fman_keygen.o
> > -fsl_fman_port-objs := fman_port.o
> > -fsl_mac-objs:= mac.o fman_dtsec.o fman_memac.o fman_tgec.o
> > +fsl_dpaa_fman-objs := fman_muram.o fman.o fman_sp.o fman_keygen.o
> > +fsl_dpaa_fman_port-objs := fman_port.o
> > +fsl_dpaa_mac-objs:= mac.o fman_dtsec.o fman_memac.o fman_tgec.o
> >
> 
> 
> --
> Florian

RE: [PATCH v2 5/5] fsl/fman: add dpaa in module names

[Madalin-cristian Bucur]

> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: Friday, October 13, 2017 8:39 PM
> To: Madalin-cristian Bucur ;
> net...@vger.kernel.org; da...@davemloft.net
> Cc: and...@lunn.ch; vivien.dide...@savoirfairelinux.com;
> jun...@outlook.com; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 5/5] fsl/fman: add dpaa in module names
> 
> On 10/13/2017 07:50 AM, Madalin Bucur wrote:
> > Signed-off-by: Madalin Bucur 
> 
> You should provide a line or two to explain why are you making this
> change, it is to resolve modular build configurations?

This change just renames the FMan driver modules, using a common prefix for
the DPAA FMan and DPAA Ethernet drivers. Besides making the names more aligned,
this allows writing udev rules that match on either driver name, if needed,
using the fsl_dpaa_* prefix. The change of netdev dev required for the DSA
probing makes the previous rules written using this prefix fail, this change
makes them work again.

> > ---
> >  drivers/net/ethernet/freescale/fman/Makefile | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/fman/Makefile
> b/drivers/net/ethernet/freescale/fman/Makefile
> > index 2c38119..4ae524a 100644
> > --- a/drivers/net/ethernet/freescale/fman/Makefile
> > +++ b/drivers/net/ethernet/freescale/fman/Makefile
> > @@ -1,9 +1,9 @@
> >  subdir-ccflags-y +=  -I$(srctree)/drivers/net/ethernet/freescale/fman
> >
> > -obj-$(CONFIG_FSL_FMAN) += fsl_fman.o
> > -obj-$(CONFIG_FSL_FMAN) += fsl_fman_port.o
> > -obj-$(CONFIG_FSL_FMAN) += fsl_mac.o
> > +obj-$(CONFIG_FSL_FMAN) += fsl_dpaa_fman.o
> > +obj-$(CONFIG_FSL_FMAN) += fsl_dpaa_fman_port.o
> > +obj-$(CONFIG_FSL_FMAN) += fsl_dpaa_mac.o
> >
> > -fsl_fman-objs  := fman_muram.o fman.o fman_sp.o fman_keygen.o
> > -fsl_fman_port-objs := fman_port.o
> > -fsl_mac-objs:= mac.o fman_dtsec.o fman_memac.o fman_tgec.o
> > +fsl_dpaa_fman-objs := fman_muram.o fman.o fman_sp.o fman_keygen.o
> > +fsl_dpaa_fman_port-objs := fman_port.o
> > +fsl_dpaa_mac-objs:= mac.o fman_dtsec.o fman_memac.o fman_tgec.o
> >
> 
> 
> --
> Florian

Re: [RFC PATCH v2 2/8] cpuidle: record the overhead of idle entry

[Li, Aubrey]

On 2017/10/14 8:35, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:28 AM CEST Aubrey Li wrote:
>> Record the overhead of idle entry in micro-second
>>
> 
> What is this needed for?

We need to figure out how long of a idle is a short idle and recording
the overhead is for this purpose. The short idle threshold is based
on this overhead.

> 
>> +void cpuidle_entry_end(void)
>> +{
>> +struct cpuidle_device *dev = cpuidle_get_device();
>> +u64 overhead;
>> +s64 diff;
>> +
>> +if (dev) {
>> +dev->idle_stat.entry_end = local_clock();
>> +overhead = div_u64(dev->idle_stat.entry_end -
>> +dev->idle_stat.entry_start, NSEC_PER_USEC);
> 
> Is the conversion really necessary?
> 
> If so, then why?

We can choose nano-second and micro-second. Given that workload results
in the short idle pattern, I think micro-second is good enough for the
real workload.

Another reason is that prediction from idle governor is micro-second, so
I convert it for comparing purpose.
> 
> And if there is a good reason, what about using right shift to do
> an approximate conversion to avoid the extra division here?

Sure >> 10 works for me as I don't think here precision is a big deal.

> 
>> +diff = overhead - dev->idle_stat.overhead;
>> +dev->idle_stat.overhead += diff >> 3;
> 
> Can you please explain what happens in the two lines above?

Online average computing algorithm, stolen from update_avg() @ 
kernel/sched/core.c.
> 
>> +/*
>> + * limit overhead to 1us
>> + */
>> +if (dev->idle_stat.overhead == 0)
>> +dev->idle_stat.overhead = 1;
>> +}
>> +}
>> +
>>  /**
>>   * cpuidle_install_idle_handler - installs the cpuidle idle loop handler
>>   */
>> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
>> index fc1e5d7..cad9b71 100644
>> --- a/include/linux/cpuidle.h
>> +++ b/include/linux/cpuidle.h
>> @@ -72,6 +72,15 @@ struct cpuidle_device_kobj;
>>  struct cpuidle_state_kobj;
>>  struct cpuidle_driver_kobj;
>>  
>> +struct cpuidle_stat {
>> +u64 entry_start;/* nanosecond */
>> +u64 entry_end;  /* nanosecond */
>> +u64 overhead;   /* nanosecond */
>> +unsigned intpredicted_us;   /* microsecond */
>> +boolpredicted;  /* ever predicted? */
>> +boolfast_idle;  /* fast idle? */
> 
> Some of the fields here are never used in the code after this patch.
> 
> Also it would be good to add a comment describing the meaning of the
> fields.
> 
okay, will add in the next version.

Thanks,
-Aubrey

Re: [RFC PATCH v2 2/8] cpuidle: record the overhead of idle entry

[Li, Aubrey]

On 2017/10/14 8:35, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:28 AM CEST Aubrey Li wrote:
>> Record the overhead of idle entry in micro-second
>>
> 
> What is this needed for?

We need to figure out how long of a idle is a short idle and recording
the overhead is for this purpose. The short idle threshold is based
on this overhead.

> 
>> +void cpuidle_entry_end(void)
>> +{
>> +struct cpuidle_device *dev = cpuidle_get_device();
>> +u64 overhead;
>> +s64 diff;
>> +
>> +if (dev) {
>> +dev->idle_stat.entry_end = local_clock();
>> +overhead = div_u64(dev->idle_stat.entry_end -
>> +dev->idle_stat.entry_start, NSEC_PER_USEC);
> 
> Is the conversion really necessary?
> 
> If so, then why?

We can choose nano-second and micro-second. Given that workload results
in the short idle pattern, I think micro-second is good enough for the
real workload.

Another reason is that prediction from idle governor is micro-second, so
I convert it for comparing purpose.
> 
> And if there is a good reason, what about using right shift to do
> an approximate conversion to avoid the extra division here?

Sure >> 10 works for me as I don't think here precision is a big deal.

> 
>> +diff = overhead - dev->idle_stat.overhead;
>> +dev->idle_stat.overhead += diff >> 3;
> 
> Can you please explain what happens in the two lines above?

Online average computing algorithm, stolen from update_avg() @ 
kernel/sched/core.c.
> 
>> +/*
>> + * limit overhead to 1us
>> + */
>> +if (dev->idle_stat.overhead == 0)
>> +dev->idle_stat.overhead = 1;
>> +}
>> +}
>> +
>>  /**
>>   * cpuidle_install_idle_handler - installs the cpuidle idle loop handler
>>   */
>> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
>> index fc1e5d7..cad9b71 100644
>> --- a/include/linux/cpuidle.h
>> +++ b/include/linux/cpuidle.h
>> @@ -72,6 +72,15 @@ struct cpuidle_device_kobj;
>>  struct cpuidle_state_kobj;
>>  struct cpuidle_driver_kobj;
>>  
>> +struct cpuidle_stat {
>> +u64 entry_start;/* nanosecond */
>> +u64 entry_end;  /* nanosecond */
>> +u64 overhead;   /* nanosecond */
>> +unsigned intpredicted_us;   /* microsecond */
>> +boolpredicted;  /* ever predicted? */
>> +boolfast_idle;  /* fast idle? */
> 
> Some of the fields here are never used in the code after this patch.
> 
> Also it would be good to add a comment describing the meaning of the
> fields.
> 
okay, will add in the next version.

Thanks,
-Aubrey

Re: [PATCH] f2fs: expose some sectors to user in inline data or dentry case

[Chao Yu]

On 2017/10/14 1:31, Jaegeuk Kim wrote:
> If there's some data written through inline data or dentry, we need to shouw
> st_blocks. This fixes reporting zero blocks even though there is small written
> data.
> 
> Signed-off-by: Jaegeuk Kim 

Reviewed-by: Chao Yu 

Thanks,

> ---
>  fs/f2fs/file.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index 2eb3efe92018..f7be6c394fa8 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -698,6 +698,11 @@ int f2fs_getattr(const struct path *path, struct kstat 
> *stat,
> STATX_ATTR_NODUMP);
>  
>   generic_fillattr(inode, stat);
> +
> + /* we need to show initial sectors used for inline_data/dentries */
> + if (f2fs_has_inline_data(inode) || f2fs_has_inline_dentry(inode))
> + stat->blocks += (stat->size + 511) >> 9;
> +
>   return 0;
>  }
>  
> 

Re: [PATCH] f2fs: expose some sectors to user in inline data or dentry case

[Chao Yu]

On 2017/10/14 1:31, Jaegeuk Kim wrote:
> If there's some data written through inline data or dentry, we need to shouw
> st_blocks. This fixes reporting zero blocks even though there is small written
> data.
> 
> Signed-off-by: Jaegeuk Kim 

Reviewed-by: Chao Yu 

Thanks,

> ---
>  fs/f2fs/file.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index 2eb3efe92018..f7be6c394fa8 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -698,6 +698,11 @@ int f2fs_getattr(const struct path *path, struct kstat 
> *stat,
> STATX_ATTR_NODUMP);
>  
>   generic_fillattr(inode, stat);
> +
> + /* we need to show initial sectors used for inline_data/dentries */
> + if (f2fs_has_inline_data(inode) || f2fs_has_inline_dentry(inode))
> + stat->blocks += (stat->size + 511) >> 9;
> +
>   return 0;
>  }
>  
> 

[PATCH 3/3] arm64: dts: realtek: Add MeLE V9

[Andreas Färber]

Add an initial Device Tree for MeLE V9 Media Player.

Cc: meleserv...@mele.cn
Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/realtek/Makefile|  1 +
 arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts | 31 +
 2 files changed, 32 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts

diff --git a/arch/arm64/boot/dts/realtek/Makefile 
b/arch/arm64/boot/dts/realtek/Makefile
index cf93f4db7a69..c0b36ba64a1e 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -1,5 +1,6 @@
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1293-ds418j.dtb
 
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-mele-v9.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-probox2-ava.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
 
diff --git a/arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts 
b/arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts
new file mode 100644
index ..bd584e99fff9
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "rtd1295.dtsi"
+
+/ {
+   compatible = "mele,v9", "realtek,rtd1295";
+   model = "MeLE V9";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x8000>;
+   };
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
-- 
2.13.6

[PATCH 3/3] arm64: dts: realtek: Add MeLE V9

[Andreas Färber]

Add an initial Device Tree for MeLE V9 Media Player.

Cc: meleserv...@mele.cn
Signed-off-by: Andreas Färber 
---
 arch/arm64/boot/dts/realtek/Makefile|  1 +
 arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts | 31 +
 2 files changed, 32 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts

diff --git a/arch/arm64/boot/dts/realtek/Makefile 
b/arch/arm64/boot/dts/realtek/Makefile
index cf93f4db7a69..c0b36ba64a1e 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -1,5 +1,6 @@
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1293-ds418j.dtb
 
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-mele-v9.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-probox2-ava.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
 
diff --git a/arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts 
b/arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts
new file mode 100644
index ..bd584e99fff9
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "rtd1295.dtsi"
+
+/ {
+   compatible = "mele,v9", "realtek,rtd1295";
+   model = "MeLE V9";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x8000>;
+   };
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
-- 
2.13.6

[PATCH 2/3] dt-bindings: arm: realtek: Document MeLE V9

[Andreas Färber]

Define a compatible string for MeLE V9 Media Player.

Cc: meleserv...@mele.cn
Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/arm/realtek.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/realtek.txt 
b/Documentation/devicetree/bindings/arm/realtek.txt
index 297c15eb81e2..95839e19ae92 100644
--- a/Documentation/devicetree/bindings/arm/realtek.txt
+++ b/Documentation/devicetree/bindings/arm/realtek.txt
@@ -12,6 +12,7 @@ Required root node properties:
 
 Root node property compatible must contain, depending on board:
 
+ - MeLE V9: "mele,v9"
  - ProBox2 AVA: "probox2,ava"
  - Zidoo X9S: "zidoo,x9s"
 
-- 
2.13.6

[PATCH 0/3] arm64: dts: Initial MeLE V9 support

[Andreas Färber]

Hello,

This mini-series adds a Device Tree for the MeLE V9 Android Media Player.

Same as with PROBOX2 AVA, serial (loady) was the only working way to boot a new
kernel from the vendor's U-Boot on this TV box.

More details at:
https://en.opensuse.org/HCL:Mele_V9

@MeLE: Please review the following three patches and either signal your
acknowledgement of my naming proposals with an "Acked-by: name "
response or point out any changes you would like to see applied. Thanks!

Latest experimental patches at:
https://github.com/afaerber/linux/commits/rtd1295-next

Have a lot of fun!

Cheers,
Andreas

Cc: meleserv...@mele.cn
Cc: devicet...@vger.kernel.org

Andreas Färber (3):
  dt-bindings: Add vendor prefix for MeLE
  dt-bindings: arm: realtek: Document MeLE V9
  arm64: dts: realtek: Add MeLE V9

 Documentation/devicetree/bindings/arm/realtek.txt  |  1 +
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 arch/arm64/boot/dts/realtek/Makefile   |  1 +
 arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts| 31 ++
 4 files changed, 34 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts

-- 
2.13.6

[PATCH 2/3] dt-bindings: arm: realtek: Document MeLE V9

[Andreas Färber]

Define a compatible string for MeLE V9 Media Player.

Cc: meleserv...@mele.cn
Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/arm/realtek.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/realtek.txt 
b/Documentation/devicetree/bindings/arm/realtek.txt
index 297c15eb81e2..95839e19ae92 100644
--- a/Documentation/devicetree/bindings/arm/realtek.txt
+++ b/Documentation/devicetree/bindings/arm/realtek.txt
@@ -12,6 +12,7 @@ Required root node properties:
 
 Root node property compatible must contain, depending on board:
 
+ - MeLE V9: "mele,v9"
  - ProBox2 AVA: "probox2,ava"
  - Zidoo X9S: "zidoo,x9s"
 
-- 
2.13.6

[PATCH 0/3] arm64: dts: Initial MeLE V9 support

[Andreas Färber]

Hello,

This mini-series adds a Device Tree for the MeLE V9 Android Media Player.

Same as with PROBOX2 AVA, serial (loady) was the only working way to boot a new
kernel from the vendor's U-Boot on this TV box.

More details at:
https://en.opensuse.org/HCL:Mele_V9

@MeLE: Please review the following three patches and either signal your
acknowledgement of my naming proposals with an "Acked-by: name "
response or point out any changes you would like to see applied. Thanks!

Latest experimental patches at:
https://github.com/afaerber/linux/commits/rtd1295-next

Have a lot of fun!

Cheers,
Andreas

Cc: meleserv...@mele.cn
Cc: devicet...@vger.kernel.org

Andreas Färber (3):
  dt-bindings: Add vendor prefix for MeLE
  dt-bindings: arm: realtek: Document MeLE V9
  arm64: dts: realtek: Add MeLE V9

 Documentation/devicetree/bindings/arm/realtek.txt  |  1 +
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 arch/arm64/boot/dts/realtek/Makefile   |  1 +
 arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts| 31 ++
 4 files changed, 34 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dts

-- 
2.13.6

[PATCH 1/3] dt-bindings: Add vendor prefix for MeLE

[Andreas Färber]

MeLE is a Chinese manufacturer of TV boxes and Mini PCs.

Cc: meleserv...@mele.cn
Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index dbbde903682b..bc7f7b4618b4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -199,6 +199,7 @@ mcube   mCube
 meas   Measurement Specialties
 mediatek   MediaTek Inc.
 megachips  MegaChips
+mele   Shenzhen MeLE Digital Technology Ltd.
 melexisMelexis N.V.
 melfas MELFAS Inc.
 mellanox   Mellanox Technologies
-- 
2.13.6

[PATCH 1/3] dt-bindings: Add vendor prefix for MeLE

[Andreas Färber]

MeLE is a Chinese manufacturer of TV boxes and Mini PCs.

Cc: meleserv...@mele.cn
Signed-off-by: Andreas Färber 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index dbbde903682b..bc7f7b4618b4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -199,6 +199,7 @@ mcube   mCube
 meas   Measurement Specialties
 mediatek   MediaTek Inc.
 megachips  MegaChips
+mele   Shenzhen MeLE Digital Technology Ltd.
 melexisMelexis N.V.
 melfas MELFAS Inc.
 mellanox   Mellanox Technologies
-- 
2.13.6

RE: [PATCH] EDAC, sb_edac: mark expected switch fall-through

[Zhuo, Qiuxu]

Hi Silva,

The actual intention of the code is NOT to fall through, though current 
code can work correctly.
Thanks for this finding. If you don't mind, I'll submit a fix patch for it 
with the tag 'Reported-by:' by you.

Thanks!
- Qiuxu

> From: linux-edac-ow...@vger.kernel.org [mailto:linux-edac-
> ow...@vger.kernel.org] On Behalf Of Gustavo A. R. Silva
> Sent: Saturday, October 14, 2017 4:28 AM
> To: Mauro Carvalho Chehab ; Borislav Petkov
> 
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Gustavo A. R.
> Silva 
> Subject: [PATCH] EDAC, sb_edac: mark expected switch fall-through
> 
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we
> are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
> This code was tested by compilation only (GCC 7.2.0 was used).
> Please, verify if the actual intention of the code is to fall through.
> 
>  drivers/edac/sb_edac.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c index
> 72b98a0..b50d714 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -2485,6 +2485,7 @@ static int ibridge_mci_bind_devs(struct mem_ctl_info
> *mci,
>   case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA:
>   case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_TA:
>   pvt->pci_ta = pdev;
> + /* fall through */
>   case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_RAS:
>   case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_RAS:

RE: [PATCH] EDAC, sb_edac: mark expected switch fall-through

[Zhuo, Qiuxu]

Hi Silva,

The actual intention of the code is NOT to fall through, though current 
code can work correctly.
Thanks for this finding. If you don't mind, I'll submit a fix patch for it 
with the tag 'Reported-by:' by you.

Thanks!
- Qiuxu

> From: linux-edac-ow...@vger.kernel.org [mailto:linux-edac-
> ow...@vger.kernel.org] On Behalf Of Gustavo A. R. Silva
> Sent: Saturday, October 14, 2017 4:28 AM
> To: Mauro Carvalho Chehab ; Borislav Petkov
> 
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Gustavo A. R.
> Silva 
> Subject: [PATCH] EDAC, sb_edac: mark expected switch fall-through
> 
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we
> are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
> This code was tested by compilation only (GCC 7.2.0 was used).
> Please, verify if the actual intention of the code is to fall through.
> 
>  drivers/edac/sb_edac.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c index
> 72b98a0..b50d714 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -2485,6 +2485,7 @@ static int ibridge_mci_bind_devs(struct mem_ctl_info
> *mci,
>   case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA:
>   case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_TA:
>   pvt->pci_ta = pdev;
> + /* fall through */
>   case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_RAS:
>   case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_RAS:

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

[Michael Ellerman]

Mathieu Desnoyers  writes:

> Implements two basic tests of RSEQ functionality, and one more
> exhaustive parameterizable test.
>
> The first, "basic_test" only asserts that RSEQ works moderately
> correctly.
> E.g. that:
> - The CPUID pointer works
> - Code infinitely looping within a critical section will eventually be
>   interrupted.
> - Critical sections are interrupted by signals.
>
> "basic_percpu_ops_test" is a slightly more "realistic" variant,
> implementing a few simple per-cpu operations and testing their
> correctness.
>
> "param_test" is a parametrizable restartable sequences test. See
> the "--help" output for usage.
>
> As part of those tests, a helper library "rseq" implements a user-space
> API around restartable sequences. It uses the cpu_opv system call as
> fallback when single-stepped by a debugger. It exposes the instruction
> pointer addresses where the rseq assembly blocks begin and end, as well
> as the associated abort instruction pointer, in the __rseq_table
> section. This section allows debuggers may know where to place
> breakpoints when single-stepping through assembly blocks which may be
> aborted at any point by the kernel.
>
> The following rseq APIs are implemented in this helper library:
> - rseq_register_current_thread()/rseq_unregister_current_thread():
> register/unregister current thread's use of rseq,
> - rseq_current_cpu_raw():
> current CPU number,
> - rseq_start():
> beginning of a restartable sequence,
> - rseq_cpu_at_start():
> CPU number at start of restartable sequence,
> - rseq_finish():
> End of restartable sequence made of zero or more loads, completed by
> a word-sized store,
> - rseq_finish2():
> End of restartable sequence made of zero or more loads, one
> speculative word-sized store, completed by a word-sized store,
> - rseq_finish2_release():
> End of restartable sequence made of zero or more loads, one
> speculative word-sized store, completed by a word-sized store with
> release semantic,
> - rseq_finish_memcpy():
> End of restartable sequence made of zero or more loads, a
> speculative copy of a variable length memory region, completed by a
> word-sized store.
> - rseq_finish_memcpy_release():
> End of restartable sequence made of zero or more loads, a
> speculative copy of a variable length memory region, completed by a
> word-sized store with release semantic.
>
> PowerPC tests have been implemented by Boqun Feng.

Hi Boqun,

I'm having trouble testing these, I get:

  ~/linus/tools/testing/selftests/cpu-opv$ ./basic_cpu_opv_test
  Testing test_compare_eq same
  Testing test_compare_eq different
  Testing test_compare_ne same
  Testing test_compare_ne different
  Testing test_2compare_eq index
  Testing test_2compare_ne index
  Testing test_memcpy
  Testing test_memcpy_u32
  Testing test_add
  Testing test_two_add
  Testing test_or
  Testing test_and
  Testing test_xor
  Testing test_lshift
  Testing test_rshift
  Testing test_cmpxchg success
  Testing test_cmpxchg fail
  
  ~/linus/tools/testing/selftests/rseq$ ./basic_test
  testing current cpu
  testing critical section
  testing critical section is interrupted by signal

  ~/linus/tools/testing/selftests/rseq$ ./basic_percpu_ops_test
  ./basic_percpu_ops_test: error while loading shared libraries: 
R_PPC64_ADDR16_HI re10d8f10a0 for symbol `' out of range
  ~/linus/tools/testing/selftests/rseq$ ./param_test
  ./param_test: error while loading shared libraries: R_PPC64_ADDR16_HI 
re136251b48 for symbol `' out of range


Any idea what's going on with the last two? I assume you don't see that
in your test setup :)

cheers

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

[Michael Ellerman]

Mathieu Desnoyers  writes:

> Implements two basic tests of RSEQ functionality, and one more
> exhaustive parameterizable test.
>
> The first, "basic_test" only asserts that RSEQ works moderately
> correctly.
> E.g. that:
> - The CPUID pointer works
> - Code infinitely looping within a critical section will eventually be
>   interrupted.
> - Critical sections are interrupted by signals.
>
> "basic_percpu_ops_test" is a slightly more "realistic" variant,
> implementing a few simple per-cpu operations and testing their
> correctness.
>
> "param_test" is a parametrizable restartable sequences test. See
> the "--help" output for usage.
>
> As part of those tests, a helper library "rseq" implements a user-space
> API around restartable sequences. It uses the cpu_opv system call as
> fallback when single-stepped by a debugger. It exposes the instruction
> pointer addresses where the rseq assembly blocks begin and end, as well
> as the associated abort instruction pointer, in the __rseq_table
> section. This section allows debuggers may know where to place
> breakpoints when single-stepping through assembly blocks which may be
> aborted at any point by the kernel.
>
> The following rseq APIs are implemented in this helper library:
> - rseq_register_current_thread()/rseq_unregister_current_thread():
> register/unregister current thread's use of rseq,
> - rseq_current_cpu_raw():
> current CPU number,
> - rseq_start():
> beginning of a restartable sequence,
> - rseq_cpu_at_start():
> CPU number at start of restartable sequence,
> - rseq_finish():
> End of restartable sequence made of zero or more loads, completed by
> a word-sized store,
> - rseq_finish2():
> End of restartable sequence made of zero or more loads, one
> speculative word-sized store, completed by a word-sized store,
> - rseq_finish2_release():
> End of restartable sequence made of zero or more loads, one
> speculative word-sized store, completed by a word-sized store with
> release semantic,
> - rseq_finish_memcpy():
> End of restartable sequence made of zero or more loads, a
> speculative copy of a variable length memory region, completed by a
> word-sized store.
> - rseq_finish_memcpy_release():
> End of restartable sequence made of zero or more loads, a
> speculative copy of a variable length memory region, completed by a
> word-sized store with release semantic.
>
> PowerPC tests have been implemented by Boqun Feng.

Hi Boqun,

I'm having trouble testing these, I get:

  ~/linus/tools/testing/selftests/cpu-opv$ ./basic_cpu_opv_test
  Testing test_compare_eq same
  Testing test_compare_eq different
  Testing test_compare_ne same
  Testing test_compare_ne different
  Testing test_2compare_eq index
  Testing test_2compare_ne index
  Testing test_memcpy
  Testing test_memcpy_u32
  Testing test_add
  Testing test_two_add
  Testing test_or
  Testing test_and
  Testing test_xor
  Testing test_lshift
  Testing test_rshift
  Testing test_cmpxchg success
  Testing test_cmpxchg fail
  
  ~/linus/tools/testing/selftests/rseq$ ./basic_test
  testing current cpu
  testing critical section
  testing critical section is interrupted by signal

  ~/linus/tools/testing/selftests/rseq$ ./basic_percpu_ops_test
  ./basic_percpu_ops_test: error while loading shared libraries: 
R_PPC64_ADDR16_HI re10d8f10a0 for symbol `' out of range
  ~/linus/tools/testing/selftests/rseq$ ./param_test
  ./param_test: error while loading shared libraries: R_PPC64_ADDR16_HI 
re136251b48 for symbol `' out of range


Any idea what's going on with the last two? I assume you don't see that
in your test setup :)

cheers

[PATCH] keys, trusted: fix missing support for TPM 2.0 in trusted_update()

[Boshi Wang]

Call tpm_seal_trusted() in trusted_update() for TPM 2.0 chips.

Signed-off-by: Boshi Wang 
---
 security/keys/trusted.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index ddfaebf..563fe5f 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -1065,6 +1065,11 @@ static int trusted_update(struct key *key, struct 
key_preparsed_payload *prep)
 size_t datalen = prep->datalen;
 char *datablob;
 int ret = 0;
+int tpm2;
+
+tpm2 = tpm_is_tpm2(TPM_ANY_NUM);
+if (tpm2 < 0)
+return tpm2;

 if (test_bit(KEY_FLAG_NEGATIVE, >flags))
 return -ENOKEY;
@@ -1110,7 +1115,10 @@ static int trusted_update(struct key *key, struct 
key_preparsed_payload *prep)
 dump_payload(p);
 dump_payload(new_p);

-ret = key_seal(new_p, new_o);
+if (tpm2)
+ret = tpm_seal_trusted(TPM_ANY_NUM, new_p, new_o);
+else
+ret = key_seal(new_p, new_o);
 if (ret < 0) {
 pr_info("trusted_key: key_seal failed (%d)\n", ret);
 kzfree(new_p);
--
2.10.1

[PATCH] keys, trusted: fix missing support for TPM 2.0 in trusted_update()

[Boshi Wang]

Call tpm_seal_trusted() in trusted_update() for TPM 2.0 chips.

Signed-off-by: Boshi Wang 
---
 security/keys/trusted.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index ddfaebf..563fe5f 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -1065,6 +1065,11 @@ static int trusted_update(struct key *key, struct 
key_preparsed_payload *prep)
 size_t datalen = prep->datalen;
 char *datablob;
 int ret = 0;
+int tpm2;
+
+tpm2 = tpm_is_tpm2(TPM_ANY_NUM);
+if (tpm2 < 0)
+return tpm2;

 if (test_bit(KEY_FLAG_NEGATIVE, >flags))
 return -ENOKEY;
@@ -1110,7 +1115,10 @@ static int trusted_update(struct key *key, struct 
key_preparsed_payload *prep)
 dump_payload(p);
 dump_payload(new_p);

-ret = key_seal(new_p, new_o);
+if (tpm2)
+ret = tpm_seal_trusted(TPM_ANY_NUM, new_p, new_o);
+else
+ret = key_seal(new_p, new_o);
 if (ret < 0) {
 pr_info("trusted_key: key_seal failed (%d)\n", ret);
 kzfree(new_p);
--
2.10.1

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

[Michael Ellerman]

Mathieu Desnoyers  writes:

> Implements two basic tests of RSEQ functionality, and one more
> exhaustive parameterizable test.
>
> The first, "basic_test" only asserts that RSEQ works moderately
> correctly.
> E.g. that:
> - The CPUID pointer works
> - Code infinitely looping within a critical section will eventually be
>   interrupted.
> - Critical sections are interrupted by signals.
>
> "basic_percpu_ops_test" is a slightly more "realistic" variant,
> implementing a few simple per-cpu operations and testing their
> correctness.
>
> "param_test" is a parametrizable restartable sequences test. See
> the "--help" output for usage.

Thanks for providing selftests :)

The Makefiles could use a little clean up:
  - cpu-opv doesn't need libpthread
  - you don't need to define your own rule just for building
  - use TEST_GEN_PROGS to hook into the right parts of lib.mk
  - .. which means you can use the clean rule in lib.mk


I notice you didn't add rseq or cpu-opv to the list of TARGETS in
tools/testing/selftests/Makefile, was that deliberate?

Feel free to squash this patch in if you're happy to.

This still works with:
  $ make -C tools/testing/selftests TARGETS=rseq

and:
  $ cd tools/testing/selftests/rseq; make

cheers

diff --git a/tools/testing/selftests/cpu-opv/Makefile 
b/tools/testing/selftests/cpu-opv/Makefile
index 81d0596824ee..d41670ad5c43 100644
--- a/tools/testing/selftests/cpu-opv/Makefile
+++ b/tools/testing/selftests/cpu-opv/Makefile
@@ -1,13 +1,9 @@
 CFLAGS += -O2 -Wall -g -I./ -I../../../../usr/include/
-LDFLAGS += -lpthread
 
-TESTS = basic_cpu_opv_test
+TEST_GEN_PROGS = basic_cpu_opv_test
 
-all: $(TESTS)
-%: %.c cpu-op.c cpu-op.h
-   $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)
+all: $(TEST_GEN_PROGS)
 
-include ../lib.mk
+$(TEST_GEN_PROGS): cpu-op.c cpu-op.h
 
-clean:
-   $(RM) $(TESTS)
+include ../lib.mk
diff --git a/tools/testing/selftests/rseq/Makefile 
b/tools/testing/selftests/rseq/Makefile
index 7f0153556b80..9f8257b4ce14 100644
--- a/tools/testing/selftests/rseq/Makefile
+++ b/tools/testing/selftests/rseq/Makefile
@@ -1,13 +1,10 @@
 CFLAGS += -O2 -Wall -g -I./ -I../cpu-opv/ -I../../../../usr/include/
-LDFLAGS += -lpthread
+LDLIBS += -lpthread
 
-TESTS = basic_test basic_percpu_ops_test param_test
+TEST_GEN_PROGS = basic_test basic_percpu_ops_test param_test
 
-all: $(TESTS)
-%: %.c rseq.h rseq-*.h rseq.c ../cpu-opv/cpu-op.c ../cpu-opv/cpu-op.h
-   $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)
+all: $(TEST_GEN_PROGS)
 
-include ../lib.mk
+$(TEST_GEN_PROGS): rseq.h rseq-*.h rseq.c ../cpu-opv/cpu-op.c 
../cpu-opv/cpu-op.h
 
-clean:
-   $(RM) $(TESTS)
+include ../lib.mk

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

[Michael Ellerman]

Mathieu Desnoyers  writes:

> Implements two basic tests of RSEQ functionality, and one more
> exhaustive parameterizable test.
>
> The first, "basic_test" only asserts that RSEQ works moderately
> correctly.
> E.g. that:
> - The CPUID pointer works
> - Code infinitely looping within a critical section will eventually be
>   interrupted.
> - Critical sections are interrupted by signals.
>
> "basic_percpu_ops_test" is a slightly more "realistic" variant,
> implementing a few simple per-cpu operations and testing their
> correctness.
>
> "param_test" is a parametrizable restartable sequences test. See
> the "--help" output for usage.

Thanks for providing selftests :)

The Makefiles could use a little clean up:
  - cpu-opv doesn't need libpthread
  - you don't need to define your own rule just for building
  - use TEST_GEN_PROGS to hook into the right parts of lib.mk
  - .. which means you can use the clean rule in lib.mk


I notice you didn't add rseq or cpu-opv to the list of TARGETS in
tools/testing/selftests/Makefile, was that deliberate?

Feel free to squash this patch in if you're happy to.

This still works with:
  $ make -C tools/testing/selftests TARGETS=rseq

and:
  $ cd tools/testing/selftests/rseq; make

cheers

diff --git a/tools/testing/selftests/cpu-opv/Makefile 
b/tools/testing/selftests/cpu-opv/Makefile
index 81d0596824ee..d41670ad5c43 100644
--- a/tools/testing/selftests/cpu-opv/Makefile
+++ b/tools/testing/selftests/cpu-opv/Makefile
@@ -1,13 +1,9 @@
 CFLAGS += -O2 -Wall -g -I./ -I../../../../usr/include/
-LDFLAGS += -lpthread
 
-TESTS = basic_cpu_opv_test
+TEST_GEN_PROGS = basic_cpu_opv_test
 
-all: $(TESTS)
-%: %.c cpu-op.c cpu-op.h
-   $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)
+all: $(TEST_GEN_PROGS)
 
-include ../lib.mk
+$(TEST_GEN_PROGS): cpu-op.c cpu-op.h
 
-clean:
-   $(RM) $(TESTS)
+include ../lib.mk
diff --git a/tools/testing/selftests/rseq/Makefile 
b/tools/testing/selftests/rseq/Makefile
index 7f0153556b80..9f8257b4ce14 100644
--- a/tools/testing/selftests/rseq/Makefile
+++ b/tools/testing/selftests/rseq/Makefile
@@ -1,13 +1,10 @@
 CFLAGS += -O2 -Wall -g -I./ -I../cpu-opv/ -I../../../../usr/include/
-LDFLAGS += -lpthread
+LDLIBS += -lpthread
 
-TESTS = basic_test basic_percpu_ops_test param_test
+TEST_GEN_PROGS = basic_test basic_percpu_ops_test param_test
 
-all: $(TESTS)
-%: %.c rseq.h rseq-*.h rseq.c ../cpu-opv/cpu-op.c ../cpu-opv/cpu-op.h
-   $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)
+all: $(TEST_GEN_PROGS)
 
-include ../lib.mk
+$(TEST_GEN_PROGS): rseq.h rseq-*.h rseq.c ../cpu-opv/cpu-op.c 
../cpu-opv/cpu-op.h
 
-clean:
-   $(RM) $(TESTS)
+include ../lib.mk

Re: [RFC PATCH v2 1/8] cpuidle: menu: extract prediction functionality

[Li, Aubrey]

On 2017/10/14 8:26, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:27 AM CEST Aubrey Li wrote:
>> There are several factors in the menu governor to predict the next
>> idle interval:
>> - the next timer
>> - the recent idle interval history
>> - the corrected idle interval pattern
>> These factors are common enough to be extracted to be one function.
>>
>> Signed-off-by: Aubrey Li 
> 
> This patch alone would break things AFAICS, because it removes code from
> menu_select() without a replacement (and menu_predict() is never called
> just yet).
> 
> Please always do your best to ensure that things will work after *every*
> patch in a series.

okay, I'll correct this in the next version.

Thanks,
-Aubrey

Re: [RFC PATCH v2 1/8] cpuidle: menu: extract prediction functionality

[Li, Aubrey]

On 2017/10/14 8:26, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:27 AM CEST Aubrey Li wrote:
>> There are several factors in the menu governor to predict the next
>> idle interval:
>> - the next timer
>> - the recent idle interval history
>> - the corrected idle interval pattern
>> These factors are common enough to be extracted to be one function.
>>
>> Signed-off-by: Aubrey Li 
> 
> This patch alone would break things AFAICS, because it removes code from
> menu_select() without a replacement (and menu_predict() is never called
> just yet).
> 
> Please always do your best to ensure that things will work after *every*
> patch in a series.

okay, I'll correct this in the next version.

Thanks,
-Aubrey