Re: [PATCH RESEND v3] staging: erofs: remove unsupported ->datamode check in fill_inline_data()
On Thu, 4 Jul 2019 07:26:49 +0200 Greg KH wrote: > On Thu, Jul 04, 2019 at 09:59:03AM +0800, Yue Hu wrote: > > On Wed, 3 Jul 2019 18:20:38 +0200 > > Greg KH wrote: > > > > > On Tue, Jul 02, 2019 at 10:56:01AM +0800, Yue Hu wrote: > > > > From: Yue Hu > > > > > > > > Already check if ->datamode is supported in read_inode(), no need to > > > > check > > > > again in the next fill_inline_data() only called by fill_inode(). > > > > > > > > Signed-off-by: Yue Hu > > > > Reviewed-by: Gao Xiang > > > > Reviewed-by: Chao Yu > > > > --- > > > > no change > > > > > > > > drivers/staging/erofs/inode.c | 2 -- > > > > 1 file changed, 2 deletions(-) > > > > > > This is already in my tree, right? > > > > Seems not, i have received notes about other 2 patches below mergerd: > > > > ```note1 > > This is a note to let you know that I've just added the patch titled > > > > staging: erofs: don't check special inode layout > > > > to my staging git tree which can be found at > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > > in the staging-next branch. > > ``` > > > > ```note2 > > This is a note to let you know that I've just added the patch titled > > > > staging: erofs: return the error value if fill_inline_data() fails > > > > to my staging git tree which can be found at > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > > in the staging-next branch. > > ``` > > > > No this patch in below link checked: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/log/drivers/staging/erofs?h=staging-testing > > > > Then if it is not present, it needs to be rebased as it does not apply. > > Please do so and resend it. Hm, no need to resend since it's included in another patch below. ec8c244 staging: erofs: add compacted ondisk compression indexes. Thanks. > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND v3] staging: erofs: remove unsupported ->datamode check in fill_inline_data()
On 2019/7/4 18:02, Yue Hu wrote: > On Thu, 4 Jul 2019 07:26:49 +0200 > Greg KH wrote: > >> On Thu, Jul 04, 2019 at 09:59:03AM +0800, Yue Hu wrote: >>> On Wed, 3 Jul 2019 18:20:38 +0200 >>> Greg KH wrote: >>> On Tue, Jul 02, 2019 at 10:56:01AM +0800, Yue Hu wrote: > From: Yue Hu > > Already check if ->datamode is supported in read_inode(), no need to check > again in the next fill_inline_data() only called by fill_inode(). > > Signed-off-by: Yue Hu > Reviewed-by: Gao Xiang > Reviewed-by: Chao Yu > --- > no change > > drivers/staging/erofs/inode.c | 2 -- > 1 file changed, 2 deletions(-) This is already in my tree, right? >>> >>> Seems not, i have received notes about other 2 patches below mergerd: >>> >>> ```note1 >>> This is a note to let you know that I've just added the patch titled >>> >>> staging: erofs: don't check special inode layout >>> >>> to my staging git tree which can be found at >>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git >>> in the staging-next branch. >>> ``` >>> >>> ```note2 >>> This is a note to let you know that I've just added the patch titled >>> >>> staging: erofs: return the error value if fill_inline_data() fails >>> >>> to my staging git tree which can be found at >>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git >>> in the staging-next branch. >>> ``` >>> >>> No this patch in below link checked: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/log/drivers/staging/erofs?h=staging-testing >>> >> >> Then if it is not present, it needs to be rebased as it does not apply. >> >> Please do so and resend it. > > Hm, no need to resend since it's included in another patch below. > > ec8c244 staging: erofs: add compacted ondisk compression indexes. Yes, it seems it was modified by the following patch occasionally months ago. https://lore.kernel.org/lkml/20190614181619.64905-2-gaoxian...@huawei.com/ Anyway, thanks for your patch. :) Thanks, Gao Xiang > > Thanks. > >> >> thanks, >> >> greg k-h > > ___ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup 187/193] drivers/iommu/omap-iommu-debug.c:264:4: error: void value not ignored as it ought to be
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: e647f5cb848a5cb522516fd5ca67d89d6b12bdb2
commit: 7fb9d02c8360513538f1de583da9174490553654 [187/193] debugfs: remove
return value of debugfs_create_u32()
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 7fb9d02c8360513538f1de583da9174490553654
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/iommu/omap-iommu-debug.c: In function 'omap_iommu_debugfs_add':
>> drivers/iommu/omap-iommu-debug.c:264:4: error: void value not ignored as it
>> ought to be
d = debugfs_create_u32("nr_tlb_entries", 0400, obj->debug_dir,
^
vim +264 drivers/iommu/omap-iommu-debug.c
14e0e6796 arch/arm/plat-omap/iommu-debug.c Hiroshi DOYU 2009-08-28 252
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 253
void omap_iommu_debugfs_add(struct omap_iommu *obj)
14e0e6796 arch/arm/plat-omap/iommu-debug.c Hiroshi DOYU 2009-08-28 254 {
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 255
struct dentry *d;
46451d622 drivers/iommu/omap-iommu-debug.c Ohad Ben-Cohen 2012-02-22 256
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 257
if (!iommu_debug_root)
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 258
return;
46451d622 drivers/iommu/omap-iommu-debug.c Ohad Ben-Cohen 2012-02-22 259
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 260
obj->debug_dir = debugfs_create_dir(obj->name, iommu_debug_root);
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 261
if (!obj->debug_dir)
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 262
return;
46451d622 drivers/iommu/omap-iommu-debug.c Ohad Ben-Cohen 2012-02-22 263
f18affbea drivers/iommu/omap-iommu-debug.c Geert Uytterhoeven 2018-01-02 @264
d = debugfs_create_u32("nr_tlb_entries", 0400, obj->debug_dir,
f18affbea drivers/iommu/omap-iommu-debug.c Geert Uytterhoeven 2018-01-02 265
&obj->nr_tlb_entries);
14e0e6796 arch/arm/plat-omap/iommu-debug.c Hiroshi DOYU 2009-08-28 266
if (!d)
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 267
return;
14e0e6796 arch/arm/plat-omap/iommu-debug.c Hiroshi DOYU 2009-08-28 268
14e0e6796 arch/arm/plat-omap/iommu-debug.c Hiroshi DOYU 2009-08-28 269
DEBUG_ADD_FILE_RO(regs);
14e0e6796 arch/arm/plat-omap/iommu-debug.c Hiroshi DOYU 2009-08-28 270
DEBUG_ADD_FILE_RO(tlb);
3ca5db072 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 271
DEBUG_ADD_FILE_RO(pagetable);
14e0e6796 arch/arm/plat-omap/iommu-debug.c Hiroshi DOYU 2009-08-28 272
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 273
return;
46451d622 drivers/iommu/omap-iommu-debug.c Ohad Ben-Cohen 2012-02-22 274
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 275
err:
61c753526 drivers/iommu/omap-iommu-debug.c Suman Anna 2014-10-22 276
debugfs_remove_recursive(obj->debug_dir);
46451d622 drivers/iommu/omap-iommu-debug.c Ohad Ben-Cohen 2012-02-22 277 }
46451d622 drivers/iommu/omap-iommu-debug.c Ohad Ben-Cohen 2012-02-22 278
:: The code at line 264 was first introduced by commit
:: f18affbea8f7aebb235bfdaf3ad4c307aa5f3d64 iommu/omap: Fix
debugfs_create_*() usage
:: TO: Geert Uytterhoeven
:: CC: Joerg Roedel
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: greybus: remove redundant assignment to variable is_empty
From: Colin Ian King
The variable is_empty is being initialized with a value that is never
read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/staging/greybus/audio_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_manager.c
b/drivers/staging/greybus/audio_manager.c
index c2a4af4c1d06..9b19ea9d3fa1 100644
--- a/drivers/staging/greybus/audio_manager.c
+++ b/drivers/staging/greybus/audio_manager.c
@@ -86,7 +86,7 @@ EXPORT_SYMBOL_GPL(gb_audio_manager_remove);
void gb_audio_manager_remove_all(void)
{
struct gb_audio_manager_module *module, *next;
- int is_empty = 1;
+ int is_empty;
down_write(&modules_rwsem);
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] erofs: promote erofs from staging
EROFS file system has been in Linux-staging for about a year.
It has been proved to be stable enough to move out of staging
by 10+ millions of HUAWEI Android mobile phones on the market
from EMUI 9.0.1, and it was promoted as one of the key features
of EMUI 9.1 [1], including P30(pro).
EROFS is a read-only file system designed to save extra storage
space with guaranteed end-to-end performance by applying
fixed-size output compression, inplace I/O and decompression
inplace technologies [2] to Linux filesystem.
In our observation, EROFS is one of the fastest Linux compression
filesystem using buffered I/O in the world. It will support
direct I/O in the future if needed. EROFS even has better read
performance in a large CR range compared with generic uncompressed
file systems with proper CPU-storage combination, which is
a reason why erofs can be landed to speed up mobile phone
performance, and which can be probably used for other use cases
such as LiveCD and Docker image as well.
Currently erofs supports 4k LZ4 fixed-size output compression
since LZ4 is the fastest widely-used decompression solution in
the world and 4k leads to unnoticable read amplification for
the worst case. More compression algorithms and cluster sizes
could be added later, which depends on the real requirement.
More informations about erofs itself are available at:
Documentation/filesystems/erofs.txt
https://kccncosschn19eng.sched.com/event/Nru2/erofs-an-introduction-and-our-smartphone-practice-xiang-gao-huawei
erofs-utils (mainly mkfs.erofs now) is available at
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git
Preliminary iomap support has been pending in erofs mailing
list by Chao Yu. The key issue is that current iomap doesn't
support tail-end packing inline data yet, it should be
resolved later.
Thanks to many contributors in the last year, the code is more
clean and improved. We hope erofs can be used in wider use cases
so let's promote erofs out of staging and enhance it more actively.
Share comments about erofs! We think erofs is useful to
community as a part of Linux upstream :)
[1]
http://web.archive.org/web/20190627021241/https://consumer.huawei.com/en/emui/
[2] https://lore.kernel.org/lkml/20190624072258.28362-1-hsiang...@aol.com/
Cc: Greg Kroah-Hartman
Cc: Alexander Viro
Cc: Andrew Morton
Cc: Theodore Ts'o
Cc: Chao Yu
Cc: Miao Xie
Cc: Li Guifu
Cc: Fang Wei
Signed-off-by: Gao Xiang
---
Note that,
This patch is based on commit 5b2736ce361989882636d4b105d1146ca3382f47
of staging-next, the latest erofs code is available at
http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/erofs?h=staging-next
with decompression in-place implementation.
The first formal release of erofs-utils will be released after erofs
is moved into fs/ in case of some major changes raised, the latest
erofs-utils is available in experimental-dip branch of erofs-utils:
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git -b
experimental-dip
Thanks,
Gao Xiang
.../filesystems/erofs.txt | 0
MAINTAINERS | 14 +++---
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile | 1 -
drivers/staging/erofs/TODO| 46 ---
fs/Kconfig| 1 +
fs/Makefile | 2 +
{drivers/staging => fs}/erofs/Kconfig | 0
{drivers/staging => fs}/erofs/Makefile| 4 +-
{drivers/staging => fs}/erofs/compress.h | 2 +-
{drivers/staging => fs}/erofs/data.c | 6 +--
{drivers/staging => fs}/erofs/decompressor.c | 2 +-
{drivers/staging => fs}/erofs/dir.c | 6 +--
{drivers/staging => fs}/erofs/erofs_fs.h | 10 ++--
{drivers/staging => fs}/erofs/inode.c | 2 +-
{drivers/staging => fs}/erofs/internal.h | 6 +--
{drivers/staging => fs}/erofs/namei.c | 2 +-
{drivers/staging => fs}/erofs/super.c | 2 +-
.../erofs/include/linux => fs/erofs}/tagptr.h | 4 +-
{drivers/staging => fs}/erofs/unzip_pagevec.h | 8 ++--
{drivers/staging => fs}/erofs/unzip_vle.c | 6 +--
{drivers/staging => fs}/erofs/unzip_vle.h | 10 ++--
{drivers/staging => fs}/erofs/utils.c | 6 +--
{drivers/staging => fs}/erofs/xattr.c | 6 +--
{drivers/staging => fs}/erofs/xattr.h | 10 ++--
{drivers/staging => fs}/erofs/zmap.c | 2 +-
.../include => include}/trace/events/erofs.h | 0
27 files changed, 40 insertions(+), 120 deletions(-)
rename {drivers/staging/erofs/Documentation =>
Documentation}/filesystems/erofs.txt (100%)
delete mode 100644 drivers/staging/erofs/TODO
rename {drivers/staging => fs}/erofs/Kconfig (100%)
rename {drivers/staging => fs}/erofs/Makefile (68%)
rename {drivers/staging => fs}/erofs/compress.h (97%)
rename {drivers/staging => fs}/erofs/data.c (97%)
rename {drivers/staging =>
Re: [PATCH] erofs: promote erofs from staging
On Thu, Jul 04, 2019 at 09:34:13PM +0800, Gao Xiang wrote: > EROFS file system has been in Linux-staging for about a year. > It has been proved to be stable enough to move out of staging > by 10+ millions of HUAWEI Android mobile phones on the market > from EMUI 9.0.1, and it was promoted as one of the key features > of EMUI 9.1 [1], including P30(pro). > > EROFS is a read-only file system designed to save extra storage > space with guaranteed end-to-end performance by applying > fixed-size output compression, inplace I/O and decompression > inplace technologies [2] to Linux filesystem. > > In our observation, EROFS is one of the fastest Linux compression > filesystem using buffered I/O in the world. It will support > direct I/O in the future if needed. EROFS even has better read > performance in a large CR range compared with generic uncompressed > file systems with proper CPU-storage combination, which is > a reason why erofs can be landed to speed up mobile phone > performance, and which can be probably used for other use cases > such as LiveCD and Docker image as well. > > Currently erofs supports 4k LZ4 fixed-size output compression > since LZ4 is the fastest widely-used decompression solution in > the world and 4k leads to unnoticable read amplification for > the worst case. More compression algorithms and cluster sizes > could be added later, which depends on the real requirement. > > More informations about erofs itself are available at: > Documentation/filesystems/erofs.txt > > https://kccncosschn19eng.sched.com/event/Nru2/erofs-an-introduction-and-our-smartphone-practice-xiang-gao-huawei > > erofs-utils (mainly mkfs.erofs now) is available at > git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git > > Preliminary iomap support has been pending in erofs mailing > list by Chao Yu. The key issue is that current iomap doesn't > support tail-end packing inline data yet, it should be > resolved later. > > Thanks to many contributors in the last year, the code is more > clean and improved. We hope erofs can be used in wider use cases > so let's promote erofs out of staging and enhance it more actively. > > Share comments about erofs! We think erofs is useful to > community as a part of Linux upstream :) I don't know if this format is easy for the linux-fsdevel people to review, it forces them to look at the in-kernel code, which makes it hard to quote. Perhaps just make a patch that adds the filesystem to the tree and after it makes it through review, I can delete the staging version? We've been doing that for wifi drivers that move out of staging as it seems to be a bit easier. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: promote erofs from staging
Hi Greg, On 2019/7/4 21:50, Greg Kroah-Hartman wrote: > On Thu, Jul 04, 2019 at 09:34:13PM +0800, Gao Xiang wrote: >> EROFS file system has been in Linux-staging for about a year. >> It has been proved to be stable enough to move out of staging >> by 10+ millions of HUAWEI Android mobile phones on the market >> from EMUI 9.0.1, and it was promoted as one of the key features >> of EMUI 9.1 [1], including P30(pro). >> >> EROFS is a read-only file system designed to save extra storage >> space with guaranteed end-to-end performance by applying >> fixed-size output compression, inplace I/O and decompression >> inplace technologies [2] to Linux filesystem. >> >> In our observation, EROFS is one of the fastest Linux compression >> filesystem using buffered I/O in the world. It will support >> direct I/O in the future if needed. EROFS even has better read >> performance in a large CR range compared with generic uncompressed >> file systems with proper CPU-storage combination, which is >> a reason why erofs can be landed to speed up mobile phone >> performance, and which can be probably used for other use cases >> such as LiveCD and Docker image as well. >> >> Currently erofs supports 4k LZ4 fixed-size output compression >> since LZ4 is the fastest widely-used decompression solution in >> the world and 4k leads to unnoticable read amplification for >> the worst case. More compression algorithms and cluster sizes >> could be added later, which depends on the real requirement. >> >> More informations about erofs itself are available at: >> Documentation/filesystems/erofs.txt >> >> https://kccncosschn19eng.sched.com/event/Nru2/erofs-an-introduction-and-our-smartphone-practice-xiang-gao-huawei >> >> erofs-utils (mainly mkfs.erofs now) is available at >> git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git >> >> Preliminary iomap support has been pending in erofs mailing >> list by Chao Yu. The key issue is that current iomap doesn't >> support tail-end packing inline data yet, it should be >> resolved later. >> >> Thanks to many contributors in the last year, the code is more >> clean and improved. We hope erofs can be used in wider use cases >> so let's promote erofs out of staging and enhance it more actively. >> >> Share comments about erofs! We think erofs is useful to >> community as a part of Linux upstream :) > > I don't know if this format is easy for the linux-fsdevel people to > review, it forces them to look at the in-kernel code, which makes it > hard to quote. > > Perhaps just make a patch that adds the filesystem to the tree and after > it makes it through review, I can delete the staging version? We've > been doing that for wifi drivers that move out of staging as it seems to > be a bit easier. OK, I will resend the whole patchset later as you suggested, but it will lack of information about some original authors and I'd like to know who is responsible to merge this kind of request to Linux upstream... maybe Linus? And it could be more consistent to leave staging version for linux-5.3 because we still use it, but anyway, I will do it now. Thanks, Gao Xiang > > thanks, > > greg k-h > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: promote erofs from staging
On Thu, Jul 04, 2019 at 10:00:53PM +0800, Gao Xiang wrote: > Hi Greg, > > On 2019/7/4 21:50, Greg Kroah-Hartman wrote: > > On Thu, Jul 04, 2019 at 09:34:13PM +0800, Gao Xiang wrote: > >> EROFS file system has been in Linux-staging for about a year. > >> It has been proved to be stable enough to move out of staging > >> by 10+ millions of HUAWEI Android mobile phones on the market > >> from EMUI 9.0.1, and it was promoted as one of the key features > >> of EMUI 9.1 [1], including P30(pro). > >> > >> EROFS is a read-only file system designed to save extra storage > >> space with guaranteed end-to-end performance by applying > >> fixed-size output compression, inplace I/O and decompression > >> inplace technologies [2] to Linux filesystem. > >> > >> In our observation, EROFS is one of the fastest Linux compression > >> filesystem using buffered I/O in the world. It will support > >> direct I/O in the future if needed. EROFS even has better read > >> performance in a large CR range compared with generic uncompressed > >> file systems with proper CPU-storage combination, which is > >> a reason why erofs can be landed to speed up mobile phone > >> performance, and which can be probably used for other use cases > >> such as LiveCD and Docker image as well. > >> > >> Currently erofs supports 4k LZ4 fixed-size output compression > >> since LZ4 is the fastest widely-used decompression solution in > >> the world and 4k leads to unnoticable read amplification for > >> the worst case. More compression algorithms and cluster sizes > >> could be added later, which depends on the real requirement. > >> > >> More informations about erofs itself are available at: > >> Documentation/filesystems/erofs.txt > >> > >> https://kccncosschn19eng.sched.com/event/Nru2/erofs-an-introduction-and-our-smartphone-practice-xiang-gao-huawei > >> > >> erofs-utils (mainly mkfs.erofs now) is available at > >> git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git > >> > >> Preliminary iomap support has been pending in erofs mailing > >> list by Chao Yu. The key issue is that current iomap doesn't > >> support tail-end packing inline data yet, it should be > >> resolved later. > >> > >> Thanks to many contributors in the last year, the code is more > >> clean and improved. We hope erofs can be used in wider use cases > >> so let's promote erofs out of staging and enhance it more actively. > >> > >> Share comments about erofs! We think erofs is useful to > >> community as a part of Linux upstream :) > > > > I don't know if this format is easy for the linux-fsdevel people to > > review, it forces them to look at the in-kernel code, which makes it > > hard to quote. > > > > Perhaps just make a patch that adds the filesystem to the tree and after > > it makes it through review, I can delete the staging version? We've > > been doing that for wifi drivers that move out of staging as it seems to > > be a bit easier. > > OK, I will resend the whole patchset later as you suggested, but it will > lack of information about some original authors and I'd like to know who > is responsible to merge this kind of request to Linux upstream... maybe Linus? I don't know who adds new filesystems to the tree these days. Usually you need to get some acks from the fsdevel developers first, and then it can go directly to Linus in one of the merge windows. > And it could be more consistent to leave staging version for linux-5.3 > because we still use it, but anyway, I will do it now. Yeah, it's too late for 5.3-rc1, so don't worry. I'll not delete anything until it's actually in someone else's tree on its way to Linus. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/7] staging: most: Use spinlock_t instead of struct spinlock
For spinlocks the type spinlock_t should be used instead of "struct
spinlock".
Use spinlock_t for spinlock's definition.
Cc: Greg Kroah-Hartman
Cc: Christian Gromm
Cc: de...@driverdev.osuosl.org
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/staging/most/net/net.c | 3 +--
drivers/staging/most/video/video.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/most/net/net.c b/drivers/staging/most/net/net.c
index c8a64e2090273..09b604df45e63 100644
--- a/drivers/staging/most/net/net.c
+++ b/drivers/staging/most/net/net.c
@@ -69,7 +69,7 @@ struct net_dev_context {
static struct list_head net_devices = LIST_HEAD_INIT(net_devices);
static struct mutex probe_disc_mt; /* ch->linked = true, most_nd_open */
-static struct spinlock list_lock; /* list_head, ch->linked = false, dev_hold */
+static DEFINE_SPINLOCK(list_lock); /* list_head, ch->linked = false, dev_hold
*/
static struct core_component comp;
static int skb_to_mamac(const struct sk_buff *skb, struct mbo *mbo)
@@ -507,7 +507,6 @@ static struct core_component comp = {
static int __init most_net_init(void)
{
- spin_lock_init(&list_lock);
mutex_init(&probe_disc_mt);
return most_register_component(&comp);
}
diff --git a/drivers/staging/most/video/video.c
b/drivers/staging/most/video/video.c
index adca250062e1b..fcd9e111e8bd0 100644
--- a/drivers/staging/most/video/video.c
+++ b/drivers/staging/most/video/video.c
@@ -54,7 +54,7 @@ struct comp_fh {
};
static struct list_head video_devices = LIST_HEAD_INIT(video_devices);
-static struct spinlock list_lock;
+static DEFINE_SPINLOCK(list_lock);
static inline bool data_ready(struct most_video_dev *mdev)
{
@@ -540,7 +540,6 @@ static struct core_component comp = {
static int __init comp_init(void)
{
- spin_lock_init(&list_lock);
return most_register_component(&comp);
}
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: remove redundant assignment to variable is_empty
On Thu, Jul 04, 2019 at 02:30:31PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable is_empty is being initialized with a value that is never
> read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> drivers/staging/greybus/audio_manager.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/greybus/audio_manager.c
> b/drivers/staging/greybus/audio_manager.c
> index c2a4af4c1d06..9b19ea9d3fa1 100644
> --- a/drivers/staging/greybus/audio_manager.c
> +++ b/drivers/staging/greybus/audio_manager.c
> @@ -86,7 +86,7 @@ EXPORT_SYMBOL_GPL(gb_audio_manager_remove);
> void gb_audio_manager_remove_all(void)
> {
> struct gb_audio_manager_module *module, *next;
> - int is_empty = 1;
> + int is_empty;
>
> down_write(&modules_rwsem);
Reviewed-by: Mark Greer
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: remove redundant assignment to variable is_empty
On Thu, Jul 4, 2019 at 7:00 PM Colin King wrote:
>
> From: Colin Ian King
>
> The variable is_empty is being initialized with a value that is never
> read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> drivers/staging/greybus/audio_manager.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/greybus/audio_manager.c
> b/drivers/staging/greybus/audio_manager.c
> index c2a4af4c1d06..9b19ea9d3fa1 100644
> --- a/drivers/staging/greybus/audio_manager.c
> +++ b/drivers/staging/greybus/audio_manager.c
> @@ -86,7 +86,7 @@ EXPORT_SYMBOL_GPL(gb_audio_manager_remove);
> void gb_audio_manager_remove_all(void)
> {
> struct gb_audio_manager_module *module, *next;
> - int is_empty = 1;
> + int is_empty;
>
> down_write(&modules_rwsem);
>
> --
> 2.20.1
>
Reviewed-by: Vaibhav Agarwal
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: promote erofs from staging
On 2019/7/4 10:18, Greg Kroah-Hartman wrote: > On Thu, Jul 04, 2019 at 10:00:53PM +0800, Gao Xiang wrote: >> Hi Greg, >> >> On 2019/7/4 21:50, Greg Kroah-Hartman wrote: >>> On Thu, Jul 04, 2019 at 09:34:13PM +0800, Gao Xiang wrote: EROFS file system has been in Linux-staging for about a year. It has been proved to be stable enough to move out of staging by 10+ millions of HUAWEI Android mobile phones on the market from EMUI 9.0.1, and it was promoted as one of the key features of EMUI 9.1 [1], including P30(pro). EROFS is a read-only file system designed to save extra storage space with guaranteed end-to-end performance by applying fixed-size output compression, inplace I/O and decompression inplace technologies [2] to Linux filesystem. In our observation, EROFS is one of the fastest Linux compression filesystem using buffered I/O in the world. It will support direct I/O in the future if needed. EROFS even has better read performance in a large CR range compared with generic uncompressed file systems with proper CPU-storage combination, which is a reason why erofs can be landed to speed up mobile phone performance, and which can be probably used for other use cases such as LiveCD and Docker image as well. Currently erofs supports 4k LZ4 fixed-size output compression since LZ4 is the fastest widely-used decompression solution in the world and 4k leads to unnoticable read amplification for the worst case. More compression algorithms and cluster sizes could be added later, which depends on the real requirement. More informations about erofs itself are available at: Documentation/filesystems/erofs.txt https://kccncosschn19eng.sched.com/event/Nru2/erofs-an-introduction-and-our-smartphone-practice-xiang-gao-huawei erofs-utils (mainly mkfs.erofs now) is available at git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git Preliminary iomap support has been pending in erofs mailing list by Chao Yu. The key issue is that current iomap doesn't support tail-end packing inline data yet, it should be resolved later. Thanks to many contributors in the last year, the code is more clean and improved. We hope erofs can be used in wider use cases so let's promote erofs out of staging and enhance it more actively. Share comments about erofs! We think erofs is useful to community as a part of Linux upstream :) >>> >>> I don't know if this format is easy for the linux-fsdevel people to >>> review, it forces them to look at the in-kernel code, which makes it >>> hard to quote. >>> >>> Perhaps just make a patch that adds the filesystem to the tree and after >>> it makes it through review, I can delete the staging version? We've >>> been doing that for wifi drivers that move out of staging as it seems to >>> be a bit easier. >> >> OK, I will resend the whole patchset later as you suggested, but it will >> lack of information about some original authors and I'd like to know who >> is responsible to merge this kind of request to Linux upstream... maybe >> Linus? > > I don't know who adds new filesystems to the tree these days. Usually > you need to get some acks from the fsdevel developers first, and then it > can go directly to Linus in one of the merge windows. Hope that fs guys could eventually take some glances / time on erofs since it's more useful than romfs/cramfs/squashfs for read-only performance scenario since storage space is not tight and slow than 10 years before, even for some embedded devices such as mobile phones/pads. and compression file system could not be designed for saving storage space only like these... I think except for unzip_vle.c (which works fine, but not very cleaned as other files), erofs is clean enough for reviewing... > >> And it could be more consistent to leave staging version for linux-5.3 >> because we still use it, but anyway, I will do it now. > > Yeah, it's too late for 5.3-rc1, so don't worry. I'll not delete > anything until it's actually in someone else's tree on its way to Linus. Sound great, I will tidy the whole patchset up and hope it eventually be ok... Thanks, Gao Xiang > > thanks, > > greg k-h > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup 185/194] drivers/iommu/omap-iommu-debug.c:253:45: error: 'attrregs_fops' undeclared; did you mean 'regs_fops'?
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: bf7e05dc3cda0560cd7addb1b5e2ee85ef1b0650
commit: 94fdb9bf360a34742797679406ff310981663ec0 [185/194] omap-iommu: no need
to check return value of debugfs_create functions
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 94fdb9bf360a34742797679406ff310981663ec0
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/iommu/omap-iommu-debug.c: In function 'omap_iommu_debugfs_add':
>> drivers/iommu/omap-iommu-debug.c:253:45: error: 'attrregs_fops' undeclared
>> (first use in this function); did you mean 'regs_fops'?
debugfs_create_file("regs", 0400, d, obj, &attrregs_fops);
^
regs_fops
drivers/iommu/omap-iommu-debug.c:253:45: note: each undeclared identifier is
reported only once for each function it appears in
>> drivers/iommu/omap-iommu-debug.c:254:44: error: 'attrtlb_fops' undeclared
>> (first use in this function); did you mean 'attrregs_fops'?
debugfs_create_file("tlb", 0400, d, obj, &attrtlb_fops);
^~~~
attrregs_fops
>> drivers/iommu/omap-iommu-debug.c:255:50: error: 'attrpagetable_fops'
>> undeclared (first use in this function); did you mean 'pagetable_fops'?
debugfs_create_file("pagetable", 0400, d, obj, &attrpagetable_fops);
^~
pagetable_fops
vim +253 drivers/iommu/omap-iommu-debug.c
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: bcm2048: Macros with complex values should be enclosed in parentheses
Hi Lukas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[cannot apply to v5.2-rc7 next-20190704]
[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/Lukas-Schneider/media-bcm2048-Macros-with-complex-values-should-be-enclosed-in-parentheses/20190628-003532
base: git://linuxtv.org/media_tree.git master
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-6) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2004:1: error: expected
>> identifier or '(' before 'do'
do { \
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2033:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(power_state, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2033:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(power_state, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2034:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(mute, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2035:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2036:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2038:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2039:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2040:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2041:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2042:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned int, "%u", 0)
^
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2007:3: error: expected
>> identifier or '(' before 'while'
} while (0)\
^
drivers/staging/media/bcm2048/radio-bcm2048.c:2043:1: note: in expansion of
macro 'DEFINE_SYSFS_PROPERTY'
[OSSNA] Intro to kernel hacking tutorial
Hi, I am doing a tutorial at OSSNA in San Diego on getting into kernel hacking. I'm only a couple of years deep into kernel hacking so I wanted to reach out to those more experienced than myself (and those less experienced). Is there any thing that you would really like to see covered in this tutorial? If you are a grey beard is there anything that you have been lamenting us newbies not knowing/doing? If you are a newbie is there anything that you are struggling with that you really want to learn? Current format/content: the tutorial will attempt to bridge the gap in the learning process between the 'first patch' page on kernelnewbies.org wiki and being 'comfortable' patching the kernel via LKML. Outcome will (hopefully) be a small patch set into drivers/staging/. (Don't worry Greg only one group got to this stage last time, you won't get flooded with patches :) Thanks, Tobin. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Fri, Jul 5, 2019 at 8:21 AM Tobin C. Harding wrote: > > Hi, > > I am doing a tutorial at OSSNA in San Diego on getting into kernel > hacking. I'm only a couple of years deep into kernel hacking so I > wanted to reach out to those more experienced than myself (and those > less experienced). > > Is there any thing that you would really like to see covered in this > tutorial? > > If you are a grey beard is there anything that you have been lamenting > us newbies not knowing/doing? > > If you are a newbie is there anything that you are struggling with that > you really want to learn? Thank you. Where can I find your tutorial? Regards, Amit Kumar > Current format/content: the tutorial will attempt to bridge the gap in > the learning process between the 'first patch' page on kernelnewbies.org > wiki and being 'comfortable' patching the kernel via LKML. Outcome will > (hopefully) be a small patch set into drivers/staging/. (Don't worry > Greg only one group got to this stage last time, you won't get flooded > with patches :) > > Thanks, > Tobin. > > ___ > Kernelnewbies mailing list > kernelnewb...@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Urgent Please
Hi, Please confirm to Mr. Fred Anderson, call his direct telephone number +447424632241 if you received my last email, so further details can be advised. Best Regards, Mrs. Catherine Mullen ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Fri, Jul 5, 2019 at 9:02 AM Amit Kumar wrote: > > On Fri, Jul 5, 2019 at 8:21 AM Tobin C. Harding wrote: > > > > Hi, > > > > I am doing a tutorial at OSSNA in San Diego on getting into kernel > > hacking. I'm only a couple of years deep into kernel hacking so I > > wanted to reach out to those more experienced than myself (and those > > less experienced). > > > > Is there any thing that you would really like to see covered in this > > tutorial? > > > > If you are a grey beard is there anything that you have been lamenting > > us newbies not knowing/doing? > > > > If you are a newbie is there anything that you are struggling with that > > you really want to learn? > Thank you. > Where can I find your tutorial? I forget to tell, merely creating and sending patches is not important. Also I would like to know how to manage patches, using git, mutt, quilt and so on. Sending patch through git-email is good. But different versions of patch. Applying patch from mutt. Replying to patch recipients. > Regards, > Amit Kumar > > > Current format/content: the tutorial will attempt to bridge the gap in > > the learning process between the 'first patch' page on kernelnewbies.org > > wiki and being 'comfortable' patching the kernel via LKML. Outcome will > > (hopefully) be a small patch set into drivers/staging/. (Don't worry > > Greg only one group got to this stage last time, you won't get flooded > > with patches :) > > > > Thanks, > > Tobin. > > > > ___ > > Kernelnewbies mailing list > > kernelnewb...@kernelnewbies.org > > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: media: davinci_vpfe: Replace function vpfe_isif_cleanup()
Rename function isif_remove to vpfe_isif_cleanup, as
vpfe_isif_cleanup does nothing but call isif_remove.
Change type of new vpfe_isif_cleanup from static to non-static to match
the old function definition.
Remove the original vpfe_isif_cleanup.
Modify calls to isif_remove to vpfe_isif_cleanup.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
.../staging/media/davinci_vpfe/dm365_isif.c | 21 +++
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_isif.c
b/drivers/staging/media/davinci_vpfe/dm365_isif.c
index 46fd8184fc77..c21106a5dc7b 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_isif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_isif.c
@@ -1932,8 +1932,13 @@ static const struct v4l2_ctrl_config
vpfe_isif_gain_offset = {
.def = 0,
};
-static void isif_remove(struct vpfe_isif_device *isif,
- struct platform_device *pdev)
+/*
+ * vpfe_isif_cleanup - isif module cleanup
+ * @isif: pointer to isif subdevice
+ * @dev: pointer to platform device structure
+ */
+void vpfe_isif_cleanup(struct vpfe_isif_device *isif,
+ struct platform_device *pdev)
{
struct resource *res;
int i = 0;
@@ -2081,17 +2086,7 @@ int vpfe_isif_init(struct vpfe_isif_device *isif, struct
platform_device *pdev)
return status;
isif_fail:
v4l2_ctrl_handler_free(&isif->ctrls);
- isif_remove(isif, pdev);
+ vpfe_isif_cleanup(isif, pdev);
return status;
}
-/*
- * vpfe_isif_cleanup - isif module cleanup
- * @isif: pointer to isif subdevice
- * @dev: pointer to platform device structure
- */
-void
-vpfe_isif_cleanup(struct vpfe_isif_device *isif, struct platform_device *pdev)
-{
- isif_remove(isif, pdev);
-}
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
