[PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
as '(iobase)' to avoid precedence issues" changed to inline function. In
relation to this, names of the callers of macro are also modified to call
this function.

Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
---
Changes in v3:
	- Whitespace error from checkpatch fixed

Changes in v2:
	- Macros with one statement that is to call 'iowrite8' function changed
	to inline function as reviewed by gregkh@linuxfoundation.org.
	In relation to this, names of the callers of macro are also modified
	to call this function.
---
 drivers/staging/vt6655/card.c    | 3 +--
 drivers/staging/vt6655/channel.c | 2 +-
 drivers/staging/vt6655/mac.h     | 4 ++--
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
index a6ff496b01b6..d2d122dc16d8 100644
--- a/drivers/staging/vt6655/card.c
+++ b/drivers/staging/vt6655/card.c
@@ -643,8 +643,7 @@ void CARDvSetRSPINF(struct vnt_private *priv, u8 bb_type)
 				   &byRsvTime);
 	iowrite16(MAKEWORD(byTxRate, byRsvTime), priv->port_offset + MAC_REG_RSPINF_A_72);
 	/* Set to Page0 */
-        vt6655_mac_select_page0(priv->port_offset);
-
+	vt6655_mac_select_page0(priv->port_offset);
 
 	spin_unlock_irqrestore(&priv->lock, flags);
 }
diff --git a/drivers/staging/vt6655/channel.c b/drivers/staging/vt6655/channel.c
index e9a44bcebe32..60b445c38424 100644
--- a/drivers/staging/vt6655/channel.c
+++ b/drivers/staging/vt6655/channel.c
@@ -121,7 +121,7 @@ bool set_channel(struct vnt_private *priv, struct ieee80211_channel *ch)
 		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWRCCK);
 		RFbSetPower(priv, RATE_6M, priv->byCurrentCh);
 		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWROFDM);
-	        vt6655_mac_select_page0(priv->port_offset);
+		vt6655_mac_select_page0(priv->port_offset);
 
 		spin_unlock_irqrestore(&priv->lock, flags);
 	}
diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h
index b9a7ca0fe604..ae3064303691 100644
--- a/drivers/staging/vt6655/mac.h
+++ b/drivers/staging/vt6655/mac.h
@@ -539,12 +539,12 @@
 
 static inline void vt6655_mac_select_page0(void __iomem *iobase)
 {
-        iowrite8(0, iobase + MAC_REG_PAGE1SEL);
+	iowrite8(0, iobase + MAC_REG_PAGE1SEL);
 }
 
 static inline void  vt6655_mac_select_page1(void __iomem *iobase)
 {
-        iowrite8(1, iobase + MAC_REG_PAGE1SEL);
+	iowrite8(1, iobase + MAC_REG_PAGE1SEL);
 }
 
 #define MAKEWORD(lb, hb) \
-- 
2.34.1


-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Christophe JAILLET]

Le 05/02/2023 à 19:11, Guru Mehar Rachaputi a écrit :
> This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> as '(iobase)' to avoid precedence issues" changed to inline function. In
> relation to this, names of the callers of macro are also modified to call
> this function.
> 
> Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>

Hi,

this patch should be v4.
You re-sent it with a modified commit message (the position of your S-o-b)

The idea behind patch versions is to help maintainer. With the way you 
did, now 2 patches stating v3 are available.
Which one is the correct one?
The maintainer would need to look at both, search for differences, maybe 
look at the date of the mails.
A v4 would be much easier for him.


Also, when you send an updated version of a patch, it should always be 
"complete". I mean that the patch below seems to need v2, and maybe even 
v1 (which is apparently not on the linux-kernel mailing list).

A maintainer can't know by himself what is needed and what is not.

So you should resend a new patch.
It should be a v4, and it should include what is needed from (v1?), v2 
and v3 all together.

CJ


> ---
> Changes in v3:
> 	- Whitespace error from checkpatch fixed
> 
> Changes in v2:
> 	- Macros with one statement that is to call 'iowrite8' function changed
> 	to inline function as reviewed by gregkh@linuxfoundation.org.
> 	In relation to this, names of the callers of macro are also modified
> 	to call this function.
> ---
>   drivers/staging/vt6655/card.c    | 3 +--
>   drivers/staging/vt6655/channel.c | 2 +-
>   drivers/staging/vt6655/mac.h     | 4 ++--
>   3 files changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
> index a6ff496b01b6..d2d122dc16d8 100644
> --- a/drivers/staging/vt6655/card.c
> +++ b/drivers/staging/vt6655/card.c
> @@ -643,8 +643,7 @@ void CARDvSetRSPINF(struct vnt_private *priv, u8 bb_type)
>   				   &byRsvTime);
>   	iowrite16(MAKEWORD(byTxRate, byRsvTime), priv->port_offset + MAC_REG_RSPINF_A_72);
>   	/* Set to Page0 */
> -        vt6655_mac_select_page0(priv->port_offset);
> -
> +	vt6655_mac_select_page0(priv->port_offset);
>   
>   	spin_unlock_irqrestore(&priv->lock, flags);
>   }
> diff --git a/drivers/staging/vt6655/channel.c b/drivers/staging/vt6655/channel.c
> index e9a44bcebe32..60b445c38424 100644
> --- a/drivers/staging/vt6655/channel.c
> +++ b/drivers/staging/vt6655/channel.c
> @@ -121,7 +121,7 @@ bool set_channel(struct vnt_private *priv, struct ieee80211_channel *ch)
>   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWRCCK);
>   		RFbSetPower(priv, RATE_6M, priv->byCurrentCh);
>   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWROFDM);
> -	        vt6655_mac_select_page0(priv->port_offset);
> +		vt6655_mac_select_page0(priv->port_offset);
>   
>   		spin_unlock_irqrestore(&priv->lock, flags);
>   	}
> diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h
> index b9a7ca0fe604..ae3064303691 100644
> --- a/drivers/staging/vt6655/mac.h
> +++ b/drivers/staging/vt6655/mac.h
> @@ -539,12 +539,12 @@
>   
>   static inline void vt6655_mac_select_page0(void __iomem *iobase)
>   {
> -        iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> +	iowrite8(0, iobase + MAC_REG_PAGE1SEL);
>   }
>   
>   static inline void  vt6655_mac_select_page1(void __iomem *iobase)
>   {
> -        iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> +	iowrite8(1, iobase + MAC_REG_PAGE1SEL);
>   }
>   
>   #define MAKEWORD(lb, hb) \

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Sun, Feb 05, 2023 at 08:12:31PM +0100, Christophe JAILLET wrote:
> Le 05/02/2023 à 19:11, Guru Mehar Rachaputi a écrit :
> > This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> > as '(iobase)' to avoid precedence issues" changed to inline function. In
> > relation to this, names of the callers of macro are also modified to call
> > this function.
> > 
> > Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
> 
> Hi,
> 
> this patch should be v4.
> You re-sent it with a modified commit message (the position of your S-o-b)
> 
> The idea behind patch versions is to help maintainer. With the way you did,
> now 2 patches stating v3 are available.
> Which one is the correct one?
> The maintainer would need to look at both, search for differences, maybe
> look at the date of the mails.
> A v4 would be much easier for him.
> 
> 
> Also, when you send an updated version of a patch, it should always be
> "complete". I mean that the patch below seems to need v2, and maybe even v1
> (which is apparently not on the linux-kernel mailing list).
> 
> A maintainer can't know by himself what is needed and what is not.
> 
> So you should resend a new patch.
> It should be a v4, and it should include what is needed from (v1?), v2 and
> v3 all together.
> 
> CJ
> 
> 
> > ---
> > Changes in v3:
> > 	- Whitespace error from checkpatch fixed
> > 
> > Changes in v2:
> > 	- Macros with one statement that is to call 'iowrite8' function changed
> > 	to inline function as reviewed by gregkh@linuxfoundation.org.
> > 	In relation to this, names of the callers of macro are also modified
> > 	to call this function.
> > ---
> >   drivers/staging/vt6655/card.c    | 3 +--
> >   drivers/staging/vt6655/channel.c | 2 +-
> >   drivers/staging/vt6655/mac.h     | 4 ++--
> >   3 files changed, 4 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
> > index a6ff496b01b6..d2d122dc16d8 100644
> > --- a/drivers/staging/vt6655/card.c
> > +++ b/drivers/staging/vt6655/card.c
> > @@ -643,8 +643,7 @@ void CARDvSetRSPINF(struct vnt_private *priv, u8 bb_type)
> >   				   &byRsvTime);
> >   	iowrite16(MAKEWORD(byTxRate, byRsvTime), priv->port_offset + MAC_REG_RSPINF_A_72);
> >   	/* Set to Page0 */
> > -        vt6655_mac_select_page0(priv->port_offset);
> > -
> > +	vt6655_mac_select_page0(priv->port_offset);
> >   	spin_unlock_irqrestore(&priv->lock, flags);
> >   }
> > diff --git a/drivers/staging/vt6655/channel.c b/drivers/staging/vt6655/channel.c
> > index e9a44bcebe32..60b445c38424 100644
> > --- a/drivers/staging/vt6655/channel.c
> > +++ b/drivers/staging/vt6655/channel.c
> > @@ -121,7 +121,7 @@ bool set_channel(struct vnt_private *priv, struct ieee80211_channel *ch)
> >   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWRCCK);
> >   		RFbSetPower(priv, RATE_6M, priv->byCurrentCh);
> >   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWROFDM);
> > -	        vt6655_mac_select_page0(priv->port_offset);
> > +		vt6655_mac_select_page0(priv->port_offset);
> >   		spin_unlock_irqrestore(&priv->lock, flags);
> >   	}
> > diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h
> > index b9a7ca0fe604..ae3064303691 100644
> > --- a/drivers/staging/vt6655/mac.h
> > +++ b/drivers/staging/vt6655/mac.h
> > @@ -539,12 +539,12 @@
> >   static inline void vt6655_mac_select_page0(void __iomem *iobase)
> >   {
> > -        iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> > +	iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> >   }
> >   static inline void  vt6655_mac_select_page1(void __iomem *iobase)
> >   {
> > -        iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> > +	iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> >   }
> >   #define MAKEWORD(lb, hb) \
> 

