Re: [PATCH 0/2] fix sparse warnings
On Wed, Feb 24, 2021 at 06:06:48PM +0300, Dan Carpenter wrote: > On Wed, Feb 24, 2021 at 08:26:41PM +0530, karthek wrote: > > On Sun, Feb 21, 2021 at 09:00:48PM +0530, karthik alapati wrote: > > > the following patches fixes two byte-order issues > > > and fixes these sparse warnings > > > > > > > > > drivers/staging//wimax/i2400m/op-rfkill.c:89:25: warning: incorrect type > > > in assignment (different base types) > > > drivers/staging//wimax/i2400m/op-rfkill.c:89:25:expected restricted > > > __le16 [usertype] length > > > drivers/staging//wimax/i2400m/op-rfkill.c:89:25:got unsigned long > > > . > > > drivers/staging//wimax/i2400m/fw.c:514:27: warning: restricted __le32 > > > degrades to integer > > > > > > > > > karthik alapati (2): > > > staging: wimax/i2400m: fix byte-order issue > > > staging: wimax/i2400m: convert __le32 type to host byte-order > > > > > > drivers/staging/wimax/i2400m/fw.c| 2 +- > > > drivers/staging/wimax/i2400m/op-rfkill.c | 2 +- > > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > > > -- > > > 2.30.1 > > > > > ping? > > The merge window is open so no one is merging these types of fixes now. > Wait until -rc1 is out, and then give the maintainer two weeks to look > at your patch and get back to you. > > regards, > dan carpenter > thanks dan, Got it. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] fix sparse warnings
On Sun, Feb 21, 2021 at 09:00:48PM +0530, karthik alapati wrote: > the following patches fixes two byte-order issues > and fixes these sparse warnings > > > drivers/staging//wimax/i2400m/op-rfkill.c:89:25: warning: incorrect type in > assignment (different base types) > drivers/staging//wimax/i2400m/op-rfkill.c:89:25:expected restricted > __le16 [usertype] length > drivers/staging//wimax/i2400m/op-rfkill.c:89:25:got unsigned long > . > drivers/staging//wimax/i2400m/fw.c:514:27: warning: restricted __le32 > degrades to integer > > > karthik alapati (2): > staging: wimax/i2400m: fix byte-order issue > staging: wimax/i2400m: convert __le32 type to host byte-order > > drivers/staging/wimax/i2400m/fw.c| 2 +- > drivers/staging/wimax/i2400m/op-rfkill.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > -- > 2.30.1 > ping? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng/p80211 : check userspacebuf size for sanity
On Mon, Feb 22, 2021 at 08:43:51PM +0530, karthek wrote:
> On Mon, Feb 22, 2021 at 04:59:37PM +0300, Dan Carpenter wrote:
> > I have added the Driver Devel list to the CC list. Adding linux-kernel
> > is sort of useless. The correct people who are interested in this patch
> > are all on the Driver Devel list.
> >
> > On Mon, Feb 22, 2021 at 07:12:22PM +0530, karthek wrote:
> > > On Mon, Feb 22, 2021 at 04:21:33PM +0300, Dan Carpenter wrote:
> > > > On Mon, Feb 22, 2021 at 06:16:24PM +0530, karthek wrote:
> > > > > currently p80211knetdev_do_ioctl() is testing user passed
> > > > > struct ifreq for sanity by checking for presence of a magic number,
> > > > > in addition to that also check size field, preventing buffer overflow
> > > > > before passing data to p80211req_dorequest() which casts it
> > > > > to *struct p80211msg
> > > > >
> > > > > Signed-off-by: karthek
> > > > > ---
> > > > > is this correct?
> > > > > is it necessary to check for size in addition to magicnum?
> > > > > did i even understand the problem correctly?
> > > > >
> > > > > drivers/staging/wlan-ng/p80211netdev.c | 5 -
> > > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/staging/wlan-ng/p80211netdev.c
> > > > > b/drivers/staging/wlan-ng/p80211netdev.c
> > > > > index 70570e8a5..c7b78d870 100644
> > > > > --- a/drivers/staging/wlan-ng/p80211netdev.c
> > > > > +++ b/drivers/staging/wlan-ng/p80211netdev.c
> > > > > @@ -568,7 +568,10 @@ static int p80211knetdev_do_ioctl(struct
> > > > > net_device *dev,
> > > > > result = -EINVAL;
> > > > > goto bail;
> > > > > }
> > > > > -
> > > > > + if (req->len < sizeof(struct p80211msg)) {
> > > > > + result = -EINVAL;
> > > > > + goto bail;
> > > > > + }
> > > >
> > > > Please don't send private emails. Always CC the list.
> > > sorry
> > > >
> > > > That's only a partial solution. You need to check in
> > > > p80211req_handlemsg()
> > > > as well and probably other places.
> > > currently p80211req_handlemsg() is only referenced in
> > > p80211req_dorequest()
> > > can we check that there instead?
> >
> > If I have to do all the work in finding the buffer overflows, then I
> > should write my own patch. :/
> >
> > Anyway the p80211knetdev_do_ioctl() function calls p80211req_dorequest()
> > which calls p80211req_handlemsg(wlandev, msg); and
> > wlandev->mlmerequest(wlandev, msg);.
> >
> > We have already discussed the p80211req_handlemsg() function. The
> > wlandev->mlmerequest() function is always just prism2sta_mlmerequest().
> > The prism2sta_mlmerequest() calls a bunch of functions and each of those
> > functions need to have a different limit check added to prevent memory
> > corruption.
other than this ioctl call codepath other codepaths leading to those
functions doesn't seem to get that msg(struct p80211req) from userspace
so may be they dont need that checking
anyway why do you think that is necessary?
> >
> > Homework #1: Should we get rid of the wlandev->mlmerequest() pointer
> > and just call prism2sta_mlmerequest() directly?
> yeah
> >
> > Homework #2: Another solution is to just delete all these custom IOCTLs.
> > I don't know what they do so I don't know if they are necessary or not.
> i wish i could
> >
> > regards,
> > dan carpenter
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng/p80211 : check userspacebuf size for sanity
On Mon, Feb 22, 2021 at 04:59:37PM +0300, Dan Carpenter wrote:
> I have added the Driver Devel list to the CC list. Adding linux-kernel
> is sort of useless. The correct people who are interested in this patch
> are all on the Driver Devel list.
>
> On Mon, Feb 22, 2021 at 07:12:22PM +0530, karthek wrote:
> > On Mon, Feb 22, 2021 at 04:21:33PM +0300, Dan Carpenter wrote:
> > > On Mon, Feb 22, 2021 at 06:16:24PM +0530, karthek wrote:
> > > > currently p80211knetdev_do_ioctl() is testing user passed
> > > > struct ifreq for sanity by checking for presence of a magic number,
> > > > in addition to that also check size field, preventing buffer overflow
> > > > before passing data to p80211req_dorequest() which casts it
> > > > to *struct p80211msg
> > > >
> > > > Signed-off-by: karthek
> > > > ---
> > > > is this correct?
> > > > is it necessary to check for size in addition to magicnum?
> > > > did i even understand the problem correctly?
> > > >
> > > > drivers/staging/wlan-ng/p80211netdev.c | 5 -
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/staging/wlan-ng/p80211netdev.c
> > > > b/drivers/staging/wlan-ng/p80211netdev.c
> > > > index 70570e8a5..c7b78d870 100644
> > > > --- a/drivers/staging/wlan-ng/p80211netdev.c
> > > > +++ b/drivers/staging/wlan-ng/p80211netdev.c
> > > > @@ -568,7 +568,10 @@ static int p80211knetdev_do_ioctl(struct
> > > > net_device *dev,
> > > > result = -EINVAL;
> > > > goto bail;
> > > > }
> > > > -
> > > > + if (req->len < sizeof(struct p80211msg)) {
> > > > + result = -EINVAL;
> > > > + goto bail;
> > > > + }
> > >
> > > Please don't send private emails. Always CC the list.
> > sorry
> > >
> > > That's only a partial solution. You need to check in
> > > p80211req_handlemsg()
> > > as well and probably other places.
> > currently p80211req_handlemsg() is only referenced in p80211req_dorequest()
> > can we check that there instead?
>
> If I have to do all the work in finding the buffer overflows, then I
> should write my own patch. :/
>
> Anyway the p80211knetdev_do_ioctl() function calls p80211req_dorequest()
> which calls p80211req_handlemsg(wlandev, msg); and
> wlandev->mlmerequest(wlandev, msg);.
>
> We have already discussed the p80211req_handlemsg() function. The
> wlandev->mlmerequest() function is always just prism2sta_mlmerequest().
> The prism2sta_mlmerequest() calls a bunch of functions and each of those
> functions need to have a different limit check added to prevent memory
> corruption.
>
> Homework #1: Should we get rid of the wlandev->mlmerequest() pointer
> and just call prism2sta_mlmerequest() directly?
yeah
>
> Homework #2: Another solution is to just delete all these custom IOCTLs.
> I don't know what they do so I don't know if they are necessary or not.
i wish i could
>
> regards,
> dan carpenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wimax: fix sparse incorrect type issue
On Mon, Feb 22, 2021 at 11:10 AM Dan Carpenter wrote: > > On Sat, Feb 20, 2021 at 05:04:00PM +0530, karthik alapati wrote: > > fix sparse warning by casting to explicit user address-space > > pointer type > > > > Signed-off-by: karthik alapati > > --- > > drivers/staging/wlan-ng/p80211netdev.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/wlan-ng/p80211netdev.c > > b/drivers/staging/wlan-ng/p80211netdev.c > > index 6f9666dc0..70570e8a5 100644 > > --- a/drivers/staging/wlan-ng/p80211netdev.c > > +++ b/drivers/staging/wlan-ng/p80211netdev.c > > @@ -569,7 +569,7 @@ static int p80211knetdev_do_ioctl(struct net_device > > *dev, > > goto bail; > > } > > > > - msgbuf = memdup_user(req->data, req->len); > > + msgbuf = memdup_user((void __user *)req->data, req->len); > > This doesn't fix anything it just silences the warning. Linus Torvalds > worked very hard to create Sparse for the express purpose of printing > the warning. People don't realize that warnings are very valuable > because they show where the bugs are. > > Please look at this some more and figure out how to fix the warning. > > To be honest, I'm tempted to not accept any patch which doesn't also fix > the buffer overflows when we pass: > > result = p80211req_dorequest(wlandev, msgbuf); > > How do we know that "msgbuf" is large enough? > > regards, > dan carpenter > Thanks dan but right after sending this patch i immediately replied to it stating to ignore this patch as i found this already applied in staging-testing branch https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=3a8a144d2a754df45127c74e273fa166f690ba43 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wimax/i2400m: fix byte-order type issue
fix sparse type warning by converting le32 types to
host byte-order types before comparison
Signed-off-by: karthek
---
drivers/staging/wimax/i2400m/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wimax/i2400m/fw.c
b/drivers/staging/wimax/i2400m/fw.c
index 92ea5c101..f09de1810 100644
--- a/drivers/staging/wimax/i2400m/fw.c
+++ b/drivers/staging/wimax/i2400m/fw.c
@@ -511,7 +511,7 @@ ssize_t __i2400m_bm_ack_verify(struct i2400m *i2400m, int
opcode,
opcode, i2400m_brh_get_response(ack));
goto error_ack_failed;
}
- if (ack_size < ack->data_size + sizeof(*ack)) {
+ if (ack_size < le32_to_cpu(ack->data_size) + sizeof(*ack)) {
dev_err(dev, "boot-mode cmd %d: SW BUG "
"driver provided only %zu bytes for %zu bytes "
"of data\n", opcode, ack_size,
--
2.30.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wimax/i2400m: fix byte-order issue
fix sparse byte-order warnings by converting host byte-order types to le32 types Signed-off-by: karthek --- drivers/staging/wimax/i2400m/op-rfkill.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wimax/i2400m/op-rfkill.c b/drivers/staging/wimax/i2400m/op-rfkill.c index a159808f0..0f438ae6a 100644 --- a/drivers/staging/wimax/i2400m/op-rfkill.c +++ b/drivers/staging/wimax/i2400m/op-rfkill.c @@ -86,7 +86,7 @@ int i2400m_op_rfkill_sw_toggle(struct wimax_dev *wimax_dev, if (cmd == NULL) goto error_alloc; cmd->hdr.type = cpu_to_le16(I2400M_MT_CMD_RF_CONTROL); - cmd->hdr.length = sizeof(cmd->sw_rf); + cmd->hdr.length = cpu_to_le16(sizeof(cmd->sw_rf)); cmd->hdr.version = cpu_to_le16(I2400M_L3L4_VERSION); cmd->sw_rf.hdr.type = cpu_to_le16(I2400M_TLV_RF_OPERATION); cmd->sw_rf.hdr.length = cpu_to_le16(sizeof(cmd->sw_rf.status)); -- 2.30.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: remove obsolete commented out code
On Thu, Feb 11, 2021 at 4:16 PM Greg Kroah-Hartman wrote: > > A: http://en.wikipedia.org/wiki/Top_post > Q: Were do I find info about this thing called top-posting? > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > On Thu, Feb 11, 2021 at 04:00:04PM +0530, karthek wrote: > > Should i send them as patch series? > > Please do. > > thanks, > > greg k-h Yeah, it is clearly mentioned in lfd103 which i do remember but i want you to know that it's purely accidental ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc
Sorry On Thu, Feb 11, 2021 at 3:34 PM Greg Kroah-Hartman wrote: > > On Thu, Feb 11, 2021 at 12:48:16AM +0530, karthek wrote: > > check this out > > Why ask us again when you already sent a patch? Do you see any other > developers doing that on the mailing lists? > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: remove obsolete commented out code
Should i send them as patch series?
On Thu, Feb 11, 2021 at 1:27 PM Dan Carpenter wrote:
>
> On Thu, Feb 11, 2021 at 12:40:41AM +0530, karthik alapati wrote:
> > @@ -867,10 +845,8 @@ static void PHY_HandleSwChnlAndSetBW8723B(
> > if (bSetBandWidth)
> > pHalData->bSetChnlBW = true;
> >
> > - if (!pHalData->bSetChnlBW && !pHalData->bSwChnl) {
> > - /* DBG_871X("<= PHY_HandleSwChnlAndSetBW8812: bSwChnl %d,
> > bSetChnlBW %d\n", pHalData->bSwChnl, pHalData->bSetChnlBW); */
> > + if (!pHalData->bSetChnlBW && !pHalData->bSwChnl)
> > return;
> > - }
>
> In this case, the + line is correct. Good job.
>
> >
> >
> > if (pHalData->bSwChnl) {
> > @@ -929,9 +905,7 @@ void PHY_SetSwChnlBWMode8723B(
> > u8 Offset80
> > )
> > {
> > - /* DBG_871X("%s() ===>\n", __func__); */
> >
> > PHY_HandleSwChnlAndSetBW8723B(Adapter, true, true, channel,
> > Bandwidth, Offset40, Offset80, channel);
> >
> > - /* DBG_871X("<==%s()\n", __func__); */
>
> Please delete the blank lines as well.
>
> regards,
> dan carpenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: remove obsolete commented out code
Hey dan, check this out too ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc
check this out ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc
On Wed, Feb 10, 2021 at 02:38:28PM +0530, karthek wrote: > On Wed, Feb 10, 2021, 2:31 PM Dan Carpenter > wrote: > > > On Wed, Feb 10, 2021 at 02:28:31PM +0530, karthek wrote: > > > On Wed, Feb 10, 2021 at 1:37 PM Dan Carpenter > > wrote: > > > > > @@ -789,7 +759,7 @@ static void phy_PostSetBwMode8723B(struct > > adapter *Adapter) > > > > > > > > > > PHY_SetBBReg(Adapter, rFPGA1_RFMOD, bRFMOD, 0x0); > > > > > > > > > > -/* PHY_SetBBReg(Adapter, rFPGA0_AnalogParameter2, > > BIT10, 1); */ > > > > > + /*PHY_SetBBReg(Adapter, rFPGA0_AnalogParameter2, BIT10, 1); */ > > > > > > > > This format is wrong. Anyway, just delete the commented out code. > > > > > > > > regards, > > > > dan carpenter > > > > > > > > > > how can i delete that, i have no idea what this driver does > > > i'm just fixing coding style issues for eudyptula challenge. > > > i dont think its a good idea to delete the code without knowing its > > > purpose even though its commented out > > > > Commented code obviously doesn't do anything at all? > > > > regards, > > dan carpenter > > > sorry for that html mail, im onthego,i sent it from phone anyway here is the original message: Ofcourse it does nothing But why does it exist in the first place, Why maintainer decided to comment it out without just deleting it? Maybe there is some reason which i don't know So i decided not to touch it Anyway I'm new to this so just say what should i do now? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc
On Wed, Feb 10, 2021 at 1:37 PM Dan Carpenter wrote:
>
> On Wed, Feb 10, 2021 at 02:42:30AM +0530, karthik alapati wrote:
> > fix checkpatch.pl warning for "block comments should align the
> > * on each line" and make function comments follow kernel-doc
> >
> > Signed-off-by: karthik alapati
> > ---
> > .../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 209 --
> > 1 file changed, 91 insertions(+), 118 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > index cf23414d7..b7fca881c 100644
> > --- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > +++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > @@ -20,16 +20,11 @@
> > #define MAX_DOZE_WAITING_TIMES_9x 64
> >
> > /**
> > -* Function: phy_CalculateBitShift
> > -*
> > -* OverView: Get shifted position of the BitMask
> > -*
> > -* Input:
> > -*u32 BitMask,
> > -*
> > -* Output:none
> > -* Return:u32 Return the shift bit bit position of the mask
> > -*/
> > + * phy_CalculateBitShift - Get shifted position of the BitMask.
> > + * @BitMask: Bitmask.
> > + *
> > + * Return: Return the shift bit position of the mask
> > + */
> > static u32 phy_CalculateBitShift(u32 BitMask)
> > {
> > u32 i;
> > @@ -43,19 +38,17 @@ staticu32 phy_CalculateBitShift(u32 BitMask)
> >
> >
> > /**
> > -* Function: PHY_QueryBBReg
> > -*
> > -* OverView: Read "specific bits" from BB register
> > -*
> > -* Input:
> > -*struct adapter *Adapter,
> > -*u32 RegAddr,The target address to be
> > readback
> > -*u32 BitMask The target bit position in
> > the target address
> > -*to be readback
> > -* Output:None
> > -* Return:u32 DataThe readback register
> > value
> > -* Note: This function is equal to "GetRegSetting" in PHY
> > programming guide
> > -*/
> > + * PHY_QueryBBReg - Read "specific bits" from BB register.
> > + * @Adapter:
> > + * @RegAddr: The target address to be readback
> > + * @BitMask: The target bit position in the target address
> > + * to be readback
> > + *
> > + * Return: The readback register value
> > + *
> > + * .. Note:: This function is equal to "GetRegSetting" in PHY programming
> > + * guide
> > + */
> > u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32 RegAddr, u32 BitMask)
> > {
> > u32 OriginalValue, BitShift;
> > @@ -64,7 +57,10 @@ u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32
> > RegAddr, u32 BitMask)
> > return 0;
> > #endif
> >
> > - /* RT_TRACE(COMP_RF, DBG_TRACE, ("--->PHY_QueryBBReg():
> > RegAddr(%#lx), BitMask(%#lx)\n", RegAddr, BitMask)); */
> > + /**
> > + * RT_TRACE(COMP_RF, DBG_TRACE, ("--->PHY_QueryBBReg():
> > + * RegAddr(%#lx), BitMask(%#lx)\n", RegAddr, BitMask));
> > + */
>
> Just delete this (in a separate patch).
>
> >
> > OriginalValue = rtw_read32(Adapter, RegAddr);
> > BitShift = phy_CalculateBitShift(BitMask);
> > @@ -75,22 +71,17 @@ u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32
> > RegAddr, u32 BitMask)
> >
> >
> > /**
> > -* Function: PHY_SetBBReg
> > -*
> > -* OverView: Write "Specific bits" to BB register (page 8~)
> > -*
> > -* Input:
> > -*struct adapter *Adapter,
> > -*u32 RegAddr,The target address to be
> > modified
> > -*u32 BitMask The target bit position in
> > the target address
> > -*to be modified
> > -*u32 DataThe new register value in the
> > target bit position
> > -*of the target
> > address
> > -*
> > -* Output:None
> > -* Return:None
> > -* Note: This function is equal to "PutRegSetting" in PHY
> > programming guide
> > -*/
> > + * PHY_SetBBReg - Write "Specific bits" to BB register (page 8~).
> > + * @Adapter:
> > + * @RegAddr: The target address to be modified
> > + * @BitMask: The target bit position in the target address
> > + * to be modified
> > + * @Data: The new register value in the target bit position
> > + * of the target address
> > + *
> > + * .. Note:: This function is equal to "PutRegSetting" in PHY programming
> > + * guide
> > + */
> >
> > void PHY_SetBBReg_8723B(
> > struct adapter *Adapter,
> > @@ -106,7 +97,10 @@ void PHY_SetBBReg_8723B(
> > return;
> > #endif
> >
> > - /* RT_TRACE(COMP_RF, DBG_TRACE, ("--->PHY_SetBBReg(): RegAddr(%#lx),
> > BitMask(%#lx), Data(%#lx)\n", RegAddr, BitMask, Data)); */
> > +
Re: [PATCH] staging: rtl8723bs: fix block comments alignment
On Wed, Feb 10, 2021 at 10:27:17AM +0300, Dan Carpenter wrote:
> On Wed, Feb 10, 2021 at 12:23:17AM +0530, karthik alapati wrote:
> > fix checkpatch.pl warning for "block comments should align the * on each
> > line"
> >
> > Signed-off-by: karthik alapati
> > ---
> > .../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 204 +-
> > 1 file changed, 102 insertions(+), 102 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > index cf23414d7..003f954c2 100644
> > --- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > +++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > @@ -20,16 +20,16 @@
> > #define MAX_DOZE_WAITING_TIMES_9x 64
> >
> > /**
> > -* Function:phy_CalculateBitShift
> > -*
> > -* OverView:Get shifted position of the BitMask
> > -*
> > -* Input:
> > -* u32 BitMask,
> > -*
> > -* Output: none
> > -* Return: u32 Return the shift bit bit position of the mask
> > -*/
> > + * Function: phy_CalculateBitShift
> > + *
> > + * OverView: Get shifted position of the BitMask
> > + *
> > + * Input:
> > + * u32 BitMask,
>
> Why is this on a different line??
>
> > + *
> > + * Output: none
> > + * Return: u32 Return the shift bit bit position of the mask
>
> The "u32" is indented more than the "none". "bit bit" is probably a
> typo?
>
> > + */
> > static u32 phy_CalculateBitShift(u32 BitMask)
> > {
> > u32 i;
>
> There is a proper kernel-doc style that function comments are supposed
> to use. https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html
>
> ./scripts/kernel-doc -v -none drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
>
> regards,
> dan carpenter
>
thats my old patch
the new one is already sent to greg,lkml
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: fix block comments alignment
fix checkpatch.pl warning for "block comments should align the * on each line"
Signed-off-by: karthek
---
eudyptula challenge thing
.../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 204 +-
1 file changed, 102 insertions(+), 102 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
index cf23414d7..003f954c2 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
@@ -20,16 +20,16 @@
#define MAX_DOZE_WAITING_TIMES_9x 64
/**
-* Function:phy_CalculateBitShift
-*
-* OverView:Get shifted position of the BitMask
-*
-* Input:
-* u32 BitMask,
-*
-* Output: none
-* Return: u32 Return the shift bit bit position of the mask
-*/
+ * Function: phy_CalculateBitShift
+ *
+ * OverView: Get shifted position of the BitMask
+ *
+ * Input:
+ * u32 BitMask,
+ *
+ * Output: none
+ * Return: u32 Return the shift bit bit position of the mask
+ */
static u32 phy_CalculateBitShift(u32 BitMask)
{
u32 i;
@@ -43,19 +43,19 @@ static u32 phy_CalculateBitShift(u32 BitMask)
/**
-* Function:PHY_QueryBBReg
-*
-* OverView:Read "specific bits" from BB register
-*
-* Input:
-* struct adapter *Adapter,
-* u32 RegAddr,The target address to be
readback
-* u32 BitMask The target bit position in the
target address
-* to be readback
-* Output: None
-* Return: u32 DataThe readback register
value
-* Note:This function is equal to "GetRegSetting" in PHY
programming guide
-*/
+ * Function: PHY_QueryBBReg
+ *
+ * OverView: Read "specific bits" from BB register
+ *
+ * Input:
+ * struct adapter *Adapter,
+ * u32 RegAddr,The target address to be
readback
+ * u32 BitMask The target bit position in the
target address
+ * to be readback
+ * Output: None
+ * Return: u32 DataThe readback register
value
+ * Note: This function is equal to "GetRegSetting" in PHY
programming guide
+ */
u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32 RegAddr, u32 BitMask)
{
u32 OriginalValue, BitShift;
@@ -75,22 +75,22 @@ u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32
RegAddr, u32 BitMask)
/**
-* Function:PHY_SetBBReg
-*
-* OverView:Write "Specific bits" to BB register (page 8~)
-*
-* Input:
-* struct adapter *Adapter,
-* u32 RegAddr,The target address to be
modified
-* u32 BitMask The target bit position in the
target address
-* to be modified
-* u32 DataThe new register value in the
target bit position
-* of the target
address
-*
-* Output: None
-* Return: None
-* Note:This function is equal to "PutRegSetting" in PHY
programming guide
-*/
+ * Function: PHY_SetBBReg
+ *
+ * OverView: Write "Specific bits" to BB register (page 8~)
+ *
+ * Input:
+ * struct adapter *Adapter,
+ * u32 RegAddr,The target address to be
modified
+ * u32 BitMask The target bit position in the
target address
+ * to be modified
+ * u32 DataThe new register value in the
target bit position
+ * of the target
address
+ *
+ * Output: None
+ * Return: None
+ * Note: This function is equal to "PutRegSetting" in PHY
programming guide
+ */
void PHY_SetBBReg_8723B(
struct adapter *Adapter,
@@ -184,25 +184,25 @@ static u32 phy_RFSerialRead_8723B(
}
/**
-* Function:phy_RFSerialWrite_8723B
-*
-* OverView:Write data to RF register (page 8~)
-*
-* Input:
-* struct adapter *Adapter,
-* RF_PATH eRFPath,Radio path of A/B/C/D
-* u32 Offset, The target address to be read
-* u32 DataThe new register Data in the
target bit position
-* of the target
to be read
-*
-* Output: None
-* Return: None
-* Note:Threre are three types of serial operations:
