[PATCH] staging: greybus: fix fw is NULL but dereferenced.
Fix the warning reported by cocci check. Changes: In queue_work fw dereference before it actually get assigned. move queue_work before gb_bootrom_set_timeout. As gb_bootrom_get_firmware () return NEXT_REQ_READY_TO_BOOT only when there is no error and offset + size is actually equal to fw->size. So initialized next_request to NEXT_REQ_GET_FIRMWARE for return in other case. Signed-off-by: Saurav Girepunje --- drivers/staging/greybus/bootrom.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/greybus/bootrom.c b/drivers/staging/greybus/bootrom.c index a8efb86..f54514e 100644 --- a/drivers/staging/greybus/bootrom.c +++ b/drivers/staging/greybus/bootrom.c @@ -246,7 +246,7 @@ static int gb_bootrom_get_firmware(struct gb_operation *op) struct gb_bootrom_get_firmware_response *firmware_response; struct device *dev = &op->connection->bundle->dev; unsigned int offset, size; - enum next_request_type next_request; + enum next_request_type next_request = NEXT_REQ_GET_FIRMWARE; int ret = 0; /* Disable timeouts */ @@ -296,13 +296,11 @@ static int gb_bootrom_get_firmware(struct gb_operation *op) unlock: mutex_unlock(&bootrom->mutex); -queue_work: /* Refresh timeout */ if (!ret && (offset + size == fw->size)) next_request = NEXT_REQ_READY_TO_BOOT; - else - next_request = NEXT_REQ_GET_FIRMWARE; +queue_work: gb_bootrom_set_timeout(bootrom, next_request, NEXT_REQ_TIMEOUT_MS); return ret; -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: binderfs interferes with syzkaller?
On Sat, Jan 25, 2020 at 06:49:49PM +0100, Dmitry Vyukov wrote: > Hi binder maintainers, > > It seems that something has happened and now syzbot has 0 coverage in > drivers/android/binder.c: > https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html > It covered at least something there before as it found some bugs in binder > code. > I _suspect_ it may be related to introduction binderfs, but it's > purely based on the fact that binderfs changed lots of things there. > And I see it claims to be backward compatible. It is backwards compatible if you mount binderfs, right? > syzkaller strategy to reach binder devices is to use > CONFIG_ANDROID_BINDER_DEVICES to create a bunch of binderN devices (to > give each test process a private one): > https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-kasan.config#L5671 > > Then it knows how to open these /dev/binderN devices: > https://github.com/google/syzkaller/blob/master/sys/linux/dev_binder.txt#L22 > and do stuff with them. > > Did these devices disappear or something? Try mounting binderfs and then you should be able to see them all. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: binderfs interferes with syzkaller?
On Sun, Jan 26, 2020 at 09:55:35AM +0100, Greg Kroah-Hartman wrote: > On Sat, Jan 25, 2020 at 06:49:49PM +0100, Dmitry Vyukov wrote: > > Hi binder maintainers, > > > > It seems that something has happened and now syzbot has 0 coverage in > > drivers/android/binder.c: > > https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html > > It covered at least something there before as it found some bugs in binder > > code. > > I _suspect_ it may be related to introduction binderfs, but it's > > purely based on the fact that binderfs changed lots of things there. > > And I see it claims to be backward compatible. > > It is backwards compatible if you mount binderfs, right? Yes, it is backwards compatible. The devices that would usually be created in devtmpfs are now created in binderfs. The core binder-codepaths are the same. Christian ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: binderfs interferes with syzkaller?
On Sat, Jan 25, 2020 at 07:13:03PM +0100, Dmitry Vyukov wrote: > On Sat, Jan 25, 2020 at 6:49 PM Dmitry Vyukov wrote: > > > > Hi binder maintainers, > > > > It seems that something has happened and now syzbot has 0 coverage in > > drivers/android/binder.c: > > https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html > > It covered at least something there before as it found some bugs in binder > > code. > > I _suspect_ it may be related to introduction binderfs, but it's > > purely based on the fact that binderfs changed lots of things there. > > And I see it claims to be backward compatible. > > > > syzkaller strategy to reach binder devices is to use > > CONFIG_ANDROID_BINDER_DEVICES to create a bunch of binderN devices (to > > give each test process a private one): > > https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-kasan.config#L5671 > > > > Then it knows how to open these /dev/binderN devices: > > https://github.com/google/syzkaller/blob/master/sys/linux/dev_binder.txt#L22 > > and do stuff with them. > > > > Did these devices disappear or something? > > Oh, I see, it's backwards compatible if it's not enabled, right? It's backwards compatible. Let me give a little more detail. The legacy binder interface would create all devices listed in the module parameter CONFIG_ANDROID_BINDER_DEVICES. These devices were created using misc_register(&binder_device->miscdev); in the host's devtmpfs mount. If binderfs is enabled these devices are now created in the binderfs instance instead. For full backwards compatibility with old Android versions symlinks (or bind mounts) can be provided in the host's devtmpfs. This is what I recommended a few months ago. > And we enabled it because, well, enabling things generally gives more > coverage. I guess I will disable CONFIG_ANDROID_BINDERFS for now to I would at least try to test both somehow. It's likely that binderfs will replace legacy binder devices so if we could keep testing it somehow that would be great. > restore coverage in the binder itself. I'm not completely sure what you mean here. The binder IPC codepaths are nearly the same. The difference is mostly in how the device information is cast out before actual binder-ipc operations take place. In any case, testing both would obviously be preferred but binderfs strikes me as more worthy of testing. Christian ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RESEND PATCH] staging: exfat: Fix alignment warnings
Fix checkpatch warning "Alignment should match open parenthesis".
Signed-off-by: Pragat Pandya
---
drivers/staging/exfat/exfat_blkdev.c | 4 ++--
drivers/staging/exfat/exfat_core.c | 29 ++--
drivers/staging/exfat/exfat_super.c | 2 +-
3 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/exfat/exfat_blkdev.c
b/drivers/staging/exfat/exfat_blkdev.c
index 7bcd98b13109..3068bfda39e4 100644
--- a/drivers/staging/exfat/exfat_blkdev.c
+++ b/drivers/staging/exfat/exfat_blkdev.c
@@ -31,7 +31,7 @@ void exfat_bdev_close(struct super_block *sb)
}
int exfat_bdev_read(struct super_block *sb, sector_t secno, struct buffer_head
**bh,
- u32 num_secs, bool read)
+ u32 num_secs, bool read)
{
struct bd_info_t *p_bd = &(EXFAT_SB(sb)->bd_info);
struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
@@ -66,7 +66,7 @@ int exfat_bdev_read(struct super_block *sb, sector_t secno,
struct buffer_head *
}
int exfat_bdev_write(struct super_block *sb, sector_t secno, struct
buffer_head *bh,
- u32 num_secs, bool sync)
+u32 num_secs, bool sync)
{
s32 count;
struct buffer_head *bh2;
diff --git a/drivers/staging/exfat/exfat_core.c
b/drivers/staging/exfat/exfat_core.c
index 794000e7bc6f..754407c738b7 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -250,7 +250,7 @@ static u32 test_alloc_bitmap(struct super_block *sb, u32
clu)
}
static s32 exfat_alloc_cluster(struct super_block *sb, s32 num_alloc,
- struct chain_t *p_chain)
+ struct chain_t *p_chain)
{
s32 num_clusters = 0;
u32 hint_clu, new_clu, last_clu = CLUSTER_32(~0);
@@ -329,7 +329,7 @@ static s32 exfat_alloc_cluster(struct super_block *sb, s32
num_alloc,
}
static void exfat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
- s32 do_relse)
+ s32 do_relse)
{
s32 num_clusters = 0;
u32 clu;
@@ -920,7 +920,7 @@ static void exfat_set_entry_size(struct dentry_t *p_entry,
u64 size)
}
static void exfat_get_entry_time(struct dentry_t *p_entry, struct timestamp_t
*tp,
- u8 mode)
+u8 mode)
{
u16 t = 0x00, d = 0x21;
struct file_dentry_t *ep = (struct file_dentry_t *)p_entry;
@@ -949,7 +949,7 @@ static void exfat_get_entry_time(struct dentry_t *p_entry,
struct timestamp_t *t
}
static void exfat_set_entry_time(struct dentry_t *p_entry, struct timestamp_t
*tp,
- u8 mode)
+u8 mode)
{
u16 t, d;
struct file_dentry_t *ep = (struct file_dentry_t *)p_entry;
@@ -1013,7 +1013,7 @@ static void init_name_entry(struct name_dentry_t *ep, u16
*uniname)
}
static s32 exfat_init_dir_entry(struct super_block *sb, struct chain_t *p_dir,
-s32 entry, u32 type, u32 start_clu, u64 size)
+ s32 entry, u32 type, u32 start_clu, u64 size)
{
sector_t sector;
u8 flags;
@@ -1089,7 +1089,7 @@ static s32 exfat_init_ext_entry(struct super_block *sb,
struct chain_t *p_dir,
}
static void exfat_delete_dir_entry(struct super_block *sb, struct chain_t
*p_dir,
- s32 entry, s32 order, s32 num_entries)
+ s32 entry, s32 order, s32 num_entries)
{
int i;
sector_t sector;
@@ -1256,7 +1256,7 @@ static s32 _walk_fat_chain(struct super_block *sb, struct
chain_t *p_dir,
}
static s32 find_location(struct super_block *sb, struct chain_t *p_dir, s32
entry,
- sector_t *sector, s32 *offset)
+sector_t *sector, s32 *offset)
{
s32 off, ret;
u32 clu = 0;
@@ -1492,7 +1492,8 @@ void release_entry_set(struct entry_set_cache_t *es)
/* search EMPTY CONTINUOUS "num_entries" entries */
static s32 search_deleted_or_unused_entry(struct super_block *sb,
- struct chain_t *p_dir, s32 num_entries)
+ struct chain_t *p_dir,
+ s32 num_entries)
{
int i, dentry, num_empty = 0;
s32 dentries_per_clu;
@@ -1668,7 +1669,7 @@ static s32 find_empty_entry(struct inode *inode, struct
chain_t *p_dir, s32 num_
}
static s32 extract_uni_name_from_name_entry(struct name_dentry_t *ep, u16
*uniname,
-s32 order)
+ s32 order)
{
int i, len = 0;
@@ -1690,8 +1691,8 @@ static s32 extract_uni_name_from_name_entry(struct
name_dentry_t *ep, u16 *unina
* -2 : entry with the name does not exist
*/
static s32 exfat_find_dir_entry(struct super_block *sb, struct chain_t *p_dir,
-struct uni_name_t *p_uniname, s32 num_entr
Re: [PATCH] staging: greybus: fix fw is NULL but dereferenced.
On Sun, Jan 26, 2020 at 02:01:30PM +0530, Saurav Girepunje wrote: > Fix the warning reported by cocci check. > > Changes: > > In queue_work fw dereference before it actually get assigned. > move queue_work before gb_bootrom_set_timeout. Nope. As I said yesterday, you need to verify the output of any static checkers you use. The code may be unnecessarily subtle, but there's no way fw can be dereferenced before being initialised currently. > -queue_work: > /* Refresh timeout */ > if (!ret && (offset + size == fw->size)) Specifically, the second operand is never evaluated if ret is non-zero. > next_request = NEXT_REQ_READY_TO_BOOT; > - else > - next_request = NEXT_REQ_GET_FIRMWARE; > > +queue_work: > gb_bootrom_set_timeout(bootrom, next_request, NEXT_REQ_TIMEOUT_MS); > > return ret; Johan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:driver-core-testing] BUILD INCOMPLETE 85db1cde825344cc1419d3adadaf4187154ad687
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-testing branch HEAD: 85db1cde825344cc1419d3adadaf4187154ad687 firmware: Rename FW_OPT_NOFALLBACK to FW_OPT_NOFALLBACK_SYSFS TIMEOUT after 2898m Sorry we cannot finish the testset for your branch within a reasonable time. It's our fault -- either some build server is down or some build worker is busy doing bisects for _other_ trees. The branch will get more complete coverage and possible error reports when our build infrastructure is restored or catches up. There will be no more build success notification for this branch head, but you can expect reasonably good test coverage after waiting for 1 day. configs timed out: 33 alpha defconfig arm allnoconfig arm allyesconfig arm efm32_defconfig arm exynos_defconfig armmulti_v5_defconfig armmulti_v7_defconfig armshmobile_defconfig arm sunxi_defconfig arm64allmodconfig arm64 allnoconfig arm64allyesconfig arm64 defconfig ia64 allmodconfig ia64 allyesconfig microblaze mmu_defconfig microblazenommu_defconfig mips 32r2_defconfig mips 64r6el_defconfig mips allmodconfig mips allnoconfig mips allyesconfig mips fuloong2e_defconfig mips malta_kvm_defconfig powerpc allnoconfig powerpc defconfig s390 alldefconfig s390 allmodconfig s390 allnoconfig s390 allyesconfig s390 debug_defconfig s390defconfig s390 zfcpdump_defconfig configs tested: 95 configs skipped: 1 ia64 allnoconfig ia64defconfig ia64 alldefconfig x86_64lkp x86_64 rhel x86_64 rhel-7.6 x86_64 fedora-25 x86_64 kexec x86_64 rhel-7.2-clear sh allmodconfig sh rsk7269_defconfig sh sh7785lcr_32bit_defconfig shallnoconfig shtitan_defconfig i386 allnoconfig i386defconfig i386 allyesconfig i386 alldefconfig xtensa common_defconfig openriscor1ksim_defconfig nios2 3c120_defconfig xtensa iss_defconfig c6xevmc6678_defconfig c6x allyesconfig nios2 10m50_defconfig openrisc simple_smp_defconfig x86_64 randconfig-a001-20200125 i386 randconfig-a001-20200125 x86_64 randconfig-a002-20200125 i386 randconfig-a002-20200125 i386 randconfig-a003-20200125 x86_64 randconfig-a003-20200125 arm64randconfig-a001-20200125 powerpc randconfig-a001-20200125 ia64 randconfig-a001-20200125 arm randconfig-a001-20200125 arc randconfig-a001-20200125 sparcrandconfig-a001-20200125 riscv rv32_defconfig riscv allnoconfig riscv defconfig riscvallmodconfig riscvnommu_virt_defconfig riscvallyesconfig sparc64 allmodconfig sparcallyesconfig sparc64 allyesconfig sparc defconfig sparc64 allnoconfig sparc64 defconfig x86_64 randconfig-f003-20200126 x86_64 randconfig-f001-20200126 x86_64 randconfig-f002-20200126 i386 randconfig-f002-20200126 i386 randconfig-f003-20200126 i386 randconfig-f001-20200126 arc allyesconfig powerpc ppc64_defconfig powerpc
[PATCH] staging: bcm2835-audio: fix warning of no space is necessary
This patch fixes "No space is necessary after a cast".
Issue found by checkpatch.pl
Signed-off-by: Valery Ivanov
---
drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
index 33485184a98a..997ce88c67c4 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
@@ -237,7 +237,7 @@ static void snd_bcm2835_pcm_transfer(struct
snd_pcm_substream *substream,
{
struct snd_pcm_runtime *runtime = substream->runtime;
struct bcm2835_alsa_stream *alsa_stream = runtime->private_data;
- void *src = (void *) (substream->runtime->dma_area + rec->sw_data);
+ void *src = (void *)(substream->runtime->dma_area + rec->sw_data);
bcm2835_audio_write(alsa_stream, bytes, src);
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: fix fw is NULL but dereferenced.
On Sun, Jan 26, 2020 at 02:01:30PM +0530, Saurav Girepunje wrote: > Fix the warning reported by cocci check. What is "cocci check"? > Changes: > Why add that line? > In queue_work fw dereference before it actually get assigned. > move queue_work before gb_bootrom_set_timeout. > > As gb_bootrom_get_firmware () return NEXT_REQ_READY_TO_BOOT > only when there is no error and offset + size is actually equal > to fw->size. So initialized next_request to NEXT_REQ_GET_FIRMWARE > for return in other case. > > Signed-off-by: Saurav Girepunje > --- > drivers/staging/greybus/bootrom.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) As Johan said, there are a lot of really bad "static checking" tools out there that can not properly parse C code. Always verify by hand what the tools said is wrong, really is an issue before sending a patch out for something that is not correct. This looks like you need to use a better tool. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH] staging: vc04_services: vchiq_dump_service_use_state can be static
Fixes: fc2dd7f28276 ("staging: vc04_services: get rid of
vchiq_platform_use_suspend_timer()")
Signed-off-by: kbuild test robot
---
vchiq_arm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index a75d5092cc73b..f87818c03cfff 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -2875,7 +2875,7 @@ struct service_data_struct {
int use_count;
};
-void
+static void
vchiq_dump_service_use_state(struct vchiq_state *state)
{
struct vchiq_arm_state *arm_state = vchiq_platform_get_arm_state(state);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 06/22] staging: vc04_services: get rid of vchiq_platform_use_suspend_timer()
Hi Nicolas, I love your patch! Perhaps something to improve: [auto build test WARNING on staging/staging-testing] [also build test WARNING on linux/master linus/master v5.5-rc7 next-20200121] [cannot apply to anholt/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Nicolas-Saenz-Julienne/staging-vc04_services-suspend-resume-cleanup/20200125-193041 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git fc157998b8257fb9cfe753e7f4af1411da995c9b reproduce: # apt-get install sparse # sparse version: v0.6.1-153-g47b6dfef-dirty make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1239:60: sparse: sparse: incorrect type in assignment (different address spaces) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1239:60: sparse:expected struct vchiq_header *header drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1239:60: sparse:got void [noderef] *[addressable] msgbuf drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1508:13: sparse: sparse: incorrect type in assignment (different address spaces) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1508:13: sparse:expected int enum vchiq_status ( *__pu_val )( ... ) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1508:13: sparse:got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1510:13: sparse: sparse: incorrect type in assignment (different address spaces) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1510:13: sparse:expected void *__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1510:13: sparse:got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1636:13: sparse: sparse: incorrect type in assignment (different address spaces) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1636:13: sparse:expected void *__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1636:13: sparse:got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1638:13: sparse: sparse: incorrect type in assignment (different address spaces) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1638:13: sparse:expected void *__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1638:13: sparse:got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1713:13: sparse: sparse: incorrect type in assignment (different address spaces) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1713:13: sparse:expected struct vchiq_completion_data *__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1713:13: sparse:got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1716:13: sparse: sparse: incorrect type in assignment (different address spaces) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1716:13: sparse:expected void **__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1716:13: sparse:got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1763:13: sparse: sparse: incorrect type in assignment (different address spaces) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1763:13: sparse:expected struct vchiq_completion_data *__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1763:13: sparse:got struct vchiq_completion_data [noderef] *[assigned] completion drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1793:59: sparse: sparse: incorrect type in argument 1 (different address spaces) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1793:59: sparse:expected void [noderef] *uptr drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1793:59: sparse:got struct vchiq_header *[addressable] header drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1795:45: sparse: sparse: incorrect type in argument 1 (different address spaces) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1795:45: sparse:expected void [noderef] *uptr drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1795:45: sparse:got void *[addressable] service_userdata drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1797:45: sparse: sparse: incor
[PATCH] staging: rtl8723bs: fix copy of overlapping memory
From: Colin Ian King
Currently the rtw_sprintf prints the contents of thread_name
onto thread_name and this can lead to a potential copy of a
string over itself. Avoid this by printing the literal string RTWHALXT
instread of the contents of thread_name.
Addresses-Coverity: ("copy of overlapping memory")
Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
b/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
index b44e902ed338..890e0ecbeb2e 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
@@ -476,14 +476,13 @@ int rtl8723bs_xmit_thread(void *context)
s32 ret;
struct adapter *padapter;
struct xmit_priv *pxmitpriv;
- u8 thread_name[20] = "RTWHALXT";
-
+ u8 thread_name[20];
ret = _SUCCESS;
padapter = context;
pxmitpriv = &padapter->xmitpriv;
- rtw_sprintf(thread_name, 20, "%s-"ADPT_FMT, thread_name,
ADPT_ARG(padapter));
+ rtw_sprintf(thread_name, 20, "RTWHALXT-" ADPT_FMT, ADPT_ARG(padapter));
thread_enter(thread_name);
DBG_871X("start "FUNC_ADPT_FMT"\n", FUNC_ADPT_ARG(padapter));
--
2.24.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Peter Joe
Dear, Did you receive the message i sent to you? Regards, Peter Joe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: exfat: remove fs_func struct.
Looks good to me. Reviewed-by: Dan Carpenter regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: wilc1000: return zero on success and non-zero on function failure
Looks good.
Reviewed-by: Dan Carpenter
On Thu, Jan 23, 2020 at 12:50:47PM +, ajay.kat...@microchip.com wrote:
> @@ -384,19 +378,18 @@ static int wilc_sdio_write_reg(struct wilc *wilc, u32
> addr, u32 data)
> cmd.address = addr;
> cmd.data = data;
> ret = wilc_sdio_cmd52(wilc, &cmd);
> - if (ret) {
> + if (ret)
> dev_err(&func->dev,
> "Failed cmd 52, read reg (%08x) ...\n", addr);
> - goto fail;
> - }
Please don't resend, but try to avoid this sort of anti-pattern in the
future. You're treating the last failure condition in the function as
special. In this case it's particularly difficult to read because we
are far from the bottom of the function, but even if we were right at
the bottom, I would try to avoid it.
I am extreme enough that I would avoid even things like:
ret = frob();
if (ret)
printf("ret failed\n");
return ret;
Instead I would write:
ret = frob();
if (ret) {
printf("ret failed\n");
return ret;
}
return 0;
It's just nice to have the error path at indent level 2 and the
success path at indent level 1. And the other thing that I like is the
BIG BOLD "return 0;" at the end of the function. Some functions return
positive numbers on success so if I see "return result;" then I have to
look back a few lines to see if "result" can be positive.
The other anti-pattern which people often do is success handling
(instead of error handling) for the last error condition in a function.
ret = one();
if (ret)
return ret;
ret = two();
if (ret)
return ret;
ret = three();
if (!ret)
ret = four();
return ret;
Never never do that. :P
Anyway, don't resend. It's just food for thought.
regards,
dan carpenter
> } else {
> struct sdio_cmd53 cmd;
>
> /**
>* set the AHB address
>**/
> - if (!wilc_sdio_set_func0_csa_address(wilc, addr))
> - goto fail;
> + ret = wilc_sdio_set_func0_csa_address(wilc, addr);
> + if (ret)
> + return ret;
>
> cmd.read_write = 1;
> cmd.function = 0;
> @@ -407,18 +400,12 @@ static int wilc_sdio_write_reg(struct wilc *wilc, u32
> addr, u32 data)
> cmd.buffer = (u8 *)&data;
> cmd.block_size = sdio_priv->block_size;
> ret = wilc_sdio_cmd53(wilc, &cmd);
> - if (ret) {
> + if (ret)
> dev_err(&func->dev,
> "Failed cmd53, write reg (%08x)...\n", addr);
> - goto fail;
> - }
> }
>
> - return 1;
> -
> -fail:
> -
> - return 0;
> + return ret;
> }
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