Thanks for the explaination.
Since I amended commit message and thought as there is no new commit it
should still be the same patch.

Is it ok if I send a new patchset based on the previous conversations?
I have four commits now, 4th commit being just the commit message and
this patchset doesn't have s-o-b issue.

or

should I undo all the amends?

-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Greg Kroah-Hartman]

On Mon, Feb 06, 2023 at 12:39:08AM +0100, Guru Mehar Rachaputi wrote:
> On Sun, Feb 05, 2023 at 08:12:31PM +0100, Christophe JAILLET wrote:
> > Le 05/02/2023 à 19:11, Guru Mehar Rachaputi a écrit :
> > > This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> > > as '(iobase)' to avoid precedence issues" changed to inline function. In
> > > relation to this, names of the callers of macro are also modified to call
> > > this function.
> > > 
> > > Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
> > 
> > Hi,
> > 
> > this patch should be v4.
> > You re-sent it with a modified commit message (the position of your S-o-b)
> > 
> > The idea behind patch versions is to help maintainer. With the way you did,
> > now 2 patches stating v3 are available.
> > Which one is the correct one?
> > The maintainer would need to look at both, search for differences, maybe
> > look at the date of the mails.
> > A v4 would be much easier for him.
> > 
> > 
> > Also, when you send an updated version of a patch, it should always be
> > "complete". I mean that the patch below seems to need v2, and maybe even v1
> > (which is apparently not on the linux-kernel mailing list).
> > 
> > A maintainer can't know by himself what is needed and what is not.
> > 
> > So you should resend a new patch.
> > It should be a v4, and it should include what is needed from (v1?), v2 and
> > v3 all together.
> > 
> > CJ
> > 
> > 
> > > ---
> > > Changes in v3:
> > > 	- Whitespace error from checkpatch fixed
> > > 
> > > Changes in v2:
> > > 	- Macros with one statement that is to call 'iowrite8' function changed
> > > 	to inline function as reviewed by gregkh@linuxfoundation.org.
> > > 	In relation to this, names of the callers of macro are also modified
> > > 	to call this function.
> > > ---
> > >   drivers/staging/vt6655/card.c    | 3 +--
> > >   drivers/staging/vt6655/channel.c | 2 +-
> > >   drivers/staging/vt6655/mac.h     | 4 ++--
> > >   3 files changed, 4 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
> > > index a6ff496b01b6..d2d122dc16d8 100644
> > > --- a/drivers/staging/vt6655/card.c
> > > +++ b/drivers/staging/vt6655/card.c
> > > @@ -643,8 +643,7 @@ void CARDvSetRSPINF(struct vnt_private *priv, u8 bb_type)
> > >   				   &byRsvTime);
> > >   	iowrite16(MAKEWORD(byTxRate, byRsvTime), priv->port_offset + MAC_REG_RSPINF_A_72);
> > >   	/* Set to Page0 */
> > > -        vt6655_mac_select_page0(priv->port_offset);
> > > -
> > > +	vt6655_mac_select_page0(priv->port_offset);
> > >   	spin_unlock_irqrestore(&priv->lock, flags);
> > >   }
> > > diff --git a/drivers/staging/vt6655/channel.c b/drivers/staging/vt6655/channel.c
> > > index e9a44bcebe32..60b445c38424 100644
> > > --- a/drivers/staging/vt6655/channel.c
> > > +++ b/drivers/staging/vt6655/channel.c
> > > @@ -121,7 +121,7 @@ bool set_channel(struct vnt_private *priv, struct ieee80211_channel *ch)
> > >   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWRCCK);
> > >   		RFbSetPower(priv, RATE_6M, priv->byCurrentCh);
> > >   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWROFDM);
> > > -	        vt6655_mac_select_page0(priv->port_offset);
> > > +		vt6655_mac_select_page0(priv->port_offset);
> > >   		spin_unlock_irqrestore(&priv->lock, flags);
> > >   	}
> > > diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h
> > > index b9a7ca0fe604..ae3064303691 100644
> > > --- a/drivers/staging/vt6655/mac.h
> > > +++ b/drivers/staging/vt6655/mac.h
> > > @@ -539,12 +539,12 @@
> > >   static inline void vt6655_mac_select_page0(void __iomem *iobase)
> > >   {
> > > -        iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> > > +	iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> > >   }
> > >   static inline void  vt6655_mac_select_page1(void __iomem *iobase)
> > >   {
> > > -        iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> > > +	iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> > >   }
> > >   #define MAKEWORD(lb, hb) \
> > 
> 
> Thanks for the explaination.
> Since I amended commit message and thought as there is no new commit it
> should still be the same patch.
> 
> Is it ok if I send a new patchset based on the previous conversations?
> I have four commits now, 4th commit being just the commit message and
> this patchset doesn't have s-o-b issue.

Look at other submissions on the mailing lists.  When you submit a new
version of a patch, it is stand-alone, with no dependancies on anything
else, otherwise tracking that would be impossible, right?

I suggest reading through the kernelnewbies.org "first patch submission"
tutorial first as I think it will answer questions like this.

good luck!

