From: Dan Carpenter <error27@gmail.com>
To: Ki-Seok Jo <kiseok.jo@irondevice.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Mark Brown <broonie@kernel.org>,
Application <application@irondevice.com>,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH 14/14] Fixed the retry_cnt bug about being zero
Date: Mon, 9 Jan 2023 11:17:33 +0300 [thread overview]
Message-ID: <Y7vNna94IE6EnIZ1@kadam> (raw)
In-Reply-To: <SLXP216MB00778F6F7D99B56DDFBF603C8CFE9@SLXP216MB0077.KORP216.PROD.OUTLOOK.COM>
On Mon, Jan 09, 2023 at 07:33:19AM +0000, Ki-Seok Jo wrote:
>
> >On Fri, Jan 06, 2023 at 09:55:43AM +0000, Ki-Seok Jo wrote:
> > >
> > > Hi Dan,
> > >
> > > I'm sorry. There was an opinion that the pach sent last time was inconvenient to look at because the entire patch aws modified at once.
> > >
>
> > What you should have done was just fold everything into two patches:
> > patch 1: add the driver
> > patch 2: add the device tree bindings
>
> > Instead you did:
> > patch 1: add the driver
> > patch 2: add the device tree bindings
> > patch 3: re-write all of patch 1.
>
> > Re-writing everything is not allowed, but it's also not necessary. And also it is against the rules to submit broken code and fix it later.
>
> > It's a new driver so just fix patch 1 and resend that as a v2 patch.
> > Same for the stuff I mentioned in my bug report.
>
> > https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/
>
> > regards,
> > dan carpenter
>
>
> Thank you for your kindly advise. I read your report and it was very helpful.
> As I understand, I already sent it the wrong way. So I want to pick up the pieces.
>
> First, I already sent the new driver code a few months ago.
> After that, I got several feedbacks.
> I've edit and test it. So a lot of things changed at once.
>
> Since I changed so many things, I didn't know what to do, so I just updated it as a patch.
> It's my mistake...
>
> So I already sent about patch 1 and 2, if I get the feedback, should I send a lot of changes as v2 patch?(not patch 3)
> For each change, should I send patch log per commit?
>
> Like that:
> Patch 1: add the driver
> Patch 2: add the device tree bindings
>
> (instead patch 3)
> + Patch v2 1: change 1 about feedback1
> + Patch v2 2: change 2 about feedback1
> + ...
> + Patch v2 10: change 3 about feedback1
>
> Is it right?
No.
>
> Or should I revise it again and send it again from v2 patch 1?
> (It's not registered with the kernel source yet..)
> Patch v2 1: add the driver (applied the feedback)
> Patch v2 2: add the device tree bindings
>
Yes. Revise again and resend everything as two patches.
regards,
dan carpenter
next prev parent reply other threads:[~2023-01-09 8:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-06 9:15 [PATCH 00/14] ASoC: Add a driver the Iron Device SMA1303 AMP Kiseok Jo
2023-01-06 9:15 ` [PATCH 01/14] ASoC: sma1303: Add driver for Iron Device SMA1303 Amp Kiseok Jo
2023-01-06 9:15 ` [PATCH 02/14] ASoC: dt-bindings: sma1303: " Kiseok Jo
2023-01-06 9:15 ` [PATCH 03/14] Add the i2c-retry count and callback function in regmap function Kiseok Jo
2023-01-06 9:15 ` [PATCH 04/14] Removed the usage control and add the power switch on DAPM route Kiseok Jo
2023-01-06 13:59 ` Mark Brown
2023-01-09 9:33 ` Ki-Seok Jo
2023-01-06 9:15 ` [PATCH 05/14] Change the DAPM route and widgets Kiseok Jo
2023-01-06 9:15 ` [PATCH 06/14] Use the prefixs all definitions Kiseok Jo
2023-01-06 9:15 ` [PATCH 07/14] Remove the control of output format Kiseok Jo
2023-01-06 9:15 ` [PATCH 08/14] Remove the mute control Kiseok Jo
2023-01-06 9:15 ` [PATCH 09/14] Add the prefix for component controls Kiseok Jo
2023-01-06 9:15 ` [PATCH 10/14] Remove the shutdown and startup when set PLL Kiseok Jo
2023-01-06 9:15 ` [PATCH 11/14] Delete the header file of "linux/version.h" Kiseok Jo
2023-01-06 9:15 ` [PATCH 12/14] Add the postscaler's switch in DAPM manage Kiseok Jo
2023-01-06 9:15 ` [PATCH 13/14] Move the initial settings to i2c driver probe Kiseok Jo
2023-01-06 9:15 ` [PATCH 14/14] Fixed the retry_cnt bug about being zero Kiseok Jo
2023-01-06 9:27 ` Dan Carpenter
2023-01-06 9:30 ` Dan Carpenter
2023-01-06 9:59 ` Ki-Seok Jo
2023-01-06 9:55 ` Ki-Seok Jo
2023-01-06 10:16 ` Dan Carpenter
2023-01-07 12:37 ` Dan Carpenter
2023-01-09 7:33 ` Ki-Seok Jo
2023-01-09 8:17 ` Dan Carpenter [this message]
2023-01-09 8:35 ` Ki-Seok Jo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y7vNna94IE6EnIZ1@kadam \
--to=error27@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=application@irondevice.com \
--cc=broonie@kernel.org \
--cc=kiseok.jo@irondevice.com \
--cc=lkp@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.