RE: [PATCH 0/3] Add Bitstream configuration support for ZynqMP
Hi Alan, Thanks for the reply... Please find my response inline. > -Original Message- > From: Alan Tull [mailto:at...@kernel.org] > Sent: Monday, October 22, 2018 9:29 PM > To: Nava kishore Manne > Cc: Moritz Fischer ; Rob Herring ; > Mark Rutland ; Michal Simek ; > Rajan Vaja ; Jolly Shah ; linux- > f...@vger.kernel.org; open list:OPEN FIRMWARE AND FLATTENED DEVICE > TREE BINDINGS ; moderated > list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE ker...@lists.infradead.org>; linux-kernel ; > kishore m > Subject: Re: [PATCH 0/3] Add Bitstream configuration support for ZynqMP > > On Fri, Oct 19, 2018 at 3:49 AM Nava kishore Manne > wrote: > > Hi Nava, > > > > > This series of patches are created On top of the below repo. > > //git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git > > BRANCH: next/drivers. > > IIUC this is dependent on some patches that aren't released yet. > Please make this explicit by specifying which patches this is dependent on in > each future submission of new versions. It will help so that I don't send > these > upstream prematurely and introduce build breaks. Of course, we can keep > reviewing! > This driver depends on the below series of patches https://lkml.org/lkml/2018/9/12/983 Which is got integrated into the below upstream repo. https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/tree/drivers/firmware/xilinx?h=for-next I hope arm maintainers will send the pull-request in soon to integrate these patches with main repo. Will add the required info for the dependent patches in s-o-b section Regards, Navakishore.
RE: [PATCH 0/3] Add Bitstream configuration support for ZynqMP
Hi Alan, Thanks for the reply... Please find my response inline. > -Original Message- > From: Alan Tull [mailto:at...@kernel.org] > Sent: Monday, October 22, 2018 9:29 PM > To: Nava kishore Manne > Cc: Moritz Fischer ; Rob Herring ; > Mark Rutland ; Michal Simek ; > Rajan Vaja ; Jolly Shah ; linux- > f...@vger.kernel.org; open list:OPEN FIRMWARE AND FLATTENED DEVICE > TREE BINDINGS ; moderated > list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE ker...@lists.infradead.org>; linux-kernel ; > kishore m > Subject: Re: [PATCH 0/3] Add Bitstream configuration support for ZynqMP > > On Fri, Oct 19, 2018 at 3:49 AM Nava kishore Manne > wrote: > > Hi Nava, > > > > > This series of patches are created On top of the below repo. > > //git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git > > BRANCH: next/drivers. > > IIUC this is dependent on some patches that aren't released yet. > Please make this explicit by specifying which patches this is dependent on in > each future submission of new versions. It will help so that I don't send > these > upstream prematurely and introduce build breaks. Of course, we can keep > reviewing! > This driver depends on the below series of patches https://lkml.org/lkml/2018/9/12/983 Which is got integrated into the below upstream repo. https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/tree/drivers/firmware/xilinx?h=for-next I hope arm maintainers will send the pull-request in soon to integrate these patches with main repo. Will add the required info for the dependent patches in s-o-b section Regards, Navakishore.
Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver
On 2018/10/19 1:13, Stephen Boyd wrote: > Quoting Jianxin Pan (2018-10-17 22:07:25) [...] >> diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-clkc.c >> new file mode 100644 >> index 000..e3f >> --- /dev/null >> +++ b/drivers/clk/meson/mmc-clkc.c >> @@ -0,0 +1,296 @@ >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) >> +/* >> + * Amlogic Meson MMC Sub Clock Controller Driver >> + * >> + * Copyright (c) 2017 Baylibre SAS. >> + * Author: Jerome Brunet >> + * >> + * Copyright (c) 2018 Amlogic, inc. >> + * Author: Yixun Lan >> + */ >> + >> +#include > > clk-provider.h instead of clk.h?> Maybe we need to keep clk.h devm_clk_get() is called in mmc_clkc_register_mux() to get parent in from DTS. I'm sorry to miss this in previous reply. >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include [...]> > . >
Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver
On 2018/10/19 1:13, Stephen Boyd wrote: > Quoting Jianxin Pan (2018-10-17 22:07:25) [...] >> diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-clkc.c >> new file mode 100644 >> index 000..e3f >> --- /dev/null >> +++ b/drivers/clk/meson/mmc-clkc.c >> @@ -0,0 +1,296 @@ >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) >> +/* >> + * Amlogic Meson MMC Sub Clock Controller Driver >> + * >> + * Copyright (c) 2017 Baylibre SAS. >> + * Author: Jerome Brunet >> + * >> + * Copyright (c) 2018 Amlogic, inc. >> + * Author: Yixun Lan >> + */ >> + >> +#include > > clk-provider.h instead of clk.h?> Maybe we need to keep clk.h devm_clk_get() is called in mmc_clkc_register_mux() to get parent in from DTS. I'm sorry to miss this in previous reply. >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include [...]> > . >
Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.
On Wed, 2018-10-24 at 08:15 +0200, Michal Hocko wrote: > On Wed 24-10-18 10:47:52, Arun KS wrote: > > On 2018-10-24 01:34, Kees Cook wrote: > [...] > > > Thank you -- I was struggling to figure out the best way to reply to > > > this. :) > > I'm sorry for the trouble caused. Sent the email using, > > git send-email --to-cmd="scripts/get_maintainer.pl -i" > > 0001-convert-totalram_pages-totalhigh_pages-and-managed_p.patch > > > > Is this not a recommended approach? > > Not really for tree wide mechanical changes. It is much more preferrable > IMHO to only CC people who should review the intention of the change > rather than each and every maintainer whose code is going to be changed. > This is a case by case thing of course but as soon as you see a giant CC > list from get_maintainer.pl then you should try to think twice to use > it. If not sure, just ask on the mailing list. Generally, it's better to use scripts to control the --to-cmd and --cc-cmd options. Something like what I detailed here: https://lkml.org/lkml/2016/9/14/482
Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.
On Wed, 2018-10-24 at 08:15 +0200, Michal Hocko wrote: > On Wed 24-10-18 10:47:52, Arun KS wrote: > > On 2018-10-24 01:34, Kees Cook wrote: > [...] > > > Thank you -- I was struggling to figure out the best way to reply to > > > this. :) > > I'm sorry for the trouble caused. Sent the email using, > > git send-email --to-cmd="scripts/get_maintainer.pl -i" > > 0001-convert-totalram_pages-totalhigh_pages-and-managed_p.patch > > > > Is this not a recommended approach? > > Not really for tree wide mechanical changes. It is much more preferrable > IMHO to only CC people who should review the intention of the change > rather than each and every maintainer whose code is going to be changed. > This is a case by case thing of course but as soon as you see a giant CC > list from get_maintainer.pl then you should try to think twice to use > it. If not sure, just ask on the mailing list. Generally, it's better to use scripts to control the --to-cmd and --cc-cmd options. Something like what I detailed here: https://lkml.org/lkml/2016/9/14/482
Re: [RFC PATCH 0/2] improve vmalloc allocation
On Tue 23-10-18 12:30:44, Joel Fernandes wrote: > On Tue, Oct 23, 2018 at 11:13:36AM -0600, Shuah Khan wrote: > > On 10/23/2018 11:05 AM, Michal Hocko wrote: > > > On Tue 23-10-18 08:26:40, Matthew Wilcox wrote: > > >> On Tue, Oct 23, 2018 at 09:02:56AM -0600, Shuah Khan wrote: > > > [...] > > >>> The way it can be handled is by adding a test module under lib. > > >>> test_kmod, > > >>> test_sysctl, test_user_copy etc. > > >> > > >> The problem is that said module can only invoke functions which are > > >> exported using EXPORT_SYMBOL. And there's a cost to exporting them, > > >> which I don't think we're willing to pay, purely to get test coverage. > > > > > > Yes, I think we do not want to export internal functionality which might > > > be still interesting for the testing coverage. Maybe we want something > > > like EXPORT_SYMBOL_KSELFTEST which would allow to link within the > > > kselftest machinery but it wouldn't allow the same for general modules > > > and will not give any API promisses. > > > > > > > I like this proposal. I think we will open up lot of test opportunities with > > this approach. > > > > Maybe we can use this stress test as a pilot and see where it takes us. > > I am a bit worried that such an EXPORT_SYMBOL_KSELFTEST mechanism can be > abused by > out-of-tree module writers to call internal functionality. > > How would you prevent that? There is no way to prevent non-exported symbols abuse by 3rd party AFAIK. EXPORT_SYMBOL_* is not there to prohibid abuse. It is a mere signal of what is, well, an exported API. -- Michal Hocko SUSE Labs
Re: [RFC PATCH 0/2] improve vmalloc allocation
On Tue 23-10-18 12:30:44, Joel Fernandes wrote: > On Tue, Oct 23, 2018 at 11:13:36AM -0600, Shuah Khan wrote: > > On 10/23/2018 11:05 AM, Michal Hocko wrote: > > > On Tue 23-10-18 08:26:40, Matthew Wilcox wrote: > > >> On Tue, Oct 23, 2018 at 09:02:56AM -0600, Shuah Khan wrote: > > > [...] > > >>> The way it can be handled is by adding a test module under lib. > > >>> test_kmod, > > >>> test_sysctl, test_user_copy etc. > > >> > > >> The problem is that said module can only invoke functions which are > > >> exported using EXPORT_SYMBOL. And there's a cost to exporting them, > > >> which I don't think we're willing to pay, purely to get test coverage. > > > > > > Yes, I think we do not want to export internal functionality which might > > > be still interesting for the testing coverage. Maybe we want something > > > like EXPORT_SYMBOL_KSELFTEST which would allow to link within the > > > kselftest machinery but it wouldn't allow the same for general modules > > > and will not give any API promisses. > > > > > > > I like this proposal. I think we will open up lot of test opportunities with > > this approach. > > > > Maybe we can use this stress test as a pilot and see where it takes us. > > I am a bit worried that such an EXPORT_SYMBOL_KSELFTEST mechanism can be > abused by > out-of-tree module writers to call internal functionality. > > How would you prevent that? There is no way to prevent non-exported symbols abuse by 3rd party AFAIK. EXPORT_SYMBOL_* is not there to prohibid abuse. It is a mere signal of what is, well, an exported API. -- Michal Hocko SUSE Labs
Re: [RFC][PATCH v3 01/10] fs: common implementation of file type
On Tue, Oct 23, 2018 at 11:19 PM Phillip Potter wrote:
>
> Many file systems use a copy implementation
> of dirent to on-disk file type conversions.
>
> Create a common implementation to be used by file systems
> with some useful conversion helpers to reduce open coded
> file type conversions in file system code.
>
> Original patch written by Amir Goldstein.
Looks good.
I guess you used 'git apply' or just 'patch'
What you usually do when applying someone else mostly unchanged
patches is use 'git am -s -3' so you preserve the original author and
original commit message including the Signed-of-by line.
You can edit your patch by hand to change the From: line to change the
author and add
Signed-off-by: Amir Goldstein
(you sign below me as you changed the patch last)
>
> v3:
> - Rebased against Linux 4.19 by Phillip Potter
> - Added SPDX tag to new include/linux/file_type.h
> - Added include/linux/file_type.h to MAINTAINERS
>
As you can see in my original posting, this part comes after the ---
line which means it will not be included in the commit message,
because the specific development history of this patch may be interesting
for reviewers but it is less interesting in the context of git log.
> v2:
> - s/DT_MASK/S_DT_MASK to fix redefinition in drivers/scsi/qla2xxx/qla_def.h
> - Explicit initialization of fs_dtype_by_ftype[] using [FT_*] = DT_*
>
> v1:
> - Initial implementation
>
> Signed-off-by: Phillip Potter
> ---
> MAINTAINERS | 1 +
> include/linux/file_type.h | 108 ++
> include/linux/fs.h| 17 +-
> 3 files changed, 110 insertions(+), 16 deletions(-)
> create mode 100644 include/linux/file_type.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b2f710eee67a..8e5b029886e6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5689,6 +5689,7 @@ L:linux-fsde...@vger.kernel.org
> S: Maintained
> F: fs/*
> F: include/linux/fs.h
> +F: include/linux/file_type.h
> F: include/uapi/linux/fs.h
>
> FINTEK F75375S HARDWARE MONITOR AND FAN CONTROLLER DRIVER
> diff --git a/include/linux/file_type.h b/include/linux/file_type.h
> new file mode 100644
> index ..f015c41ca90c
> --- /dev/null
> +++ b/include/linux/file_type.h
> @@ -0,0 +1,108 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_FILE_TYPE_H
> +#define _LINUX_FILE_TYPE_H
> +
> +/*
> + * This is a common implementation of dirent to fs on-disk
> + * file type conversion. Although the fs on-disk bits are
> + * specific to every file system, in practice, many file systems
> + * use the exact same on-disk format to describe the lower 3
> + * file type bits that represent the 7 POSIX file types.
> + * All those file systems can use this generic code for the
> + * conversions:
> + * i_mode -> fs on-disk file type (ftype)
> + * fs on-disk file type (ftype) -> dirent file type (dtype)
> + * i_mode -> dirent file type (dtype)
> + */
> +
> +/*
> + * struct dirent file types
> + * exposed to user via getdents(2), readdir(3)
> + *
> + * These match bits 12..15 of stat.st_mode
> + * (ie "(i_mode >> 12) & 15").
> + */
> +#define S_DT_SHIFT 12
> +#define S_DT(mode) (((mode) & S_IFMT) >> S_DT_SHIFT)
> +#define S_DT_MASK (S_IFMT >> S_DT_SHIFT)
> +
> +#define DT_UNKNOWN 0
> +#define DT_FIFOS_DT(S_IFIFO) /* 1 */
> +#define DT_CHR S_DT(S_IFCHR) /* 2 */
> +#define DT_DIR S_DT(S_IFDIR) /* 4 */
> +#define DT_BLK S_DT(S_IFBLK) /* 6 */
> +#define DT_REG S_DT(S_IFREG) /* 8 */
> +#define DT_LNK S_DT(S_IFLNK) /* 10 */
> +#define DT_SOCKS_DT(S_IFSOCK) /* 12 */
> +#define DT_WHT 14
> +
> +#define DT_MAX (S_DT_MASK + 1) /* 16 */
> +
> +/*
> + * fs on-disk file types.
> + * Only the low 3 bits are used for the POSIX file types.
> + * Other bits are reserved for fs private use.
> + *
> + * Note that no fs currently stores the whiteout type on-disk,
> + * so whiteout dirents are exposed to user as DT_CHR.
> + */
> +#define FT_UNKNOWN 0
> +#define FT_REG_FILE1
> +#define FT_DIR 2
> +#define FT_CHRDEV 3
> +#define FT_BLKDEV 4
> +#define FT_FIFO5
> +#define FT_SOCK6
> +#define FT_SYMLINK 7
> +
> +#define FT_MAX 8
> +
> +/*
> + * fs on-disk file type to dirent file type conversion
> + */
> +static unsigned char fs_dtype_by_ftype[FT_MAX] = {
> + [FT_UNKNOWN]= DT_UNKNOWN,
> + [FT_REG_FILE] = DT_REG,
> + [FT_DIR]= DT_DIR,
> + [FT_CHRDEV] = DT_CHR,
> + [FT_BLKDEV] = DT_BLK,
> + [FT_FIFO] = DT_FIFO,
> + [FT_SOCK] = DT_SOCK,
> + [FT_SYMLINK]= DT_LNK
> +};
> +
> +static inline unsigned char fs_dtype(int filetype)
> +{
> + if (filetype >= FT_MAX)
> + return DT_UNKNOWN;
> +
> + return fs_dtype_by_ftype[filetype];
> +}
> +
> +/*
> + * dirent file type to fs on-disk file type conversion
> +
Re: [RFC][PATCH v3 01/10] fs: common implementation of file type
On Tue, Oct 23, 2018 at 11:19 PM Phillip Potter wrote:
>
> Many file systems use a copy implementation
> of dirent to on-disk file type conversions.
>
> Create a common implementation to be used by file systems
> with some useful conversion helpers to reduce open coded
> file type conversions in file system code.
>
> Original patch written by Amir Goldstein.
Looks good.
I guess you used 'git apply' or just 'patch'
What you usually do when applying someone else mostly unchanged
patches is use 'git am -s -3' so you preserve the original author and
original commit message including the Signed-of-by line.
You can edit your patch by hand to change the From: line to change the
author and add
Signed-off-by: Amir Goldstein
(you sign below me as you changed the patch last)
>
> v3:
> - Rebased against Linux 4.19 by Phillip Potter
> - Added SPDX tag to new include/linux/file_type.h
> - Added include/linux/file_type.h to MAINTAINERS
>
As you can see in my original posting, this part comes after the ---
line which means it will not be included in the commit message,
because the specific development history of this patch may be interesting
for reviewers but it is less interesting in the context of git log.
> v2:
> - s/DT_MASK/S_DT_MASK to fix redefinition in drivers/scsi/qla2xxx/qla_def.h
> - Explicit initialization of fs_dtype_by_ftype[] using [FT_*] = DT_*
>
> v1:
> - Initial implementation
>
> Signed-off-by: Phillip Potter
> ---
> MAINTAINERS | 1 +
> include/linux/file_type.h | 108 ++
> include/linux/fs.h| 17 +-
> 3 files changed, 110 insertions(+), 16 deletions(-)
> create mode 100644 include/linux/file_type.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b2f710eee67a..8e5b029886e6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5689,6 +5689,7 @@ L:linux-fsde...@vger.kernel.org
> S: Maintained
> F: fs/*
> F: include/linux/fs.h
> +F: include/linux/file_type.h
> F: include/uapi/linux/fs.h
>
> FINTEK F75375S HARDWARE MONITOR AND FAN CONTROLLER DRIVER
> diff --git a/include/linux/file_type.h b/include/linux/file_type.h
> new file mode 100644
> index ..f015c41ca90c
> --- /dev/null
> +++ b/include/linux/file_type.h
> @@ -0,0 +1,108 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_FILE_TYPE_H
> +#define _LINUX_FILE_TYPE_H
> +
> +/*
> + * This is a common implementation of dirent to fs on-disk
> + * file type conversion. Although the fs on-disk bits are
> + * specific to every file system, in practice, many file systems
> + * use the exact same on-disk format to describe the lower 3
> + * file type bits that represent the 7 POSIX file types.
> + * All those file systems can use this generic code for the
> + * conversions:
> + * i_mode -> fs on-disk file type (ftype)
> + * fs on-disk file type (ftype) -> dirent file type (dtype)
> + * i_mode -> dirent file type (dtype)
> + */
> +
> +/*
> + * struct dirent file types
> + * exposed to user via getdents(2), readdir(3)
> + *
> + * These match bits 12..15 of stat.st_mode
> + * (ie "(i_mode >> 12) & 15").
> + */
> +#define S_DT_SHIFT 12
> +#define S_DT(mode) (((mode) & S_IFMT) >> S_DT_SHIFT)
> +#define S_DT_MASK (S_IFMT >> S_DT_SHIFT)
> +
> +#define DT_UNKNOWN 0
> +#define DT_FIFOS_DT(S_IFIFO) /* 1 */
> +#define DT_CHR S_DT(S_IFCHR) /* 2 */
> +#define DT_DIR S_DT(S_IFDIR) /* 4 */
> +#define DT_BLK S_DT(S_IFBLK) /* 6 */
> +#define DT_REG S_DT(S_IFREG) /* 8 */
> +#define DT_LNK S_DT(S_IFLNK) /* 10 */
> +#define DT_SOCKS_DT(S_IFSOCK) /* 12 */
> +#define DT_WHT 14
> +
> +#define DT_MAX (S_DT_MASK + 1) /* 16 */
> +
> +/*
> + * fs on-disk file types.
> + * Only the low 3 bits are used for the POSIX file types.
> + * Other bits are reserved for fs private use.
> + *
> + * Note that no fs currently stores the whiteout type on-disk,
> + * so whiteout dirents are exposed to user as DT_CHR.
> + */
> +#define FT_UNKNOWN 0
> +#define FT_REG_FILE1
> +#define FT_DIR 2
> +#define FT_CHRDEV 3
> +#define FT_BLKDEV 4
> +#define FT_FIFO5
> +#define FT_SOCK6
> +#define FT_SYMLINK 7
> +
> +#define FT_MAX 8
> +
> +/*
> + * fs on-disk file type to dirent file type conversion
> + */
> +static unsigned char fs_dtype_by_ftype[FT_MAX] = {
> + [FT_UNKNOWN]= DT_UNKNOWN,
> + [FT_REG_FILE] = DT_REG,
> + [FT_DIR]= DT_DIR,
> + [FT_CHRDEV] = DT_CHR,
> + [FT_BLKDEV] = DT_BLK,
> + [FT_FIFO] = DT_FIFO,
> + [FT_SOCK] = DT_SOCK,
> + [FT_SYMLINK]= DT_LNK
> +};
> +
> +static inline unsigned char fs_dtype(int filetype)
> +{
> + if (filetype >= FT_MAX)
> + return DT_UNKNOWN;
> +
> + return fs_dtype_by_ftype[filetype];
> +}
> +
> +/*
> + * dirent file type to fs on-disk file type conversion
> +
Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.
On Wed 24-10-18 10:47:52, Arun KS wrote: > On 2018-10-24 01:34, Kees Cook wrote: [...] > > Thank you -- I was struggling to figure out the best way to reply to > > this. :) > I'm sorry for the trouble caused. Sent the email using, > git send-email --to-cmd="scripts/get_maintainer.pl -i" > 0001-convert-totalram_pages-totalhigh_pages-and-managed_p.patch > > Is this not a recommended approach? Not really for tree wide mechanical changes. It is much more preferrable IMHO to only CC people who should review the intention of the change rather than each and every maintainer whose code is going to be changed. This is a case by case thing of course but as soon as you see a giant CC list from get_maintainer.pl then you should try to think twice to use it. If not sure, just ask on the mailing list. -- Michal Hocko SUSE Labs
Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.
On Wed 24-10-18 10:47:52, Arun KS wrote: > On 2018-10-24 01:34, Kees Cook wrote: [...] > > Thank you -- I was struggling to figure out the best way to reply to > > this. :) > I'm sorry for the trouble caused. Sent the email using, > git send-email --to-cmd="scripts/get_maintainer.pl -i" > 0001-convert-totalram_pages-totalhigh_pages-and-managed_p.patch > > Is this not a recommended approach? Not really for tree wide mechanical changes. It is much more preferrable IMHO to only CC people who should review the intention of the change rather than each and every maintainer whose code is going to be changed. This is a case by case thing of course but as soon as you see a giant CC list from get_maintainer.pl then you should try to think twice to use it. If not sure, just ask on the mailing list. -- Michal Hocko SUSE Labs
Re: [PATCH 4/5] spi: lpspi: enable runtime pm for lpspi
Hi Clark,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on spi/for-next]
[also build test ERROR on next-20181019]
[cannot apply to v4.19]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Clark-Wang/spi-lpspi-Add-slave-mode-support-for-imx7ulp/20181024-125200
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=mips
All errors (new ones prefixed by >>):
drivers//spi/spi-fsl-lpspi.c: In function 'fsl_lpspi_transfer_one':
drivers//spi/spi-fsl-lpspi.c:399:8: error: implicit declaration of function
'fsl_lpspi_txfifo_empty'; did you mean 'fsl_lpspi_set_cmd'?
[-Werror=implicit-function-declaration]
ret = fsl_lpspi_txfifo_empty(fsl_lpspi);
^~
fsl_lpspi_set_cmd
drivers//spi/spi-fsl-lpspi.c: In function 'fsl_lpspi_suspend':
>> drivers//spi/spi-fsl-lpspi.c:622:2: error: implicit declaration of function
>> 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
pinctrl_pm_select_sleep_state(dev);
^
drivers//spi/spi-fsl-lpspi.c: In function 'fsl_lpspi_resume':
>> drivers//spi/spi-fsl-lpspi.c:637:2: error: implicit declaration of function
>> 'pinctrl_pm_select_default_state'; did you mean 'irq_set_default_host'?
>> [-Werror=implicit-function-declaration]
pinctrl_pm_select_default_state(dev);
^~~
irq_set_default_host
cc1: some warnings being treated as errors
vim +/pinctrl_pm_select_sleep_state +622 drivers//spi/spi-fsl-lpspi.c
616
617 #ifdef CONFIG_PM_SLEEP
618 static int fsl_lpspi_suspend(struct device *dev)
619 {
620 int ret;
621
> 622 pinctrl_pm_select_sleep_state(dev);
623 ret = pm_runtime_force_suspend(dev);
624 return ret;
625 }
626
627 static int fsl_lpspi_resume(struct device *dev)
628 {
629 int ret;
630
631 ret = pm_runtime_force_resume(dev);
632 if (ret) {
633 dev_err(dev, "Error in resume: %d\n", ret);
634 return ret;
635 }
636
> 637 pinctrl_pm_select_default_state(dev);
638
639 return 0;
640 }
641 #endif /* CONFIG_PM_SLEEP */
642
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 4/5] spi: lpspi: enable runtime pm for lpspi
Hi Clark,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on spi/for-next]
[also build test ERROR on next-20181019]
[cannot apply to v4.19]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Clark-Wang/spi-lpspi-Add-slave-mode-support-for-imx7ulp/20181024-125200
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=mips
All errors (new ones prefixed by >>):
drivers//spi/spi-fsl-lpspi.c: In function 'fsl_lpspi_transfer_one':
drivers//spi/spi-fsl-lpspi.c:399:8: error: implicit declaration of function
'fsl_lpspi_txfifo_empty'; did you mean 'fsl_lpspi_set_cmd'?
[-Werror=implicit-function-declaration]
ret = fsl_lpspi_txfifo_empty(fsl_lpspi);
^~
fsl_lpspi_set_cmd
drivers//spi/spi-fsl-lpspi.c: In function 'fsl_lpspi_suspend':
>> drivers//spi/spi-fsl-lpspi.c:622:2: error: implicit declaration of function
>> 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
pinctrl_pm_select_sleep_state(dev);
^
drivers//spi/spi-fsl-lpspi.c: In function 'fsl_lpspi_resume':
>> drivers//spi/spi-fsl-lpspi.c:637:2: error: implicit declaration of function
>> 'pinctrl_pm_select_default_state'; did you mean 'irq_set_default_host'?
>> [-Werror=implicit-function-declaration]
pinctrl_pm_select_default_state(dev);
^~~
irq_set_default_host
cc1: some warnings being treated as errors
vim +/pinctrl_pm_select_sleep_state +622 drivers//spi/spi-fsl-lpspi.c
616
617 #ifdef CONFIG_PM_SLEEP
618 static int fsl_lpspi_suspend(struct device *dev)
619 {
620 int ret;
621
> 622 pinctrl_pm_select_sleep_state(dev);
623 ret = pm_runtime_force_suspend(dev);
624 return ret;
625 }
626
627 static int fsl_lpspi_resume(struct device *dev)
628 {
629 int ret;
630
631 ret = pm_runtime_force_resume(dev);
632 if (ret) {
633 dev_err(dev, "Error in resume: %d\n", ret);
634 return ret;
635 }
636
> 637 pinctrl_pm_select_default_state(dev);
638
639 return 0;
640 }
641 #endif /* CONFIG_PM_SLEEP */
642
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