greg k-h

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Mon, Feb 06, 2023 at 10:43:56AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 06, 2023 at 12:39:08AM +0100, Guru Mehar Rachaputi wrote:
> > On Sun, Feb 05, 2023 at 08:12:31PM +0100, Christophe JAILLET wrote:
> > > Le 05/02/2023 à 19:11, Guru Mehar Rachaputi a écrit :
> > > > This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> > > > as '(iobase)' to avoid precedence issues" changed to inline function. In
> > > > relation to this, names of the callers of macro are also modified to call
> > > > this function.
> > > > 
> > > > Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
> > > 
> > > Hi,
> > > 
> > > this patch should be v4.
> > > You re-sent it with a modified commit message (the position of your S-o-b)
> > > 
> > > The idea behind patch versions is to help maintainer. With the way you did,
> > > now 2 patches stating v3 are available.
> > > Which one is the correct one?
> > > The maintainer would need to look at both, search for differences, maybe
> > > look at the date of the mails.
> > > A v4 would be much easier for him.
> > > 
> > > 
> > > Also, when you send an updated version of a patch, it should always be
> > > "complete". I mean that the patch below seems to need v2, and maybe even v1
> > > (which is apparently not on the linux-kernel mailing list).
> > > 
> > > A maintainer can't know by himself what is needed and what is not.
> > > 
> > > So you should resend a new patch.
> > > It should be a v4, and it should include what is needed from (v1?), v2 and
> > > v3 all together.
> > > 
> > > CJ
> > > 
> > > 
> > > > ---
> > > > Changes in v3:
> > > > 	- Whitespace error from checkpatch fixed
> > > > 
> > > > Changes in v2:
> > > > 	- Macros with one statement that is to call 'iowrite8' function changed
> > > > 	to inline function as reviewed by gregkh@linuxfoundation.org.
> > > > 	In relation to this, names of the callers of macro are also modified
> > > > 	to call this function.
> > > > ---
> > > >   drivers/staging/vt6655/card.c    | 3 +--
> > > >   drivers/staging/vt6655/channel.c | 2 +-
> > > >   drivers/staging/vt6655/mac.h     | 4 ++--
> > > >   3 files changed, 4 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
> > > > index a6ff496b01b6..d2d122dc16d8 100644
> > > > --- a/drivers/staging/vt6655/card.c
> > > > +++ b/drivers/staging/vt6655/card.c
> > > > @@ -643,8 +643,7 @@ void CARDvSetRSPINF(struct vnt_private *priv, u8 bb_type)
> > > >   				   &byRsvTime);
> > > >   	iowrite16(MAKEWORD(byTxRate, byRsvTime), priv->port_offset + MAC_REG_RSPINF_A_72);
> > > >   	/* Set to Page0 */
> > > > -        vt6655_mac_select_page0(priv->port_offset);
> > > > -
> > > > +	vt6655_mac_select_page0(priv->port_offset);
> > > >   	spin_unlock_irqrestore(&priv->lock, flags);
> > > >   }
> > > > diff --git a/drivers/staging/vt6655/channel.c b/drivers/staging/vt6655/channel.c
> > > > index e9a44bcebe32..60b445c38424 100644
> > > > --- a/drivers/staging/vt6655/channel.c
> > > > +++ b/drivers/staging/vt6655/channel.c
> > > > @@ -121,7 +121,7 @@ bool set_channel(struct vnt_private *priv, struct ieee80211_channel *ch)
> > > >   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWRCCK);
> > > >   		RFbSetPower(priv, RATE_6M, priv->byCurrentCh);
> > > >   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWROFDM);
> > > > -	        vt6655_mac_select_page0(priv->port_offset);
> > > > +		vt6655_mac_select_page0(priv->port_offset);
> > > >   		spin_unlock_irqrestore(&priv->lock, flags);
> > > >   	}
> > > > diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h
> > > > index b9a7ca0fe604..ae3064303691 100644
> > > > --- a/drivers/staging/vt6655/mac.h
> > > > +++ b/drivers/staging/vt6655/mac.h
> > > > @@ -539,12 +539,12 @@
> > > >   static inline void vt6655_mac_select_page0(void __iomem *iobase)
> > > >   {
> > > > -        iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> > > > +	iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> > > >   }
> > > >   static inline void  vt6655_mac_select_page1(void __iomem *iobase)
> > > >   {
> > > > -        iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> > > > +	iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> > > >   }
> > > >   #define MAKEWORD(lb, hb) \
> > > 
> > 
> > Thanks for the explaination.
> > Since I amended commit message and thought as there is no new commit it
> > should still be the same patch.
> > 
> > Is it ok if I send a new patchset based on the previous conversations?
> > I have four commits now, 4th commit being just the commit message and
> > this patchset doesn't have s-o-b issue.
> 
> Look at other submissions on the mailing lists.  When you submit a new
> version of a patch, it is stand-alone, with no dependancies on anything
> else, otherwise tracking that would be impossible, right?
> 
> I suggest reading through the kernelnewbies.org "first patch submission"
> tutorial first as I think it will answer questions like this.
> 
> good luck!
> 
> greg k-h

Thanks for taking time.

If my understanding is correct, every version of the patch should
include all the patches/patchfiles and it should explain what happened in each
version(in decrement order) through a coverletter. Please correct me otherwise.

I do refer "first patch submission" and above is my current
understanding.

-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Greg Kroah-Hartman]

On Tue, Feb 07, 2023 at 08:25:57AM +0100, Guru Mehar Rachaputi wrote:
> On Mon, Feb 06, 2023 at 10:43:56AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Feb 06, 2023 at 12:39:08AM +0100, Guru Mehar Rachaputi wrote:
> > > On Sun, Feb 05, 2023 at 08:12:31PM +0100, Christophe JAILLET wrote:
> > > > Le 05/02/2023 à 19:11, Guru Mehar Rachaputi a écrit :
> > > > > This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> > > > > as '(iobase)' to avoid precedence issues" changed to inline function. In
> > > > > relation to this, names of the callers of macro are also modified to call
> > > > > this function.
> > > > > 
> > > > > Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
> > > > 
> > > > Hi,
> > > > 
> > > > this patch should be v4.
> > > > You re-sent it with a modified commit message (the position of your S-o-b)
> > > > 
> > > > The idea behind patch versions is to help maintainer. With the way you did,
> > > > now 2 patches stating v3 are available.
> > > > Which one is the correct one?
> > > > The maintainer would need to look at both, search for differences, maybe
> > > > look at the date of the mails.
> > > > A v4 would be much easier for him.
> > > > 
> > > > 
> > > > Also, when you send an updated version of a patch, it should always be
> > > > "complete". I mean that the patch below seems to need v2, and maybe even v1
> > > > (which is apparently not on the linux-kernel mailing list).
> > > > 
> > > > A maintainer can't know by himself what is needed and what is not.
> > > > 
> > > > So you should resend a new patch.
> > > > It should be a v4, and it should include what is needed from (v1?), v2 and
> > > > v3 all together.
> > > > 
> > > > CJ
> > > > 
> > > > 
> > > > > ---
> > > > > Changes in v3:
> > > > > 	- Whitespace error from checkpatch fixed
> > > > > 
> > > > > Changes in v2:
> > > > > 	- Macros with one statement that is to call 'iowrite8' function changed
> > > > > 	to inline function as reviewed by gregkh@linuxfoundation.org.
> > > > > 	In relation to this, names of the callers of macro are also modified
> > > > > 	to call this function.
> > > > > ---
> > > > >   drivers/staging/vt6655/card.c    | 3 +--
> > > > >   drivers/staging/vt6655/channel.c | 2 +-
> > > > >   drivers/staging/vt6655/mac.h     | 4 ++--
> > > > >   3 files changed, 4 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
> > > > > index a6ff496b01b6..d2d122dc16d8 100644
> > > > > --- a/drivers/staging/vt6655/card.c
> > > > > +++ b/drivers/staging/vt6655/card.c
> > > > > @@ -643,8 +643,7 @@ void CARDvSetRSPINF(struct vnt_private *priv, u8 bb_type)
> > > > >   				   &byRsvTime);
> > > > >   	iowrite16(MAKEWORD(byTxRate, byRsvTime), priv->port_offset + MAC_REG_RSPINF_A_72);
> > > > >   	/* Set to Page0 */
> > > > > -        vt6655_mac_select_page0(priv->port_offset);
> > > > > -
> > > > > +	vt6655_mac_select_page0(priv->port_offset);
> > > > >   	spin_unlock_irqrestore(&priv->lock, flags);
> > > > >   }
> > > > > diff --git a/drivers/staging/vt6655/channel.c b/drivers/staging/vt6655/channel.c
> > > > > index e9a44bcebe32..60b445c38424 100644
> > > > > --- a/drivers/staging/vt6655/channel.c
> > > > > +++ b/drivers/staging/vt6655/channel.c
> > > > > @@ -121,7 +121,7 @@ bool set_channel(struct vnt_private *priv, struct ieee80211_channel *ch)
> > > > >   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWRCCK);
> > > > >   		RFbSetPower(priv, RATE_6M, priv->byCurrentCh);
> > > > >   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWROFDM);
> > > > > -	        vt6655_mac_select_page0(priv->port_offset);
> > > > > +		vt6655_mac_select_page0(priv->port_offset);
> > > > >   		spin_unlock_irqrestore(&priv->lock, flags);
> > > > >   	}
> > > > > diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h
> > > > > index b9a7ca0fe604..ae3064303691 100644
> > > > > --- a/drivers/staging/vt6655/mac.h
> > > > > +++ b/drivers/staging/vt6655/mac.h
> > > > > @@ -539,12 +539,12 @@
> > > > >   static inline void vt6655_mac_select_page0(void __iomem *iobase)
> > > > >   {
> > > > > -        iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> > > > > +	iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> > > > >   }
> > > > >   static inline void  vt6655_mac_select_page1(void __iomem *iobase)
> > > > >   {
> > > > > -        iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> > > > > +	iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> > > > >   }
> > > > >   #define MAKEWORD(lb, hb) \
> > > > 
> > > 
> > > Thanks for the explaination.
> > > Since I amended commit message and thought as there is no new commit it
> > > should still be the same patch.
> > > 
> > > Is it ok if I send a new patchset based on the previous conversations?
> > > I have four commits now, 4th commit being just the commit message and
> > > this patchset doesn't have s-o-b issue.
> > 
> > Look at other submissions on the mailing lists.  When you submit a new
> > version of a patch, it is stand-alone, with no dependancies on anything
> > else, otherwise tracking that would be impossible, right?
> > 
> > I suggest reading through the kernelnewbies.org "first patch submission"
> > tutorial first as I think it will answer questions like this.
> > 
> > good luck!
> > 
> > greg k-h
> 
> Thanks for taking time.
> 
> If my understanding is correct, every version of the patch should
> include all the patches/patchfiles and it should explain what happened in each
> version(in decrement order) through a coverletter. Please correct me otherwise.

