| Message ID | 20170120212716.29887-2-Larry.Finger@lwfinger.net (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Kalle Valo |
| Headers | show |
Larry Finger <Larry.Finger@lwfinger.net> writes: > From: Ping-Ke Shih <pkshih@realtek.com> > > There is a potential race condition when the control byte of a CAM > entry is written first. Write in reverse order to correct the condition. > > Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> > Signed-off-by: shaofu <shaofu@realtek.com> > Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> > --- > V2 - no changes Weird, I don't see any of the v2 patches in patchwork: https://patchwork.kernel.org/project/linux-wireless/list/?state=*&page=1 I do see other recent patches from you Larry, but not this set. Can you resubmit, please?
Larry Finger <Larry.Finger@lwfinger.net> writes: > From: Ping-Ke Shih <pkshih@realtek.com> > > There is a potential race condition when the control byte of a CAM > entry is written first. Write in reverse order to correct the condition. > > Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> > Signed-off-by: shaofu <shaofu@realtek.com> > Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> > --- > V2 - no changes > V3 - no changes I missed in my reply to v2 that you had already sent v3 from this patchset. Strange that I don't see this v3 patchset either in patchwork, only v1. Try submitting v4 in case it was just a temporary glitch in patchwork. But if that doesn't help I'll apply these manually.
On 02/06/2017 06:45 AM, Kalle Valo wrote: > Larry Finger <Larry.Finger@lwfinger.net> writes: > >> From: Ping-Ke Shih <pkshih@realtek.com> >> >> There is a potential race condition when the control byte of a CAM >> entry is written first. Write in reverse order to correct the condition. >> >> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> >> Signed-off-by: shaofu <shaofu@realtek.com> >> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> >> --- >> V2 - no changes >> V3 - no changes > > I missed in my reply to v2 that you had already sent v3 from this > patchset. Strange that I don't see this v3 patchset either in patchwork, > only v1. > > Try submitting v4 in case it was just a temporary glitch in patchwork. > But if that doesn't help I'll apply these manually. I have no idea why that patchsets are missing. I will send V4 shortly. Sorry I did not respond more quickly. I was out of my office today. Larry
On 02/06/2017 06:45 AM, Kalle Valo wrote: > Larry Finger <Larry.Finger@lwfinger.net> writes: > >> From: Ping-Ke Shih <pkshih@realtek.com> >> >> There is a potential race condition when the control byte of a CAM >> entry is written first. Write in reverse order to correct the condition. >> >> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> >> Signed-off-by: shaofu <shaofu@realtek.com> >> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> >> --- >> V2 - no changes >> V3 - no changes > > I missed in my reply to v2 that you had already sent v3 from this > patchset. Strange that I don't see this v3 patchset either in patchwork, > only v1. > > Try submitting v4 in case it was just a temporary glitch in patchwork. > But if that doesn't help I'll apply these manually. I have no idea why my patches are not getting handled by patchwork, but V4 is not there either. Larry
Larry Finger <Larry.Finger@lwfinger.net> writes: > On 02/06/2017 06:45 AM, Kalle Valo wrote: >> Larry Finger <Larry.Finger@lwfinger.net> writes: >> >>> From: Ping-Ke Shih <pkshih@realtek.com> >>> >>> There is a potential race condition when the control byte of a CAM >>> entry is written first. Write in reverse order to correct the condition. >>> >>> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> >>> Signed-off-by: shaofu <shaofu@realtek.com> >>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> >>> --- >>> V2 - no changes >>> V3 - no changes >> >> I missed in my reply to v2 that you had already sent v3 from this >> patchset. Strange that I don't see this v3 patchset either in patchwork, >> only v1. >> >> Try submitting v4 in case it was just a temporary glitch in patchwork. >> But if that doesn't help I'll apply these manually. > > I have no idea why my patches are not getting handled by patchwork, > but V4 is not there either. Yeah, that's odd. I do see your patches on the mailing list so I guess something in this set is breaking patchwork's email parser. The only notable difference I saw that in our patches the tags were in this format: [PATCH 01/11 V4] But normally we use something like this: [PATCH V4 01/11] I don't know if that would cause patchwork to fail and I don't really have time to investigate it right now. I'll just apply V4 manually now and let's hope that the problem doesn't reappear.
diff --git a/drivers/net/wireless/realtek/rtlwifi/cam.c b/drivers/net/wireless/realtek/rtlwifi/cam.c index a0605d8..f7a7dcb 100644 --- a/drivers/net/wireless/realtek/rtlwifi/cam.c +++ b/drivers/net/wireless/realtek/rtlwifi/cam.c @@ -45,12 +45,13 @@ static void rtl_cam_program_entry(struct ieee80211_hw *hw, u32 entry_no, u32 target_command; u32 target_content = 0; - u8 entry_i; + int entry_i; RT_PRINT_DATA(rtlpriv, COMP_SEC, DBG_DMESG, "Key content :", key_cont_128, 16); - for (entry_i = 0; entry_i < CAM_CONTENT_COUNT; entry_i++) { + /* 0-1 config + mac, 2-5 fill 128key,6-7 are reserved */ + for (entry_i = CAM_CONTENT_COUNT - 1; entry_i >= 0; entry_i--) { target_command = entry_i + CAM_CONTENT_COUNT * entry_no; target_command = target_command | BIT(31) | BIT(16); @@ -102,7 +103,6 @@ static void rtl_cam_program_entry(struct ieee80211_hw *hw, u32 entry_no, target_content); rtl_write_dword(rtlpriv, rtlpriv->cfg->maps[RWCAM], target_command); - udelay(100); RT_TRACE(rtlpriv, COMP_SEC, DBG_LOUD, "WRITE A4: %x\n", target_content);