2023-06-05 06:06:06

by msmulski2

[permalink] [raw]
Subject: [PATCH net-next v7 0/1] net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393x

From: Michal Smulski <[email protected]>

Changelist:
* do not enable USXGMII for 6361 chips
* track state->an_complete with state->link

*** BLURB HERE ***

Michal Smulski (1):
net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393x

drivers/net/dsa/mv88e6xxx/chip.c | 3 +-
drivers/net/dsa/mv88e6xxx/port.c | 3 ++
drivers/net/dsa/mv88e6xxx/serdes.c | 47 ++++++++++++++++++++++++++++--
drivers/net/dsa/mv88e6xxx/serdes.h | 4 +++
4 files changed, 53 insertions(+), 4 deletions(-)

--
2.34.1



2023-06-05 13:09:08

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next v7 0/1] net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393x

On Sun, Jun 04, 2023 at 10:39:53PM -0700, [email protected] wrote:
> From: Michal Smulski <[email protected]>
>
> Changelist:
> * do not enable USXGMII for 6361 chips
> * track state->an_complete with state->link
>
> *** BLURB HERE ***

Hi Michal

Please remember to remove the *** BLURB HERE ***. What often happens
is that a branch is created for a patchset, and then the branch is
merged and the content of patch 0/X is used as the merge commit
message. So this can end up in the git history.

For a single patch, you are not required to have a patch 0/X.

Andrew

2023-06-05 16:51:02

by Michal Smulski

[permalink] [raw]
Subject: RE: [PATCH net-next v7 0/1] net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393x

Andrew,

I will remove this line and resend v7. This was a mistake on my part. However, could you clarify on what is the best way to let reviewers know what changed between different version of the same patch? It seemed to me that changlist should not be part of the git commit message and hence I decided to add 'cover-letter' email for each new version of the patch so that it would not be part of the applied patch to net-next git repo (but it would also be easy to match changelist email with patch email to people reviewing latest patch)

Thank you,
Michal

-----Original Message-----
From: Andrew Lunn <[email protected]>
Sent: Monday, June 5, 2023 5:42 AM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Michal Smulski <[email protected]>
Subject: Re: [PATCH net-next v7 0/1] net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393x

CAUTION: This email is originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On Sun, Jun 04, 2023 at 10:39:53PM -0700, [email protected] wrote:
> From: Michal Smulski <[email protected]>
>
> Changelist:
> * do not enable USXGMII for 6361 chips
> * track state->an_complete with state->link
>
> *** BLURB HERE ***

Hi Michal

Please remember to remove the *** BLURB HERE ***. What often happens is that a branch is created for a patchset, and then the branch is merged and the content of patch 0/X is used as the merge commit message. So this can end up in the git history.

For a single patch, you are not required to have a patch 0/X.

Andrew

2023-06-05 17:10:06

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next v7 0/1] net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393x

On Mon, Jun 05, 2023 at 04:32:03PM +0000, Michal Smulski wrote:
> Andrew,
>

> I will remove this line and resend v7. This was a mistake on my
> part. However, could you clarify on what is the best way to let
> reviewers know what changed between different version of the same
> patch? It seemed to me that changlist should not be part of the git
> commit message and hence I decided to add 'cover-letter' email for
> each new version of the patch so that it would not be part of the
> applied patch to net-next git repo (but it would also be easy to
> match changelist email with patch email to people reviewing latest
> patch)

Some people think the history is actually useful, it shows what has
been considered etc and the patch matured.

However, anything text after the --- marker in a patch will get
discarded by git am when the patch is merged. So you can place the
history there.

Andrew