I recommend reading the in-kernel documentation about all of this which
can be found at Documentation/process/submitting-patches.rst in the
kernel source tree.  That should explain all of this and is recommended
reading first if you have questions about how to create and submit a
patch.

If after reading that, you have specific questions, please let us know.

thanks,

greg k-h

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Tue, Feb 07, 2023 at 08:39:48AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 07, 2023 at 08:25:57AM +0100, Guru Mehar Rachaputi wrote:
> > On Mon, Feb 06, 2023 at 10:43:56AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Feb 06, 2023 at 12:39:08AM +0100, Guru Mehar Rachaputi wrote:
> > > > On Sun, Feb 05, 2023 at 08:12:31PM +0100, Christophe JAILLET wrote:
> > > > > Le 05/02/2023 à 19:11, Guru Mehar Rachaputi a écrit :
> > > > > > This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> > > > > > as '(iobase)' to avoid precedence issues" changed to inline function. In
> > > > > > relation to this, names of the callers of macro are also modified to call
> > > > > > this function.
> > > > > > 
> > > > > > Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > this patch should be v4.
> > > > > You re-sent it with a modified commit message (the position of your S-o-b)
> > > > > 
> > > > > The idea behind patch versions is to help maintainer. With the way you did,
> > > > > now 2 patches stating v3 are available.
> > > > > Which one is the correct one?
> > > > > The maintainer would need to look at both, search for differences, maybe
> > > > > look at the date of the mails.
> > > > > A v4 would be much easier for him.
> > > > > 
> > > > > 
> > > > > Also, when you send an updated version of a patch, it should always be
> > > > > "complete". I mean that the patch below seems to need v2, and maybe even v1
> > > > > (which is apparently not on the linux-kernel mailing list).
> > > > > 
> > > > > A maintainer can't know by himself what is needed and what is not.
> > > > > 
> > > > > So you should resend a new patch.
> > > > > It should be a v4, and it should include what is needed from (v1?), v2 and
> > > > > v3 all together.
> > > > > 
> > > > > CJ
> > > > > 
> > > > > 
> > > > > > ---
> > > > > > Changes in v3:
> > > > > > 	- Whitespace error from checkpatch fixed
> > > > > > 
> > > > > > Changes in v2:
> > > > > > 	- Macros with one statement that is to call 'iowrite8' function changed
> > > > > > 	to inline function as reviewed by gregkh@linuxfoundation.org.
> > > > > > 	In relation to this, names of the callers of macro are also modified
> > > > > > 	to call this function.
> > > > > > ---
> > > > > >   drivers/staging/vt6655/card.c    | 3 +--
> > > > > >   drivers/staging/vt6655/channel.c | 2 +-
> > > > > >   drivers/staging/vt6655/mac.h     | 4 ++--
> > > > > >   3 files changed, 4 insertions(+), 5 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
> > > > > > index a6ff496b01b6..d2d122dc16d8 100644
> > > > > > --- a/drivers/staging/vt6655/card.c
> > > > > > +++ b/drivers/staging/vt6655/card.c
> > > > > > @@ -643,8 +643,7 @@ void CARDvSetRSPINF(struct vnt_private *priv, u8 bb_type)
> > > > > >   				   &byRsvTime);
> > > > > >   	iowrite16(MAKEWORD(byTxRate, byRsvTime), priv->port_offset + MAC_REG_RSPINF_A_72);
> > > > > >   	/* Set to Page0 */
> > > > > > -        vt6655_mac_select_page0(priv->port_offset);
> > > > > > -
> > > > > > +	vt6655_mac_select_page0(priv->port_offset);
> > > > > >   	spin_unlock_irqrestore(&priv->lock, flags);
> > > > > >   }
> > > > > > diff --git a/drivers/staging/vt6655/channel.c b/drivers/staging/vt6655/channel.c
> > > > > > index e9a44bcebe32..60b445c38424 100644
> > > > > > --- a/drivers/staging/vt6655/channel.c
> > > > > > +++ b/drivers/staging/vt6655/channel.c
> > > > > > @@ -121,7 +121,7 @@ bool set_channel(struct vnt_private *priv, struct ieee80211_channel *ch)
> > > > > >   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWRCCK);
> > > > > >   		RFbSetPower(priv, RATE_6M, priv->byCurrentCh);
> > > > > >   		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWROFDM);
> > > > > > -	        vt6655_mac_select_page0(priv->port_offset);
> > > > > > +		vt6655_mac_select_page0(priv->port_offset);
> > > > > >   		spin_unlock_irqrestore(&priv->lock, flags);
> > > > > >   	}
> > > > > > diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h
> > > > > > index b9a7ca0fe604..ae3064303691 100644
> > > > > > --- a/drivers/staging/vt6655/mac.h
> > > > > > +++ b/drivers/staging/vt6655/mac.h
> > > > > > @@ -539,12 +539,12 @@
> > > > > >   static inline void vt6655_mac_select_page0(void __iomem *iobase)
> > > > > >   {
> > > > > > -        iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> > > > > > +	iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> > > > > >   }
> > > > > >   static inline void  vt6655_mac_select_page1(void __iomem *iobase)
> > > > > >   {
> > > > > > -        iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> > > > > > +	iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> > > > > >   }
> > > > > >   #define MAKEWORD(lb, hb) \
> > > > > 
> > > > 
> > > > Thanks for the explaination.
> > > > Since I amended commit message and thought as there is no new commit it
> > > > should still be the same patch.
> > > > 
> > > > Is it ok if I send a new patchset based on the previous conversations?
> > > > I have four commits now, 4th commit being just the commit message and
> > > > this patchset doesn't have s-o-b issue.
> > > 
> > > Look at other submissions on the mailing lists.  When you submit a new
> > > version of a patch, it is stand-alone, with no dependancies on anything
> > > else, otherwise tracking that would be impossible, right?
> > > 
> > > I suggest reading through the kernelnewbies.org "first patch submission"
> > > tutorial first as I think it will answer questions like this.
> > > 
> > > good luck!
> > > 
> > > greg k-h
> > 
> > Thanks for taking time.
> > 
> > If my understanding is correct, every version of the patch should
> > include all the patches/patchfiles and it should explain what happened in each
> > version(in decrement order) through a coverletter. Please correct me otherwise.
> 
> I recommend reading the in-kernel documentation about all of this which
> can be found at Documentation/process/submitting-patches.rst in the
> kernel source tree.  That should explain all of this and is recommended
> reading first if you have questions about how to create and submit a
> patch.
> 
> If after reading that, you have specific questions, please let us know.
> 
> thanks,
> 
> greg k-h
Thanks for the info, greg.
I will check it out and get back to you, incase.

