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 <[email protected]>
---
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 [email protected].
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
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 <[email protected]>
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 [email protected].
> 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) \
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 <[email protected]>
>
> 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 [email protected].
> > 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
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 <[email protected]>
> >
> > 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 [email protected].
> > > 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
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 <[email protected]>
> > >
> > > 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 [email protected].
> > > > 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
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 <[email protected]>
> > > >
> > > > 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 [email protected].
> > > > > 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
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
>
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
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 <[email protected]>
> > > > >
> > > > > 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 [email protected].
> > > > > > 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
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
>
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
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
>
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
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
>
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/[email protected]/
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
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/[email protected]/
> 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.
>
> > >
> > >
> > > > >
> > > > > 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
>
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/[email protected]/
> > 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