[PATCH 2/2] staging: rtl8192u: Renames variables in setKey function
Renames the local variables of the setKey
function, making them explicit.
Signed-off-by: Camylla Goncalves Cantanheide
---
drivers/staging/rtl8192u/r8192U_core.c | 48 +-
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 87c02aee3854..cc02c3b1eb91 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4877,48 +4877,48 @@ void EnableHWSecurityConfig8192(struct net_device *dev)
write_nic_byte(dev, SECR, SECR_value);
}
-void setKey(struct net_device *dev, u8 entryno, u8 keyindex, u16 keytype,
- u8 *macaddr, u8 defaultkey, u32 *keycontent)
+void setKey(struct net_device *dev, u8 entry_no, u8 key_idx, u16 key_type,
+ u8 *mac_addr, u8 default_key, u32 *key_content)
{
- u32 target_command = CAM_CONTENT_COUNT * entryno | BIT(31) | BIT(16);
- u32 target_content = 0;
- u16 us_config = 0;
+ u32 cmd = CAM_CONTENT_COUNT * entry_no | BIT(31) | BIT(16);
+ u32 content = 0;
+ u16 config = 0;
u8 i;
- if (entryno >= TOTAL_CAM_ENTRY)
+ if (entry_no >= TOTAL_CAM_ENTRY)
RT_TRACE(COMP_ERR, "cam entry exceeds in %s\n", __func__);
RT_TRACE(COMP_SEC,
">to %s, dev:%p, EntryNo:%d, KeyIndex:%d, KeyType:%d,
MacAddr%pM\n",
-__func__, dev, entryno, keyindex, keytype, macaddr);
+__func__, dev, entry_no, key_idx, key_type, mac_addr);
- if (defaultkey)
- us_config |= BIT(15) | (keytype << 2);
+ if (default_key)
+ config |= BIT(15) | (key_type << 2);
else
- us_config |= BIT(15) | (keytype << 2) | keyindex;
+ config |= BIT(15) | (key_type << 2) | key_idx;
- target_content = macaddr[0] << 16 |
-macaddr[0] << 24 |
- (u32)us_config;
+ content = mac_addr[0] << 16 |
+ mac_addr[0] << 24 |
+(u32)config;
- write_nic_dword(dev, WCAMI, target_content);
- write_nic_dword(dev, RWCAM, target_command++);
+ write_nic_dword(dev, WCAMI, content);
+ write_nic_dword(dev, RWCAM, cmd++);
/* MAC */
- target_content = macaddr[2] |
-macaddr[3] << 8 |
-macaddr[4] << 16 |
-macaddr[5] << 24;
- write_nic_dword(dev, WCAMI, target_content);
- write_nic_dword(dev, RWCAM, target_command++);
+ content = mac_addr[2] |
+ mac_addr[3] << 8 |
+ mac_addr[4] << 16 |
+ mac_addr[5] << 24;
+ write_nic_dword(dev, WCAMI, content);
+ write_nic_dword(dev, RWCAM, cmd++);
/* Key Material */
- if (!keycontent)
+ if (!key_content)
return;
for (i = 2; i < CAM_CONTENT_COUNT; i++) {
- write_nic_dword(dev, WCAMI, *keycontent++);
- write_nic_dword(dev, RWCAM, target_command++);
+ write_nic_dword(dev, WCAMI, *key_content++);
+ write_nic_dword(dev, RWCAM, cmd++);
}
}
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: rtl8192u: Refactoring setKey function
Changes of the local variable value and
modification in the seletive repetition structure.
Signed-off-by: Camylla Goncalves Cantanheide
---
drivers/staging/rtl8192u/r8192U_core.c | 52 --
1 file changed, 24 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 9b8d85a4855d..87c02aee3854 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4880,7 +4880,7 @@ void EnableHWSecurityConfig8192(struct net_device *dev)
void setKey(struct net_device *dev, u8 entryno, u8 keyindex, u16 keytype,
u8 *macaddr, u8 defaultkey, u32 *keycontent)
{
- u32 target_command = 0;
+ u32 target_command = CAM_CONTENT_COUNT * entryno | BIT(31) | BIT(16);
u32 target_content = 0;
u16 us_config = 0;
u8 i;
@@ -4890,39 +4890,35 @@ void setKey(struct net_device *dev, u8 entryno, u8
keyindex, u16 keytype,
RT_TRACE(COMP_SEC,
">to %s, dev:%p, EntryNo:%d, KeyIndex:%d, KeyType:%d,
MacAddr%pM\n",
-__func__, dev, entryno, keyindex, keytype, macaddr);
+__func__, dev, entryno, keyindex, keytype, macaddr);
if (defaultkey)
us_config |= BIT(15) | (keytype << 2);
else
us_config |= BIT(15) | (keytype << 2) | keyindex;
- for (i = 0; i < CAM_CONTENT_COUNT; i++) {
- target_command = i + CAM_CONTENT_COUNT * entryno;
- target_command |= BIT(31) | BIT(16);
-
- if (i == 0) { /* MAC|Config */
- target_content = (u32)(*(macaddr + 0)) << 16 |
- (u32)(*(macaddr + 1)) << 24 |
- (u32)us_config;
-
- write_nic_dword(dev, WCAMI, target_content);
- write_nic_dword(dev, RWCAM, target_command);
- } else if (i == 1) { /* MAC */
- target_content = (u32)(*(macaddr + 2)) |
- (u32)(*(macaddr + 3)) << 8 |
- (u32)(*(macaddr + 4)) << 16 |
- (u32)(*(macaddr + 5)) << 24;
- write_nic_dword(dev, WCAMI, target_content);
- write_nic_dword(dev, RWCAM, target_command);
- } else {
- /* Key Material */
- if (keycontent) {
- write_nic_dword(dev, WCAMI,
- *(keycontent + i - 2));
- write_nic_dword(dev, RWCAM, target_command);
- }
- }
+ target_content = macaddr[0] << 16 |
+macaddr[0] << 24 |
+ (u32)us_config;
+
+ write_nic_dword(dev, WCAMI, target_content);
+ write_nic_dword(dev, RWCAM, target_command++);
+
+ /* MAC */
+ target_content = macaddr[2] |
+macaddr[3] << 8 |
+macaddr[4] << 16 |
+macaddr[5] << 24;
+ write_nic_dword(dev, WCAMI, target_content);
+ write_nic_dword(dev, RWCAM, target_command++);
+
+ /* Key Material */
+ if (!keycontent)
+ return;
+
+ for (i = 2; i < CAM_CONTENT_COUNT; i++) {
+ write_nic_dword(dev, WCAMI, *keycontent++);
+ write_nic_dword(dev, RWCAM, target_command++);
}
}
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] media: staging: ipu3: Fix stale list entries on parameter queue failure
Hi, Tomasz, Thanks for your patch. BRs, Bingbu Cao > -Original Message- > From: Tomasz Figa > Sent: Sunday, April 12, 2020 1:37 AM > To: linux-me...@vger.kernel.org > Cc: Sakari Ailus ; Mauro Carvalho Chehab > ; Greg Kroah-Hartman ; Qiu, > Tian Shu ; Cao, Bingbu ; > de...@driverdev.osuosl.org; linux-ker...@vger.kernel.org; Laurent Pinchart > ; jacopo mondi ; > Tomasz Figa > Subject: [PATCH] media: staging: ipu3: Fix stale list entries on parameter > queue failure > > When queuing parameters fails, current code bails out without deleting the > corresponding vb2 buffer from the driver buffer list, but the buffer is > returned to vb2. This leads to stale list entries and a crash when the > driver stops streaming: > > [ 224.935561] ipu3-imgu :00:05.0: set parameters failed. > [ 224.998932] ipu3-imgu :00:05.0: set parameters failed. > [ 225.064430] ipu3-imgu :00:05.0: set parameters failed. > [ 225.128534] ipu3-imgu :00:05.0: set parameters failed. > [ 225.194945] ipu3-imgu :00:05.0: set parameters failed. > [ 225.360363] [ cut here ] [ 225.360372] WARNING: > CPU: 0 PID: 6704 at > drivers/media/common/videobuf2/videobuf2-core.c:927 > vb2_buffer_done+0x20f/0x21a [videobuf2_common] [ 225.360374] Modules linked > in: snd_seq_dummy snd_seq snd_seq_device veth bridge stp llc tun nf_nat_tftp > nf_conntrack_tftp nf_nat_ftp nf_conntrack_ftp esp6 ah6 ip6t_REJECT > ip6t_ipv6header cmac rfcomm uinput > ipu3_imgu(C) ipu3_cio2 iova videobuf2_v4l2 videobuf2_common videobuf2_dma_sg > videobuf2_memops ov13858 ov5670 v4l2_fwnode dw9714 acpi_als xt_MASQUERADE > fuse iio_trig_sysfs cros_ec_sensors_ring cros_ec_light_prox cros_ec_sensors > cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf industrialio > cros_ec_sensorsupport cdc_ether btusb btrtl btintel btbcm usbnet bluetooth > ecdh_generic ecc hid_google_hammer iwlmvm iwl7000_mac80211 > r8152 mii lzo_rle lzo_compress iwlwifi zram cfg80211 joydev [ 225.360400] > CPU: 0 PID: 6704 Comm: CameraDeviceOps Tainted: G > C5.4.30 #5 > [ 225.360402] Hardware name: HP Soraka/Soraka, BIOS > Google_Soraka.10431.106.0 12/03/2019 > [ 225.360405] RIP: 0010:vb2_buffer_done+0x20f/0x21a [videobuf2_common] > [ 225.360408] Code: 5e 41 5f 5d e9 e0 16 5a d4 41 8b 55 08 48 c7 c7 8f 8b > 5c c0 48 c7 c6 36 9a 5c c0 44 89 f9 31 c0 e8 a5 1c 5b d4 e9 53 fe ff ff <0f> > 0b eb a3 e8 12 d7 43 d4 eb 97 0f 1f 44 00 00 55 48 89 e5 41 56 [ 225.360410] > RSP: 0018:9468ab32fba8 EFLAGS: 00010297 [ 225.360412] RAX: > 8aa7a51577a8 RBX: dead0122 RCX: > 8aa7a51577a8 > [ 225.360414] RDX: RSI: 0006 RDI: > 8aa7a5157400 > [ 225.360416] RBP: 9468ab32fbd8 R08: 8aa64e47e600 R09: > > [ 225.360418] R10: R11: c06036e6 R12: > dead0100 > [ 225.360420] R13: 8aa7820f1940 R14: 8aa7a51577a8 R15: > 0006 > [ 225.360422] FS: 7c1146ffd700() GS:8aa7baa0() > knlGS: > [ 225.360424] CS: 0010 DS: ES: CR0: 80050033 > [ 225.360426] CR2: 7aea3473a000 CR3: 537d6004 CR4: > 003606f0 > [ 225.360427] Call Trace: > [ 225.360434] imgu_return_all_buffers+0x6f/0x8e [ipu3_imgu] [ 225.360438] > imgu_vb2_stop_streaming+0xd6/0xf0 [ipu3_imgu] [ 225.360441] > __vb2_queue_cancel+0x33/0x22d [videobuf2_common] [ 225.360443] > vb2_core_streamoff+0x16/0x78 [videobuf2_common] [ 225.360448] > __video_do_ioctl+0x33d/0x42a [ 225.360452] video_usercopy+0x34a/0x615 > [ 225.360455] ? video_ioctl2+0x16/0x16 [ 225.360458] > v4l2_ioctl+0x46/0x53 [ 225.360462] do_vfs_ioctl+0x50a/0x787 [ 225.360465] > ksys_ioctl+0x58/0x83 [ 225.360468] __x64_sys_ioctl+0x1a/0x1e [ 225.360470] > do_syscall_64+0x54/0x68 [ 225.360474] > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 225.360476] RIP: 0033:0x7c118030f497 > [ 225.360479] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00 > 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f > 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48 > [ 225.360480] RSP: 002b:7c1146ffa5a8 EFLAGS: 0246 ORIG_RAX: > 0010 > [ 225.360483] RAX: ffda RBX: 7c1140010018 RCX: > 7c118030f497 > [ 225.360484] RDX: 7c114001019c RSI: 40045613 RDI: > 004c > [ 225.360486] RBP: 7c1146ffa700 R08: 7c1140010048 R09: > > [ 225.360488] R10: R11: 0246 R12: > 7c11400101b0 > [ 225.360489] R13: 7c1140010200 R14: 7c1140010048 R15: > 0001 > [ 225.360492] ---[ end trace 73625ecfbd1c930e ]--- [ 225.360498] general > protection fault: [#1] PREEMPT SMP PTI [ 225.360501] CPU: 0 PID: 6704 > Comm: CameraDeviceOps Tainted: G > WC5.4.30 #5 > [ 225.360502] Hardware name: HP Soraka/Soraka, BIOS > Google_Soraka.10431.106.0
Re: [PATCH] media: staging: ipu3: Fix stale list entries on parameter queue failure
Hi Tomasz, Thank you for the patch. On Sat, Apr 11, 2020 at 05:37:10PM +, Tomasz Figa wrote: > When queuing parameters fails, current code bails out without deleting > the corresponding vb2 buffer from the driver buffer list, but the buffer > is returned to vb2. This leads to stale list entries and a crash when > the driver stops streaming: > > [ 224.935561] ipu3-imgu :00:05.0: set parameters failed. > [ 224.998932] ipu3-imgu :00:05.0: set parameters failed. > [ 225.064430] ipu3-imgu :00:05.0: set parameters failed. > [ 225.128534] ipu3-imgu :00:05.0: set parameters failed. > [ 225.194945] ipu3-imgu :00:05.0: set parameters failed. > [ 225.360363] [ cut here ] > [ 225.360372] WARNING: CPU: 0 PID: 6704 at > drivers/media/common/videobuf2/videobuf2-core.c:927 > vb2_buffer_done+0x20f/0x21a [videobuf2_common] > [ 225.360374] Modules linked in: snd_seq_dummy snd_seq snd_seq_device > veth bridge stp llc tun nf_nat_tftp nf_conntrack_tftp nf_nat_ftp > nf_conntrack_ftp esp6 ah6 ip6t_REJECT ip6t_ipv6header cmac rfcomm uinput > ipu3_imgu(C) ipu3_cio2 iova videobuf2_v4l2 videobuf2_common > videobuf2_dma_sg videobuf2_memops ov13858 ov5670 v4l2_fwnode dw9714 > acpi_als xt_MASQUERADE fuse iio_trig_sysfs cros_ec_sensors_ring > cros_ec_light_prox cros_ec_sensors cros_ec_sensors_core > industrialio_triggered_buffer kfifo_buf industrialio > cros_ec_sensorsupport cdc_ether btusb btrtl btintel btbcm usbnet > bluetooth ecdh_generic ecc hid_google_hammer iwlmvm iwl7000_mac80211 > r8152 mii lzo_rle lzo_compress iwlwifi zram cfg80211 joydev > [ 225.360400] CPU: 0 PID: 6704 Comm: CameraDeviceOps Tainted: G > C5.4.30 #5 > [ 225.360402] Hardware name: HP Soraka/Soraka, BIOS > Google_Soraka.10431.106.0 12/03/2019 > [ 225.360405] RIP: 0010:vb2_buffer_done+0x20f/0x21a [videobuf2_common] > [ 225.360408] Code: 5e 41 5f 5d e9 e0 16 5a d4 41 8b 55 08 48 c7 c7 8f > 8b 5c c0 48 c7 c6 36 9a 5c c0 44 89 f9 31 c0 e8 a5 1c 5b d4 e9 53 fe ff > ff <0f> 0b eb a3 e8 12 d7 43 d4 eb 97 0f 1f 44 00 00 55 48 89 e5 41 56 > [ 225.360410] RSP: 0018:9468ab32fba8 EFLAGS: 00010297 > [ 225.360412] RAX: 8aa7a51577a8 RBX: dead0122 RCX: > 8aa7a51577a8 > [ 225.360414] RDX: RSI: 0006 RDI: > 8aa7a5157400 > [ 225.360416] RBP: 9468ab32fbd8 R08: 8aa64e47e600 R09: > > [ 225.360418] R10: R11: c06036e6 R12: > dead0100 > [ 225.360420] R13: 8aa7820f1940 R14: 8aa7a51577a8 R15: > 0006 > [ 225.360422] FS: 7c1146ffd700() GS:8aa7baa0() > knlGS: > [ 225.360424] CS: 0010 DS: ES: CR0: 80050033 > [ 225.360426] CR2: 7aea3473a000 CR3: 537d6004 CR4: > 003606f0 > [ 225.360427] Call Trace: > [ 225.360434] imgu_return_all_buffers+0x6f/0x8e [ipu3_imgu] > [ 225.360438] imgu_vb2_stop_streaming+0xd6/0xf0 [ipu3_imgu] > [ 225.360441] __vb2_queue_cancel+0x33/0x22d [videobuf2_common] > [ 225.360443] vb2_core_streamoff+0x16/0x78 [videobuf2_common] > [ 225.360448] __video_do_ioctl+0x33d/0x42a > [ 225.360452] video_usercopy+0x34a/0x615 > [ 225.360455] ? video_ioctl2+0x16/0x16 > [ 225.360458] v4l2_ioctl+0x46/0x53 > [ 225.360462] do_vfs_ioctl+0x50a/0x787 > [ 225.360465] ksys_ioctl+0x58/0x83 > [ 225.360468] __x64_sys_ioctl+0x1a/0x1e > [ 225.360470] do_syscall_64+0x54/0x68 > [ 225.360474] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 225.360476] RIP: 0033:0x7c118030f497 > [ 225.360479] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00 > 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f > 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48 > [ 225.360480] RSP: 002b:7c1146ffa5a8 EFLAGS: 0246 ORIG_RAX: > 0010 > [ 225.360483] RAX: ffda RBX: 7c1140010018 RCX: > 7c118030f497 > [ 225.360484] RDX: 7c114001019c RSI: 40045613 RDI: > 004c > [ 225.360486] RBP: 7c1146ffa700 R08: 7c1140010048 R09: > > [ 225.360488] R10: R11: 0246 R12: > 7c11400101b0 > [ 225.360489] R13: 7c1140010200 R14: 7c1140010048 R15: > 0001 > [ 225.360492] ---[ end trace 73625ecfbd1c930e ]--- > [ 225.360498] general protection fault: [#1] PREEMPT SMP PTI > [ 225.360501] CPU: 0 PID: 6704 Comm: CameraDeviceOps Tainted: G > WC5.4.30 #5 > [ 225.360502] Hardware name: HP Soraka/Soraka, BIOS > Google_Soraka.10431.106.0 12/03/2019 > [ 225.360505] RIP: 0010:imgu_return_all_buffers+0x52/0x8e [ipu3_imgu] > [ 225.360507] Code: d4 49 8b 85 70 0a 00 00 49 81 c5 70 0a 00 00 49 39 > c5 74 3b 49 bc 00 01 00 00 00 00 ad de 49 8d 5c 24 22 4c 8b 30 48 8b 48 > 08 <49> 89 4e 08 4c 89 31 4c 89 20 48 89 58 08 48 8d b8 58 fc ff ff 44 > [ 225.360509] RSP: 0018:9468ab32fbe8 EFLAGS: 00010293 > [ 225.360511] RAX: 8aa7a51577a8 RBX:
[staging:staging-testing] BUILD SUCCESS f4f7714f055fa662cf2f27dd0809a8781538e780
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-testing branch HEAD: f4f7714f055fa662cf2f27dd0809a8781538e780 staging: rtl8723bs: hal: Correct misspelled symbolic name elapsed time: 480m configs tested: 162 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm allyesconfig arm64allmodconfig arm allmodconfig arm64 allnoconfig arm allnoconfig arm efm32_defconfig arm at91_dt_defconfig armshmobile_defconfig arm64 defconfig arm exynos_defconfig armmulti_v5_defconfig arm sunxi_defconfig armmulti_v7_defconfig sparcallyesconfig i386 allnoconfig i386 allyesconfig i386 alldefconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig ia64 alldefconfig nios2 3c120_defconfig nios2 10m50_defconfig c6xevmc6678_defconfig xtensa iss_defconfig c6x allyesconfig xtensa common_defconfig openrisc simple_smp_defconfig openriscor1ksim_defconfig nds32 defconfig nds32 allnoconfig cskydefconfig alpha defconfig h8300 h8s-sim_defconfig h8300 edosk2674_defconfig m68k m5475evb_defconfig m68k allmodconfig h8300h8300h-sim_defconfig m68k sun3_defconfig m68k multi_defconfig arc defconfig arc allyesconfig powerpc defconfig powerpc ppc64_defconfig powerpc rhel-kconfig microblaze mmu_defconfig microblazenommu_defconfig powerpc allnoconfig mips fuloong2e_defconfig mips malta_kvm_defconfig mips allyesconfig mips 64r6el_defconfig mips allnoconfig mips 32r2_defconfig mips allmodconfig pariscallnoconfig pariscgeneric-64bit_defconfig pariscgeneric-32bit_defconfig parisc allyesconfig i386 randconfig-a002-20200412 x86_64 randconfig-a001-20200412 x86_64 randconfig-a002-20200412 i386 randconfig-a003-20200412 x86_64 randconfig-a003-20200412 i386 randconfig-a001-20200412 mips randconfig-a001-20200412 nds32randconfig-a001-20200412 riscvrandconfig-a001-20200412 m68k randconfig-a001-20200412 parisc randconfig-a001-20200412 alpharandconfig-a001-20200412 h8300randconfig-a001-20200412 nios2randconfig-a001-20200412 c6x randconfig-a001-20200412 sparc64 randconfig-a001-20200412 s390 randconfig-a001-20200412 xtensa randconfig-a001-20200412 sh randconfig-a001-20200412 openrisc randconfig-a001-20200412 csky randconfig-a001-20200412 x86_64 randconfig-b002-20200412 i386 randconfig-b001-20200412 x86_64 randconfig-b001-20200412 x86_64 randconfig-b003-20200412 i386 randconfig-b003-20200412 i386 randconfig-b002-20200412 x86_64 randconfig-c003-20200412 i386 randconfig-c003-20200412 i386 randconfig-c002-20200412 x86_64 randconfig-c002-20200412 i386 randconfig-c001-20200412 i386 randconfig-d002-20200412 x86_64 randconfig-d003-20200412 i386 randconfig-d003-20200412 i386 randconfig-d001-20200412 x86_64 randconfig-d002-20200412 x86_64
[PATCH] staging: r8188eu: replace rtw_malloc/copy_from_user sequence with memdup_user
memdup_user is shorter and expressively.
Signed-off-by: Ivan Safonov
---
.../staging/rtl8188eu/os_dep/ioctl_linux.c| 22 +--
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 0aff01bb69c3..d5968ef9f43d 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -2012,14 +2012,9 @@ static int wpa_supplicant_ioctl(struct net_device *dev,
struct iw_point *p)
if (!p->pointer || p->length != sizeof(struct ieee_param))
return -EINVAL;
- param = (struct ieee_param *)rtw_malloc(p->length);
- if (!param)
- return -ENOMEM;
-
- if (copy_from_user(param, p->pointer, p->length)) {
- kfree(param);
- return -EFAULT;
- }
+ param = memdup_user(p->pointer, p->length);
+ if (IS_ERR(param))
+ return PTR_ERR(param);
switch (param->cmd) {
case IEEE_CMD_SET_WPA_PARAM:
@@ -2789,14 +2784,9 @@ static int rtw_hostapd_ioctl(struct net_device *dev,
struct iw_point *p)
if (!p->pointer || p->length != sizeof(struct ieee_param))
return -EINVAL;
- param = (struct ieee_param *)rtw_malloc(p->length);
- if (!param)
- return -ENOMEM;
-
- if (copy_from_user(param, p->pointer, p->length)) {
- kfree(param);
- return -EFAULT;
- }
+ param = memdup_user(p->pointer, p->length);
+ if (IS_ERR(param))
+ return PTR_ERR(param);
switch (param->cmd) {
case RTL871X_HOSTAPD_FLUSH:
--
2.24.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: comedi: drivers: jr3_pci: fixed two warnings
Hi, Thank you for the patch! Yet something to improve: [auto build test ERROR on staging/staging-testing] [also build test ERROR on v5.6 next-20200412] [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/carlosteniswarrior-gmail-com/Staging-comedi-drivers-jr3_pci-fixed-two-warnings/20200412-234205 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git f4f7714f055fa662cf2f27dd0809a8781538e780 config: alpha-allmodconfig (attached as .config) compiler: alpha-linux-gcc (GCC) 9.3.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=9.3.0 make.cross ARCH=alpha If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot All error/warnings (new ones prefixed by >>): >> drivers/staging/comedi/drivers/jr3_pci.c:94:8: error: unknown type name >> 'comedi_lrange' 94 | const comedi_lrange l; |^ In file included from : drivers/staging/comedi/drivers/jr3_pci.c:95:32: error: unknown type name 'comedi_lrange' 95 | char _reserved[offsetof(const comedi_lrange, range[1])]; |^ include/linux/compiler_types.h:129:54: note: in definition of macro '__compiler_offsetof' 129 | #define __compiler_offsetof(a, b) __builtin_offsetof(a, b) | ^ >> drivers/staging/comedi/drivers/jr3_pci.c:95:17: note: in expansion of macro >> 'offsetof' 95 | char _reserved[offsetof(const comedi_lrange, range[1])]; | ^~~~ drivers/staging/comedi/drivers/jr3_pci.c: In function 'jr3_pci_poll_subdevice': >> drivers/staging/comedi/drivers/jr3_pci.c:527:10: error: request for member >> 'range' in something not a structure or union 527 |r[0].l.range[0].min = -get_s16(>fx) * 1000; | ^ drivers/staging/comedi/drivers/jr3_pci.c:528:10: error: request for member 'range' in something not a structure or union 528 |r[0].l.range[0].max = get_s16(>fx) * 1000; | ^ drivers/staging/comedi/drivers/jr3_pci.c:529:10: error: request for member 'range' in something not a structure or union 529 |r[1].l.range[0].min = -get_s16(>fy) * 1000; | ^ drivers/staging/comedi/drivers/jr3_pci.c:530:10: error: request for member 'range' in something not a structure or union 530 |r[1].l.range[0].max = get_s16(>fy) * 1000; | ^ drivers/staging/comedi/drivers/jr3_pci.c:531:10: error: request for member 'range' in something not a structure or union 531 |r[2].l.range[0].min = -get_s16(>fz) * 1000; | ^ drivers/staging/comedi/drivers/jr3_pci.c:532:10: error: request for member 'range' in something not a structure or union 532 |r[2].l.range[0].max = get_s16(>fz) * 1000; | ^ drivers/staging/comedi/drivers/jr3_pci.c:533:10: error: request for member 'range' in something not a structure or union 533 |r[3].l.range[0].min = -get_s16(>mx) * 100; | ^ drivers/staging/comedi/drivers/jr3_pci.c:534:10: error: request for member 'range' in something not a structure or union 534 |r[3].l.range[0].max = get_s16(>mx) * 100; | ^ drivers/staging/comedi/drivers/jr3_pci.c:535:10: error: request for member 'range' in something not a structure or union 535 |r[4].l.range[0].min = -get_s16(>my) * 100; | ^ drivers/staging/comedi/drivers/jr3_pci.c:536:10: error: request for member 'range' in something not a structure or union 536 |r[4].l.range[0].max = get_s16(>my) * 100; | ^ drivers/staging/comedi/drivers/jr3_pci.c:537:10: error: request for member 'range' in something not a structure or union 537 |r[5].l.range[0].min = -get_s16(>mz) * 100; | ^ drivers/staging/comedi/drivers/jr3_pci.c:539:10: error: request for member 'range' in something not a structure or union 539 |r[5].l.range[0].max = get_s16(>mz) * 100; | ^ drivers/staging/comedi/drivers/jr3_pci.c:540:10: error: request for member 'range' in something not a structure or union 540 |r[6].l.range[0].min = -get_s16(>v1) * 100; | ^ drivers/staging/comedi/drivers/jr3_pci.c:541:10: error: request for member 'range' in something not a structure or union 541 |r[6].l.range[0].max = get_s16(>v1) * 100; |
Re: [PATCH] Staging: comedi: drivers: jr3_pci: fixed two warnings
On Sun, 2020-04-12 at 16:25 +0200, carlosteniswarr...@gmail.com wrote:
> Fixed two checkpatch warnings.
by introducing compiler errors.
> diff --git a/drivers/staging/comedi/drivers/jr3_pci.c
> b/drivers/staging/comedi/drivers/jr3_pci.c
[]
> @@ -91,8 +91,8 @@ struct jr3_pci_dev_private {
> };
> union jr3_pci_single_range {
> - struct comedi_lrange l;
> - char _reserved[offsetof(struct comedi_lrange, range[1])];
> + const comedi_lrange l;
> + char _reserved[offsetof(const comedi_lrange, range[1])];
> };
try this:
$ make allyesconfig
$ make drivers/staging/comedi/drivers/jr3_pci.o
_always_ compile the files modified by your patch before
you post it to a mailing list or submit it to a maintainer.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: comedi: drivers: jr3_pci: fixed two warnings
Fixed two checkpatch warnings.
Signed-off-by: Carlos Guerrero Alvarez
---
drivers/staging/comedi/drivers/jr3_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/jr3_pci.c
b/drivers/staging/comedi/drivers/jr3_pci.c
index c3c88e6d298f..6bc87d3c6c3b 100644
--- a/drivers/staging/comedi/drivers/jr3_pci.c
+++ b/drivers/staging/comedi/drivers/jr3_pci.c
@@ -91,8 +91,8 @@ struct jr3_pci_dev_private {
};
union jr3_pci_single_range {
- struct comedi_lrange l;
- char _reserved[offsetof(struct comedi_lrange, range[1])];
+ const comedi_lrange l;
+ char _reserved[offsetof(const comedi_lrange, range[1])];
};
enum jr3_pci_poll_state {
--
2.26.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/8] staging: rtl8188eu: Remove function rtw_modular64()
Remove function rtw_modular64 as all it does is call do_div. This is wrong. Macro do_div(x, y) change first argument x, but rtw_modular64(x, y) preserve it. + tsf = pmlmeext->TSFValue - do_div(pmlmeext->TSFValue, (pmlmeinfo->bcn_interval*1024)) - 1024; /* us */ rounddown(pmlmeext->TSFValue, pmlmeinfo->bcn_interval * 1024) - 1024 is a better replacement for - tsf = pmlmeext->TSFValue - rtw_modular64(pmlmeext->TSFValue, (pmlmeinfo->bcn_interval*1024)) - 1024; /* us */ Patch '[PATCH 01/10] staging: rtl8723bs: Remove function rtw_modular64()' have same bug. Ivan Safonov. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-dts: fix PCIe interrupt mapping
Hi all,
On Sun, Apr 12, 2020 at 12:29 PM Sergio Paracuellos
wrote:
>
> MT7621 has three assigned interrupts for the pcie. This
> interrupts should properly being mapped taking into account
> which devices are finally connected in which bus. Because of
> this current information of these mappings is not enough and
> should be a little modified to properly got interrupts working
> for any scenario. For example, as it is now, if we only have
> connected pcie1 on PCI enumeration will get that bus 1 is using
> slot 0 for this pci device and the interrupt will be wrongly
> mapped to the one in pcie0 istead of use the good one for pcie1.
> Hence, add interrupt map information to pcie child nodes and
> properly update the global pcie node information.
>
> Fixes: 46d093124df4 ("staging: mt7621-pci: improve interrupt mapping")
> Signed-off-by: Sergio Paracuellos
> ---
>
> Tested in gnubee pc1 (which uses all the buses and also worked without
> changes) and tested also in ZyXEL LTE3301-PLUS which has PCIe and a
> mt7615e connected to second bus on the first phy where the current
> mapping was failing and this changes seems to fix the mapping problems.
>
> On gnubee we get:
>
> # cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> ...
>
> 23: 0 0 0 0 MIPS GIC 11
> ahci[:01:00.0]
> 24: 0 0 0 0 MIPS GIC 31
> ahci[:02:00.0]
> 25:279 0 0 0 MIPS GIC 32
> ahci[:03:00.0]
>
> On the ZyXEL LTE3301-PLUS before this changes (wrongly '23' (pcie0 one) is
> assigned):
>
> root@OpenWrt:/# cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> ...
>
> 23: 0 0 0 0 MIPS GIC 11 mt7615e
>
> After this changes:
>
> root@OpenWrt:/# cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> ...
>
> 24: 85 0 0 0 MIPS GIC 31 mt7615e
>
> Thanks!
>
> drivers/staging/mt7621-dts/mt7621.dtsi | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
> b/drivers/staging/mt7621-dts/mt7621.dtsi
> index 9e5cf68731bb..bee7731eb60a 100644
> --- a/drivers/staging/mt7621-dts/mt7621.dtsi
> +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
> @@ -524,10 +524,10 @@ pcie: pcie@1e14 {
> >;
>
> #interrupt-cells = <1>;
> - interrupt-map-mask = <0xF 0 0 1>;
> - interrupt-map = <0x1 0 0 1 GIC_SHARED 4
> IRQ_TYPE_LEVEL_HIGH>,
> - <0x2 0 0 1 GIC_SHARED 24
> IRQ_TYPE_LEVEL_HIGH>,
> - <0x3 0 0 1 GIC_SHARED 25
> IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-map-mask = <0xF800 0 0 0>;
> + interrupt-map = <0x 0 0 0 GIC_SHARED 4
> IRQ_TYPE_LEVEL_HIGH>,
> + <0x0800 0 0 0 GIC_SHARED 24
> IRQ_TYPE_LEVEL_HIGH>,
> + <0x1000 0 0 0 GIC_SHARED 25
> IRQ_TYPE_LEVEL_HIGH>;
>
> status = "disabled";
>
> @@ -544,6 +544,9 @@ pcie@0,0 {
> reg = <0x 0 0 0 0>;
> #address-cells = <3>;
> #size-cells = <2>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0>;
> + interrupt-map = <0 0 0 0 GIC_SHARED 4
> IRQ_TYPE_LEVEL_HIGH>;
> ranges;
> bus-range = <0x00 0xff>;
> };
> @@ -552,6 +555,9 @@ pcie@1,0 {
> reg = <0x0800 0 0 0 0>;
> #address-cells = <3>;
> #size-cells = <2>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0>;
> + interrupt-map = <0 0 0 0 GIC_SHARED 24
> IRQ_TYPE_LEVEL_HIGH>;
> ranges;
> bus-range = <0x00 0xff>;
> };
> @@ -560,6 +566,9 @@ pcie@2,0 {
> reg = <0x1000 0 0 0 0>;
> #address-cells = <3>;
> #size-cells = <2>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0>;
> + interrupt-map = <0 0 0 0 GIC_SHARED 25
> IRQ_TYPE_LEVEL_HIGH>;
> ranges;
> bus-range = <0x00 0xff>;
> };
> --
> 2.25.1
>
Forget about this patch I was told the ZyXEL side was not working as
expected. Sorry for the noise. Keep investigating.
Thanks,
Sergio Paracuellos
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] iio: kfifo: add iio_device_attach_kfifo_buffer() helper
On Mon, 6 Apr 2020 08:12:42 + "Ardelean, Alexandru" wrote: > On Sun, 2020-04-05 at 11:46 +0100, Jonathan Cameron wrote: > > [External] > > > > On Wed, 1 Apr 2020 15:59:34 +0300 > > Alexandru Ardelean wrote: > > > > > This change adds the iio_device_attach_kfifo_buffer() helper/short-hand, > > > which groups the simple routine of allocating a kfifo buffers via > > > devm_iio_kfifo_allocate() and calling iio_device_attach_buffer(). > > > > > > The mode_flags parameter is required. The setup_ops parameter is optional. > > > > > > This function will be a bit more useful when needing to define multiple > > > buffers per IIO device. > > > > > > One requirement [that is more a recommendation] for this helper, is to > > > call > > > it after 'indio_dev' has been populated. > > > > > > Also, one consequence related to using this helper is that the resource > > > management of the buffer will be tied to 'indio_dev->dev'. Previously it > > > was open-coded, and each driver does it slightly differently. Most of them > > > tied it to the parent device, some of them to 'indio_dev->dev'. > > > This shouldn't be a problem, and may be a good idea when adding more > > > buffers per-device. > > > > I'm glad you highlighted this subtlety. I'm not sure it's safe in all cases > > because the result is that the managed cleanup for this will occur once we > > get to the cleanup for devm_iio_device_alloc and we release the > > indio_dev->dev > > > > That would put it 'after' any other devm calls that are still hung off the > > parent > > device. > > > > Now the question is whether that ever causes us problems... See next patch. > > It potentially does. I think we need to provide the dev separately even > > if it feels a bit silly to do so. Scope management is complex so I don't > > really want to force people to mix and match between different devices > > and so get it wrong by accident. > > > > The other issue is that it's not readily apparent from the naming that > > this function is registering stuff that is cleaned up automatically or > > that it even allocates anything that might need that.. > > > > devm_iio_device_attach_new_kfifo_buffer maybe? > > > > I'm sort of wondering if we should do what dma did and have > > > > iiom_device_attach_new_kfifo_buffer to indicate it's managed in the > > scope of the iio device? > > > > What do people think? > > > > However, see patch 2 before commenting. Reality is I'm not sure forcing > > managed calls to hang off iio_dev->dev is a good idea (at this stage given > > where we are). > > What I am really after with this patch is to hide away these: > iio_kfifo_free(indio_dev->buffer); > iio_buffer_set_attrs(indio_dev->buffer, _fifo_attributes); > i.e. not have 'indio_dev->buffer' open-coded in drivers, and hide it in IIO > core > somewhere. > Some ideas can go in parallel [like this one] to add support for multiple > buffers. > > So, I will think of a better [less sloppy] V2 for this. > > One intermediate alternative is to do 'iio_device_kfifo_free(indio_dev)', but > I'll still try to think of a better devm_ approach. > devm_iio_device_attach_new_kfifo_buffer() sounds a bit long but may work. > iiom_device_attach_new_kfifo_buffer() can also work. > > What if we just default attaching to the parent device? That would work and be consistent with the vast majority of current cases. > > Would it work to also attach the parent device in devm_iio_device_alloc() by > default? That would need a thorough audit to check nothing crazy is done by a driver with an odd structure. Such a driver would (I think) be buggy though as the child lifetime should be dependent on the parent and not some other device. > Or change 'iio_device_alloc()' to take a parent device as argument? I think there are only a couple of users, so that would work. > Which for devm_iio_device_alloc(dev,...) would implicitly mean that 'dev' is > 'parent'? I think that's a fair assumption (though needs a sanity check) > > These are just some thoughts. > > > > > > Thanks > > > > Jonathan > > > > > > > Signed-off-by: Alexandru Ardelean > > > --- > > > drivers/iio/buffer/kfifo_buf.c | 37 ++ > > > include/linux/iio/kfifo_buf.h | 4 > > > 2 files changed, 41 insertions(+) > > > > > > diff --git a/drivers/iio/buffer/kfifo_buf.c > > > b/drivers/iio/buffer/kfifo_buf.c > > > index 3150f8ab984b..05b7c5fc6f1d 100644 > > > --- a/drivers/iio/buffer/kfifo_buf.c > > > +++ b/drivers/iio/buffer/kfifo_buf.c > > > @@ -228,4 +228,41 @@ void devm_iio_kfifo_free(struct device *dev, struct > > > iio_buffer *r) > > > } > > > EXPORT_SYMBOL(devm_iio_kfifo_free); > > > > > > +/** > > > + * iio_device_attach_kfifo_buffer - Allocate a kfifo buffer & attach it > > > to > > > an IIO device > > > + * @indio_dev: The device the buffer should be attached to > > > + * @mode_flags: The mode flags for this buffer (INDIO_BUFFER_SOFTWARE > > > and/or >
Re: [PATCH] staging: vt6656: formulate rspinf values into tables
Drop this patch v2 sent Regards Malcolm ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: vt6656: formulate rspinf values into tables
Four tables can be extracted from RSPINF_A_* based on BB_TYPE_11A or
else being GB rates.
Preamble short or long tables from fixed size len of 14 for RSPINF_B rates.
Remove function vnt_calculate_ofdm_rate and replace with the tables
calling RSPINF_A and RSPINF_B separately.
Signed-off-by: Malcolm Priestley
---
v1 has error in vnt_rspinf_a_table.
drivers/staging/vt6656/card.c | 196 +++---
1 file changed, 40 insertions(+), 156 deletions(-)
diff --git a/drivers/staging/vt6656/card.c b/drivers/staging/vt6656/card.c
index 82c775bd20d2..dedb343f3ef3 100644
--- a/drivers/staging/vt6656/card.c
+++ b/drivers/staging/vt6656/card.c
@@ -74,99 +74,25 @@ void vnt_set_channel(struct vnt_private *priv, u32
connection_channel)
(u8)(connection_channel | 0x80));
}
-/*
- * Description: Calculate TxRate and RsvTime fields for RSPINF in OFDM mode.
- *
- * Parameters:
- * In:
- * rate- Tx Rate
- * bb_type - Tx Packet type
- * Out:
- * tx_rate - pointer to RSPINF TxRate field
- * rsv_time- pointer to RSPINF RsvTime field
- *
- * Return Value: none
- *
- */
-static void vnt_calculate_ofdm_rate(u16 rate, u8 bb_type,
- u8 *tx_rate, u8 *rsv_time)
-{
- switch (rate) {
- case RATE_6M:
- if (bb_type == BB_TYPE_11A) {
- *tx_rate = 0x9b;
- *rsv_time = 24;
- } else {
- *tx_rate = 0x8b;
- *rsv_time = 30;
- }
- break;
- case RATE_9M:
- if (bb_type == BB_TYPE_11A) {
- *tx_rate = 0x9f;
- *rsv_time = 16;
- } else {
- *tx_rate = 0x8f;
- *rsv_time = 22;
- }
- break;
- case RATE_12M:
- if (bb_type == BB_TYPE_11A) {
- *tx_rate = 0x9a;
- *rsv_time = 12;
- } else {
- *tx_rate = 0x8a;
- *rsv_time = 18;
- }
- break;
- case RATE_18M:
- if (bb_type == BB_TYPE_11A) {
- *tx_rate = 0x9e;
- *rsv_time = 8;
- } else {
- *tx_rate = 0x8e;
- *rsv_time = 14;
- }
- break;
- case RATE_36M:
- if (bb_type == BB_TYPE_11A) {
- *tx_rate = 0x9d;
- *rsv_time = 4;
- } else {
- *tx_rate = 0x8d;
- *rsv_time = 10;
- }
- break;
- case RATE_48M:
- if (bb_type == BB_TYPE_11A) {
- *tx_rate = 0x98;
- *rsv_time = 4;
- } else {
- *tx_rate = 0x88;
- *rsv_time = 10;
- }
- break;
- case RATE_54M:
- if (bb_type == BB_TYPE_11A) {
- *tx_rate = 0x9c;
- *rsv_time = 4;
- } else {
- *tx_rate = 0x8c;
- *rsv_time = 10;
- }
- break;
- case RATE_24M:
- default:
- if (bb_type == BB_TYPE_11A) {
- *tx_rate = 0x99;
- *rsv_time = 8;
- } else {
- *tx_rate = 0x89;
- *rsv_time = 14;
- }
- break;
- }
-}
+static const u8 vnt_rspinf_b_short_table[] = {
+ 0x70, 0x00, 0x00, 0x00, 0x38, 0x00, 0x09, 0x00,
+ 0x15, 0x00, 0x0a, 0x00, 0x0b, 0x00, 0x0b, 0x80
+};
+
+static const u8 vnt_rspinf_b_long_table[] = {
+ 0x70, 0x00, 0x00, 0x00, 0x38, 0x00, 0x01, 0x00,
+ 0x15, 0x00, 0x02, 0x00, 0x0b, 0x00, 0x03, 0x80
+};
+
+static const u8 vnt_rspinf_a_table[] = {
+ 0x9b, 0x18, 0x9f, 0x10, 0x9a, 0x0a, 0x9e, 0x08, 0x99,
+ 0x08, 0x9d, 0x04, 0x98, 0x04, 0x9c, 0x04, 0x9c, 0x04
+};
+
+static const u8 vnt_rspinf_gb_table[] = {
+ 0x8b, 0x1e, 0x8f, 0x16, 0x8a, 0x12, 0x8e, 0x0e, 0x89,
+ 0x0e, 0x8d, 0x0a, 0x88, 0x0a, 0x8c, 0x0a, 0x8c, 0x0a
+};
/*
* Description: Set RSPINF
@@ -183,74 +109,32 @@ static void vnt_calculate_ofdm_rate(u16 rate, u8 bb_type,
void vnt_set_rspinf(struct vnt_private *priv, u8 bb_type)
{
- struct vnt_phy_field phy[4];
- u8 tx_rate[9] = {0, 0, 0, 0, 0, 0, 0, 0, 0}; /* For OFDM */
- u8 rsv_time[9] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
- u8 data[34];
- int i;
-
- /*RSPINF_b_1*/
- vnt_get_phy_field(priv, 14, RATE_1M, PK_TYPE_11B, [0]);
-
- /*RSPINF_b_2*/
- vnt_get_phy_field(priv, 14, RATE_2M, PK_TYPE_11B, [1]);
-
- /*RSPINF_b_5*/
- vnt_get_phy_field(priv, 14, RATE_5M, PK_TYPE_11B, [2]);
-
-
[PATCH] staging: mt7621-dts: fix PCIe interrupt mapping
MT7621 has three assigned interrupts for the pcie. This
interrupts should properly being mapped taking into account
which devices are finally connected in which bus. Because of
this current information of these mappings is not enough and
should be a little modified to properly got interrupts working
for any scenario. For example, as it is now, if we only have
connected pcie1 on PCI enumeration will get that bus 1 is using
slot 0 for this pci device and the interrupt will be wrongly
mapped to the one in pcie0 istead of use the good one for pcie1.
Hence, add interrupt map information to pcie child nodes and
properly update the global pcie node information.
Fixes: 46d093124df4 ("staging: mt7621-pci: improve interrupt mapping")
Signed-off-by: Sergio Paracuellos
---
Tested in gnubee pc1 (which uses all the buses and also worked without
changes) and tested also in ZyXEL LTE3301-PLUS which has PCIe and a
mt7615e connected to second bus on the first phy where the current
mapping was failing and this changes seems to fix the mapping problems.
On gnubee we get:
# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
...
23: 0 0 0 0 MIPS GIC 11
ahci[:01:00.0]
24: 0 0 0 0 MIPS GIC 31
ahci[:02:00.0]
25:279 0 0 0 MIPS GIC 32
ahci[:03:00.0]
On the ZyXEL LTE3301-PLUS before this changes (wrongly '23' (pcie0 one) is
assigned):
root@OpenWrt:/# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
...
23: 0 0 0 0 MIPS GIC 11 mt7615e
After this changes:
root@OpenWrt:/# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
...
24: 85 0 0 0 MIPS GIC 31 mt7615e
Thanks!
drivers/staging/mt7621-dts/mt7621.dtsi | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 9e5cf68731bb..bee7731eb60a 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -524,10 +524,10 @@ pcie: pcie@1e14 {
>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0xF 0 0 1>;
- interrupt-map = <0x1 0 0 1 GIC_SHARED 4
IRQ_TYPE_LEVEL_HIGH>,
- <0x2 0 0 1 GIC_SHARED 24
IRQ_TYPE_LEVEL_HIGH>,
- <0x3 0 0 1 GIC_SHARED 25
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0xF800 0 0 0>;
+ interrupt-map = <0x 0 0 0 GIC_SHARED 4
IRQ_TYPE_LEVEL_HIGH>,
+ <0x0800 0 0 0 GIC_SHARED 24
IRQ_TYPE_LEVEL_HIGH>,
+ <0x1000 0 0 0 GIC_SHARED 25
IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
@@ -544,6 +544,9 @@ pcie@0,0 {
reg = <0x 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 GIC_SHARED 4
IRQ_TYPE_LEVEL_HIGH>;
ranges;
bus-range = <0x00 0xff>;
};
@@ -552,6 +555,9 @@ pcie@1,0 {
reg = <0x0800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 GIC_SHARED 24
IRQ_TYPE_LEVEL_HIGH>;
ranges;
bus-range = <0x00 0xff>;
};
@@ -560,6 +566,9 @@ pcie@2,0 {
reg = <0x1000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 GIC_SHARED 25
IRQ_TYPE_LEVEL_HIGH>;
ranges;
bus-range = <0x00 0xff>;
};
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6656: Use BIT() macro instead of bit shift operator
Use the BIT() macro instead of the bit left shift operator. So the code
is more clear.
It's safe to remove the casting to u16 type because the value obtained
never exceeds 16 bits. So the casting is unnecessary.
Signed-off-by: Oscar Carter
---
drivers/staging/vt6656/card.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vt6656/card.c b/drivers/staging/vt6656/card.c
index dc3ab10eb630..14e6c71f122c 100644
--- a/drivers/staging/vt6656/card.c
+++ b/drivers/staging/vt6656/card.c
@@ -92,7 +92,7 @@ static u16 vnt_get_cck_rate(struct vnt_private *priv, u16
rate_idx)
u16 ui = rate_idx;
while (ui > RATE_1M) {
- if (priv->basic_rates & (1 << ui))
+ if (priv->basic_rates & BIT(ui))
return ui;
ui--;
}
@@ -129,7 +129,7 @@ static u16 vnt_get_ofdm_rate(struct vnt_private *priv, u16
rate_idx)
}
while (ui > RATE_11M) {
- if (priv->basic_rates & (1 << ui)) {
+ if (priv->basic_rates & BIT(ui)) {
dev_dbg(>usb->dev, "%s rate: %d\n",
__func__, ui);
return ui;
@@ -420,7 +420,7 @@ void vnt_update_top_rates(struct vnt_private *priv)
/*Determines the highest basic rate.*/
for (i = RATE_54M; i >= RATE_6M; i--) {
- if (priv->basic_rates & (u16)(1 << i)) {
+ if (priv->basic_rates & BIT(i)) {
top_ofdm = i;
break;
}
@@ -429,7 +429,7 @@ void vnt_update_top_rates(struct vnt_private *priv)
priv->top_ofdm_basic_rate = top_ofdm;
for (i = RATE_11M;; i--) {
- if (priv->basic_rates & (u16)(1 << i)) {
+ if (priv->basic_rates & BIT(i)) {
top_cck = i;
break;
}
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