-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Tue, Feb 07, 2023 at 01:49:15PM +0530, Deepak R Varma wrote:
> On Tue, Feb 07, 2023 at 08:25:57AM +0100, Guru Mehar Rachaputi wrote:
> > On Mon, Feb 06, 2023 at 10:43:56AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Feb 06, 2023 at 12:39:08AM +0100, Guru Mehar Rachaputi wrote:
> > > good luck!
> > > 
> > > greg k-h
> > 
> > Thanks for taking time.
> > 
> > If my understanding is correct, every version of the patch should
> > include all the patches/patchfiles and it should explain what happened in each
> > version(in decrement order) through a coverletter. Please correct me otherwise.
> 
> Hi Guru,
> Other than the cover letter, each individual patch should also include the patch
> version history in the descending order. If a specific patch(es) that is/are
> part of a patch-set, did not have any change, we should still increment its
> version and record "none" as the change in current version for such patches.
> 
> However, from the patch-set, any patches that are acked, do not need to be
> resent along with other patches that are still under revision. But do mentioned
> about such accepted/acked patches in the cover letter.
> 
> Hope this helps.
> 
> Thanks,
> deepak.
> 
> > 
> > I do refer "first patch submission" and above is my current
> > understanding.
> > 
> > -- 
> > Thanks & Regards,
> > Guru
> > 
> 
> 
Thanks for the info, deepak.
Is is possible for you to share some reference that is easy to
understand. It would be helpful.

-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Deepak R Varma]

On Tue, Feb 07, 2023 at 09:49:55AM +0100, Guru Mehar Rachaputi wrote:
> On Tue, Feb 07, 2023 at 01:49:15PM +0530, Deepak R Varma wrote:
> > On Tue, Feb 07, 2023 at 08:25:57AM +0100, Guru Mehar Rachaputi wrote:
> > > On Mon, Feb 06, 2023 at 10:43:56AM +0100, Greg Kroah-Hartman wrote:
> > > > On Mon, Feb 06, 2023 at 12:39:08AM +0100, Guru Mehar Rachaputi wrote:
> > > > good luck!
> > > > 
> > > > greg k-h
> > > 
> > > Thanks for taking time.
> > > 
> > > If my understanding is correct, every version of the patch should
> > > include all the patches/patchfiles and it should explain what happened in each
> > > version(in decrement order) through a coverletter. Please correct me otherwise.
> > 
> > Hi Guru,
> > Other than the cover letter, each individual patch should also include the patch
> > version history in the descending order. If a specific patch(es) that is/are
> > part of a patch-set, did not have any change, we should still increment its
> > version and record "none" as the change in current version for such patches.
> > 
> > However, from the patch-set, any patches that are acked, do not need to be
> > resent along with other patches that are still under revision. But do mentioned
> > about such accepted/acked patches in the cover letter.
> > 
> > Hope this helps.
> > 
> > Thanks,
> > deepak.
> > 
> > > 
> > > I do refer "first patch submission" and above is my current
> > > understanding.
> > > 
> > > -- 
> > > Thanks & Regards,
> > > Guru
> > > 
> > 
> > 
> Thanks for the info, deepak.
> Is is possible for you to share some reference that is easy to
> understand. It would be helpful.

Please read this: https://kernelnewbies.org/FirstKernelPatch#SubmitPatchSet

./drv

> 
> -- 
> Thanks & Regards,
> Guru
> 

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Tue, Feb 07, 2023 at 01:49:15PM +0530, Deepak R Varma wrote:
> On Tue, Feb 07, 2023 at 08:25:57AM +0100, Guru Mehar Rachaputi wrote:
> > On Mon, Feb 06, 2023 at 10:43:56AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Feb 06, 2023 at 12:39:08AM +0100, Guru Mehar Rachaputi wrote:
> > > good luck!
> > > 
> > > greg k-h
> > 
> > Thanks for taking time.
> > 
> > If my understanding is correct, every version of the patch should
> > include all the patches/patchfiles and it should explain what happened in each
> > version(in decrement order) through a coverletter. Please correct me otherwise.
> 
> Hi Guru,
> Other than the cover letter, each individual patch should also include the patch
> version history in the descending order. If a specific patch(es) that is/are
> part of a patch-set, did not have any change, we should still increment its
> version and record "none" as the change in current version for such patches.
> 
> However, from the patch-set, any patches that are acked, do not need to be
> resent along with other patches that are still under revision. But do mentioned
> about such accepted/acked patches in the cover letter.
> 
> Hope this helps.
> 
> Thanks,
> deepak.
> 
> > 
> > I do refer "first patch submission" and above is my current
> > understanding.
> > 
> > -- 
> > Thanks & Regards,
> > Guru
> > 
> 
> 

Hej Deepak,

I have a problem in sending patchset through mutt.
I have been trying sending to my own mail address but it won't work.

When sending patchset I think we should use "In-Reply-To" flag and
include "Message-ID" to which we want this to be in series to. I tried
both "git send-email" feature and mutt "forwarding feature".

Another issue is, how to attach patch file from inside mutt(for example: 
"mutt -H x.patch" from command line is used to extract header and body of a 
mail in mutt)?


-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Deepak R Varma]

On Mon, Mar 06, 2023 at 05:52:51AM +0100, Guru Mehar Rachaputi wrote:
> On Tue, Feb 07, 2023 at 01:49:15PM +0530, Deepak R Varma wrote:
> 
> Hej Deepak,
> 
> I have a problem in sending patchset through mutt.
> I have been trying sending to my own mail address but it won't work.

This could be because of mutt configuration. There are some additional checks if
you are trying to use mutt with gmail. Search over google or lore old posts to
know more about it. The important aspect is to configure and test mutt well
before you use it for sending out patches.

> 
> When sending patchset I think we should use "In-Reply-To" flag and
> include "Message-ID" to which we want this to be in series to. I tried
> both "git send-email" feature and mutt "forwarding feature".

I have not used "git send-email", so can't help you there. But mutt has worked
very well for me. Ensure you are reading and following the instructions from
this page well: https://kernelnewbies.org/Outreachyfirstpatch

> 
> Another issue is, how to attach patch file from inside mutt(for example: 
> "mutt -H x.patch" from command line is used to extract header and body of a 
> mail in mutt)?

Why do you want to do that?
Build a patch file using "git format-patch" and then use "mutt -H" to send the
patch. Both the commands work directly from the command line. If there is a need 
for any additional attachments in support of your patch [configs, logs, trace as
evidence, test outcomes etc], you can attach those from within the "mutt -H"
execution context.

I suggest testing mutt well before you start sending any patches out by sending
the patches to yourself. Do not use any kernel mailing list for testing.


Regards,
Deepak.

> 
> 
> -- 
> Thanks & Regards,
> Guru
> 

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Mon, Mar 06, 2023 at 11:06:06AM +0530, Deepak R Varma wrote:
> On Mon, Mar 06, 2023 at 05:52:51AM +0100, Guru Mehar Rachaputi wrote:
> > On Tue, Feb 07, 2023 at 01:49:15PM +0530, Deepak R Varma wrote:
> > 
> > Hej Deepak,
> > 
> > I have a problem in sending patchset through mutt.
> > I have been trying sending to my own mail address but it won't work.
> 
> This could be because of mutt configuration. There are some additional checks if
> you are trying to use mutt with gmail. Search over google or lore old posts to
> know more about it. The important aspect is to configure and test mutt well
> before you use it for sending out patches.
> 
> > 
> > When sending patchset I think we should use "In-Reply-To" flag and
> > include "Message-ID" to which we want this to be in series to. I tried
> > both "git send-email" feature and mutt "forwarding feature".
> 
> I have not used "git send-email", so can't help you there. But mutt has worked
> very well for me. Ensure you are reading and following the instructions from
> this page well: https://kernelnewbies.org/Outreachyfirstpatch
>

So for example from these patches: 0.patch, 1.patch
how to use "mutt -H" to send patches in one thread?

if first one is: mutt -H 0.patch
then should second one be: mutt -H 1.patch In-Reply-To: Message-ID?


> > 
> > Another issue is, how to attach patch file from inside mutt(for example: 
> > "mutt -H x.patch" from command line is used to extract header and body of a 
> > mail in mutt)?
> 
> Why do you want to do that?
> Build a patch file using "git format-patch" and then use "mutt -H" to send the
> patch. Both the commands work directly from the command line. If there is a need 
> for any additional attachments in support of your patch [configs, logs, trace as
> evidence, test outcomes etc], you can attach those from within the "mutt -H"
> execution context.
> 
> I suggest testing mutt well before you start sending any patches out by sending
> the patches to yourself. Do not use any kernel mailing list for testing.
> 
> 
> Regards,
> Deepak.
> 
> > 
> > 
> > -- 
> > Thanks & Regards,
> > Guru
> > 
> 
> 

-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Deepak R Varma]

On Mon, Mar 06, 2023 at 06:57:31AM +0100, Guru Mehar Rachaputi wrote:
> On Mon, Mar 06, 2023 at 11:06:06AM +0530, Deepak R Varma wrote:
> > On Mon, Mar 06, 2023 at 05:52:51AM +0100, Guru Mehar Rachaputi wrote:
> > > On Tue, Feb 07, 2023 at 01:49:15PM +0530, Deepak R Varma wrote:
> > > 
> > > Hej Deepak,
> > > 
> > > I have a problem in sending patchset through mutt.
> > > I have been trying sending to my own mail address but it won't work.
> > 
> > This could be because of mutt configuration. There are some additional checks if
> > you are trying to use mutt with gmail. Search over google or lore old posts to
> > know more about it. The important aspect is to configure and test mutt well
> > before you use it for sending out patches.
> > 
> > > 
> > > When sending patchset I think we should use "In-Reply-To" flag and
> > > include "Message-ID" to which we want this to be in series to. I tried
> > > both "git send-email" feature and mutt "forwarding feature".
> > 
> > I have not used "git send-email", so can't help you there. But mutt has worked
> > very well for me. Ensure you are reading and following the instructions from
> > this page well: https://kernelnewbies.org/Outreachyfirstpatch
> >
> 
> So for example from these patches: 0.patch, 1.patch
> how to use "mutt -H" to send patches in one thread?
> 
> if first one is: mutt -H 0.patch
> then should second one be: mutt -H 1.patch In-Reply-To: Message-ID?

Try this out by sending to yourself and you will know :)

There is a section "Using git format-patch to send patchsets" in the link I sent
in my last email. Please read that.

Deepak.

> 
> 
> > > 
> > > Another issue is, how to attach patch file from inside mutt(for example: 
> > > "mutt -H x.patch" from command line is used to extract header and body of a 
> > > mail in mutt)?
> > 
> > Why do you want to do that?
> > Build a patch file using "git format-patch" and then use "mutt -H" to send the
> > patch. Both the commands work directly from the command line. If there is a need 
> > for any additional attachments in support of your patch [configs, logs, trace as
> > evidence, test outcomes etc], you can attach those from within the "mutt -H"
> > execution context.
> > 
> > I suggest testing mutt well before you start sending any patches out by sending
> > the patches to yourself. Do not use any kernel mailing list for testing.
> > 
> > 
> > Regards,
> > Deepak.
> > 
> > > 
> > > 
> > > -- 
> > > Thanks & Regards,
> > > Guru
> > > 
> > 
> > 
> 
> -- 
> Thanks & Regards,
> Guru
> 

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Mon, Mar 06, 2023 at 12:30:35PM +0530, Deepak R Varma wrote:
> On Mon, Mar 06, 2023 at 06:57:31AM +0100, Guru Mehar Rachaputi wrote:
> > On Mon, Mar 06, 2023 at 11:06:06AM +0530, Deepak R Varma wrote:
> > > On Mon, Mar 06, 2023 at 05:52:51AM +0100, Guru Mehar Rachaputi wrote:
> > > > On Tue, Feb 07, 2023 at 01:49:15PM +0530, Deepak R Varma wrote:
> > > > 
> > > > Hej Deepak,
> > > > 
> > > > I have a problem in sending patchset through mutt.
> > > > I have been trying sending to my own mail address but it won't work.
> > > 
> > > This could be because of mutt configuration. There are some additional checks if
> > > you are trying to use mutt with gmail. Search over google or lore old posts to
> > > know more about it. The important aspect is to configure and test mutt well
> > > before you use it for sending out patches.
> > > 
> > > > 
> > > > When sending patchset I think we should use "In-Reply-To" flag and
> > > > include "Message-ID" to which we want this to be in series to. I tried
> > > > both "git send-email" feature and mutt "forwarding feature".
> > > 
> > > I have not used "git send-email", so can't help you there. But mutt has worked
> > > very well for me. Ensure you are reading and following the instructions from
> > > this page well: https://kernelnewbies.org/Outreachyfirstpatch
> > >
> > 
> > So for example from these patches: 0.patch, 1.patch
> > how to use "mutt -H" to send patches in one thread?
> > 
> > if first one is: mutt -H 0.patch
> > then should second one be: mutt -H 1.patch In-Reply-To: Message-ID?
> 
> Try this out by sending to yourself and you will know :)
> 
> There is a section "Using git format-patch to send patchsets" in the link I sent
> in my last email. Please read that.
> 
> Deepak.
>

I tried it and it won't work.
My question itself was how to use mutt to send patchset? which is not
clear on the site.

I have no problem in sending one single patch through mutt.

To be more clear:
https://lore.kernel.org/lkml/cover.1666299151.git.drv@mailo.com/
at above link, you submitted patchset.

How to send this series using mutt?
If I use "mutt -H x.patch" for every patch file they are seperate emails
in my inbox.

> > 
> > 
> > > > 
> > > > Another issue is, how to attach patch file from inside mutt(for example: 
> > > > "mutt -H x.patch" from command line is used to extract header and body of a 
> > > > mail in mutt)?
> > > 
> > > Why do you want to do that?
> > > Build a patch file using "git format-patch" and then use "mutt -H" to send the
> > > patch. Both the commands work directly from the command line. If there is a need 
> > > for any additional attachments in support of your patch [configs, logs, trace as
> > > evidence, test outcomes etc], you can attach those from within the "mutt -H"
> > > execution context.
> > > 
> > > I suggest testing mutt well before you start sending any patches out by sending
> > > the patches to yourself. Do not use any kernel mailing list for testing.
> > > 
> > > 
> > > Regards,
> > > Deepak.
> > > 
> > > > 
> > > > 
> > > > -- 
> > > > Thanks & Regards,
> > > > Guru
> > > > 
> > > 
> > > 
> > 
> > -- 
> > Thanks & Regards,
> > Guru
> > 
> 
> 

-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Mon, Mar 06, 2023 at 02:01:10PM +0530, Deepak R Varma wrote:
> On Mon, Mar 06, 2023 at 08:48:52AM +0100, Guru Mehar Rachaputi wrote:
> > On Mon, Mar 06, 2023 at 12:30:35PM +0530, Deepak R Varma wrote:
> > > On Mon, Mar 06, 2023 at 06:57:31AM +0100, Guru Mehar Rachaputi wrote:
> > > > On Mon, Mar 06, 2023 at 11:06:06AM +0530, Deepak R Varma wrote:
> > > > > On Mon, Mar 06, 2023 at 05:52:51AM +0100, Guru Mehar Rachaputi wrote:
> > > > > > On Tue, Feb 07, 2023 at 01:49:15PM +0530, Deepak R Varma wrote:
> > > > > > 
> > > > > > Hej Deepak,
> > > > > > 
> > > > > > I have a problem in sending patchset through mutt.
> > > > > > I have been trying sending to my own mail address but it won't work.
> > > > > 
> > > > > This could be because of mutt configuration. There are some additional checks if
> > > > > you are trying to use mutt with gmail. Search over google or lore old posts to
> > > > > know more about it. The important aspect is to configure and test mutt well
> > > > > before you use it for sending out patches.
> > > > > 
> > > > > > 
> > > > > > When sending patchset I think we should use "In-Reply-To" flag and
> > > > > > include "Message-ID" to which we want this to be in series to. I tried
> > > > > > both "git send-email" feature and mutt "forwarding feature".
> > > > > 
> > > > > I have not used "git send-email", so can't help you there. But mutt has worked
> > > > > very well for me. Ensure you are reading and following the instructions from
> > > > > this page well: https://kernelnewbies.org/Outreachyfirstpatch
> > > > >
> > > > 
> > > > So for example from these patches: 0.patch, 1.patch
> > > > how to use "mutt -H" to send patches in one thread?
> > > > 
> > > > if first one is: mutt -H 0.patch
> > > > then should second one be: mutt -H 1.patch In-Reply-To: Message-ID?
> > > 
> > > Try this out by sending to yourself and you will know :)
> > > 
> > > There is a section "Using git format-patch to send patchsets" in the link I sent
> > > in my last email. Please read that.
> > > 
> > > Deepak.
> > >
> > 
> > I tried it and it won't work.
> > My question itself was how to use mutt to send patchset? which is not
> > clear on the site.
> > 
> > I have no problem in sending one single patch through mutt.
> > 
> > To be more clear:
> > https://lore.kernel.org/lkml/cover.1666299151.git.drv@mailo.com/
> > at above link, you submitted patchset.
> > 
> > How to send this series using mutt?
> > If I use "mutt -H x.patch" for every patch file they are seperate emails
> > in my inbox.
> 
> The following command creates cover letter and patches as a threads
> 
> git format-patch -o /tmp/ --cover-letter -n --thread=shallow commitIDx^..commitIDy
> 
> Send cover-letter and patches with mutt -H XXXXX command
> 
> Note: Cover letter us optional. If you do not have one, the patches will still
> be threaded.
> 
> HTH
> Deepak.
> 
>
I get it now, thank you deepak :)
> 
> 
> > 
> > > > 
> > > > 
> > > > > > 
> > > > > > Another issue is, how to attach patch file from inside mutt(for example: 
> > > > > > "mutt -H x.patch" from command line is used to extract header and body of a 
> > > > > > mail in mutt)?
> > > > > 
> > > > > Why do you want to do that?
> > > > > Build a patch file using "git format-patch" and then use "mutt -H" to send the
> > > > > patch. Both the commands work directly from the command line. If there is a need 
> > > > > for any additional attachments in support of your patch [configs, logs, trace as
> > > > > evidence, test outcomes etc], you can attach those from within the "mutt -H"
> > > > > execution context.
> > > > > 
> > > > > I suggest testing mutt well before you start sending any patches out by sending
> > > > > the patches to yourself. Do not use any kernel mailing list for testing.
> > > > > 
> > > > > 
> > > > > Regards,
> > > > > Deepak.
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > -- 
> > > > > > Thanks & Regards,
> > > > > > Guru
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > -- 
> > > > Thanks & Regards,
> > > > Guru
> > > > 
> > > 
> > > 
> > 
> > -- 
> > Thanks & Regards,
> > Guru
> > 
> 
> 

-- 
Thanks & Regards,
Guru

[PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
as '(iobase)' to avoid precedence issues"

---
Changes in v3:
	- Whitespace error from checkpatch fixed

Changes in v2:
	- Macros with one statement that is to call 'iowrite8' function changed
	to inline function as reviewed by gregkh@linuxfoundation.org.
	In relation to this, names of the callers of macro are also modified
	to call this function.

Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
---
 drivers/staging/vt6655/card.c    | 3 +--
 drivers/staging/vt6655/channel.c | 2 +-
 drivers/staging/vt6655/mac.h     | 4 ++--
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
index a6ff496b01b6..d2d122dc16d8 100644
--- a/drivers/staging/vt6655/card.c
+++ b/drivers/staging/vt6655/card.c
@@ -643,8 +643,7 @@ void CARDvSetRSPINF(struct vnt_private *priv, u8 bb_type)
 				   &byRsvTime);
 	iowrite16(MAKEWORD(byTxRate, byRsvTime), priv->port_offset + MAC_REG_RSPINF_A_72);
 	/* Set to Page0 */
-        vt6655_mac_select_page0(priv->port_offset);
-
+	vt6655_mac_select_page0(priv->port_offset);
 
 	spin_unlock_irqrestore(&priv->lock, flags);
 }
diff --git a/drivers/staging/vt6655/channel.c b/drivers/staging/vt6655/channel.c
index e9a44bcebe32..60b445c38424 100644
--- a/drivers/staging/vt6655/channel.c
+++ b/drivers/staging/vt6655/channel.c
@@ -121,7 +121,7 @@ bool set_channel(struct vnt_private *priv, struct ieee80211_channel *ch)
 		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWRCCK);
 		RFbSetPower(priv, RATE_6M, priv->byCurrentCh);
 		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWROFDM);
-	        vt6655_mac_select_page0(priv->port_offset);
+		vt6655_mac_select_page0(priv->port_offset);
 
 		spin_unlock_irqrestore(&priv->lock, flags);
 	}
diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h
index b9a7ca0fe604..ae3064303691 100644
--- a/drivers/staging/vt6655/mac.h
+++ b/drivers/staging/vt6655/mac.h
@@ -539,12 +539,12 @@
 
 static inline void vt6655_mac_select_page0(void __iomem *iobase)
 {
-        iowrite8(0, iobase + MAC_REG_PAGE1SEL);
+	iowrite8(0, iobase + MAC_REG_PAGE1SEL);
 }
 
 static inline void  vt6655_mac_select_page1(void __iomem *iobase)
 {
-        iowrite8(1, iobase + MAC_REG_PAGE1SEL);
+	iowrite8(1, iobase + MAC_REG_PAGE1SEL);
 }
 
 #define MAKEWORD(lb, hb) \
-- 
2.34.1


-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Greg Kroah-Hartman]

On Sun, Feb 05, 2023 at 02:08:02PM +0100, Guru Mehar Rachaputi wrote:
> This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> as '(iobase)' to avoid precedence issues"
> 
> ---
> Changes in v3:
> 	- Whitespace error from checkpatch fixed
> 
> Changes in v2:
> 	- Macros with one statement that is to call 'iowrite8' function changed
> 	to inline function as reviewed by gregkh@linuxfoundation.org.
> 	In relation to this, names of the callers of macro are also modified
> 	to call this function.
> 
> Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>

Try to take this patch and apply it to a tree, and see that everything
below the --- line is thrown away, including your signed-off-by: line :(

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Sun, Feb 05, 2023 at 02:16:07PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Feb 05, 2023 at 02:08:02PM +0100, Guru Mehar Rachaputi wrote:
> > This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> > as '(iobase)' to avoid precedence issues"
> > 
> > ---
> > Changes in v3:
> > 	- Whitespace error from checkpatch fixed
> > 
> > Changes in v2:
> > 	- Macros with one statement that is to call 'iowrite8' function changed
> > 	to inline function as reviewed by gregkh@linuxfoundation.org.
> > 	In relation to this, names of the callers of macro are also modified
> > 	to call this function.
> > 
> > Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
> 
> Try to take this patch and apply it to a tree, and see that everything
> below the --- line is thrown away, including your signed-off-by: line :(
> 
Sorry, should not a patch contain signed-off-by: line?
I did not understand.

-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Nam Cao]

On Sun, Feb 05, 2023 at 02:30:59PM +0100, Guru Mehar Rachaputi wrote:
> On Sun, Feb 05, 2023 at 02:16:07PM +0100, Greg Kroah-Hartman wrote:
> > On Sun, Feb 05, 2023 at 02:08:02PM +0100, Guru Mehar Rachaputi wrote:
> > > This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> > > as '(iobase)' to avoid precedence issues"
> > > 
> > > ---
> > > Changes in v3:
> > > 	- Whitespace error from checkpatch fixed
> > > 
> > > Changes in v2:
> > > 	- Macros with one statement that is to call 'iowrite8' function changed
> > > 	to inline function as reviewed by gregkh@linuxfoundation.org.
> > > 	In relation to this, names of the callers of macro are also modified
> > > 	to call this function.
> > > 
> > > Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
> > 
> > Try to take this patch and apply it to a tree, and see that everything
> > below the --- line is thrown away, including your signed-off-by: line :(
> > 
> Sorry, should not a patch contain signed-off-by: line?
> I did not understand.

Patches must include signed-off-by. However your patch has it below the
--- line, and git will throw it away. You can try "git am <your patch>"
and see for yourself.

Best regards,
Nam

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Sun, Feb 05, 2023 at 04:34:29PM +0100, Nam Cao wrote:
> On Sun, Feb 05, 2023 at 02:30:59PM +0100, Guru Mehar Rachaputi wrote:
> > On Sun, Feb 05, 2023 at 02:16:07PM +0100, Greg Kroah-Hartman wrote:
> > > On Sun, Feb 05, 2023 at 02:08:02PM +0100, Guru Mehar Rachaputi wrote:
> > > > This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> > > > as '(iobase)' to avoid precedence issues"
> > > > 
> > > > ---
> > > > Changes in v3:
> > > > 	- Whitespace error from checkpatch fixed
> > > > 
> > > > Changes in v2:
> > > > 	- Macros with one statement that is to call 'iowrite8' function changed
> > > > 	to inline function as reviewed by gregkh@linuxfoundation.org.
> > > > 	In relation to this, names of the callers of macro are also modified
> > > > 	to call this function.
> > > > 
> > > > Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
> > > 
> > > Try to take this patch and apply it to a tree, and see that everything
> > > below the --- line is thrown away, including your signed-off-by: line :(
> > > 
> > Sorry, should not a patch contain signed-off-by: line?
> > I did not understand.
> 
> Patches must include signed-off-by. However your patch has it below the
> --- line, and git will throw it away. You can try "git am <your patch>"
> and see for yourself.
> 
> Best regards,
> Nam
Oh I see. Thanks for that. I changed it now.

-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Guru Mehar Rachaputi]

On Sun, Feb 05, 2023 at 04:34:29PM +0100, Nam Cao wrote:
> On Sun, Feb 05, 2023 at 02:30:59PM +0100, Guru Mehar Rachaputi wrote:
> > On Sun, Feb 05, 2023 at 02:16:07PM +0100, Greg Kroah-Hartman wrote:
> > > On Sun, Feb 05, 2023 at 02:08:02PM +0100, Guru Mehar Rachaputi wrote:
> > > > This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> > > > as '(iobase)' to avoid precedence issues"
> > > > 
> > > > ---
> > > > Changes in v3:
> > > > 	- Whitespace error from checkpatch fixed
> > > > 
> > > > Changes in v2:
> > > > 	- Macros with one statement that is to call 'iowrite8' function changed
> > > > 	to inline function as reviewed by gregkh@linuxfoundation.org.
> > > > 	In relation to this, names of the callers of macro are also modified
> > > > 	to call this function.
> > > > 
> > > > Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
> > > 
> > > Try to take this patch and apply it to a tree, and see that everything
> > > below the --- line is thrown away, including your signed-off-by: line :(
> > > 
> > Sorry, should not a patch contain signed-off-by: line?
> > I did not understand.
> 
> Patches must include signed-off-by. However your patch has it below the
> --- line, and git will throw it away. You can try "git am <your patch>"
> and see for yourself.
> 
> Best regards,
> Nam
I made my current working branch track origin/staging-testing and
modified the commit message and sent the patch again. I hope there won't
be any issue.

-- 
Thanks & Regards,
Guru

Re: [PATCH v3] staging: vt6655: Macro with braces issue change to inline function

[Greg Kroah-Hartman]

On Sun, Feb 05, 2023 at 02:08:02PM +0100, Guru Mehar Rachaputi wrote:
> This patch is to fix checkpatch warning: "Macro argument 'iobase' may be better
> as '(iobase)' to avoid precedence issues"
> 
> ---
> Changes in v3:
> 	- Whitespace error from checkpatch fixed
> 
> Changes in v2:
> 	- Macros with one statement that is to call 'iowrite8' function changed
> 	to inline function as reviewed by gregkh@linuxfoundation.org.
> 	In relation to this, names of the callers of macro are also modified
> 	to call this function.
> 
> Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@gmail.com>
> ---
>  drivers/staging/vt6655/card.c    | 3 +--
>  drivers/staging/vt6655/channel.c | 2 +-
>  drivers/staging/vt6655/mac.h     | 4 ++--
>  3 files changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
> index a6ff496b01b6..d2d122dc16d8 100644
> --- a/drivers/staging/vt6655/card.c
> +++ b/drivers/staging/vt6655/card.c
> @@ -643,8 +643,7 @@ void CARDvSetRSPINF(struct vnt_private *priv, u8 bb_type)
>  				   &byRsvTime);
>  	iowrite16(MAKEWORD(byTxRate, byRsvTime), priv->port_offset + MAC_REG_RSPINF_A_72);
>  	/* Set to Page0 */
> -        vt6655_mac_select_page0(priv->port_offset);
> -
> +	vt6655_mac_select_page0(priv->port_offset);
>  
>  	spin_unlock_irqrestore(&priv->lock, flags);
>  }
> diff --git a/drivers/staging/vt6655/channel.c b/drivers/staging/vt6655/channel.c
> index e9a44bcebe32..60b445c38424 100644
> --- a/drivers/staging/vt6655/channel.c
> +++ b/drivers/staging/vt6655/channel.c
> @@ -121,7 +121,7 @@ bool set_channel(struct vnt_private *priv, struct ieee80211_channel *ch)
>  		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWRCCK);
>  		RFbSetPower(priv, RATE_6M, priv->byCurrentCh);
>  		iowrite8(priv->byCurPwr, priv->port_offset + MAC_REG_PWROFDM);
> -	        vt6655_mac_select_page0(priv->port_offset);
> +		vt6655_mac_select_page0(priv->port_offset);
>  
>  		spin_unlock_irqrestore(&priv->lock, flags);
>  	}
> diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h
> index b9a7ca0fe604..ae3064303691 100644
> --- a/drivers/staging/vt6655/mac.h
> +++ b/drivers/staging/vt6655/mac.h
> @@ -539,12 +539,12 @@
>  
>  static inline void vt6655_mac_select_page0(void __iomem *iobase)
>  {
> -        iowrite8(0, iobase + MAC_REG_PAGE1SEL);
> +	iowrite8(0, iobase + MAC_REG_PAGE1SEL);
>  }
>  
>  static inline void  vt6655_mac_select_page1(void __iomem *iobase)
>  {
> -        iowrite8(1, iobase + MAC_REG_PAGE1SEL);
> +	iowrite8(1, iobase + MAC_REG_PAGE1SEL);
>  }
>  
>  #define MAKEWORD(lb, hb) \
> -- 
> 2.34.1
> 
> 
> -- 
> Thanks & Regards,
> Guru
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch did not apply to any known trees that Greg is in control
  of.  Possibly this is because you made it against Linus's tree, not
  the linux-next tree, which is where all of the development for the
  next version of the kernel is at.  Please refresh your patch against
  the linux-next tree, or even better yet, the development tree
  specified in the MAINTAINERS file for the subsystem you are submitting
  a patch for, and resend it.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot